Free tool

MCP Tool Schema Linter

When an agent calls the wrong tool, the descriptions are usually why. Paste your MCP server URL for a review of every tool description and input schema, with suggested rewrites.

Works with streamable HTTP and SSE endpoints, for example https://mcp.example.com/mcp
This server needs authentication
Used for this one request and never stored.

Better descriptions for the model. What about for people?

A description tuned for tool selection is not documentation a customer can read. MCP Showcase generates both from the same server: lean schemas for the agent, a live playground with real documentation for everyone else.

How it works

link
Paste the URL

We read the tool definitions your server advertises — exactly what an agent receives when it connects.

play_circle
Every description is checked

Missing or thin descriptions, undocumented parameters, schemas with no declared properties, and descriptions long enough to cost real context on every turn.

checklist
Get findings and rewrites

A score, each problem with the tool it affects, and — where it would change how a model behaves — a suggested replacement description.

Why an agent calls the wrong tool

A Model Context Protocol tool description is not documentation for a human. It is sent to the model on every request, and it is the only thing the model uses to decide whether to call that tool. When an agent reaches for delete_branch instead of list_branches, that is almost never a bug in the agent — it is two descriptions the model could not tell apart.

Paste your MCP server URL above and this linter reads every tool definition your server advertises, exactly as an agent receives it, and reports the things that make selection unreliable.

What it checks

  • Missing or thin descriptions — a tool described in three words gives the model nothing to choose on.
  • Descriptions that restate the name — the model already has the name. "List issues: lists issues" adds no signal at all.
  • Undocumented parameters — parameter descriptions are how the model knows what to put in each field. Without them it infers from the field name and gets it wrong.
  • Schemas with no declared properties — a tool that declares no inputs will accept whatever the model invents.
  • No required array — every parameter then looks optional, so the model omits one the server needs and gets an error back.
  • Descriptions long enough to cost real context — sent on every single turn, so verbosity is a recurring charge, not a one-off.

Longer is not better

This is worth stating plainly because the instinct is usually wrong. The linter flags descriptions that are too long as well as too short. Tool definitions are re-sent with every request, so an extra paragraph is paid for on every turn of every conversation, forever, while adding nothing to selection accuracy. Aim for one or two specific sentences: what the tool does, and when to choose it over the one next to it. You can see exactly what your current tool list costs with the MCP token calculator.

What the report includes

A quality score, every finding with the tool it affects, and — where a rewrite would genuinely change how a model behaves — a suggested replacement description. The checks themselves use no model at all and always run. The suggested rewrites do, and there is a monthly budget for them so the tool can stay free; if it is exhausted, the report says so plainly and every finding above it still stands.

Related tools and guides

One description cannot serve two readers

Tuning a description for tool selection makes it terse, specific and machine-facing — and useless to a customer trying to understand what your server does. That tension is real and it does not resolve by writing harder. MCP Showcase settles it by generating both from the same server: your lean schemas keep going to the model, while prospects get a live playground with readable per-tool documentation they can actually try in a browser.

Frequently asked questions

Almost always the descriptions. A model picks a tool by reading its description, and nothing else. If two tools describe themselves similarly, or one says only what it is called, the model is guessing. That failure looks like a bug in your agent but lives in your server's schema.

One or two plain sentences saying what the tool does and when to choose it over a similar one. Specific, not marketing, and not a restatement of the tool name. Every parameter gets its own description, and the required array is declared so the model knows what it cannot omit.

No. It reads only what your server advertises — names, descriptions and input schemas. It cannot tell you whether a tool works, only whether a model reading your descriptions would pick the right one.

The checks always run; they use no model at all. The suggested rewrites do, and there is a monthly budget for that so the free tool stays free. If it is exhausted the report tells you so plainly, and every finding above it still applies.

No — the linter flags descriptions that are too long as well as too short. Tool definitions are sent on every single request, so verbose text is paid for on every turn while adding nothing to selection accuracy. Aim for clear and specific, not thorough.

More free MCP tools