Tool definitions are sent on every request, not once. Paste your MCP server URL to see how many tokens that is, which tools are the heaviest, and what it costs.
Cutting context cost makes your server cheaper to run. It still does not show a customer what it does. Point MCP Showcase at the same URL for a live playground with per-tool documentation.
We read the tool definitions the server advertises — the same ones an agent receives.
Name, description and the full JSON input schema, because all three are sent to the model on every turn.
Total tokens per request, an estimated cost per 1,000 turns, and the tools ranked by how much context each one eats.
This is the part that surprises people. An MCP server's tool definitions are not loaded once at the start of a conversation — the model has no memory of them between turns, so the complete list of tools, with every description and every JSON input schema, is sent again with each request. Forty verbose tools is not a one-off; it is a fixed tax on every turn of every conversation your agent will ever have.
Paste an MCP server URL above and this calculator reads exactly what an agent receives, measures it, and shows where the weight actually is.
In order of payoff. Remove tools nothing calls. Servers accumulate them; every one is charged on every turn whether or not it is ever useful. Shorten descriptions to one clear sentence covering what the tool does and when to use it — anything longer is usually written for a human reader who will never see it. Trim the input schemas: long per-property descriptions and deeply nested optional objects are typically the bulk of a heavy tool, and they compound because schemas are verbose JSON rather than prose.
There is a second reason to do this that has nothing to do with money. Tool-selection accuracy falls as the list grows. A model choosing between eighty similarly-described tools picks the wrong one far more often than one choosing between eight — so trimming the list usually makes the agent behave better, not just cost less.
Counts are approximated at roughly 3.6 characters per token, which suits the JSON-dense text of tool definitions and typically lands within about 10–15% of a real tokenizer. That is the right tool for comparing tools against each other and finding bloat. It is not the right tool for reconciling an invoice, and the page says so on every result rather than leaving you to assume otherwise.
Cutting descriptions to save context makes your server cheaper and your agent more accurate. It also makes the server harder for a human to understand, which is a problem the moment you want someone to evaluate it. MCP Showcase resolves that split: the model gets your lean schemas, while prospects get a live playground with generated, readable documentation for every tool — so you are not writing one description that has to serve two very different readers.