An MCP tool is a model-invokable function exposed by an MCP server. Each tool has three required pieces: a name, a description (written for the model to read), and a JSON Schema declaring its arguments. The LLM decides when to call a tool based on the description; the host routes the call through the MCP client via tools/call; the server executes the underlying action and returns the result. Tools are the side-effecting primitive in MCP (create an issue, write a file, send a message). Resources are the read-only primitive (host-pulled data). Prompts are user-invoked templates. The split lets hosts apply different consent rules to each: resources flow freely, prompts require user action, and side-effecting tool calls can require explicit approval.
**An MCP tool** is a function the model can call. It is one of the three primitives an MCP server exposes (the other two are resources and prompts), and it is the primitive designed for taking action in the outside world.
Each tool has three required parts. The **name** identifies it uniquely within the server (`create_issue`, `write_file`, `query`). The **description** explains what the tool does, written for the model to read when deciding which tool fits. The **input schema** is a JSON Schema specifying what arguments the tool accepts, with types, required fields, and per-property descriptions.
The call flow is straightforward. On startup, the client asks the server `tools/list` and gets back the tool catalog. The host translates this catalog into the format expected by the LLM provider's function-calling API. The model reads descriptions, picks a tool, and emits a structured call. The host routes the call via `tools/call` over JSON-RPC. The server executes the action (hits the GitHub API, writes a file, runs a SQL query) and returns a result, which the host feeds back to the model.
Tools are the **side-effecting primitive**: calling `create_issue` actually creates an issue. Resources, by contrast, are read-only data the host pulls. Prompts are templates the user invokes. The three-way split lets hosts apply different safety policies to each.
**An MCP tool** is a model-invokable function exposed by an MCP server. Each tool has a name, a description, and a JSON Schema for its arguments. The model decides when to call the tool; the host routes the call through the MCP client; the server executes the underlying action and returns the result.
Tools are one of three primitive families in MCP. **Resources** are host-pulled, read-only data. **Prompts** are user-invoked templates. Tools are the **side-effecting primitive**: a tool call can write to the filesystem, hit an external API, modify a database, or send a message. The three-way split lets hosts apply different consent policies cleanly: resources flow into context freely, prompts require user action, side-effecting tool calls can trigger approval flows.
The lifecycle spans five steps. (1) On initialize, the server declares tools capability. (2) The client calls `tools/list` to fetch the catalog. (3) The host translates the catalog into the LLM provider's expected format (Anthropic tool_use blocks, OpenAI function declarations, Google function_declarations). (4) The model emits a structured tool call; the provider's function-calling layer guarantees the emitted JSON is structurally valid against the declared schema. (5) The host sends `tools/call` to the server, receives the result, and appends it to the conversation.
The JSON Schema for arguments is what makes the loop reliable. Function calling at the inference layer constrains token sampling so the emitted arguments are always parseable and match the declared types. The model can still pick the wrong tool semantically, but the structure is guaranteed.
Concrete examples: the filesystem server exposes `read_text_file`, `write_file`, `list_directory`. The GitHub server exposes `create_issue`, `search_repositories`. The Slack server exposes `send_message`, `list_channels`.
Quick reference
TL;DR
An MCP tool is a model-invokable function with a name, description, and JSON Schema for its arguments. The LLM decides when to call it; the server executes the action.
Imagine the AI has a toolbox in front of it. Each tool in the box has a label (the name), a small card explaining what it does (the description), and a little form showing what inputs it needs (the JSON Schema). The AI reads the cards, picks a tool that fits the current task, fills in the form, and hands it to the runtime. The runtime actually picks up the tool, uses it (creates the GitHub issue, writes the file, sends the message), and reports back what happened. The AI never touches the tool directly; it only chooses which one to use and fills in the form. Tools are how MCP servers let the model take action in the outside world.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Exposing data the model only needs to read without modifying anything That is a resource, not a tool. Resources are designed for read-only, host-pulled data and avoid the consent overhead of a side-effecting tool call.
Providing a fixed user-initiated workflow like 'review this PR with these prompts' That is a prompt template, not a tool. Prompts are user-invoked and render structured message content; using a tool here mixes up the invocation model.
Building a capability that requires multi-step human approval within a single call A single tool call follows a request-response pattern. Multi-step approval belongs in the host's consent layer or in a higher-level workflow, not inside one tool implementation.
Quick scan · 2–4 min
Everything important, quickly.
5 min: state the definition (name, description, JSON Schema), walk the five-step call lifecycle (initialize, tools/list, catalog translation, function-calling emission, tools/call plus result), distinguish tools from resources and prompts on the invocation axis, name three concrete tools from reference servers, and explain what function calling guarantees versus what it does not.
Real-world examples
Real products, models, and research that use this idea.
1Filesystem server tools: `read_text_file`, `write_file`, `list_directory`, `create_directory`, `move_file`.
2GitHub server tools: `create_issue`, `list_issues`, `search_repositories`, `get_pull_request`, `merge_pull_request`.
3Sqlite server: a `query` tool that accepts SQL and returns parsed rows.
4Slack server: `send_message`, `list_channels`, `search_messages`, all model-invocable from any MCP host.
5Stripe MCP server tools list customers and create charges, with strict consent flows enforced by the host before any payment action executes.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a tool call in MCP relate to function calling at the LLM provider layer?
Sign in or go Pro to see the approach for this follow-up.
QWhat is in the input schema, and what happens if the model supplies wrong values?
Sign in or go Pro to see the approach for this follow-up.
QCan a tool return more than plain text?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Confusing tools with resources. Tools are model-invoked and may have side effects; resources are host-pulled and strictly read-only. The invocation path and safety model are completely different.