Our MCP server at Supademo has grown to more than 100 tools. AI assistants can edit demos, generate voiceovers, translate content, pull analytics, and do a lot more with the product.
As that catalog grows, I keep coming back to two decisions: how the assistant finds a tool, and how much of the product’s internal workflow that tool should handle.
Loading every definition into the model’s context gets expensive. And even when an assistant finds the right tools, I don’t want it reconstructing the same sequence of internal operations every time a user asks for a voiceover.
Tool definitions use context before the work starts
A tool has a name, a description, an input schema, parameters, and instructions for when to use it. In clients that load everything upfront, all of that competes for context before the assistant starts the user’s task.
Anthropic published an example where 58 tools across five MCP servers consumed roughly 55,000 tokens in definitions alone. As catalogs grow, similar names and overlapping descriptions can also make it harder to select the right tool.
A product with more capabilities will naturally have more tools. The client needs a way to make that catalog available without loading the whole thing into every conversation.
Discover tools as they’re needed
With progressive tool discovery, the assistant searches the available catalog, inspects the relevant definitions, and executes the tools it needs. The rest of the catalog stays available for later.
Some systems also support code mode or programmatic tool calling. The model writes a small script that calls several tools in an execution environment. Intermediate data can stay there, with only the useful result returning to the model’s context.
That gives the assistant a way to coordinate multiple calls without bringing every intermediate response into the conversation. Support depends on the assistant application, so it’s worth understanding how the clients your users connect handle discovery and execution.
Give the server ownership of the workflow
Finding a tool still leaves the assistant with a product to understand. At Supademo, voiceover generation is a good example.
The user’s request is one task: generate voiceovers for these steps. Internally, we have to validate the demo and its steps, queue generation, wait for the audio, save the results back to the steps, and update the demo state.
I don’t want the assistant figuring out that sequence every single time. We expose voiceover generation as one high-level tool. The assistant makes one call, and our server handles the workflow.
That’s how I think about the division of responsibility. The assistant application handles discovery and orchestration. Our MCP server defines useful tool boundaries and handles execution, including the product-specific sequence behind a call.
Look for tasks that take too many calls
A growing catalog is a good reason to review the work you’re asking the assistant to do. If a user thinks of something as one task, but the assistant needs five low-level tools to complete it, that’s probably a candidate for a workflow tool.
Start with one of those tasks. Trace the calls an assistant has to make, identify the sequence your server already understands, and consider exposing that sequence as a single operation. That’s the approach we’re taking with voiceovers as Supademo’s MCP server grows.
Co-Founder & CTO
Koushik co-founded Supademo after years of experience running a creative agency, bringing deep product, design, and engineering expertise to help shape Supademo’s vision and build its core platform. He leads technical execution and product strategy.
