Resource Design Guide

A resource in the MCP sense is not a raw database dump. It is readable data context, structured, filtered, and tailored to the agent that currently needs it. While a tool executes an action, a resource provides the context on which meaningful decisions can be made.

Resources with kind="resources" describe exactly that: which context objects a system provides, how they are structured, and what protection level they carry.

Effective AI Access

Data access for AI cannot be reduced to a single question. The correct model is additive:

User Permission
+ Agent Permission
+ Client Trust Level
+ Resource Sensitivity
+ Purpose
+ Context
+ Confirmation State
= Effective AI Access

Each of these factors can restrict access, even if all previous ones would in principle permit it.

This is too coarse. User permissions and AI permissions are different dimensions. A user acts consciously, in context, with responsibility. An agent acts automatically, without judgment about sensitivity, within a scope that must be clearly bounded.

Example: Salary data

The executive fundamentally has access to salary data, that is their user permission. A Sales Assistant Agent running in the context of this user should still not have this data in its context.

Why: the agent has a clearly defined purpose (contact management, follow-ups, project work). Salary data lies outside this purpose. The agent permission and purpose exclude the access, regardless of what the user themselves may see.

User Permission:     ✓ (executive may see salary data)
Agent Permission:    ✗ (Sales Assistant has no salary:read scope)
Resource Sensitivity: sensitive
Purpose:             Contact management / project work
= Effective AI Access: denied

Redaction & Context Filtering

MCP-first systems should prepare data specifically for AI agents, not simply pass it through. This means: not every field that exists internally belongs in the agent context.

Full internal data

{
  "name": "Max Müller",
  "email": "[email protected]",
  "phone": "+49...",
  "privateNotes": "...",
  "bankAccount": "...",
  "internalRiskScore": "...",
  "lastEmails": ["..."]
}

This version contains personal data, bank details, private notes, and the full email history. It is intended for internal views and users with the appropriate permissions, not for an agent that is supposed to suggest a follow-up.

Agent-ready version

{
  "name": "Max Müller",
  "company": "Müller GmbH",
  "role": "Investment Manager",
  "lastInteractionSummary": "Opened exposé but did not reply.",
  "recommendedNextAction": "Follow up by email."
}

The agent receives only what it needs for its task: name, context, last interaction status, and a recommended action. Bank details, risk score, and raw email data are filtered out. This is redaction by design.

Redaction is not a retroactive security measure. It is part of the resource design: every resource has an agent-ready variant that contains only the fields relevant for the respective purpose.

Resources with context

Well-designed resources deliver not just raw data but embedded context: timelines, summaries, recommended actions. These are the resources that actually make agents useful.

These resources go beyond contacts.get or projects.list. They deliver prepared context that allows an agent to recommend a meaningful next action, without having to make raw database queries or evaluate sensitive fields itself.