Model Context Protocol gives agent builders a useful vocabulary: servers can expose resources and tools, clients and servers negotiate protocol capabilities, and HTTP transports can use MCP’s authorization model for access to a target server.
The specification does not call context, capability, and consent “planes.” Virillio Code Editorial proposes those terms as an application-level review model for MCP clients. The taxonomy groups several protocol features and product-policy decisions; it should not be read as normative MCP terminology.
The protocol’s modularity leaves an application-level design question:
When an MCP feature appears in an agent, is it information the agent may see, an action it may perform, or a decision it is allowed to make right now?
Those are different questions. Treating them as one “tool integration” is how a client ends up auto-loading sensitive data, presenting destructive actions as harmless context, or requesting a broad OAuth grant before the user has seen the actual operation.
Our proposed model separates three concerns: context, capability, and consent.
Plane 1: Context — what may the agent know?
The MCP resources specification describes server-exposed, URI-identified data such as files, database schemas, or application-specific information. It leaves the interaction model to the host application: a client may show a picker, allow search, or include resources automatically according to its own policy.
That flexibility means the application owns the policy. A resource is not automatically safe to inject into every model turn just because it can be read.
For each resource, a client should answer:
- Is the resource relevant to the current task?
- Is the user aware that it may be passed to a model?
- Is the data appropriately scoped, size-limited, and sanitized?
- Does the resource’s freshness matter, and can the client tell when it changed?
Context is mostly about relevance and disclosure. It can still be sensitive, but it should not be confused with permission to act.
Plane 2: Capability — what may the agent do?
The MCP tools specification defines callable functionality with a name, description, input schema, and optional output schema. It distinguishes protocol errors from tool-execution errors and discusses validation, access control, rate limits, output sanitization, timeouts, audit logging, and confirmation for sensitive operations.
That is a different category from a resource. Reading a resource retrieves context; calling a tool crosses an executable interface. Some tools are read-only, while others might create a branch, send an email, change a subscription, or query a production system. The client needs policy that distinguishes those effect profiles.
The capability question is therefore not “can the model call this?” but “what contractual boundary does this call cross?”
A robust tool registry should preserve enough information to enforce that boundary:
- Tool property: Stable identifier — Why it matters: Prevents ambiguous dispatch and makes auditing possible
- Tool property: Input schema — Why it matters: Rejects malformed or over-broad requests before side effects occur
- Tool property: Output schema — Why it matters: Lets the client validate structured results before model reuse
- Tool property: Side-effect classification — Why it matters: Drives confirmation and permission policy
- Tool property: Timeout and retry policy — Why it matters: Prevents a stuck or repeated call from becoming a hidden workflow
- Tool property: Audit metadata — Why it matters: Makes it possible to explain what was invoked and why
The model should be able to reason over tool descriptions. The host must remain responsible for deciding whether the tool is actually executable.
Plane 3: Consent — what is allowed right now?
In this editorial model, consent is the application-level concern that connects a capability to a specific user, server, scope, and moment. MCP authorization is one input to that decision; the specification does not define the complete product concept of human consent used here.
MCP’s authorization specification requires clients to identify the target MCP server as the resource when requesting a token and recommends least-privilege scope selection with incremental elevation. Servers must validate that tokens were issued for them and must not accept or relay tokens intended for other resources. These are authorization requirements; whether a particular action also requires just-in-time human confirmation is a host-application policy choice.
At the agent-harness level, consent has at least three layers:
- Authorization: Does the client have a valid, audience-bound credential for this MCP server?
- Permission policy: Does the current agent, workspace, or user policy allow this class of action?
- Human confirmation: Has the user approved this specific sensitive operation with enough context to understand its impact?
Those layers should not be collapsed. A valid OAuth token does not imply that a coding agent should send an external message. An allowlisted tool does not mean a particular call is safe without confirmation. And a confirmation dialog should not be asked before the client has verified that the request is structurally valid.
The review matrix
The three planes become concrete when a client applies the right question at the right boundary.
- Interaction: Listing resources — Primary question: What context is available? — Suggested default: Show or index metadata; do not inject contents by default
- Interaction: Reading a resource — Primary question: Is this information relevant and safe to send to the model? — Suggested default: Require task relevance, size limits, and clear provenance
- Interaction: Listing tools — Primary question: What capabilities exist? — Suggested default: Expose descriptions subject to policy; do not execute
- Interaction: Calling a read-only tool — Primary question: Is this operation permitted and bounded? — Suggested default: Validate input, apply timeout, log the call
- Interaction: Calling a side-effecting tool — Primary question: Is this operation permitted and explicitly approved? — Suggested default: Validate, show decisive inputs, request confirmation when policy requires
- Interaction: Requesting OAuth scope — Primary question: Is this scope necessary for the intended server and action? — Suggested default: Start narrow; step up only when the operation requires it
This matrix helps avoid a deceptively common error: treating an agent’s growing context as evidence that it should have more power. Knowledge and authority are related but not interchangeable.
Resource links are not a loophole
MCP tool results may contain resource links or embedded resources. A resource link returned by a tool is not guaranteed to appear in the ordinary resource listing because a tool may discover a context artifact dynamically.
But a dynamically discovered resource still belongs to the context plane. A client should apply the same provenance, size, and relevance rules before passing it to a model. Tool output is not automatically trustworthy just because it came from a server the user authorized. The tools specification explicitly tells clients to validate tool results before passing them to the LLM.
This is an important design principle for agent safety: the route by which data arrived does not determine whether it should influence the model.
A minimal implementation pattern
You do not need a large policy engine to use this model. Start with a small set of explicit records:
- A resource record: URI, source server, MIME type, size, freshness metadata, and inclusion policy.
- A tool record: schema, declared effect category, timeout, confirmation requirement, and audit label.
- A grant record: server identity, scope, expiry, and the user or workspace policy that allowed it.
- A call record: input summary, approval decision, tool result status, and links to any resulting resources.
Then make the orchestration sequence clear:
- Discover features and classify them as context or capability.
- Resolve credentials only for the target server.
- Validate the request against policy and schema.
- Request human confirmation for the action classes that need it.
- Execute with an explicit timeout and retain an audit record.
- Treat returned data as a new context candidate, not as automatically trusted instruction.
What we are learning building Virillio Code
Virillio Code’s MCP integration work remains in development. The current design direction treats resources, tools, permissions, and moment-of-action consent as separate application concerns because they fail differently and may need different UI. This is not a claim that MCP itself mandates the three-part taxonomy.
That separation is especially valuable as tool ecosystems grow. A rich MCP catalog should make an agent more useful without quietly expanding its authority or flooding its context window. The context–capability–consent model is a compact way to keep that promise visible in the runtime, the product surface, and the audit trail.
Sources and further reading
- MCP Resources specification — Resources expose URI-identified server data and leave inclusion UX to the client.
- MCP Tools specification — Tools define callable functionality with schema, validation, access-control, confirmation, and audit concerns.
- MCP Authorization specification — Authorization uses resource indicators, scope minimization, and audience-bound tokens.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.