MCP-first ist kein Hype um ein neues Protokoll. Es ist ein Architekturwechsel. Moderne Software wird nicht mehr zuerst als Webapp gedacht, sondern als vollständig steuerbares, maschinenlesbares, sicheres Capability-System. Webapp, Mobile App, CLI und Admin-Oberflächen sind danach nur noch sekundäre Interfaces auf denselben Kern.
Ein Screen ist nur eine Oberfläche. Die eigentliche Software ist ihre Fähigkeit.
1 · Capabilities statt Screens
Ein Feature ist keine Seite. Ein Feature ist eine Fähigkeit. Wer zuerst die Fähigkeit beschreibt, kann sie überall anbieten, im UI, im Agenten, im Worker.
2 · Tools statt Buttons
Ein Button ist nur die menschliche Darstellung eines Tools. Das Tool, typisiert, berechtigungsgeprüft, auditiert, ist das Eigentliche.
3 · Resources statt Tabellen
Eine Tabelle ist nur eine visuelle Darstellung einer Resource. Agents brauchen die Resource mit Kontext, nicht die gerenderte Tabelle.
4 · Workflows statt Navigation
Agents brauchen keine Navigation. Sie brauchen klare Workflows, die durch komplexe Prozesse führen.
5 · Policies statt Vertrauen
6 · Bestätigung statt blinder Automatik
Riskante Aktionen brauchen menschliche Zustimmung. MCP-first heißt vollständig steuerbar, nicht vollautomatisch.
7 · Audit statt Intransparenz
Jede Agentenaktion muss nachvollziehbar sein: wer, was, wann, mit welcher Freigabe.
8 · Kontext statt Rohdaten
Agents brauchen relevanten, aufbereiteten Kontext, nicht vollständige Datenbanken. Redaction und Context-Filtering sind Pflicht.
9 · Human UI als Client
Webapp und Mobile App sind Clients, nicht der Kern. Sie rufen dieselben Actions auf wie der Agent.
10 · 100 % steuerbar, nicht 100 % autonom
Alles muss steuerbar sein. Nicht alles darf autonom passieren.
Wenn deine Software es kann, muss MCP es beschreiben können. Wenn ein Agent es aufrufen kann, muss Policy es kontrollieren können.
Beispiel-Skills
Die Prinzipien sind kein Selbstzweck. Sie zeigen sich am besten dort, wo Agenten den MCP-Server selbst bedienen, ihn erstellen, steuern und auditieren. Solche Skills sind verpackte Workflows, die sich an genau dieselben Regeln halten, die sie durchsetzen: jeder riskante Schritt trägt eine Risikostufe, kritische Schritte stehen hinter einer Freigabe, und jede Aktion wird auditiert.
mcp.scaffold_server 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
- Domain-Actions modellieren, Business-Logik bleibt in der Domäne. Low
- Typisierte Input-, Output- und Fehler-Schemas erzeugen. Low
- Jedem Tool Risikostufe und Confirmation-Policy zuweisen. Medium
- Server als Adapter generieren: Discovery, Policy-Checks, Audit. High
- Kritische Tools erst nach expliziter Freigabe registrieren. Critical ⏸ Freigabe
mcp.audit_trail Read-only-Review: liest Audit-Trail und Risiko-Abdeckung, läuft die Checkliste durch und meldet Lücken. Verändert nichts.
trigger "Prüfe den MCP-Server gegen MCP-first" Auditieren
Ablauf
- Capability-Inventar und Risikostufen lesen. Low
- Audit-Events auf Vollständigkeit und Redaction prüfen. Low
- Tools ohne Risikoklassifizierung markieren. Low
- Befund als strukturierten Report ausgeben, keine Schreibaktion. Low
Weitere Beispiele, Capability hinzufügen, Tool-Sichtbarkeit steuern, Clients anbinden, Sicherheit härten, auf der Seite Beispiel-Skills.
Die Zukunft gehört Software, die nicht nur bedienbar ist, sondern sicher steuerbar.