Tools · interactive

Building an MCP server

An MCP server exposes tools that any client (Claude, an IDE, an agent) can call. The model only knows your tool through its name, description and input schema, and it has to read whatever you return. Try three versions of the same order-lookup tool.

{
  name: "query",
  description: "Query data",
  inputSchema: { type: "object",
    properties: { q: { type: "string" } } }
}

“Where is my order? I'm ada@example.com”
query({ q: "order ada" })
The model has to guess a query language. Your server can't parse it reliably.
“Show refunded orders for bo@example.com since March”
query({ q: "refunded bo march" })
No fields for status or date, so the filter is lost.
“What's the weather in Paris?”
query({ q: "weather in Paris" })
“Query data” could mean anything, so the model tries it for the weather. The tool returns junk.

0/3 handled well · ~2,500 result tokens per lookup

A generic name and a free-text parameter leave the model guessing when to call it and what to send.

Tool version

Step 1 of 4 · read left to right

1
Name and describe for the model
Say what the tool does and when to use it, in plain words. The description is the model's only documentation.
search_orders, not query
2
Type every parameter
Use enums, formats and required fields in the JSON schema. Validate on the server anyway, and return a helpful error the model can fix.
Fewer, well-shaped tools beat many vague ones.
3
Return just enough
Summaries, ids and pagination instead of raw dumps. Context is the model's working memory and it isn't free.
Offer a details tool for drill-down.
4
Run it locally or remotely
stdio for local tools, Streamable HTTP with OAuth for shared ones. Test with the MCP Inspector, then with real prompts.
npx @modelcontextprotocol/inspector

In production

Tools and technologies

Official SDKs make writing MCP servers quick.

Not tied to one language — use these names when you search docs or design a system.