MCP Tools Explained

An MCP tool is a named action that a server offers to an AI model, such as "look up an order" or "create an invoice." The model decides when to call it, the client sends the call, and the server runs it and returns a result. Tools are how MCP lets an AI do things, not just read things.

Status in the 2026-07-28 spec: core. Tools are one of the three server features in the current specification, next to resources and prompts. A server opts in by declaring the tools capability.

This page explains tools in plain English for technical managers and developers new to MCP. Every rule below comes from the 2026-07-28 Tools page of the official specification, checked on 28 October 2026.

What a tool is

The specification describes tools as a way for servers "to expose tools that can be invoked by language models." Tools let models query databases, call APIs or run computations. Each tool has a unique name and metadata that describes its inputs.

A tool definition has a few parts:

• name: the unique identifier, such as get_weather.
• title: an optional display name for people.
• description: plain text that tells the model what the tool does.
• inputSchema: a JSON Schema that defines the arguments.
• outputSchema: an optional schema for structured results.
• annotations: optional hints, such as whether the tool is read-only.
• icons: optional images for the user interface.

Why tools exist

Tools give AI apps one shared format for describing actions. A server written once can offer the same tools to any MCP client, instead of a separate integration for each app.

Tools also define who is in control. The spec calls tools model-controlled: the model can discover and call them based on the conversation. But it adds a warning: "there SHOULD always be a human in the loop with the ability to deny tool invocations." Apps should show which tools are exposed, show when a tool runs, and ask for confirmation on operations.

How tools work

There are two main requests. The client lists tools, then calls one.

Listing tools

The client sends tools/list. The server returns its tools. Here is a trimmed version of the spec's response example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "get_weather",
        "title": "Weather Information Provider",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string", "description": "City name or zip code" }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

Three details are new in 2026-07-28. Every result carries resultType. The ttlMs and cacheScope fields tell the client how long it can cache the list and whether shared caches may store it. The list has supported pagination since 2024-11-05.

Calling a tool

The client sends tools/call with the tool name and arguments:

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

The server replies with a content array, such as text, images or audio, and an isError flag. It can also return structured output that matches an output schema.

The spec examples omit one thing for brevity. Every request in 2026-07-28 must also carry _meta fields with the protocol version, client info and client capabilities, because there is no longer a startup handshake. Our guide to why MCP became stateless explains why.

When a tool needs more input

A server may answer tools/call with resultType: "input_required" and a list of questions, for example an elicitation form. The client collects the answers and retries the same call with inputResponses, using a new JSON-RPC id. This is the multi-round-trip request pattern.

When the tool list changes

If the server declared listChanged, it should send notifications/tools/list_changed. In 2026-07-28 that only goes to clients that opened a subscriptions/listen stream with toolsListChanged: true.

What changed across spec versions

The 2025-11-25 version also had an execution.taskSupport field on tools for the experimental Tasks feature. That field is gone from the core Tools page in 2026-07-28, because Tasks moved to an official extension.

Stateful tools without sessions

Since there is no protocol session, a server cannot quietly link one call to the next. The spec's non-normative guidance is to return an explicit handle from a "create" tool, such as a basket ID, and accept it as an argument on later calls. It adds that the server should check the caller's authorization against the handle on every call.

Common mistakes

1. Trusting the model to ask first. The client should confirm sensitive operations, but the server must still validate inputs, enforce access control, rate limit calls and sanitize outputs. Those four are MUST rules for servers.
2. Returning different tools per connection. The 2026-07-28 spec forbids it. The list may vary by the caller's authorization, but not by connection state.
3. Reporting bad input as a protocol error. Validation failures belong in the result with isError: true, so the model can fix its call. See how MCP servers report tool errors.
4. Vague descriptions. The description is what the model reads to choose a tool. Read our tool naming and description guide.
5. Treating annotations as security. The spec says clients must treat annotations as untrusted unless the server is trusted.

Tools are also the main attack surface in MCP. The MCP security center covers threats like tool poisoning.

Next step

Tools are only as good as their inputs. Read MCP tool input and output schemas next, or browse the full MCP specification reference.

Frequently asked questions