MCP Servers, Clients, and Trust Boundaries
Model Context Protocol standardizes how an AI host discovers and uses external resources, prompts, and tools. MCP improves interoperability; it does not make a server trustworthy or a tool safe. Clients must authenticate servers, constrain capabilities, validate results, preserve user consent, and enforce the same authorization, budgets, and audit rules as any integration.
What will you be able to do?
- explain MCP host, client, server, tools, resources, and prompts;
- decide whether a capability belongs in an internal API or MCP server;
- design tenant-safe MCP tools and read-only resources;
- threat-model local and remote transports.
What is the mental model?
- The host is the AI application coordinating model and user experience.
- An MCP client maintains a connection to one server.
- An MCP server advertises capabilities.
- Tools request actions or computations.
- Resources expose addressable context.
- Prompts expose reusable prompt templates.
Protocol negotiation tells you what is available, not what should be allowed. Maintain an application allow-list and policy per server, tool, tenant, environment, and effect class.
How should SupportDesk AI expose capabilities?
Good candidates are narrow and application-owned:
- resource: an authorized ticket summary by opaque URI;
- resource: approved knowledge passage with source metadata;
- tool: create an unsent ticket reply draft;
- tool: request human approval for a specified action.
Avoid generic SQL, filesystem, shell, HTTP fetch, secret access, or cross-tenant search. Server code derives tenant context from authenticated credentials, not a tool argument.
Which threats matter?
- malicious or compromised server returns instructions or poisoned content;
- tool-name collision or capability change after approval;
- local server inherits excessive filesystem/environment access;
- remote server impersonation, credential theft, or confused deputy behavior;
- token forwarding to an unintended audience;
- result injection manipulates later model behavior;
- unbounded resources exhaust context, memory, or cost.
Pin trusted origins/packages where possible, isolate local processes, use minimal environment and filesystem access, validate transport identity, request explicit consent for consequential capabilities, and display the exact server/tool/action to users.
Why does this matter in AI-native systems?
MCP can prevent bespoke integration sprawl, but central discovery can also expand an agent's authority. Treat each server as a third-party dependency and each returned value as untrusted input. Standard protocol envelopes do not validate semantic truth.
Common mistakes
- Auto-approving every discovered tool.
- Passing the user's broad bearer token to arbitrary servers.
- A local MCP process receives the entire environment, including secrets.
- Resource contents are inserted as system policy.
- Tool schema changes without re-review or contract tests.
- No audit correlation between host run and server effect.
AI Pair-Programmer Prompt
Exercise
Design an MCP server for read-ticket-summary and create-reply-draft plus a client policy. Add a malicious resource containing instructions to reveal another tenant and call a hidden tool.
Acceptance criteria: the content is treated as data, unavailable capabilities cannot be invoked, server credentials are least-privileged, tenant scope is server-enforced, and every call maps to the host AI-run trace.
Knowledge check
- Does MCP discovery grant permission?
- Are MCP resource contents trusted instructions?
- Why isolate a local MCP server?
Answers
- No; application policy and user consent determine permission.
- No; they are untrusted external data.
- It may be compromised and otherwise inherit filesystem, environment, and network authority.
Completion checklist
Primary references