Your MCP Server Doesn’t Need 50 Tools: Design a Tool Budget Before It Eats Your Context

Adding another MCP tool feels free.

It is not.

Each tool comes with a name, description, input schema, examples, and an implied decision: when should the agent use this instead of every other available tool? That material competes with the task, the repository, the user’s request, and the agent’s own plan for a finite place in context.

The usual response is to expose the whole catalog and hope the model sorts it out. The predictable results are familiar:

• a read task reaches for a write tool;
• the agent calls three near-duplicate tools before it starts work;
• an expensive search tool is used where a cheap lookup would do;
• a destructive tool is available long before a human has seen a plan;
• a tool list changes, but the workflow that relied on it was never re-tested.

The fix is not one giant do_everything tool. That only moves ambiguity from the tool list into a larger, less inspectable parameter schema.

The goal: give an agent enough capability to finish the next decision safely, not every capability it could conceivably need.

The hidden cost of a large tool list

MCP tools are not just functions on a server. Their definitions are part of the agent’s working environment. More tools means more text, more overlapping verbs, and more possible action paths.

That does not mean there is a universal safe number of tools. A two-tool server can still be dangerous, and a well-separated 20-tool server can be usable. The budget is about reducing unnecessary choice for a particular task mode.

Ask two questions for every tool:

1. What decision becomes impossible without this tool?
2. Can the agent safely defer this capability until a later stage?

If the answer to the first is vague and the second is yes, do not load it in the first stage.

Budget by workflow stage, not by server

The useful unit is not “how many tools does this MCP server expose?” It is “which tools can this agent see right now?”

Here is a conservative budget for a workflow that investigates, proposes, then changes deployment configuration:

This is a budget, not a protocol requirement. The important part is the direction: writes arrive late, narrowly, and with a verification path.

Example: a deploy workflow with five tools—not fifty

Instead of handing an agent a generic cloud account with every operation available, define the stage-specific surface:

OBSERVE
  get_service_status(service)
  get_recent_deploys(service)
  read_deploy_config(service)
  search_runbook(query)

PREPARE
  validate_deploy_plan(plan)
  preview_config_diff(service, proposed_config)

EXECUTE — after human approval
  apply_approved_deploy(change_id)
  get_service_status(service)

Notice what is absent: delete_service, arbitrary shell execution, account-wide secret enumeration, and five slightly different deployment actions. Those may belong to a separate, explicit workflow. They do not help an agent answer, “What is wrong with this deployment?”

Give each tool one job

Tool lists become unreliable when names overlap: search, find, query, lookup, get, and fetch can all mean nearly the same thing. A model should not have to infer operational policy from a marketing-style description.

For every visible tool, write a one-line contract:

tool: find_failed_deployments
use_when: "You need failed deployments for one named service and time range."
do_not_use_when: "You need logs, a configuration diff, or a deployment action."
returns: "Deployment ID, timestamp, status, and failure summary."
side_effects: none

Then test the contrast. Give the agent four small prompts:

1. A request that should invoke this tool.
2. A near miss that should invoke a different tool.
3. A request that must stop for missing input.
4. A request that must ask for approval rather than acting.

If two tools would both be plausible for the same prompt, remove, rename, or route one of them—not write a longer description for both.

Start from a workflow, not a tool catalog

This is also a useful filter when you are looking for a skill to install. Do not begin with “Which integration looks powerful?” Begin with the bounded job: triage a failed deploy, package a repeated runbook, audit a repository before a change.

The skill should make the workflow legible—trigger, allowed inputs, approval boundary, and a verifiable done condition—not quietly expand the agent’s reach.

Terminal Skills organizes skills around practical jobs, so it is a useful place to find a starting workflow. A catalog can help you discover a workflow; it should never replace validating one in your environment.

Safety annotations help—but they are not enforcement

MCP tool annotations can express whether a tool is read-only, destructive, idempotent, or reaches an open world. Use them. They make the workflow more legible and can drive better confirmation UX.

But they are hints from a server, not a security boundary. Keep the actual guardrails outside the model:

• the host enforces an allow-list for the current stage;
• approval binds to an exact change or plan, not a vague “yes, go ahead”;
• write operations accept idempotency keys or a change ID where possible;
• validation runs after the write using an independent read-back path;
• output from web pages, logs, tickets, and retrieved documents is treated as data—not instructions.

A low-risk tool can return hostile text. A harmless-looking action can become expensive or irreversible when repeated. The policy must be deterministic even when the agent is not.

A compact tool-budget review

Before you add a tool to a skill or agent workflow, fill in this scorecard:

TOOL: __________________________
STAGE: observe / prepare / execute / verify

[ ] It unlocks a named decision in this stage.
[ ] Its name and description are distinct from every visible alternative.
[ ] Its input schema rejects missing or dangerous ambiguity.
[ ] Its output has a small, documented shape.
[ ] We know whether it reads, writes, retries safely, or reaches external systems.
[ ] There is a negative test showing when the agent must not call it.
[ ] If it writes, the exact effect needs approval and has a read-back check.

Do not replace 50 tools with one opaque mega-tool

The common over-correction is a tool called manage_deployment, operate_database, or handle_customer. It sounds tidy until its schema contains every operation and every escape hatch.

A better consolidation rule:

• combine tools only when they share the same risk level, input shape, authorization rule, and success check;
• separate them when any one of those changes;
• prefer a small read tool plus a separate approved write tool over a “read-or-write depending on a flag” tool.

Test tool selection as a regression surface

Tool budgets decay. A new integration gets added. A description changes. An old alias remains for compatibility. A skill that once picked the right sequence begins to wander.

Keep a small fixture suite next to the workflow:

case: investigate failed deploy
expected_tools:
  - get_service_status
  - get_recent_deploys
forbidden_tools:
  - apply_approved_deploy
  - delete_service
done_when: "The agent cites a deployment ID and asks for missing evidence or proposes a plan."

case: apply approved config change
precondition: "approval token matches the displayed config diff"
expected_tools:
  - apply_approved_deploy
  - get_service_status
done_when: "The post-change status and config digest match the approved plan."

Start with the workflow’s expensive mistakes: a wrong write, an unnecessary external search, a missing approval, or a “done” claim with no evidence. Run those cases when the tool list, the skill instructions, or the host policy changes.

The smallest safe surface wins

An agent does not become capable because it can see every action your systems expose. It becomes dependable when each step has a constrained purpose, a clear boundary, and proof of completion.

Before adding your next MCP integration, do not ask only, “Can the agent call this?” Ask: “At which stage is this necessary—and what must be true before it is visible?”

Find a workflow you can actually govern. Browse practical agent use cases on Terminal Skills, then check the trigger, tool budget, approval boundary, and proof of completion before installing.

Further reading: MCP specification and the MCP changelog.