CORE GUIDE
MCP boundaries
MCP connects models to external capabilities, but the protocol boundary should not be mistaken for a permission boundary; clients and runtimes still need explicit trust, capability and side-effect controls.
Mental model
An MCP boundary defines what capability metadata, inputs, outputs and lifecycle cross between client and server. Security and reliability come from how the application scopes, validates and authorizes those capabilities, not from the existence of the protocol itself.
Why it matters
Teams can adopt MCP and accidentally widen the reachable action surface because discovery becomes easier. A clear boundary keeps interoperability separate from authority: a server advertising a tool does not mean every agent or user should be allowed to call it, and a valid response does not mean the side effect was appropriate.
01
Treat protocol discovery and runtime authorization as separate steps
Inventory the capabilities an MCP server exposes, then filter them through application policy before presenting them to the model. Validate input/output schemas, attach user and task context to authorization decisions, and put approvals or irreversible-action gates around consequential operations. Log negotiated capabilities so incident review can reconstruct what was reachable.
02
Example: CRM server exposes export and read tools
An MCP CRM server advertises both read_customer and export_all_customers. A support agent only needs scoped reads, so the client exposes the read capability and withholds export. The protocol remains interoperable while the runtime preserves least privilege and can request additional capability only through an explicit approval path.
Common failure modes
- Assuming every discovered MCP capability should be exposed to the model.
- Treating schema validity as proof that an action is authorized.
- Using MCP adoption as a reason to bypass existing approval or audit boundaries.
Engineering heuristics
- Separate capability discovery from capability authorization.
- Scope tools to the current task and user before model exposure.
- Keep consequential actions behind runtime policy, approval and audit.
Takeaways
- 01MCP standardizes capability exchange, not trust.
- 02Protocol reachability is not equivalent to permission.
- 03Least privilege still belongs to the application runtime.
Reading evidence
This records actions you actually took; it does not claim mastery, proficiency, or certification.
Used in
This Concept is reused across these canonical learning paths.
Related concepts from the Knowledge Graph
These relationships come from the canonical graph, not a separate Guide taxonomy.