Segment spent 3 full-time engineers just keeping its software alive. Then it folded more than 140 separate services into one, and shipped 46 improvements to shared code the next year against 32 before [1][2][3]. The gap between those two counts is what an unneeded boundary costs, and it is the same bill a team takes on when it splits the tool layer for an agent.

Your team faces the same call at a smaller scale. Splitting a program into separate services means each piece gets its own release process and its own pager. So an agent runtime wired to a dozen Model Context Protocol (MCP) servers raises a plain question: how many pieces of the tool layer get their own release, and what does each one have to buy? MCP is an open standard for handing an AI assistant a set of tools.

The big picture:

The same trade has been priced from both ends. The two readings disagree in a way that matters. One team pulled five business tasks out of a twelve-year-old system of 280K lines of code and ran them as separate services. Their maintenance backlog then grew on a slope 89.76% smaller than the old single system’s [4][5]. The same paper records the bill: overall development cost rose by more than 20%, because a spread-out system costs more to build and run [4].

My read is that neither result proves the other wrong. Neither study asked whether small services are good. Both priced a split, one from the invoices and one from the interest on that mess.

Teams pick these cuts on two tests. When teams chose which part to pull out, the top test was whether it needed to scale on its own. That was named by 40 of 53 staff (75.5%). The top reason to split at all was easier upkeep and change, at 43 of 53 (81.1%) [6][7]. Scaling is a question about load. Upkeep is a question about time.

What I’d watch:

Four signals separate a split that earns its keep from one that only adds another release process. I look for them in every design review that crosses this desk.

  • Change cadence: a piece that always ships with everything else is a library wearing a network hop. The bill for that hop is the on-call rota behind it. Segment’s improvement count moved once a change to one shared library stopped needing 140+ releases [3].
  • Resource profile: combined, Segment’s outbound destinations scaled more easily. One large pool of workers soaked up spikes that the small, chatty services used to page on [1]. A split sold on its own scaling is a claim to test, not a starting point.
  • Discovery cost: every MCP server adds a tool list the model has to find before it can call anything. Anthropic’s own engineers put the saving from loading only what a task needs at 98.7%, in a fleet built from dozens of servers [9]. That is a vendor measuring its own set-up, so I read it as a direction rather than a test of your estate.
  • Where the seam lands: most surveyed teams cut along a business job rather than the old wiring [7]. Our earlier note on how many tools one agent can hold makes the same point from the other side, since a job-shaped seam usually fits inside one context window.

By the numbers

  • $407,940 — a year of engineers: three full-time staff at the 2025 median software wage of $135,980 each [8]. That is the wage line a needless split shows up on.
  • 50.9% — one service at a time: 27 of the 53 staff surveyed split work piece by piece rather than all at once [7]. It is the path that keeps a split easy to undo.
  • 52.8% — seams cut by business job: 28 of 53 teams chose the cut by what the service does for the business, not by how the old system was wired [7].
  • 98.7% — the vendor’s token cut: Anthropic reports token use for the tool list falling from 150,000 to 2,000 when only the needed ones load. That is a claim about its own set-up rather than an outside test [9].
Your Tool Boundary Costs 3 Engineers Figures as stated in this article's own numbers section (verified figures, %) one service at a time 50.9% ([7]) seams cut by business job 52.8% ([7]) the vendor's token cut 98.7% ([9])

The catch

The evidence is thinner than the trust in either camp, and three limits matter more than the two big results. The maintenance study tracks a single system, however well it was measured. One case with two teams, one language and one path of migration is a strong example of how it works and a weak guess at the size of the gain [4][5]. The survey covers 53 people, 41 of them working in Brazil, so it reports how one group works rather than a global rule of design [6][7].

Segment’s move also cost something the post names plainly. The small services had been a way to fence off faults and ship on their own, and folding them together traded that fence for speed [1]. My read is that this is the honest shape of the call. You are picking which fault you can live with, not removing one.

Neither source gives a break-even count, and I would distrust any piece that supplied one. The number of splits follows from how many scales and speeds a team truly runs. That is why the same design can fit one company and be pure overhead at the next.

At a glance

  • The Big Shift: Agent runtimes are being split into fleets of MCP servers, which turns a tool list into a set of separate services with release processes and on-call duties. It is the same call product teams had to re-open.
  • Why It Matters: A split that does not buy its own scale or its own speed of change is pure overhead. One case measured it at 3 full-time engineers, the other at a 20% cost rise.
  • What I’d Watch: where the next split lands, and whether anyone prices it before the release processes appear.
  • Change cadence: a piece whose code always ships with another team’s code is a library with a network hop.
  • Resource profile: whether the claimed need to scale is measured or assumed, since one large pool often soaks up the spikes.
  • Discovery cost: each new server adds tools the model must load before it can call anything.
  • The Catch: the strongest numbers come from a single case study and a small survey, and folding services together buys speed with the fault fence you gave up.

Related reading

Sources

[1] Segment Engineering, “Goodbye Microservices: From 100s of problem children to 1 superstar,” Alexandra Noonan, 10 July 2018. https://segment.com/blog/goodbye-microservices/ [2] Same post, on-call and velocity sections. https://segment.com/blog/goodbye-microservices/ [3] Same post, shared-library improvement count. https://segment.com/blog/goodbye-microservices/ [4] Lenarduzzi, Saarimäki and Taibi, “Does Migrating a Monolithic System to Microservices Decrease the Technical Debt?”, arXiv:1902.06282v3, 4 July 2020. https://arxiv.org/html/1902.06282v3 [5] Same paper, case description and scaling section. https://arxiv.org/html/1902.06282v3 [6] Nogueira, Felizardo, Amaral et al., “Insights on Microservice Architecture Through the Eyes of Industry Practitioners,” arXiv:2408.10434v1, 19 August 2024. https://arxiv.org/html/2408.10434v1 [7] Same paper, extraction criteria and migration process. https://arxiv.org/html/2408.10434v1 [8] O*NET OnLine, Software Developers (15-1252.00), 2025 median wages. https://www.onetonline.org/link/summary/15-1252.00 [9] Anthropic Engineering, “Code execution with MCP: Building more efficient agents,” 4 November 2025. https://www.anthropic.com/engineering/code-execution-with-mcp