MCP with Claude: Tools, Context and Security

Model Context Protocol gives Claude applications a standard way to discover and use tools, resources, prompts, and related capabilities exposed by external servers. For certification context, the CCA-F exam is the architecture-oriented internal target most closely related to deciding where MCP belongs in a production Claude system.

The current MCP specification, released July 28, 2026, moves the protocol to a stateless core, strengthens authorization, makes lists more cacheable, adds routing-friendly headers, and formalizes extensions. Those changes make MCP easier to scale and govern—and make security design more important because one Claude client can connect to many independent tool and data providers.

MCP separates model reasoning from integration contracts

Without a shared protocol, every Claude integration needs custom code for discovery, authentication, schemas, tool calls, and result handling.

MCP gives clients a common contract for listing tools, reading resources, and obtaining reusable prompts from servers.

This separation makes integrations easier to reuse across applications and lets server owners evolve business logic without embedding it directly into the model prompt.

The architecture is strongest when MCP standardizes connectivity while business authorization and data ownership remain explicit.

This separation also improves organizational ownership. A payroll team can own an MCP server that exposes approved payroll operations while the Claude application team owns orchestration and user experience. The server can enforce payroll policy without exposing its internal database or implementation. A good MCP boundary therefore resembles an internal product API: clear contract, clear owner, least-privilege identity, stable versioning, and observable behavior.

Tools, resources and prompts solve different integration needs

Tools are actions the model can call, resources expose readable data by URI, and prompts expose reusable prompt templates or messages.

A lookup-order capability may be a tool when parameters trigger server logic, while a product-policy document may be a resource and a standardized review instruction may be a prompt.

Do not force every integration into a tool because actions and read-only context have different security and caching behavior.

Clear capability modeling gives Claude a smaller and more understandable interface.

Resources are especially useful for content the model may read repeatedly without changing it, while tools should represent operations whose result depends on arguments or side effects. Prompts can encode organization-approved interaction patterns but should not contain secret authorization logic. Choosing the correct primitive makes caching, review, and security clearer because the client can treat read-only context differently from an action that modifies an external system.

Tool descriptions are part of the model interface

Claude decides whether and how to use a tool from its name, description, input schema, and surrounding instructions.

Use specific names and parameter descriptions and avoid several tools with overlapping purposes that make the model guess.

Return structured success or error state so Claude can reason about the result without parsing human-oriented logs.

The internal Model Context Protocol material provides useful background on the role of MCP in agentic systems.

Test tool descriptions with realistic model behavior rather than only with human reviewers. Give Claude several similar tools and measure whether it selects the intended one under ambiguous language. If selection is unreliable, simplify the catalog, rename tools, or improve schemas before upgrading the model. Tool-interface quality can be the limiting factor in an agent system even when the underlying business APIs and the foundation model are both strong.

The 2026 stateless core changes deployment architecture

The July 2026 MCP revision removes protocol-level session dependence so ordinary load balancing can distribute requests across server instances.

Method and capability names can travel in request headers, which helps gateways route, meter, authorize, and observe traffic without inspecting the full request body.

List responses can include cache hints, reducing repeated tool or resource discovery and stabilizing prompt prefixes.

These changes improve production scalability, but servers still need application state where the business workflow itself is stateful.

Stateless protocol requests do not mean the business operation itself is stateless. A long-running export, approval, or remediation task may still require a server-side task record, durable job ID, or workflow engine. The current MCP extensions model makes that distinction clearer: protocol transport can scale horizontally while task state lives in the application layer that understands ownership, cancellation, retention, and recovery.

Authorization must bind users, clients and servers correctly

The current MCP specification strengthens OAuth-related behavior and emphasizes validating authorization-server identity and binding credentials to the correct issuer.

Enterprise Managed Authorization can centralize server access through organizational identity providers so users do not repeat separate OAuth setup for every connected server.

Server authorization should distinguish read from write or high-risk scopes where appropriate.

A valid MCP connection should never be interpreted as unlimited permission to every downstream system the server can reach.

