Tool Use and MCP

Tool use lets a model propose a structured operation that application code validates and executes. The result becomes input for a later model decision or answer. The model does not gain database, filesystem or network access merely by generating a tool-call object.

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to external tools and contextual data. It standardizes integration messages and capabilities. Business authorization, safe execution and correct use of results remain application responsibilities. This chapter checks protocol details against the 2026-07-28 specification, the current revision at this September 2026 review. MCP specification.

Follow one tool call across the boundary

For a support assistant, lookup_order can return an order's current status. The application should derive the caller's identity from authenticated state and verify access to the order. A model-provided order ID is a requested object, not proof that the caller owns it.

sequenceDiagram
    participant Model
    participant Runtime as Application runtime
    participant Policy as Authorization policy
    participant Tool as Order service adapter
    Model->>Runtime: Proposed lookup_order arguments
    Runtime->>Runtime: Validate schema and limits
    Runtime->>Policy: May this identity read this order?
    Policy-->>Runtime: Permit or deny
    Runtime->>Tool: Execute permitted lookup with deadline
    Tool-->>Runtime: Typed result or explicit error
    Runtime->>Runtime: Validate shape, scope and provenance
    Runtime-->>Model: Bounded tool result

The permit path is shown; a denial stops execution. A service timeout produces an unknown or failed outcome according to the operation's contract, not a fabricated success.

Define a tool that is easy to use correctly

The tool contract should state:

1. What the operation does and when it is appropriate.
2. Required arguments, formats, units, bounds and defaults.
3. Required authorization and object-level scope.
4. Output shape, source version and error meanings.
5. Whether it changes external state.
6. Deadline, cancellation and retry/idempotency behavior.

An illustrative input schema for a read operation is:

{
  "type": "object",
  "properties": {
    "order_id": {
      "type": "string",
      "pattern": "^ORD-[0-9]{8}$",
      "description": "The order identifier from the user's authorized context."
    }
  },
  "required": ["order_id"],
  "additionalProperties": false
}

Validate the generated arguments at execution time. A schema shown to a model does not enforce anything by itself. A syntactically valid order ID can still identify an unauthorized object. Pydantic, Zod or JSON Schema validators can enforce shape, while service code enforces business rules.

For a SQL tool, “read-only” in the description is insufficient. Use appropriate database privileges, parameterized operations or a validated query interface, bounded result size and execution time. A model-generated confidence score is not an authorization check.

Understand the MCP participants and primitives

Core method names include tools/list, tools/call, resources/list, resources/read, resources/templates/list, prompts/list and prompts/get. A resource listing is not a tool listing. A host may select relevant tool schemas after discovery, but MCP does not automatically decide which tools belong in every model prompt. Tools, resources, prompts.

Tools can advertise metadata and annotations, but the host must evaluate their trustworthiness. Discovery tells the host what a server claims to offer, not whether the implementation is safe or whether the user authorized an action.

Provider tool calling and MCP fit at different layers

A host can discover an MCP tool, expose an appropriate schema through its model provider, then dispatch the resulting call through MCP. Native tool calling is not only for prototypes, and every internal function does not need a remote MCP server. Choose a protocol boundary when reuse, interoperability or independent operation justifies it.

Use the current transport and version model

MCP uses JSON-RPC messages. Standard transports include stdio, where a client communicates with a subprocess through its standard streams, and Streamable HTTP, where messages use HTTP POSTs and responses may be JSON or request-scoped SSE streams. Streamable HTTP is not defined as one permanent bidirectional connection carrying every call. Transport specification.

MCP revisions use dates. Referring loosely to “MCP 2.0” can confuse a protocol revision with an SDK's major version. Streamable HTTP was already introduced in the 2025 revisions; it was not first ratified in March 2026.

The July 2026 revision changes important integration assumptions:

Roots, Sampling and Logging are deprecated features in this revision, with documented migration paths. The former server-initiated request mechanism was removed. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, while remaining available for backward compatibility. Revision changelog.

Stateless protocol messages do not imply a stateless business service. Orders, workflows and idempotency records still require application storage. A server can return a state handle, but every subsequent operation must authorize the caller against that state. Older clients may require a compatibility path; removing their handshake without version detection breaks them.

Resume input and long-running work safely

