In MCP, what exactly is a 'tool' and who decides when to call it?

Flashcard·Easy·4.0 · 0·~30s·Asked atMidjourney Moveworks Roblox·Relevant atAnthropic

Attempt it

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.

Your answer

**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`.

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.

Memory aid

Easy to grasp

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.

Key concepts

Tool JSON Schema Function Calling MCP Server

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

An MCP tool is the primitive that lets a model take action in the outside world through an MCP server. It is one of three primitives the protocol defines (resources and prompts are the other two) and the only one the model itself decides to invoke. Tools are where the model crosses from generating text into producing real effects.

This walkthrough covers what a tool is structurally, the lifecycle of a tool call from model emission to server execution, the contrast with resources and prompts, and the boundaries of what function calling at the inference layer does and does not guarantee.

The definition, unpacked

An MCP tool is a model-invokable function exposed by an MCP server, with a name, a description, and a JSON Schema for its arguments.

Four properties sit in that definition. Model-invokable means the model decides when to call the tool based on the description. The model does not execute the tool; it emits a structured call that the runtime executes. Function exposed by a server means the tool implementation lives on the server side; the server does whatever the tool advertises. Name and description are the metadata the model reads when choosing which tool to call. The name identifies uniquely within the server; the description is written for the model, not for end users. JSON Schema for arguments is the contract for what the model must supply when calling the tool; it is what makes structured, type-safe function calling possible.

The definition also clarifies what tools are not. They are not the only primitive (resources and prompts coexist). They are not where the LLM lives (the model is in the host; the server executes actions). And they are not guaranteed to be called correctly every time (function calling guarantees structure, not semantics).

The call lifecycle: five steps from catalog to result

What a tool definition looks like in practice

Tools versus resources versus prompts

What function calling guarantees and what it does not

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Filesystem server tools: `read_text_file`, `write_file`, `list_directory`, `create_directory`, `move_file`.
GitHub server tools: `create_issue`, `list_issues`, `search_repositories`, `get_pull_request`, `merge_pull_request`.

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?

Function calling is the inference-layer mechanism: the model emits a structured JSON object naming the tool and its arguments, with structural well-formedness guaranteed by the provider's sampling layer. A tool call in MCP is the system-layer routing: the host takes the emitted function call, finds the right MCP client, and sends tools/call over JSON-RPC. The two compose: function calling makes emission reliable; MCP makes routing standardized.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

60 second bullets to scan on the way to the call.

Define an MCP tool using the name, description, and JSON Schema framing
Name the three roles in a tool call: model (decides), host (routes), server (executes)

Primary sources. Browse if you want the original framing.