MCP Tools Explained: How AI Agents Take Action
A practical guide to MCP tools, including schemas, discovery, execution, approvals, errors, and safe production design.
A practical guide to MCP tools, including schemas, discovery, execution, approvals, errors, and safe production design.
Servers expose tools with names, descriptions, and input schemas.
MCP tools are the action surface of a Model Context Protocol server. They let an AI application request calculations, database queries, API calls, file operations, or business actions through a structured contract.
The key word is request. A model may propose a tool call, but the host application must decide whether that call is available, valid, and authorized.
TL;DR
- Servers expose tools with names, descriptions, and input schemas.
- Clients discover tools before invoking them.
- Model output is a proposal, not permission.
- The host should validate, authorize, and sometimes request human approval.
- A small set of task-level tools is usually better than a mirror of backend endpoints.
What is an MCP tool?
An MCP tool is a server-exposed operation that a client invokes with structured arguments. A tool may read information, such as getorderstatus, or change an external system, such as create_refund.
The server gives each tool a unique name, description, and input schema. Good metadata explains intent, boundaries, and expected use. A name such as do_action gives the model almost no useful guidance.
Discovery before execution
A client asks a server for its current tool list. The host may filter that list by user, tenant, task, environment, or risk before converting selected definitions into its model provider format.
Discovery is not authorization. A server might advertise a refund tool while the current user may only read orders. The host should not expose that tool, and the server must still enforce permission if a request arrives.
A complete call
A customer asks, "Where is order 4812?"
- The host gives the model the approved tool definition.
- The model proposes getorderstatus with order ID 4812.
- The host validates the name and arguments.
- The host checks object-level permission.
- The client sends a tools/call request.
- The server validates again and calls the backend API.
- The server returns structured result content.
- The host supplies useful content to the model.
If the next action creates a ticket or refund, the host can show a confirmation before sending the state-changing call.
Different tools need different controls
| Tool type | Example | Typical controls |
|---|---|---|
| Read-only | getorderstatus | Identity, object access, rate limit |
| Reversible write | addticketnote | Confirmation, audit log, idempotency |
| High-impact write | issue_refund | Strong approval, amount limit, reconciliation |
| Communication | sendcustomeremail | Preview, recipient validation, approval |
Schemas validate shape. They do not prove business permission. A refund request can be perfectly shaped and still unauthorized.
Design tools models can use
Prefer task-level operations with narrow scope. createapprovedrefund is easier to govern than a generic call_api. Use bounded enums, specific arguments, useful descriptions, and structured outputs.
Avoid huge raw payloads. Return the fields needed to continue while preserving identifiers and provenance for auditing.
Errors are part of the contract
Separate invalid input, permission denial, downstream failure, timeout, and business rejection. A timeout on an idempotent read may be retried; a refund with an unknown outcome must be reconciled first.
Never let fluent model prose hide failure. Tell the user an action succeeded only after a confirmed result.
Common mistakes
- Exposing every backend endpoint.
- Treating schema validation as authorization.
- Sending the full catalog to every model request.
- Allowing arbitrary URLs, queries, or shell commands.
- Retrying writes without idempotency protection.
- Trusting tool output as safe prompt content.
Builder checklist
- Can a user understand the action before approval?
- Are credentials minimally scoped?
- Are arguments validated by host and server?
- Is the result bounded and attributable?
- Are duration, outcome, server identity, and approval recorded?
- Is there a recovery plan for ambiguous failure?
My Take
The best MCP tool catalogs are not the largest. They are the ones where every operation has a clear purpose, a narrow permission boundary, and an observable outcome.
Continue learning
Review [What Is MCP?](/what-is-mcp/), [Tool Use in AI Agents](/tool-use-in-ai-agents/), and [MCP Security and Permissions](/mcp-security-and-permissions/).
