Most MCP servers get built by adding. Someone needs a lookup, so a tool goes in. Someone needs an update, so another goes in. Nobody comes back to remove anything.
If a workflow uses MCP, that pile of tools has two costs. Both shrink when you trim it.
The token cost
Every tool the server exposes has a name, a description and a parameter schema. The client typically loads those into the model's context so it can choose among them. More tools means more of that text, on every session, whether or not the tools are used.
I won't put a number on it, because it depends on the server and the client. You can measure your own. List the tools, count the tokens in the definitions, and compare that to the size of the task.
The access cost
Each tool is also something the agent can do. A reviewer looking at the server has to ask what each one reads, what it changes and who can trigger it. Twenty tools is twenty answers. Three tools is three.
A smaller surface is easier to review, easier to explain and easier to hand off.
An example (hypothetical)
Say a team wants an assistant that drafts replies to internal IT help requests, for a person to review before sending. The server was built broadly. It can search tickets, edit tickets, close tickets, reassign them, delete comments, and read the staff directory.
For this one workflow, the assistant needs two things:
- Read a single ticket by ID
- Save a draft reply that a person approves
That is the trimmed server. Closing, reassigning and deleting are gone, along with the broad directory read. The draft goes to a human, so a bad draft costs a few seconds of review, not a changed ticket.
How to trim
Start from the workflow, not the server. Write down the steps. Keep only the tools those steps need. Then check three things:
- Does each remaining tool do only one job, with read and write kept apart?
- Do the credentials behind it match the trimmed scope, or are they still the old broad ones?
- Can a person say, in a sentence, what the assistant can touch?
The second check matters most. Removing a tool from the list does not help if the token behind it can still do everything.
Keep it bounded
This is not an argument that every team needs an MCP audit. If your workflow does not use MCP, this does not apply. If it does, one bounded workflow is a good place to start. Internal and lower-risk work still involves privacy and security duties, and a smaller tool list is a cheap way to respect them.
We review this kind of thing one workflow at a time. The output is a short list of tools kept, tools removed and a note the next person can follow.
I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.
Top comments (0)