Wiki · Concept · Last reviewed June 25, 2026

MCP Tools

MCP tools are the Model Context Protocol server feature for exposing callable external capabilities to model-driven clients through named tools, input schemas, tool calls, results, and governance boundaries.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Tool Use, AI Agents, Security, Governance, Audit Trails

Definition

MCP tools are callable capabilities exposed by a Model Context Protocol server. The versioned 2025-11-25 MCP tools specification describes tools as a way for servers to let language models interact with external systems, such as databases, APIs, and computation services. Each tool has a unique name and metadata that describes how it should be called.

The important distinction is operational. A prompt can frame a task, and a resource can provide context, but a tool is where the model-mediated session can trigger work outside the text window. That makes tools adjacent to Tool Use and Function Calling, AI Agent Sandboxing, and AI Audit Trails.

Protocol Surface

A server that supports tools declares the tools capability during capability negotiation. The capability can include listChanged, which indicates whether the server will notify clients when the available tool list changes. Tool discovery happens through tools/list, and the tools page states that this operation supports pagination.

A tool definition includes fields such as name, optional display title, description, icons, inputSchema, optional outputSchema, optional behavior annotations, and execution metadata. The specification says the input schema is a JSON Schema object, defaults to JSON Schema 2020-12 when no $schema field is present, and must not be null. For no-parameter tools, the recommended shape is still an object that explicitly accepts no additional properties.

Tool names are not decorative. The spec recommends case-sensitive names, uniqueness within a server, and a restricted character set using ASCII letters, digits, underscore, hyphen, and dot. A governed client should treat a changed name, schema, description, annotation, or output schema as a fresh review event.

Calling Tools

Tool invocation uses tools/call with the tool name and an arguments object. Results can return unstructured content blocks such as text, images, audio, resource links, or embedded resources, and can also return structured content. When an output schema is supplied, the spec says servers must provide structured results that conform to it and clients should validate those structured results.

Error handling has two layers. Protocol errors cover issues such as unknown tools, malformed requests, and server errors. Tool execution errors are reported inside tool results with isError: true and can include feedback that a model may use to repair a later call. This distinction matters for logging: a failed HTTP-like request is not the same evidence as a business-rule rejection inside a tool result.

Lifecycle Role

MCP Lifecycle places tools inside initialization and capability negotiation. The lifecycle example shows a server advertising tools and a task capability for tools/call. After successful initialization, normal protocol communication can proceed. Before that, a client should not assume that a tool exists merely because it saw a previous server description or cached registry entry.

This makes stale discovery a governance problem. A client that caches a tool list should know when it was fetched, which server identity supplied it, which protocol version applied, and whether the server later emitted a list-changed notification.

Governance Requirements

The MCP tools page recommends strong safety controls around tool use: visible user interface for exposed tools, visual indicators when tools are invoked, and confirmation prompts for operations. Its security section also says servers must validate tool inputs, implement access controls, rate limit invocations, and sanitize tool outputs; clients should confirm sensitive operations, show inputs before calling the server, validate results before passing them to the language model, use timeouts, and log tool usage for audit.

A production tool log should preserve the server identity, protocol version, tool name, schema hash, visible description, visible annotations, arguments, approval path, calling model or policy engine, result type, isError value, downstream service, authorization context, timeout, retry, cancellation status, and redaction policy. Logs should also record whether the call changed external state or only read from it.

Authorization must live below the label. A tool that says it searches a database should still have least-privilege credentials. A tool that returns structured content should still be validated. A tool that claims to be read-only through MCP Tool Annotations should still be treated as untrusted unless the server itself is trusted and governed.

Failure Modes

Descriptor trust. The model and the user interface over-trust a tool description or annotation while the implementation has broader side effects.

Schema laundering. A schema appears narrow, but fields are interpreted by the downstream service in wider, hidden, or policy-relevant ways.

Open-world injection. A tool retrieves untrusted web, email, repository, document, or chat content and returns it to the model as if it were safe instruction context.

Result confusion. A tool execution error is displayed as ordinary assistant text, or a protocol error is treated as a model-correctable business-rule failure.

Retry harm. A timeout or model retry repeats a non-idempotent call such as sending, purchasing, deleting, publishing, or permission changing.

Source Discipline

Claims about tool discovery, tools/list, tools/call, schemas, result structure, errors, and tool security should cite the versioned MCP tools page. Claims about capability negotiation should cite the lifecycle page. Claims about confused-deputy risk, token passthrough, local-server compromise, dangerous authorization URLs, and scope minimization should cite MCP Security Best Practices.

Spiralist Reading

An MCP tool is the moment when language leans on a lever.

The Spiralist concern is not that tools exist. Tools are how agent systems become useful. The concern is that a sentence, a schema, and a pretty confirmation screen can make action look cleaner than it is. The discipline is to keep the lever named, scoped, logged, and interruptible.

Open Questions

Sources

Return to Wiki