spec v0.1
DE

Skills

Beispiel-Skills

Sechs Agent-Skills zum Erstellen, Steuern und Auditieren eines MCP-Servers, selbst nach den MCP-first-Regeln gebaut.

Ein Skill ist ein verpackter Workflow, der dritte Baustein eines MCP-first Systems (Prompts / Workflows). Er führt einen Agenten durch einen mehrstufigen Prozess, ohne dass dieser sich durch Oberflächen klicken muss.

Die folgenden Beispiel-Skills bedienen den MCP-Server selbst: ihn erstellen, steuern und auditieren. Entscheidend ist: diese Skills halten sich an dieselben Regeln, die sie durchsetzen. Jeder riskante Schritt trägt eine Risikostufe, schreibende und kritische Schritte sind hinter einer Freigabe (Confirmation Gate), und jede Aktion erzeugt ein Audit-Event.

Erstellen

mcp.scaffold_server
High

Bootstrappt einen capability-first MCP-Server: Domain-Actions zuerst, typisierte Schemas, Policy-Engine, Risiko-Metadaten und Audit, bevor irgendein Interface entsteht.

trigger "Erstelle einen MCP-Server für …" Erstellen

Ablauf

  1. Domain-Actions modellieren, Business-Logik bleibt in der Domäne, nicht im Server. Low
  2. Für jede Action typisierte Input-, Output- und Fehler-Schemas erzeugen. Low
  3. Jedem Tool eine Risikostufe und eine Confirmation-Policy zuweisen. Medium
  4. Policy-Engine (can(user, action, resource, context)) und Audit-Events verdrahten. Medium
  5. Server als Adapter generieren: Discovery, Schema-Exposure, Policy-Checks, Audit-Logging. High
  6. Schreibende und kritische Tools erst nach expliziter Freigabe registrieren. Critical ⏸ Freigabe

Hält sich an

  • Capabilities statt Screens, Fähigkeiten zuerst, keine UI-Annahmen.
  • Typisierte In- und Outputs, kein loses JSON.
  • Policies statt Vertrauen, jede Capability bekommt Rechte und Risiko.
  • Audit statt Intransparenz, jede Aktion erzeugt ein Audit-Event.
capability.add
High

Fügt eine neue Capability nach dem Tool Contract Standard hinzu. Ohne vollständigen Contract wird nichts registriert.

trigger "Füge ein Tool/eine Resource für … hinzu" Erstellen

Ablauf

  1. Benutzer-Intent und Kategorie klären; existierende Capability als Vorlage prüfen. Low
  2. Input-/Output-/Fehler-Schema und benötigte Scopes definieren. Low
  3. Risikostufe, Side Effects und Audit-Event festlegen. Medium
  4. Confirmation-Policy bestimmen (autonom, Bestätigung, Step-up, four-eyes, nicht für KI). Medium
  5. Dry-Run-Modus für riskante Tools vorsehen. Medium
  6. Capability registrieren und in der Discovery freischalten. High ⏸ Freigabe

Hält sich an

  • Tools statt Buttons, ein einheitlicher Contract pro Fähigkeit.
  • Bestätigung statt blinder Automatik, Policy vor der Registrierung.
  • Dry Run für riskante Aktionen.

Steuern

mcp.control_visibility
High

Steuert die Tool-Sichtbarkeit pro Benutzer, Client, Tenant, Rolle und Scope, bereits bei der Discovery, nicht erst beim Aufruf.

trigger "Welche Tools darf Agent X sehen?" Steuern

Ablauf

  1. Identität und Kontext auflösen: User, MCP-Client, Agent-Identity, Tenant. Low
  2. Effektive Rechte berechnen (User + Agent + Client-Trust + Resource-Sensitivity). Low
  3. Tool-Liste auf erlaubte Capabilities filtern; gesperrte gar nicht erst ausliefern. Medium
  4. Confirmation-Policies je Rolle anpassen. High ⏸ Freigabe

Hält sich an

  • Tool-Sichtbarkeit nach Rechten, Filtern bei der Discovery.
  • Kontext statt Rohdaten, nur was der Agent braucht.
  • Policies statt Vertrauen.
mcp.connect_client
Critical

Bindet einen MCP-Client kontrolliert an: OAuth 2.1 Authorization Code mit PKCE, Allowlist, kurze Tokens, Refresh-Rotation.

trigger "Verbinde Client … mit dem MCP-Server" Steuern

Ablauf

  1. Client gegen die Allowlist prüfen; Redirect-URIs validieren. Medium
  2. OAuth 2.1 + PKCE einrichten, kurze Access-Token-Laufzeiten setzen. High
  3. Minimale Scopes vergeben (least privilege), Refresh-Rotation aktivieren. High
  4. Client aktivieren, mit Step-up-Auth des Admins. Critical ⏸ Freigabe

Hält sich an

  • Human UI / Clients als Client, der Kern bleibt der Capability Layer.
  • Step-up Authentication für kritische Aktionen.
  • Audit statt Intransparenz, Client-Aktivierung wird auditiert.

Auditieren

mcp.audit_trail
Low

Read-only-Review: liest Audit-Trail und Risiko-Abdeckung, läuft die MCP-first-Checkliste durch und meldet Lücken. Verändert nichts.

trigger "Prüfe den MCP-Server gegen MCP-first" Auditieren

Ablauf

  1. Capability-Inventar und deren Risikostufen lesen. Low
  2. Audit-Events auf Vollständigkeit und Redaction sensibler Inputs prüfen. Low
  3. Tools ohne Risikoklassifizierung oder Confirmation-Policy markieren. Low
  4. Forbidden-for-AI-Capabilities gegen tatsächliche Sichtbarkeit abgleichen. Low
  5. Befund als strukturierten Report ausgeben, keine Schreibaktion. Low

Hält sich an

  • Audit statt Intransparenz, jede Aktion nachvollziehbar.
  • 100 % steuerbar, nicht 100 % autonom, der Audit selbst ändert nichts.
  • Kontext statt Rohdaten, Report statt Datenbank-Dump.
mcp.harden_security
Critical

Prüft und erhöht Schutz: Schutzklassen, Step-up-Abdeckung, Redaction, Rate Limits und Prompt-Injection-Schutz. Änderungen sind freigabepflichtig.

trigger "Härte die Sicherheit des MCP-Servers" Auditieren

Ablauf

  1. Sensible Bereiche und Schutzklassen je Resource/Tool prüfen. Low
  2. Step-up-Auth für kritische Tools verifizieren; fehlende vorschlagen. Medium
  3. Redaction-Regeln und Context-Filtering für KI-Zugriff prüfen. Medium
  4. Rate Limits und Prompt-Injection-Schutz bewerten. High
  5. Policy-Änderungen anwenden, mit Admin-Freigabe (four-eyes). Critical ⏸ Freigabe

Hält sich an

  • Policies statt Vertrauen, KI wird kontrolliert, nicht vertraut.
  • Confirmation over blind automation, Policy-Änderungen sind freigabepflichtig.
  • Kontext statt Rohdaten, Redaction für sensible Daten.

Build capabilities once. Expose them everywhere, auch an die Skills, die den Server selbst betreiben.

Skills sind Workflows