sequenceDiagram
    participant Client
    participant Server
    participant Store as Operation state
    Client->>Server: Call scoped operation
    Server-->>Client: input_required and requestState
    Client->>Client: Collect required input under host policy
    Client->>Server: Retry with inputResponses and requestState
    Server->>Store: Validate ownership and current operation state
    Store-->>Server: Authorized state
    Server-->>Client: Completed result or task handle

The exact message shape follows the selected revision and extension. In current tool results, resultType distinguishes completion from an input-needed result. Protocol errors and tool-execution errors also have different meanings; receiving a valid JSON-RPC response does not prove that the requested operation succeeded. Tool result contract.

For long operations, define durable identity, polling, cancellation, expiration, result retention and retry behavior. The Tasks extension provides protocol mechanisms; the service still needs to make its side effects reliable. Never equate a JSON-RPC request ID with a durable business idempotency key.

For example, if a request to issue a credit times out, retrying with a new transport ID may issue a second credit unless the service recognizes the original operation. Reconcile by business operation ID or use an idempotent credit endpoint before reporting the outcome.

Authenticate the caller and authorize the action

The HTTP authorization specification defines discovery and token-handling requirements for protected MCP servers. Validate tokens for their intended resource, issuer, expiration and allowed scope; do not forward an unrelated upstream token as though it authorizes the MCP service. Bind persisted client credentials to their issuer. Select the supported authorization flow for the client type rather than prescribing an interactive user flow for every machine client. Authorization specification.

Enterprise-Managed Authorization can let an organization provision access through its identity provider. That changes how access is established; it does not remove per-operation business authorization. Host, identity provider and server support must be compatible. Extension announcement.

For local stdio servers, execution typically occurs with the privileges of the launched process. A separate process is not automatically a sandbox. Restrict filesystem, network, credentials and resources according to what the tool actually needs. A network-reading tool cannot work in an environment with all network access disabled; use narrowly permitted destinations where appropriate.

Moving the same unsafe shell-executing code from stdio to HTTPS does not fix command injection. TLS protects the connection, not the service's internal execution logic.

Design against the actual threats

MCP's security guidance explicitly addresses state-handle hijacking and local server compromise. Preserve those checks across every request and tool path. Security guidance.

Approval policy should reflect the actual action and existing user authorization. Give users understandable controls for consequential capabilities. Repeated approval for every harmless lookup is not a substitute for enforcing real boundaries, and approval of one operation does not grant unlimited future access.

Manage a large tool catalog

1. Discover only permitted servers and capabilities.
2. Cache catalogs according to their freshness and visibility rules.
3. Select a relevant subset of tool definitions for the task.
4. Preserve a way to discover another permitted tool when the first subset is insufficient.
5. Evaluate missed-tool selection, wrong-tool calls, argument errors and schema-token overhead.

Stable naming, distinct descriptions and unambiguous schemas help selection. Test overlapping tools such as search_orders and search_articles on ambiguous questions. Hundreds of available tools do not mean hundreds of schemas must be sent on every invocation; selective exposure is a host design decision that can also introduce a recall bottleneck.

Streaming a proposed call can improve responsiveness, but incomplete arguments are not ready for execution. Wait for a complete validated call before a consequential action. Carefully scoped speculative reads may be possible, with authorization, cancellation and waste accounting; there is no universal 400–800 ms saving.

Distinguish tool access, delegation and packaging

A2A describes agents using Agent Cards and supports messages, tasks, status and artifacts. Its documented discovery path is /.well-known/agent-card.json. Cards may be signed; trust depends on validating the signature and its key/source, not merely seeing a signature field. Protocol and language-SDK versions are different version lines. A2A specification.

The IBM-originated Agent Communication Protocol has joined A2A; its own documentation points readers to migration guidance. “ACP” is also used for other protocols, so expand the name rather than treating the acronym as a unique standard. ACP project notice.

Work through a delegation boundary

Imagine a support assistant allowed to read an order and prepare a credit request. A separate credit service owns approval rules and ledger access. The support assistant can delegate the authorized task; delegation must carry the required identity/scope, explicit requested operation and correlation identity.

sequenceDiagram
    participant Support as Support application
    participant Orders as Order MCP server
    participant Credit as Credit agent service
    participant Ledger as Scoped ledger adapter
    Support->>Orders: Authorized order lookup
    Orders-->>Support: Order facts and revision
    Support->>Credit: Delegate scoped credit request
    Credit->>Credit: Validate caller, eligibility and authorization
    Credit->>Ledger: Authorized idempotent operation
    Ledger-->>Credit: Confirmed result or unknown outcome
    Credit-->>Support: Task status and verified artifact

