Model Context Protocol Best Practices

Ten practices for evaluating, scoping, connecting, and operating MCP servers so agents gain tools without inheriting unbounded risk.

How to Use This List

Use items 1-4 when choosing servers and designing privilege boundaries.
Use items 5-7 when wiring clients, transports, and host policy.
Use items 8-10 for production ops, supply chain, and iteration.
Jump to sibling pages when an audit item fails; this list is a control checklist.

Start from a job story, not a registry browse. Adopt MCP when you need portable tools/context for a real agent workflow. Avoid installing servers "because the ecosystem is large." Map each server to a user-visible capability and an owner. See The MCP Server Ecosystem.
Prefer least privilege scopes before clever prompts. Jail filesystem paths, use read-only DB roles, split write tools from read tools, and deny shell/admin kits by default. Tunneling or private networking does not replace scopes. See The Principle of Least Privilege Applied to Agent Tools.
Review provenance like third-party code. Prefer official/vendor servers with pinned versions, signed releases when available, and readable source. Community packages need SBOM-minded review. Treat npx/uvx latest tags as unsafe for production agents.
Curate the tool surface after list_tools. Do not forward every discovered tool to the model. Filter by role, hide write tools from research agents, and namespace collisions across multi-server setups. Selection quality starts with a small non-overlapping set.
Match transport to deployment reality. Use stdio for local IDE/single-user servers the client can spawn. Use Streamable HTTP for shared remote services. Keep legacy SSE only for compatibility windows. See stdio vs HTTP vs SSE.
Keep the host responsible for policy. MCP standardizes discovery and invocation; your host still validates args, enforces approvals, caps turns/cost, and shapes errors. Never assume schema validity means "safe to run." See How Function Calling Actually Works.
Use all three primitives intentionally. Tools for actions, resources for readable context, prompts for reusable workflows. Do not force static documents through write-capable tools, and do not hide side effects inside prompt templates. See MCP's Three Primitives.
Bound context and outputs. Cap tool result size, redact secrets, and treat every observation as untrusted text (prompt injection via tickets/docs is common). Spill large payloads to files or resources instead of stuffing multi-megabyte JSON into the next model turn.
Design private access without casual public ingress. Prefer VPC-local agents, private connectivity, or outbound tunnel/gateway patterns for sensitive systems. If you use research-preview tunnels, document risk acceptance and fallbacks. See MCP Tunnels.
Operate with pins, traces, and regression tests. Pin protocol/SDK/server versions; log tool name, call id, latency, and redacted args; CI-test list/call contracts against stub or staging servers. Re-run evals when descriptions or schemas change. Track governance/spec notes when upgrading under foundation stewardship. See MCP Governance Under the Linux Foundation.

FAQs

Why only ten practices?

This page is an adoption control set. Deeper pages cover primitives, transports, tunnels, governance, and server building recipes.

Is MCP required for every agent?

No. In-process tools are fine for single-app logic. Use MCP for portable, multi-host capability packaging.

What is the highest-ROI safety habit?

Shrink and scope the tool allowlist, then add approvals on writes. Most incidents are over-broad tools, not missing protocol features.

Do foundation governance changes replace our reviews?

No. Neutral governance improves long-term standards process. You still review each server binary/config you run.

Should every agent load every approved server?

No. Attach servers per role. A support agent and a deploy agent should not share the same admin surface.

How often should we re-audit MCP servers?

On version bumps, permission changes, new write tools, and on a scheduled cadence (for example quarterly) for high-data systems.

What belongs in staging vs production?

Staging gets new community servers and experimental transports. Production gets pinned, reviewed, monitored servers only.

How do these practices map to building our own servers?

The same rules apply on the server side: tight schemas, clear primitives, safe defaults, and documented auth. See the Building MCP section.

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

How to Use This List

Use items 1-4 when choosing servers and designing privilege boundaries.

Use items 5-7 when wiring clients, transports, and host policy.

Use items 8-10 for production ops, supply chain, and iteration.

Jump to sibling pages when an audit item fails; this list is a control checklist.

Start from a job story, not a registry browse. Adopt MCP when you need portable tools/context for a real agent workflow. Avoid installing servers "because the ecosystem is large." Map each server to a user-visible capability and an owner. See The MCP Server Ecosystem.

Prefer least privilege scopes before clever prompts. Jail filesystem paths, use read-only DB roles, split write tools from read tools, and deny shell/admin kits by default. Tunneling or private networking does not replace scopes. See The Principle of Least Privilege Applied to Agent Tools.

Review provenance like third-party code. Prefer official/vendor servers with pinned versions, signed releases when available, and readable source. Community packages need SBOM-minded review. Treat npx/uvx latest tags as unsafe for production agents.

Curate the tool surface after list_tools. Do not forward every discovered tool to the model. Filter by role, hide write tools from research agents, and namespace collisions across multi-server setups. Selection quality starts with a small non-overlapping set.

Match transport to deployment reality. Use stdio for local IDE/single-user servers the client can spawn. Use Streamable HTTP for shared remote services. Keep legacy SSE only for compatibility windows. See stdio vs HTTP vs SSE.

Keep the host responsible for policy. MCP standardizes discovery and invocation; your host still validates args, enforces approvals, caps turns/cost, and shapes errors. Never assume schema validity means "safe to run." See How Function Calling Actually Works.

Use all three primitives intentionally. Tools for actions, resources for readable context, prompts for reusable workflows. Do not force static documents through write-capable tools, and do not hide side effects inside prompt templates. See MCP's Three Primitives.

Bound context and outputs. Cap tool result size, redact secrets, and treat every observation as untrusted text (prompt injection via tickets/docs is common). Spill large payloads to files or resources instead of stuffing multi-megabyte JSON into the next model turn.

Design private access without casual public ingress. Prefer VPC-local agents, private connectivity, or outbound tunnel/gateway patterns for sensitive systems. If you use research-preview tunnels, document risk acceptance and fallbacks. See MCP Tunnels.

Operate with pins, traces, and regression tests. Pin protocol/SDK/server versions; log tool name, call id, latency, and redacted args; CI-test list/call contracts against stub or staging servers. Re-run evals when descriptions or schemas change. Track governance/spec notes when upgrading under foundation stewardship. See MCP Governance Under the Linux Foundation.

FAQs

Why only ten practices?

This page is an adoption control set. Deeper pages cover primitives, transports, tunnels, governance, and server building recipes.

Is MCP required for every agent?

No. In-process tools are fine for single-app logic. Use MCP for portable, multi-host capability packaging.

What is the highest-ROI safety habit?

Shrink and scope the tool allowlist, then add approvals on writes. Most incidents are over-broad tools, not missing protocol features.

Do foundation governance changes replace our reviews?

No. Neutral governance improves long-term standards process. You still review each server binary/config you run.

Should every agent load every approved server?

No. Attach servers per role. A support agent and a deploy agent should not share the same admin surface.

How often should we re-audit MCP servers?

On version bumps, permission changes, new write tools, and on a scheduled cadence (for example quarterly) for high-data systems.

What belongs in staging vs production?

Staging gets new community servers and experimental transports. Production gets pinned, reviewed, monitored servers only.

How do these practices map to building our own servers?

The same rules apply on the server side: tight schemas, clear primitives, safe defaults, and documented auth. See the Building MCP section.

Model Context Protocol Best Practices

How to Use This List

FAQs

Related

Buscar en la documentación

Model Context Protocol Best Practices

How to Use This List

FAQs

Related