Naming, describing, and schematizing a tool
A minimal MCP server that exposes a single tool needs three things per tool: a name the model and client refer to it by, a natural-language description of what it does and, critically, when to use it, and an input schema defining what arguments it accepts. This is the exact same discipline as tool-calling in general, MCP just gives it a standardized transport: the model never executes your code directly, it only ever sees the name, description, and schema, and decides whether to call the tool based on that text alone. A tool named `search` with the description 'searches' is functionally useless even if the underlying implementation is flawless, because the model has nothing to distinguish it from any other search-shaped tool it might have access to.
Good descriptions do two things: they say what the tool does, and they say when it should be used relative to other tools the model might have available, especially if there's any ambiguity. 'Fetch a single invoice by ID; use this before answering any question about whether an invoice has been paid' is a description that both explains the function and steers the model toward calling it at the right moment, rather than guessing or hallucinating an answer from memory.