This diagram describes the application flow, not invented wire method names. Use the selected A2A binding and revision for exact messages. A service behind another agent must independently enforce its permissions; delegation does not legitimize an action the original caller was not allowed to request.

Some applications need only direct tool calls or a shared workflow runtime. MCP and A2A can be complementary, but using both is not mandatory for every production system.

Package capabilities carefully

Agent Plugins 1.0 defines a portable package with a root plugin.json, optional skills and MCP configuration, and namespaced client-specific additions. A simplified layout is:

documentation-tools/
  plugin.json
  skills/
    api-review/
      SKILL.md
  mcp.json
  com.example.client/

The portable surface and schema versions follow the specification. A host's support for one plugin format does not imply support for every vendor-specific hook or extension. The runtime-provided PLUGIN_ROOT and PLUGIN_DATA distinguish installed files from persistent plugin data. Manifest environment values are visible configuration, not a secret store. Agent Plugins specification.

Review installed code and instructions as dependencies, pin suitable versions and constrain capabilities. A package signature can establish provenance under a trusted key policy; it does not prove the package's behavior is harmless. Avoid unsupported detection percentages as a reason to trust a scanner.

Computer use and documentation tools

Computer-use tools expose operations such as screenshot capture, pointer movement and keyboard input. Shell and file-edit tools expose different interfaces; they are not all equivalent to browser control. Their names, schemas, supported model versions and runtime behavior are provider-specific, so pin and test the actual integration.

The application must implement the tool actions, validate the observed UI state and enforce environment permissions. Screenshots can become stale and page content can be adversarial. Prefer a purpose-built API when it gives the needed stable semantics. A sandbox, bounded loop and explicit outcome verification remain useful for UI automation; no universal environment variable configures these limits across providers.

Documentation retrieval tools can reduce reliance on stale training data. Context7 currently exposes resolve-library-id and query-docs; these are tools, not MCP resource-listing methods. Resolve the correct library/version and inspect relevant documentation before using an API. The tool's installation alone does not guarantee that a host will invoke it or that every answer is current. Context7 repository.

Interview practice

Q1: What problem does MCP solve?

It standardizes integration between an AI host and services exposing tools, resources and prompts. It can reduce repeated connector work. It does not replace the model's tool-selection interface, business authorization or execution isolation.

Q2: How do you make a tool read-only?

Enforce that property in the implementation and downstream credentials, with bounded inputs and results. A description or annotation helps the model choose correctly but is not a security mechanism. Test attempts to bypass the intended operation.

Q3: Does stateless MCP eliminate server-side state?

It removes protocol-level session assumptions in the current revision. Business state, operation records and task results still exist where the application needs them. Every request must authorize access to any supplied state handle.

Q4: How does MCP address too many tools?

It provides discovery and capability interfaces. The host can select a relevant subset of schemas and discover more when needed. I would evaluate selection recall and wrong-tool errors; resources/list does not automatically attach the correct tools to the model.

Q5: What happens if a write tool times out?

Determine whether the outcome is known. Use a durable operation ID, status reconciliation or idempotency contract before retrying. A new protocol request ID cannot establish that the previous action did not execute.

Q6: Is an HTTP MCP server safer than a local subprocess?

They expose different trust boundaries. HTTPS and token authorization help secure remote access; local processes need restricted privileges and reviewed code. Neither transport repairs unsafe command construction or excessive downstream privileges.

Q7: When would you add A2A?

When communicating with a separately operated agent service benefits from standardized discovery, task status and artifacts. Define delegated authority, identity propagation and failure semantics. Direct tool integration may be simpler within one service boundary.

Q8: Can you execute streamed tool arguments before completion?

Not a consequential action. The final arguments may differ or fail validation. Any speculative read needs a permitted scope and a measured latency benefit that justifies wasted work and cancellation complexity.

Q9: What must be tested during an MCP revision upgrade?

Version detection, metadata, transport behavior, tool/result schemas, authorization, mid-call input, task handling and supported older clients. Separate the protocol upgrade from SDK package numbering and retain application idempotency and access checks.

Final notes

Recall card: Discover → select → validate → authorize → execute → verify → record. Protocol interoperability makes integrations easier to connect; the application still owns their meaning and consequences.