MCP Tools: What They Are and How to Pick Them

An MCP tool is a named action that an MCP server offers to an AI model. It comes with a description and a JSON Schema for its inputs. The agent lists a server's tools, picks one, sends arguments and gets a result back. This page explains how that works, what to check in a tool, how to limit tools, and where to find good ones. We checked the spec on 31 October 2026.

Quick facts

What a tool is

A server declares a tools capability. When a client sends tools/list, the server answers with the tools it has. Each entry says what the tool is called, what it does and what arguments it takes.

{
  "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"]
  }
}

The example is from the spec. Three parts do the work:

• `name` is the identifier the model uses to call the tool.
• `description` is plain text the model reads to decide when to use it. This is the most important field. A vague description means a tool used at the wrong time, or never.
• `inputSchema` is a JSON Schema for the arguments. It tells the model which fields exist, which are required and what type each is. The spec says it defaults to the 2020-12 schema dialect and must be a valid schema object.

Optional fields add polish. title is a display name, icons are for interfaces, and outputSchema describes structured results. annotations describe behaviour, and the spec is careful on trust: clients must treat annotations as untrusted unless they come from trusted servers. A tool that claims to be read-only may not be.

Names

The spec says tool names should be 1 to 128 characters, case-sensitive, and use only letters, digits, underscore, hyphen and dot. They should be unique within a server. Across servers, collisions happen: two servers can each have a search tool. The spec tells clients and proxies that merge tools to disambiguate, for example by prefixing a server name. In practice your agent does this for you. Claude Code, for one, shows tool names in the form mcp__<server>__<tool>, and that prefix is how you write permission rules for a single server's tools: mcp__<server>__* matches all of a server's tools, and mcp__<server>__<tool> matches one. Claude Code leaves out any tool whose full name is over 128 characters.

How a call works

1. The client connects and asks for the tool list.
2. The model sees the tool definitions in its context, with your prompt.
3. The model decides to call a tool and produces a name and arguments.
4. The client sends tools/call. A well-behaved client shows you the call first.
5. The server runs the action and returns content: text, an image, audio, a link to a resource, or structured data.
6. The result goes back into the model's context, and the model continues.

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

Two things worth knowing from the spec.

Errors are results. A tool that fails returns a result flagged isError, with text the model can read. That lets the model correct a bad argument and try again. The Git server's README shows the pattern: a failed call returns Error executing tool <name>: <message>. An unknown tool name, by contrast, is a protocol error.

A tool can ask for more. A server may answer with an "input required" result, asking for something like a username through an elicitation request. The client collects it and retries the call with the answers. Several servers use this for confirmations. MongoDB's server, for instance, lists tools that need user confirmation before they run, which relies on a client that supports elicitation. Check each agent's docs for that support.

Tools, resources and prompts

MCP servers can offer three kinds of thing. People mix them up.

The spec describes tools as model-controlled. That is why they get the most attention in security talks: the model can reach for one without you asking. A resource sits there until a client reads it. A prompt waits for you to pick it.

Many servers expose the same data both ways. The Memory server has tools to read and change its graph, and a resource that shows the whole graph. The tool is for the model to act with. The resource is for a client to display or subscribe to.

What tools cost

A tool costs three things.

Context. Every tool's name, description and schema is sent to the model with your prompt. A server with 5 tools adds little. One with 200 adds a lot. Vercel's docs list 217 catalog tools and 31 workflow or widget tools, and Kubernetes MCP lists 78 tool entries across toolsets. Both give you ways to load fewer. The spec notes that returning tools in a deterministic order helps clients cache the list and improves prompt cache hits, which is a hint that the list is a real cost.

Money. The tool call is free. The service behind it may not be. Search, crawl and cloud tools bill by call or credit. See Free MCP servers for which are metered.

Risk. A tool is a capability. execute_sql can drop a table. build_submit can publish an app. The right question for each tool is "what is the worst thing this can do with the credentials it has".

Choosing tools well

Fewer, sharper tools beat a long menu. Some tests we apply, from the docs of the servers we cover:

1. Does the description say when to use it? Good ones do. The Firecrawl README has a decision table that says "use this when you know the URL" and "use this when you start from a question". That is the standard to look for.
2. Is the schema tight? Required fields, enums and defaults help the model pass valid arguments.
3. Can you turn groups off? Kubernetes MCP loads only two toolsets by default. Neon takes a category parameter in its URL. Chrome DevTools MCP has a --slim flag. Look for this.
4. Is there a read-only mode? MongoDB has --readOnly. Neon has ?readonly=true. Redis relies on an ACL user. Postgres and SQLite servers vary. Our pages say which.
5. Does it separate reads from writes? The old SQLite reference server had a read_query and a write_query. That split lets a client ask for approval on writes only.
6. Does it return a lot of text? Tools that dump a whole file, log or table fill the context. Look for limits and paging.

