Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to writeup argues large agent tool surfaces should collapse into a few domain routers with an action discriminator. The pattern is sound; the post ships no measurements.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
A developer writeup on dev.to sets out a pattern for shrinking sprawling agent tool surfaces: keep every capability, but expose three to five domain-oriented tools that route internally on an `action` field instead of thirty separately named ones [1][8]. The author's framing is the useful part, because the symptom looks like missing or confused capability and is actually a surface problem: the agent does not need fewer capabilities, it needs fewer top-level tools [4].
The cost has two components. First, context: an MCP server is not only an execution interface, it is also part of the model's prompt, since the model has to see tool names, descriptions, input schemas, parameters, enums and constraints [5]. Connect forty tools and even modest per-tool schemas aggregate into something significant [6]. Second, selection: the author points out that operations like `jira_search_issues`, `jira_search_projects`, `jira_get_issue`, `jira_get_issue_comments`, `jira_get_issue_transitions` and `jira_get_issue_worklogs` all live in one conceptual domain, and forcing the model to treat each as an independent top-level capability widens the decision space for no gain [7].
The fix is an intermediate discriminator. Rather than `jira_search`, you expose `jira`, called as `jira({ action: "search", ... })`, and the tool becomes a small router to the same handlers [8]. The author's formulation is worth keeping: the tool is the external interface, the action is the capability [9]. Implementation is a tagged union, in this case Zod's `z.discriminatedUnion("action", [...])` [13]. The database example is the concrete one: thirteen listed operations, from `listTables` and `getTableSchema` through `executeQuery`, `profileColumn` and `compareSchemas`, collapse into `db_tables`, `db_query` and `db_advanced` [12], a 77 percent cut in top-level tool count [15]. Applied to the headline case, three to five domain tools in place of thirty leaves 10 to 17 percent of the original surface [16].
The author is explicit that this is not arithmetic. Splitting thirty operations into ten-per-tool buckets misses the point; grouping should follow semantic domains, such as `jira` covering search, issue, comment, transition and project, or an `observability` tool covering search, trace, log and error [11][10]. There is no universal number, only the smallest surface that still holds clear semantic boundaries [14].
Two things to hold onto before you refactor. The portion of the article available carries no token counts, no latency numbers and no before-and-after task accuracy comparison [17], so treat the savings as structural rather than demonstrated. And the discriminator does not delete the selection problem, it relocates it: the action enum still has to be described somewhere in the schema, so the win comes from eliminating per-tool boilerplate and giving the model one obvious door per domain, not from hiding the branch.
What to watch in your own stack. Per-tool telemetry collapses when every Jira call is logged as `jira`, so log the action field before you migrate, not after. Check whether your client's approval or allowlist mechanism operates at tool granularity; if it does, a router is a coarser permission boundary than what you have now, and a read-only agent that could previously be handed `jira_search` alone now gets `createIssue` in the same union. And watch where invalid calls surface: with a tagged union they fail at schema parse rather than at a missing tool name, which is a better error only if you pass the parse failure back to the model in a form it can act on.
Ranked by verification strength, evidence, and original report placement.
The author argues that a large tool count first looks like a capability problem but is actually a tool-surface problem: the agent does not necessarily need fewer capabilities, it needs fewer top-level tools. The core idea is stated as "Consolidate the tool surface, not the capabilities."
The article states that an MCP server is not only an execution interface but also part of the model's context, and that when an agent connects to an MCP server the model generally needs to understand tool names, descriptions, input schemas, parameters, enums, constraints and sometimes additional metadata.
The author writes that for an agent connected to 40 tools, even if each tool has a relatively small schema, the aggregate context can become significant.
The article states that the tool is not the capability: the tool is the external interface and the action represents the capability.
Example groupings given are jira (search, issue, comment, transition, project), gitlab (project, issue, mergeRequest, pipeline) and observability (search, trace, log, error); alternative groupings offered include jira_issues/jira_projects/jira_search and gitlab_repository/gitlab_issues/gitlab_mergeRequests.
The author names as the easiest mistake the reasoning "I have 30 tools, so I will put 10 operations into each tool", and says grouping should instead follow semantic domains.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Coherent design argument, zero measurement
The mechanism is specified precisely enough to reproduce - action discriminator, Zod tagged union, switch dispatch, semantic domain grouping - and the numeric before/after counts are internally consistent. But every benefit claim (context savings, better tool selection) is asserted qualitatively: there are no token counts, no latency figures and no before/after accuracy comparison, and the text ends mid-example. One publisher, one author, no independent corroboration.
One self-reported practitioner use
The only adoption signal is the author's own statement that this is a pattern he has been using, with example groupings for Jira, GitLab and a database. No named deployment, no user or install counts, no MCP server release, and no third party reporting the pattern in production.
Titled 'token-efficient' without token data
The framing promises efficiency ('From 30 Tools to 3: Designing a Token-Efficient MCP Tool Surface') and the derived ratios read as dramatic reductions, yet the reduction is in exposed tool names only - capabilities and their schemas persist behind the action union - and no token, latency or accuracy measurement is offered. Modestly overstated rather than baseless: the underlying design claim is plausible and honestly hedged with 'there is no universal number'.
Individual author advocating own pattern
The visible incentive is authorial: a named individual publishing on dev.to promotes a pattern he reports using, which favours presenting it as clean and complete. No vendor, product, pricing, sponsorship or funding interest appears anywhere in the supplied text, and no commercial tool is being sold, so distortion pressure is low but non-zero.
Low: single unmeasured source
Confidence in this assessment is limited by structure, not ambiguity: one publisher, one author, one truncated article, no measurements and no corroboration. The descriptive claims about what the post says are high-certainty; any judgement about whether the pattern actually improves token use or tool-selection reliability is not supportable from this cluster.
build
The refund that fired three times: tool calls are a systems problem, not a prompt problem1 distinct publisher
build
The only gate that ran was a hand-typed enum, and it had never heard of the new value1 distinct publisher
build
Your first MCP workflow should be a draft queue, not an agent with keys to the inbox1 distinct publisher
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026