What 140+ MCP tools taught us

The number quoted about SalesCrew's MCP server is 145 registered tools. Nobody set that as a target. It is what happens when the rule is "every UI action gets an MCP twin with identical effect", and the UI already has contacts, companies, deals, an inbox, cadences, campaigns, approvals, agent controls, marketing queries, a knowledge base, an Upwork module, billing, webhooks and a fleet console. Each surface contributes its own handful of tools: create, update, list, search, and whatever domain-specific actions it needs, such as approval_approve or cadence_advance.

The alternative, which most products with an AI layer build first, is one general tool that accepts a natural-language instruction. An LLM inside the server decides what to do with it. That is faster to ship. It also leaves the permission system with nothing to hold on to. The scope of what an agent can touch lives inside a prompt, not inside a grant. Two agents with different intended access end up with the same tool and different instructions. That is a much weaker boundary.

Choosing one tool per action meant choosing the access model first. That model came from a decision already made for the UI: a three-axis scope, channel, Upwork profile and area, enforced by row-level security. Reusing it for MCP tokens means a token issued to an agent inherits the same restrictions a human teammate would have with the same scopes. That part took longest. Not the tool count.

With a handful of tools, you can review every call by hand while building. With 145, you cannot. You have to decide up front which actions an agent may take on its own and which need a person to see the artefact first. SalesCrew's answer is a default policy table, seeded per instance and editable in Agents → Guardrails. Research, enrichment, tagging, scoring, summaries and internal tasks default to auto. Classifying a reply, and suppressing on unsubscribe or bounce, default to auto too, because they read and react with no external side effect. Anything that leaves the building, an email, a LinkedIn message, an SMS, a marketplace proposal, defaults to review. Anything that spends money is human-only, with no mode that lets an agent do it unattended.

That policy table exists because a tool count in the hundreds makes "review every call" unworkable and "let every call run" unacceptable. The alternative most teams reach for is a single global on/off switch. It is too coarse. It cannot tell an agent tagging a contact from an agent emailing a prospect. A policy per action class can. That is why the tool inventory and the approval queue had to be designed together, rather than the queue being added after the tools existed.

The other forcing function was naming. With 145 tools, an ambiguous name costs real time. An agent, or a person reading the tool list, has to guess between contact_update and something that sounds similar but does something narrower. The tools follow one convention, noun_verb, consistently enough that an unfamiliar caller can predict a tool's name from what it needs to do. That matters more at 145 tools than at 15.

Every one of the 145 tools also has a UI twin with identical effect, so the manual path in the app never breaks when automation is turned off. That constraint, dual control, shapes the design before the AI question comes up. The tool schema has to mirror what a person can already do through a form or a button. It cannot invent a shortcut the UI does not offer.

If you are building an MCP surface for a system that already has an admin UI, the practical order is scope first, review policy second, tool count last. Decide the axes access will be scoped on: object type, team, client, or role. Decide which action classes run unattended and which queue, and write that policy down somewhere editable, not buried in an agent's system prompt. Only then build the tools. By that point each tool's schema, what it needs, what it returns, whether it queues, is already decided by the policy. Nothing is improvised per tool.

Every tool call in SalesCrew is also written to an audit log, with the actor recorded as a user, a token or an agent. That is the other piece that has to exist before the tool count grows past what a person can watch by hand. Once 145 tools run against real client data, the audit log is what answers "what changed, and who or what changed it". It has to be there from the first tool, not retrofitted after something goes wrong.