Limiting tools in your agent

Every agent has a way to see and restrict tools, and the details differ. The common pattern is a list of connected servers, a way to inspect each one's tools, and approval settings.

See MCP clients for the comparison we maintain, and Claude Code agents for how to give a subagent only the tools its job needs.

Examples of tools in the wild

These are tools from servers we cover, grouped by what they do. Each links to a page with install lines for five agents.

For a broader view, MCP servers explains the servers behind the tools, and best MCP servers says which to add first.

Security notes

The spec's own security section is short and worth reading.

Servers must validate all tool inputs, implement proper access controls, rate limit invocations and sanitise tool outputs.

Clients should prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server (to avoid accidental or malicious data exfiltration), validate results before passing them to the model, set timeouts, and log tool use for audit.

From our side, as a user:

1. Read the call before you approve it. The arguments tell you what the tool will do. A path, a URL or a SQL statement is the point.
2. Treat results as untrusted. A tool result is text that enters the model's context. A web page, an email, a log line or a database row can carry instructions. This is prompt injection, and it is the main risk of tool use.
3. Mind combinations. One tool that reads private data plus one that can send data out is the shape of an attack. Keep them in separate agents or sessions.
4. Do not trust annotations. The spec says clients must treat them as untrusted unless the server is trusted. A "read-only" hint is not a fence.
5. Grant least access. Give the server a limited account, folder, role or token. The tool can only do what its credentials allow.
6. Watch the headers. On HTTP transports a server can mirror chosen parameters into headers, which network intermediaries can see. The spec says servers should not do this for secrets. As a user, you cannot see this, so prefer vendors you trust.
7. Log it. If you can, keep a record of tool calls for anything that touches production.

Limits and known issues

• No tool count limit in the spec. Your client or model may have one, and we found no published figure in the agent docs we read apart from Claude Code's 128-character cap on a tool's full name.
• Lists can change. A server can send a list-changed notification, so a tool you used yesterday may be gone or renamed. Pin versions for workflows you depend on.
• Lists can vary by user. The spec allows the tool list to vary by the authorization on a request. Two people on one server may see different tools.
• Quality varies widely. The spec defines the shape of a tool, not whether its description is any good.
• Name collisions. Two servers with a search tool can confuse an agent unless the client prefixes names.
• Deprecations. The 2026-07-28 revision deprecates roots and sampling. Check a server's notes if it relies on them.

Alternatives to tools

Our take

We did not run any server for this page. This is the spec, plus the documentation of the servers we cover.

The tool model is simple and well designed: a name, a description, a schema and a result. Its simplicity is why it spread. The real skill is not in calling tools but in choosing a few good ones and fencing them.

Our advice is to start small. Add the handful of servers you will use weekly. Look at each tool list once, and switch off groups you do not need. Prefer servers with a read-only mode and narrow scopes. Keep a person in the loop for writes. And remember that the description is the interface: a model chooses a tool by reading it, so when an agent keeps picking the wrong tool, the fix is often in the text, not the model.

A short checklist

1. List the servers your agent has connected.
2. Open each server's tools and read the descriptions.
3. Switch off tool groups you never use.
4. Turn on read-only mode where it exists.
5. Require approval for tools that write, send or spend.
6. Keep private-data tools and outbound tools in separate sessions.
7. Review your list monthly.

Frequently asked questions

What is an MCP tool?

A named action that an MCP server exposes to an AI model, described by a name, a description and a JSON Schema for its inputs. The model can call it, and the server returns the result.

How are MCP tools different from MCP resources and prompts?

Tools are model-controlled actions. Resources are data the client can read, and prompts are templates. The spec says tools are designed to be model-controlled, so the model can discover and call them on its own.

Do I have to approve each tool call?

The spec says there should always be a human in the loop with the ability to deny invocations, and that applications should prompt for confirmation. How it works depends on your agent.

Can tools differ between users?

Yes. The spec says the tool list may vary by the authorization presented on a request, for example returning only the tools the granted scopes allow.

How many tools is too many?

The spec sets no limit. Each tool's description and schema take up space in the model's context, so a long list costs tokens and can make choices worse. Trim what you do not use.