One important threat is token misuse across servers. An access token issued for one resource should not become a universal credential that another MCP server accepts. Validate audience, issuer, expiry, and scopes, and keep credentials bound to the intended resource. Enterprise environments should also centralize revocation and access review so removing a user or application from a role predictably removes the corresponding MCP capabilities.

Tool risk belongs in policy, not only annotations

MCP tool annotations can describe hints such as whether a tool is read-only, destructive, idempotent, or reaches external systems.

Those hints are useful for clients and reviewers but are not a substitute for deterministic authorization and server-side validation.

High-impact operations should have narrow credentials, explicit input validation, limits, and audit trails even when the annotation says the tool is dangerous.

Treat annotations as risk vocabulary and treat enforcement as application and infrastructure responsibility.

Read-only tools still deserve scrutiny because reading sensitive data can be harmful even when nothing is modified. Conversely, a destructive annotation does not mean a tool must always require a human if the business operation is low-risk, bounded, and reversible. Risk classification should consider data sensitivity, side effects, reversibility, transaction value, blast radius, and user authorization. Annotations can communicate those properties but cannot determine the organization’s policy alone.

Untrusted resources can carry prompt-injection content

Resources may contain email, tickets, web pages, uploaded files, source code, or other content controlled by users or third parties.

Claude should be told that retrieved resource content is data, not system instruction, and trusted instructions should be structurally separated.

Do not let text inside a resource grant access to a new tool or expand the user’s permissions.

Prompt-injection resistance depends on context boundaries, tool authorization, and output validation working together.

The safest architecture assumes external content may contain hostile instructions. Tag source and trust level, keep system policy separate, and require tool calls to pass server-side authorization regardless of what the document says. For sensitive workflows, use allowlisted data sources and sanitization or content review where appropriate. The security goal is not to make Claude unable to read untrusted text; it is to prevent that text from acquiring authority it never had.

Observability should follow the request through the MCP boundary

Distributed tracing is especially valuable when a Claude request calls an MCP server that calls another API or service.

Record model request, tool selection, MCP server, downstream action, result, latency, error, and user or workload identity where policy permits.

The 2026 specification formalizes trace-context propagation so compatible systems can correlate the path more consistently.

A production incident is much easier to diagnose when the organization can see whether the failure came from model selection, client transport, MCP server logic, or the downstream service.

Use trace identifiers that connect the user request to the Claude call, MCP operation, downstream API, and resulting business action. Record enough structured metadata to answer which tool was chosen, which version of the server handled it, whether authorization was evaluated, and what the downstream system returned. Avoid logging secrets or full sensitive payloads by default. Good tracing explains the decision path without creating a second uncontrolled copy of protected data.

Use MCP as a governed integration layer for Claude

The CCDV-F exam is the developer-oriented internal target.

The Anthropic exam inventory can help with internal path navigation.

Architects should define which servers are trusted, which capabilities are approved, what identities flow across the boundary, how tools are contained, and how servers are retired.

Developers then implement schemas, error handling, context assembly, logging, and tests. MCP is most valuable when it simplifies integration without making authorization, provenance, or operational ownership implicit.

Maintain an approved server registry with owner, endpoint, protocol version, data classifications, tools/resources exposed, OAuth configuration, environments, and retirement date. Require review when a server adds a new high-impact tool even if the endpoint is unchanged. This prevents an integration approved for read-only lookup from quietly becoming a write-capable production actor. Governance should follow capability, not merely connection existence.

Before production, run one end-to-end security test in which a low-privilege user connects through Claude to an MCP server exposing both read and write capabilities. Verify discovery, authorization, resource access, tool selection, downstream permission, tracing, and revocation. The exercise should prove that the protocol makes integration easier without turning one connected client into a shortcut around normal business authorization.

A useful final test is to remove one tool or one context source and observe whether the workflow still fails safely. Agents should degrade predictably when a dependency is missing instead of inventing a substitute action. That exercise reveals hidden coupling between prompt context, tool authority, and the assumptions the application makes about external systems.

• Category: All Certifications Certifications