MCP tool

How an MCP tool works

An MCP server that offers tools declares a tools capability, and it can say whether it will notify clients when its list of tools changes 1. The MCP client asks for the list with a tools/list request 1. The server answers with every tool currently available to that caller, and the list may differ by the authorization on the request, so a caller may see only the tools its granted scopes permit 1. Servers should return tools in the same order each time, which lets clients cache the list and helps a model's prompt cache 1.

Each entry in the list tells the model what the tool does and what it needs. The name identifies the tool, the description says what it is for, and the inputSchema is a JSON Schema for the arguments 1. An optional outputSchema describes the shape of a structured result 1. The host passes those definitions to the model, and the model chooses a tool through tool calling when a request matches one.

The call itself is one more request. The client sends tools/call with the tool name and the arguments 1. The server runs the operation and returns a result with a content array and an isError flag 1. The client hands the result back to the model, which reads it and either answers or calls another tool.

People stay in charge of the loop. The specification says there should always be a human in the loop with the ability to deny tool invocations 1. Applications should show which tools are exposed to the model, mark each invocation clearly and ask for confirmation on operations 1. A tool description and a tool schema are the two parts a server author controls most directly.

What makes a good MCP tool

The model knows a tool only through its definition. The specification sets a few rules, and good servers add habits of their own.

• A clear, stable name. Names should be 1 to 128 characters, case-sensitive and unique within a server, using letters, digits, underscores, hyphens and dots 1. Clients that combine tools from several servers may need to prefix names to avoid clashes 1.
• A description that states the job, the inputs it expects and what it costs, so the model can tell two similar tools apart.
• A strict input schema. The inputSchema must be a valid JSON Schema object, and a tool with no parameters should accept only an empty object 1.
• Errors the model can act on. The specification separates protocol errors, such as an unknown tool, from tool execution errors such as a bad date or a failed API call 1. Execution errors come back in the result with isError set to true, so the model can correct itself and retry 1.
• One job per tool. The MCP server guide describes each tool as performing a single operation with clearly defined inputs and outputs 2.

Security rules apply on both sides. Servers must validate all tool inputs, apply access controls, rate limit tool calls and sanitize outputs 1. Clients should confirm sensitive operations, show tool inputs to the user before calling the server, set timeouts and log tool usage 1.

Example of an MCP tool call

The specification shows a complete call 1. After listing tools, the client asks the server to run one by name, shortened here 1.

{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "get_weather", "arguments": {"location": "New York"}}}

The server returns a content array with a text block describing the weather and isError set to false 1. If the client had asked for a tool that does not exist, the server would return a standard JSON-RPC error with code -32602 and the message Unknown tool 1. If the tool existed but the input was wrong, such as a date in the past, the server would return a normal result with isError set to true and a message the model can use to fix the call 1.

A data tool follows the same pattern with a cost attached. RichAPI's hosted MCP server exposes phone_finder as a tool 4. Given a request to get the mobile for a LinkedIn profile and fall back to the work email if there is no number, the agent calls phone_finder, sees the miss and moves to the email finder on its own 4. The phone finder bills 25 credits per successful call and zero on a miss, so the fallback costs nothing on records with no number 4. A tool whose description states those terms lets the model plan the cheaper path before it calls anything.

MCP tool vs MCP resource

Servers offer both, and they differ in who decides to use them. The MCP server guide marks tools as model-controlled, resources as application-controlled and prompts as user-controlled 2. A tool is a function the model calls, and it can write to databases, call external APIs or trigger other logic 2. A resource is a passive data source that gives read-only access to context, such as file contents or an API's documentation, and each one has a unique URI 2. Use a tool when something has to run, and a resource when the application only needs to read.