Model Context Protocol: Architecture & Security Guide

By AI Agent Hub Editorial Desk · Review method · Corrections

The Model Context Protocol (MCP) is an open standard for connecting AI applications to data sources, tools, and reusable workflows. It reduces one-off integration work, but the protocol boundary should be understood before installing a server or exposing a production API.

The three participants

A host can create multiple clients, each connected to a different server. This separation matters: permissions granted to a filesystem server should not silently become permissions for an unrelated remote service.

What servers can expose

• Tools are callable operations. They may calculate a value, query a system, write a file, or trigger a workflow.
• Resources expose context identified by URIs, such as documents, schemas, or application state.
• Prompts are reusable interaction templates offered by a server.

Capability discovery tells the client what is available; it is not a reason to expose every capability to the model. A mature host can progressively disclose tools relevant to the task and apply policy before execution.

Data and transport layers

MCP uses JSON-RPC messages for lifecycle negotiation and protocol operations. Local servers commonly use standard input/output, while remote servers commonly use Streamable HTTP. Transport changes the threat model. A local process may inherit filesystem and user privileges; a remote service adds authentication, authorization, network, redirect, and server-side isolation concerns.

A minimal design exercise

Before writing code, describe one narrow server contract. For a read-only issue tracker server, for example:

Tool: get_issue
Input: { repository: string, issue_number: integer }
Output: { title, body, labels, updated_at }
Authority: read-only access to approved repositories
Errors: not_found | forbidden | rate_limited
Logging: tool name, repository, issue number, outcome

This contract is easier to secure and test than a generic “run API request” tool. Keep input schemas narrow, return structured errors, apply authorization outside the model, and avoid passing arbitrary URLs or shell fragments.

Local server checklist

1. Inspect the package, repository, exact startup command, and transitive dependencies before execution.
2. Run with the least operating-system privilege and limit filesystem and network access.
3. Prefer a dedicated workspace; never assume localhost is inaccessible to malicious browser or process activity.
4. Show the exact command and arguments before one-click installation.
5. Require confirmation before writes, execution, deletion, deployment, or communication.
6. Provide a clear uninstall and credential-revocation path.

Remote server checklist

1. Authenticate the user and authorize each resource or action.
2. Validate token audience; do not pass arbitrary upstream tokens through.
3. Use exact redirect URI validation and CSRF protections in authorization flows.
4. Protect OAuth discovery and redirects against SSRF and internal-network access.
5. Separate tenants in storage, logs, caches, and queues.
6. Rate-limit and audit actions without recording unnecessary sensitive content.

Testing an MCP integration

Test protocol success and policy failure. Verify capability negotiation, schema validation, cancellation, timeouts, malformed messages, permission denial, expired credentials, and a server that returns hostile instructions in otherwise valid data. Confirm that the host does not treat a tool result as higher-priority policy.

Common misconceptions

• “MCP tools are trusted because they are installed.” Installation expands the trusted computing base; it does not prove safety.
• “Read-only means harmless.” Reading secrets or private data can still create a serious breach.
• “The model will ask before dangerous actions.” Approval must be enforced by the host or tool boundary.
• “One broad tool is more flexible.” Broad primitives are harder to validate, authorize, and audit than task-specific operations.

Follow the lifecycle, not just the tool call

1. Connect: establish the transport and authenticate the remote endpoint where required.
2. Initialize: negotiate protocol version and capabilities; reject unsupported or inconsistent peers.
3. Discover: list tools, resources, or prompts and apply host-side visibility policy.
4. Present: show users which server supplies a capability and what authority it requires.
5. Authorize: evaluate user identity, tenant, scope, target, and approval before each consequential call.
6. Execute: send a bounded request with timeout, cancellation, and correlation identifiers.
7. Validate: parse the result as untrusted structured data and enforce size and content limits.
8. Close or revoke: terminate sessions, remove credentials, and invalidate cached capability state when trust changes.

Use a host-side permission manifest

The protocol describes capabilities; the host still needs a local policy. One possible manifest is:

{
  "server": "tickets.example",
  "tenant": "tenant_42",
  "visible_tools": ["ticket_get", "ticket_search", "ticket_addComment"],
  "automatic": ["ticket_get", "ticket_search"],
  "requires_approval": ["ticket_addComment"],
  "resource_allowlist": ["ticket://tenant_42/*"],
  "max_calls_per_run": 20,
  "credential_ref": "vault://mcp/tickets/user_7",
  "expires_at": "2026-08-10T12:00:00Z"
}

Do not let a server response expand this manifest. Approval should bind the tool name, normalized arguments, user, server identity, and a short validity window. If any of those change, ask again.

Transport-specific review

Authorization review for remote servers

• Validate token issuer, signature, expiry, audience, and required scopes.
• Do not accept a client token and pass it unchanged to a downstream API.
• Use exact registered redirect URIs and bind authorization responses to the initiating client and browser session.
• Display the requesting client, requested third-party scopes, and destination before consent.
• Protect discovery, dynamic registration, callbacks, and redirects against SSRF and internal-network access.
• Store refresh tokens encrypted and separately by user, client, server, and tenant.
• Re-evaluate authorization on each call; capability discovery is not an access grant.

Reproducible integration test matrix

Incident response and removal

1. Disable the server connection or specific capability without waiting for a full application release.
2. Revoke user grants and rotate any credentials available to the server process.
3. Preserve a minimal audit trail: server identity, tool, normalized target, user, authorization result, and time.
4. Search for related calls while avoiding unnecessary prompt or document disclosure.
5. Invalidate cached tool definitions and authorization metadata.
6. Patch or remove the server, rerun the adversarial suite, and document the new trust decision before reconnecting.

Primary references

• MCP introduction
• MCP architecture overview
• MCP security best practices
• MCP client best practices

What MCP tool calls cost

Model Context Protocol makes it easy to attach tools, and each attachment adds context that is sent on every relevant call. The protocol is cheap; the context it carries is not free. Below: one tool-using request at 25K input, 15K cached, 2.5K output. Of the 25,000 input tokens, 15,000 are billed at the cache-read rate and 10,000 at full input rate.

The interesting comparison is the two small models: they differ by a factor of two while both being far below the flagship, which suggests that for tool-heavy traffic the decision is mostly about how much context the server injects, not about the token rate.

Rates verified against provider documentation on September 18, 2026. Promotional rates expire, so re-check before budgeting: LLM API cost planning · September 2026 pricing update. Run your own numbers in the cost calculator.