Guide

When to use an MCP Tool

Published 14 September 2026

You want an MCP tool when the thing you are building is a capability that some other model invokes: a defined input, a defined output, a defined error set, and no opinion about when it should run. An agent decides what to do, a tool does one thing when asked. The deciding belongs to whoever calls you, and if that sentence makes you uncomfortable, you are probably describing an agent.

What a tool actually is in protocol terms

The Model Context Protocol specification, at revision 2026-07-28, lists three things a server can offer: Resources, Prompts, and Tools, which it defines as "Functions for the AI model to execute."

The server concepts page prints a "Who controls it" table:

Primitive Who controls it
Tools Model
Resources Application
Prompts User

The tools page states it directly: "Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." Two operations carry the whole surface: tools/list to find out what exists, and tools/call to run one.

Three definitions and no fourth

A tool spec is finished when three things are pinned down: the input, the output, and the error set.

The input. A JSON Schema for the arguments, not a description of what the caller should probably send. The schema is the contract, and the model reads it before it calls you.

The output. The exact shape that comes back, fields and types. A model that cannot predict your return shape cannot chain you to anything.

The error set. The spec separates two mechanisms: Protocol Errors, returned as standard JSON-RPC errors for things like unknown tools and malformed requests, versus Tool Execution Errors, reported inside the tool result with isError set true. The spec says those results "contain actionable feedback that language models can use to self-correct and retry with adjusted parameters." An unnamed failure mode is an undesigned retry loop.

Naming is part of the interface too: the spec says tool names should be between 1 and 128 characters, case-sensitive, using only ASCII letters, digits, underscore, hyphen and dot.

The tell that you are describing an agent

A tool description that contains a decision the model must make, or more than one job, is describing an agent. Read your own one-line description of the tool. Two things disqualify it.

It contains a decision the model must make. Look up the customer's plan and decide whether they qualify for a refund is not one tool. The lookup is a tool; the qualifying is a judgment, and judgments belong to the caller. Split it: return the plan, the tenure and the refund history, and let whatever called you decide. Bury the decision inside the tool and nobody upstream can see it, log it, or override it.

It contains more than one job. Search the tickets, then summarise the themes, then email the report is three. The giveaway is that word: then. Each of those is a separate capability with its own failure mode. Bundled together they are a workflow filed as a tool.

A third, quieter tell: you want the tool to remember the previous call. The spec closes that door on purpose: "MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next." A server that genuinely needs cross-call state is told to return an explicit handle from a creation tool and accept it as an argument on later calls. State becomes a visible parameter instead of an invisible assumption.

The protocol will not think for you

Older descriptions of MCP gave servers a way to borrow the host's model for reasoning mid-call. The docs architecture page now states "Sampling is deprecated as of protocol version 2026-07-28", and adds "New implementations should integrate directly with LLM provider APIs." The spec landing page lists exactly one feature clients may offer servers: Elicitation, server-initiated requests for additional information from users. That is a narrow slot for a missing argument, not a place to relocate a decision you did not want to make.

That missing session is not an oversight. The spec's architecture page: "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities." The versioning page is blunter: "There is no negotiation handshake." Anything you learned about an initialize handshake and a negotiated session is what that page now calls Legacy: 2025-11-25 and earlier. Microsoft's widely used MCP for Beginners curriculum states "This curriculum is aligned with MCP Specification 2025-11-25 (the latest stable release)." Good material can sit a revision behind the protocol.

Consent is the host's job, not yours

The spec's tools page carries a warning: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." The landing page's security principles say "Hosts must obtain explicit user consent before invoking any tool." So do not design your tool around asking permission mid-execution: the approval gate lives in the application that calls you. What you owe it is a description honest enough that a person reading the confirmation prompt understands what will happen.

When it is an agent instead

An agent holds a goal, picks its own next step, and stops when a condition it is tracking becomes true. Claude Code's documentation describes subagents as "specialized AI assistants that handle specific types of tasks", and that page has sections on scoping MCP servers to a subagent. Notice the hierarchy: the agent is the thing that has tools scoped to it, not a peer of them.

The MCP connector documentation notes that of the MCP feature set, only tool calls are currently supported, and that once a server is connected, Claude calls its tools when the user's request maps to a tool's described capability. The model does the mapping. Your job was to be mappable.

One thing changes the build without changing the answer: who calls it. The docs note the typical split:

Server Transport Typically serves
Local STDIO A single MCP client
Remote Streamable HTTP Many MCP clients

Where this fits if you use Bespoke Prompting

Bespoke Prompting's MCP Tool build type derives tool count as one before it writes anything, on the doctrine of one callable tool doing one job. Rather than quietly building whatever it was handed, it flags the contradictions by name: reads_as_agent when the request reads as an autonomous agent rather than one callable tool, multi_tool_implied when more than one tool is implied, multi_user_implied when a stdio setup meets a multi-user scenario, and arrays_were_empty when the signature, return shape or error set was left blank. Three mandatory error codes are floored into every spec it emits, so the error set is never the section you forgot.

Sources

Suggested internal links