The fix for MCP tool sprawl isn't fewer tools. It's playbooks.

I build a creative platform for ad agencies and brand teams. It makes ads, product videos, brand assets, that kind of thing, and it's driven by Claude Code, Cowork and Claude.ai over the browser all over MCP. There are over 200 tools.

Everyone hits the same wall somewhere around twenty tools, where the agent stops routing well and starts guessing. Two obvious fixes didn't work for me.

Fewer tools didn't work, because the work genuinely needs that many verbs. Making an ad and publishing an ad and scoring it with music are different things.

Better tool descriptions didn't work either, and that one surprised me. Every description is prefill. You pay for all of them on every turn, including the turns where that tool was never getting called. So writing more of them makes the problem quietly worse.

What worked was giving up on the idea that the agent should figure out the route.

Think about what you're actually asking it to do. A user says "make me a product video for the new jacket." The agent now has to decide: pull the product from the store, or ask which one? Generate the shots or use the existing photos? Score it before or after the cut? Publish, or stage for approval? None of that is in any single tool's description, because it isn't about any single tool. It's about creating an OUTCOME that uses multiple tools.

My solution was to create what I call Playbooks. I have over 150 of them now, one per outcome an agency actually asks for. And these literally drive complex multi-step decisions, routes, processes, and the checks-and-balances any predictable outcome needs.

Each one names real tools and the order, and marks where a human has to say yes and where money gets spent. The user fills in a couple of blanks and the agent runs it.

Two rules keep these from rotting, and they're the bit I'd actually steal if I were reading this.

Don't re-teach. A playbook names tools and the order and nothing else. It never restates what a parameter does or how the craft works. That stuff lives in the tool description, which gets served fresh every time you connect. The first version I wrote duplicated the rules into the playbooks and it fell apart in about three weeks, because the tools changed and the playbooks didn't. Now there's one home for each fact.

Steer, don't script. Steps say things like "reuse an existing project before making a new one" rather than dictating exact calls. The agent still gets to think. You want a spine, not a script, and you find out which one you wrote the first time reality doesn't match the happy path.

The part that makes this MCP rather than documentation: the playbooks are served by the server. There are tools to search them and fetch one by name. So nobody pastes a recipe in. The agent asks what the play is for this outcome, gets it back, and runs it. That's the routing layer, and it's why the tool count stopped mattering.

The test that convinced me it was real: fresh agents, no memory, no docs, never talked to me, given only a user's plain sentence and the connection. Over a hundred runs against the live platform. They do it right on first contact.

Disclosure, this is my own platform so obvious bias. But none of this is specific to it. If you're deep into tool count and losing the agent to route-finding or getting inconsistent outcomes, that's where I'd look.