MCP Tool

What is an MCP tool?

An MCP tool is an executable capability exposed by an [MCP server](/glossary/mcp-server/) for discovery and invocation through the Model Context Protocol. A tool has a name and descriptive metadata, including an input schema. It may also describe its output.

Tools let a model act beyond text generation—for example, querying a database, creating an issue, performing a calculation, or calling an external service.

How it works

The server declares support for tools. An [MCP client](/glossary/mcp-client/) can obtain the tools currently available from that server. The AI application may present suitable definitions to the model, which can choose a tool and prepare arguments.

The client sends the call through MCP, and the server executes its implementation. The returned tool result can contain text, structured content, media, or resource references, depending on the tool and protocol support.

MCP defines the exchange. It does not require an application to execute every model-requested call. The host can validate arguments, enforce permissions, request human confirmation, or reject the operation.

Simple example

An MCP server exposes a create_ticket tool requiring title, description, and priority. A model prepares valid arguments after reading a user request. Before execution, the host asks the user to confirm because the action writes to an external system. The server then creates the ticket and returns its identifier.

MCP tool versus normal application tool

“Tool” is a broad agent-system concept. A normal application tool may be wired directly into one codebase using a framework-specific interface. An MCP tool uses MCP’s standard discovery and invocation structures, allowing compatible clients to integrate it through a shared protocol.

The label does not make the implementation safer, more reliable, or universally portable. The server may wrap an API, database query, local command, or custom function, each with its own constraints.

Why it matters

MCP tools create a consistent integration surface for model-directed actions. Good tool quality still depends on clear descriptions, narrow schemas, stable behavior, useful errors, and least-privilege permissions.

Builders should treat tool output as untrusted external data and distinguish execution errors from successful results that contain an undesirable business outcome. See [Tool Use in AI Agents](/tool-use-in-ai-agents/) for the broader tool-use loop.