Resource Design Guide

Eine Resource im Sinne von MCP ist kein roher Datenbankdump. Sie ist lesbarer Datenkontext, strukturiert, gefiltert und auf den Agenten zugeschnitten, der sie gerade braucht. Während ein Tool eine Aktion ausführt, liefert eine Resource den Kontext, auf dessen Basis sinnvolle Entscheidungen möglich sind.

Resources mit kind="resources" beschreiben genau das: welche Kontextobjekte ein System bereitstellt, wie sie aufgebaut sind, und welche Schutzstufe sie tragen.

Effective AI Access

Datenzugriff für KI lässt sich nicht auf eine einzige Frage reduzieren. Das richtige Modell ist additiv:

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

Jeder dieser Faktoren kann den Zugriff einschränken, auch wenn alle vorherigen ihn prinzipiell erlauben würden.

Das ist zu grob. Benutzerrechte und KI-Rechte sind unterschiedliche Dimensionen. Ein Benutzer agiert bewusst, im Kontext, mit Verantwortung. Ein Agent handelt automatisiert, ohne Urteilsvermögen über Sensibilität, innerhalb eines Scopes, der klar begrenzt sein muss.

Beispiel: Gehaltsdaten

Der Geschäftsführer hat grundsätzlich Zugriff auf Gehaltsdaten, das ist sein Benutzerrecht. Ein Sales Assistant Agent, der im Kontext dieses Benutzers läuft, sollte diese Daten trotzdem nicht in seinen Kontext bekommen.

Warum: Der Agent hat einen klar definierten Zweck (Kontaktpflege, Follow-ups, Projektarbeit). Gehaltsdaten liegen außerhalb dieses Zwecks. Die Agent Permission und der Purpose schließen den Zugriff aus, unabhängig davon, was der Benutzer selbst sehen darf.

User Permission:     ✓ (Geschäftsführer darf Gehaltsdaten sehen)
Agent Permission:    ✗ (Sales Assistant hat keinen salary:read Scope)
Resource Sensitivity: sensitive
Purpose:             Kontaktpflege / Projektarbeit
= Effective AI Access: verweigert

Redaction & Context Filtering

MCP-first Systeme sollten Daten für AI Agents gezielt aufbereiten, nicht einfach durchreichen. Das bedeutet: nicht jedes Feld, das intern existiert, gehört in den Agenten-Kontext.

Volle interne Daten

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

Diese Version enthält personenbezogene Daten, Bankdaten, private Notizen und den vollständigen E-Mail-Verlauf. Sie ist für interne Ansichten und Benutzer mit den entsprechenden Rechten gedacht, nicht für einen Agenten, der einen Follow-up vorschlagen soll.

Agentenfähige Version

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

Der Agent bekommt nur das, was er für seine Aufgabe braucht: Name, Kontext, letzten Interaktionsstatus und eine Handlungsempfehlung. Bankdaten, Risikoscore und E-Mail-Rohdaten sind herausgefiltert. Das ist Redaction by Design.

Redaction ist keine nachträgliche Sicherheitsmaßnahme. Sie ist Teil des Resource- Designs: Jede Resource hat eine agentenfähige Variante, die nur die für den jeweiligen Zweck relevanten Felder enthält.

Resources mit Kontext

Gut gestaltete Resources liefern nicht nur Rohdaten, sondern eingebetteten Kontext: Zeitlinien, Zusammenfassungen, Handlungsempfehlungen. Das sind die Resources, die Agents tatsächlich nützlich machen.

Diese Resources gehen über contacts.get oder projects.list hinaus. Sie liefern aufbereiteten Kontext, der einem Agenten erlaubt, eine sinnvolle nächste Aktion zu empfehlen, ohne dass er selbst rohe Datenbankabfragen stellen oder sensible Felder auswerten muss.