Agent-Fähigkeiten vs. MCP-Server: Entscheidungsrahmen

Agent Skills und MCP-Server werden oft als konkurrierende Ansätze zur Erweiterung eines KI-Agenten dargestellt. Diese Einordnung ist falsch: Eine Skill lehrt den Agenten, wie er arbeitet, während ein MCP-Server ihm kontrollierten Zugriff auf live Funktionen gewährt.

Die nützliche Frage lautet nicht „Welcher Standard gewinnt?“. Sie lautet „Wo sollte diese Verantwortung liegen?“. Dieser Leitfaden beantwortet das für gehostete Assistenten wie Hermes Agent und OpenClaw, bei denen Kontextgröße, langlaufende Verbindungen, Anmeldeinformationen und Betriebssicherheit wichtiger sind als eine saubere Demo.

Dies ist kein akademischer Vergleich. Es handelt sich um ein praktisches Entscheidungsframework, das aus realer Deployment-Erfahrung mit beiden Mechanismen entstanden ist, einschließlich der Kontextkosten-Tradeoffs, die erst sichtbar werden, wenn ein Agent in Produktion läuft. Wenn Sie Multi-Agent-Systeme aufbauen, möchten Sie vielleicht auch unseren A2A vs. MCP Protokollvergleich lesen, der eine andere Achse desselben Problemraums abdeckt.

Agent Skills vs. MCP-Server in einer Tabelle

Verwenden Sie eine Skill für Prozeduren, Urteilsvermögen und wiederverwendbares Betriebswissen. Verwenden Sie einen MCP-Server für autoritative Zustände, geschützte Operationen und stabile Funktionsverträge.

Meine Standardentscheidung ist bewusst konservativ: Beginnen Sie mit einer Skill, wenn die Aufgabe lokal, leseintensiv und prozedural ist. Fügen Sie einen MCP-Server hinzu, wenn der Agent eine Vertrauensgrenze überschreitet, veränderlichen externen Zustand berührt oder eine Operation benötigt, die auch bei Verwirrung des Modells korrekt bleiben sollte.

Die Kernunterscheidung: Prozedur vs. Fähigkeit

Eine Agent Skill ist ein Verzeichnis mit SKILL.md im Zentrum, ergänzt durch optionale Skripte, Referenzen und Assets. Die Agent Skills Spezifikation definiert erforderliche Metadaten und ein progressives Offenlegungsmodell: Der Host kann zuerst einen kleinen Namen und eine Beschreibung entdecken, die vollständigen Anweisungen bei Relevanz laden und unterstützende Dateien nur bei Bedarf abrufen.

Das macht eine Skill zu einem starken Zuhause für eine Incident-Rubrik, eine Release-Checkliste, eine Forschungsmethode oder Anweisungen zur Verwendung eines bestehenden Kommandozeilenwerkzeugs. Ihr zentraler Wert liegt in kodifizierten Prozeduren: Sequenz, Urteilsvermögen, Einschränkungen, Beispiele und die Definition eines guten Ergebnisses. Für Hermes-spezifische Autordetails einschließlich Frontmatter-Struktur und bedingter Aktivierung siehe Hermes Agent Skill Authoring.

MCP löst ein anderes Problem. Die Model Context Protocol Spezifikation gibt Client und Server einen auf JSON-RPC basierenden Vertrag für Funktionen einschließlich Tools, Ressourcen und Prompts, mit standardisierten Transportschichten und Entdeckungsverhalten. Praktische Implementierungsleitfäden für MCP-Server in Python und MCP-Server in Go zeigen, wie einfach die Integrationsschicht sein kann, sobald das Protokoll die schwere Arbeit übernimmt.

Ein MCP-Server ist daher eine gute Grenze um ein Ticketsystem, eine Cloud-Kontrollfläche, eine Single Source of Truth Datenbank oder einen internen Suchdienst. Er besitzt die Mechanik der Erreichung dieses Systems und kann Validierung, Autorisierung, Timeouts, Rate Limits und Audit-Verhalten außerhalb der Prosa-Anweisungen des Modells erzwingen.

Eine präzisere Regel

Fragen Sie sich, ob eine Verantwortung ohne Erinnerung des Modells an eine Instruktion korrekt bleiben muss. Wenn die Antwort ja ist, gehört sie in deterministischen Code oder Server-Politik, nicht nur in SKILL.md.

Zum Beispiel ist „Sammle drei unterstützende Signale vor der Eskalation“ eine nützliche Skill-Anweisung. „Verwerfe eine Statusänderung, es sei denn, der Aufrufer hat den incident-manager Scope“ muss vom Service oder MCP-Server erzwungen werden, selbst wenn die Skill die Regel wiederholt.

Das ist die Grenze, die zählt:

• Eine Skill kann dem Agenten sagen, wann eine Aktion angemessen ist.
• Ein MCP-Tool kann die Aktion durch eine getypete Schnittstelle verfügbar machen.
• Der zugrunde liegende Service muss entscheiden, ob die Aktion tatsächlich erlaubt ist.

MCP-Server können auch Prompts exponieren, sodass die Standards an den Rändern überlappen. Trotzdem führt die Platzierung einer gesamten Betriebsprozedur in einer riesigen Tool-Beschreibung normalerweise zu einem fragilen Funktionskatalog, während das Verstecken eines privilegierten API-Clients in einem Shell-Skript innerhalb einer Skill normalerweise zu einem vermeidbaren Sicherheitsproblem führt.

Wann eine SKILL.md ausreicht

Eine Skill reicht aus, wenn der Agent bereits sicheren Zugriff auf alles hat, was benötigt wird, und nur das Know-how fehlt. Das ist häufig bei Repository-Analyse, Dokumenttransformation, Berichtsgenerierung oder lokalen Workflows, die auf reifen CLI-Befehlen basieren.

Die Daten sind lokal oder vom Benutzer bereitgestellt

Nehmen wir an, ein Agent muss ein gechecktes Repository inspizieren, read-only Linter ausführen, Konfigurationsdateien vergleichen und einen Migrationsbericht erstellen. Die Dateien sind bereits in der Arbeitsumgebung, und der Host exponiert bereits Dateisystem- und Prozess-Tools, sodass ein weiterer Netzwerkdienst wenig Wert hinzufügt.

Die Skill kann beschreiben, welche Dateien zu inspizieren sind, die Befehlsreihenfolge, Fehlerbehandlung und den erforderlichen Beweis. Ein gebündeltes Skript kann die Ausgabe normalisieren, aber die existierende Sandbox und Command-Berechtigungen des Hosts bleiben die eigentliche Ausführungsgrenze.

Der Workflow hängt von Urteilsvermögen ab

Skills sind besonders nützlich, wenn mehrere technisch gültige Aktionen existieren, die Organisation aber eine bestimmte Betriebsmethode bevorzugt. Eine Code-Review-Skill kann erklären, welche Risiken blockierende Kommentare verdienen, wann eine Reproduktion angefordert werden soll und wie man Korrektheitsprobleme von Geschmack trennt.

Diese Regeln ändern sich, wenn Teams lernen. Das Behalten als versionierte Prosa und kleine Referenzen ist oft klarer als das Neukompilieren oder Redeployen eines Servers für jede redaktionelle Anpassung.

Portabilität ist wichtiger als zentrale Kontrolle

Das offene Agent Skills Format ist als portabler Ordner und nicht als entfernter Runtime konzipiert. Eine gut abgegrenzte Skill kann zwischen kompatiblen Hosts mit ihren Anweisungen, Beispielen und unterstützenden Assets wandern, obwohl Tool-Namen und Sandbox-Verhalten noch host-spezifische Tests erfordern.

Diese Portabilität ist nützlich für Hermes Agent und OpenClaw Workflows, die eine Methode teilen, aber nicht unbedingt dasselbe Deployment. Halten Sie host-spezifische Notizen in kurzen Referenzen, anstatt die Kernprozedur bei der ersten Differenz zu forken. Der OpenClaw Skills Ökosystem-Leitfaden deckt ab, welche Skills die Installation wert sind und wie man sie sicher pro Agent-Rolle steuert.

Eine bestehende CLI bietet bereits die Funktion

Bauen Sie keinen Server nur, um einen zuverlässigen lokalen Befehl zu wrappen. Wenn ein Single-User-Assistent eine schmale CLI aufrufen kann, die bereits Authentifizierung, strukturierte Ausgabe und Fehler behandelt, kann eine Skill die kleinere und wartbarere Lösung sein.

Die Einschränkung ist wichtig: Eine CLI ist nicht automatisch sicher, nur weil sie lokal ist. Vermeiden Sie breite Shell-Interpolation, bevorzugen Sie strukturierte Ausgabe, beschränken Sie schreibbare Ziele und behandeln Sie die vom Skill vorgeschlagene Tool-Allowlist nicht als vollständiges Autorisierungssystem.

Wann Sie einen MCP-Server brauchen

Wählen Sie MCP, wenn das Problem nicht nur darin besteht, sich zu erinnern, was zu tun ist. Ein MCP-Server wird wertvoll, wenn der Agent eine dauerhafte, getypete und steuerbare Brücke zu einem veränderlichen System braucht.

Der Zustand ist live und autoritativ

Kundentickets, Deployment-Status, Inventar, Abrechnungsdaten und Produktionsmetriken können sich zwischen zwei Modell-Turns ändern. Das Kopieren dieses Zustands in eine Skill macht ihn konstruktionsbedingt veraltet, während das Fragen des Modells, eine Oberfläche zu scrapen, einen instabilen Vertrag erzeugt.

Ein MCP-Ressource oder Tool kann den aktuellen Datensatz zum Ausführungszeitpunkt abrufen. Der Server kann Upstream-Sonderheiten normalisieren und ein kompaktes Ergebnis zurückgeben, anstatt die gesamte Vendor-Antwort dem Modell zu exponieren.

Anmeldeinformationen oder Benutzeridentität sind beteiligt

Anmeldeinformationen sollten nicht in SKILL.md, Beispielen oder gebündelten Hilfsskripten leben. Für entfernte HTTP-Deployments definiert die MCP-Autorisierungsspezifikation ein OAuth-basiertes Modell; für lokale stdio-Server können Anmeldeinformationen durch den Prozess-Umgebung oder einen anderen host-gesteuerten Mechanismus bereitgestellt werden. Siehe die offizielle MCP-Autorisierungsrichtlinie.

Der tiefere Grund für die Verwendung eines Servers ist nicht nur die Geheimnis-Speicherung. Ein Server kann Identität auf Scopes abbilden, Tenants einschränken, Felder redigieren und aufzeichnen, wer eine Mutation angefordert hat, während eine Prosa-Anweisung das Modell nur bitten kann, sich zu benehmen.

Schreibvorgänge brauchen transaktionale Garantien

Die Erstellung einer Rechnung, die Änderung eines Ticket-Status oder der Start eines Deployments erfordert mehr als ein plausibles JSON-Objekt. Die Operation kann Idempotenz-Schlüssel, optimistischeConcurrency, serverseitige Validierung und eine dauerhafte Audit-Trail benötigen.

Diese Eigenschaften gehören unter das Modell. Die Skill kann die Genehmigungsrichtlinie definieren, aber der MCP-Server sollte eine ungültige Transition ablehnen und einen wiederholten Request sicher machen.

Mehrere Agenten brauchen dieselbe Funktion

Ein geteilter MCP-Server kann einen Vertrag an mehrere Agent-Hosts, Sprachen und Modell-Anbieter präsentieren. Das gibt Plattformteams einen zentralen Ort zur Verbesserung von Schemas, zum Patchen von Upstream-API-Verhalten und zur Anwendung von Zugriffskontrollen, ohne Integrationslogik in jede Skill zu kopieren.

Zentralisierung ist nicht gratis. Der Server wird eine betriebene Abhängigkeit mit Versionierung, Observability, Verfügbarkeit und Incident-Response-Pflichten, daher sollte er seine Existenz mit einer echten Grenze verdienen, nicht mit architektonischem Enthusiasmus.

Die Frage der Kontextkosten

Kontextkosten werden häufig auf den Slogan „Skills sind progressiv, Tools sind immer geladen“ reduziert. Reale Hosts sind nuancierter, und der Unterschied sollte in serialisiertem Modell-Eingabe gemessen werden, nicht vom Erweiterungsformat angenommen.

Die Agent Skills Dokumentation beschreibt ungefähr 100 Tokens Entdeckungs-Metadaten pro Skill, empfiehlt, aktivierte Anweisungen unter 5.000 Tokens zu halten und ermöglicht das Laden von Referenzen auf Abruf. Eine einfache Planungsschätzung ist:

C_skill = Entdeckungs-Metadaten + aktivierte Anweisungen + ausgewählte Referenzen

MCP-Clients entdecken Tool-Definitionen von Servern, aber das Protokoll erfordert nicht, dass jede entdeckte Schema in jedem Modell-Aufruf erscheint. Hosts können Tools filtern, verschieben, cachen oder routen, sodass die praktische Schätzung ist:

C_mcp = diesem Turn exponierte Tool-Schemas + im Kontext beibehaltene Tool-Ergebnisse

Die MCP-Tools Spezifikation bemerkt auch, dass stabile Tool-Reihenfolge das Prompt-Cache-Verhalten verbessern kann. Caching kann wiederholte Verarbeitungs-Kosten reduzieren, aber es macht einen überdimensionierten Katalog nicht leichter für ein Modell auszuwählen.

Ein illustrierendes Token-Budget

Betrachten Sie einen gehosteten Assistenten mit 20 installierten Skills. Bei der Agent Skills Dokumentations ungefähren Entdeckungskosten ist der kompakte Skill-Index etwa 2.000 Tokens; die Aktivierung einer fokussierten Triage-Skill könnte weitere 1.200 Tokens und eine 600-Tokens-Referenz hinzufügen.

Vergleichen Sie jetzt zwei MCP-Designs. Ein dünner Ticket-Server mit vier prägnanten Schemas könnte sich auf 500-800 Tokens serialisieren, während ein breiter Unternehmensserver mit 35 ausführlichen Tools mehrere tausend Tokens verbrauchen könnte, bevor ein Ergebnis ankommt.

Das sind illustrierende Planungszahlen, keine Protokoll-Garantien oder Benchmarks. Messen Sie den exakten Prompt, den Ihr Host generiert, da Schema-Ausführlichkeit, Beschreibungen, Routing, Ergebnisbeibehaltung und Tokenizer-Wahl das Gesamtergebnis erheblich verschieben können.

Die praktische Schlussfolgerung ist nicht „Skills sind billig“ oder „MCP ist teuer“. Es ist, dass progressive Offenlegung und Funktionsauswahl Architektur-Funktionen sind: Halten Sie Skill-Metadaten diskriminativ, aktivieren Sie nur relevante Anweisungen, exponieren Sie den kleinsten nützlichen Tool-Satz und geben Sie Projektionen statt roher Upstream-Payloads zurück.

Das Thin-Server-Muster: MCP unten, Skill oben

Das dauerhafteste Design kombiniert oft beide Mechanismen. Platzieren Sie eine kleine Funktionsgrenze in MCP, dann legen Sie die Betriebsmethode in eine Skill, die sie aufruft.

Betrachten Sie einen Support-Incident-Workflow, der entweder von Hermes Agent oder OpenClaw verwendet wird. Der Agent muss ein Ticket lesen, Beweise sammeln, Schwere klassifizieren, einen Operator-Hinweis entwerfen und den Status nur nach der erforderlichen Genehmigung ändern.

Was der MCP-Server besitzt

Halten Sie die Serverschnittstelle schmal und wörtlich:

Der Server sollte kein Tool namens triage_everything mit einer paragraphenlangen Beschreibung und einem Dutzend unzusammenhängender Flags enthalten. Vier abgegrenzte Operationen sind leichter zu autorisieren, zu testen, zu beobachten und wiederzuverwenden.

Was die Skill besitzt

Die Skill besitzt die Sequenz und das Urteilsvermögen. Eine kompakte SKILL.md könnte so aussehen:

---
name: incident-triage
description: Triage Support-Inzidents mit Ticket-Beweis und Schwere-Rubrik.
---

1. Lesen Sie das Ticket und seine aktuelle Version.
2. Sammeln Sie mindestens zwei unabhängige Signale vor der Schwere-Zuweisung.
3. Trennen Sie beobachtete Fakten von Hypothesen in dem Hinweis.
4. Fragen Sie nach Operator-Genehmigung vor jedem kundensichtbaren Hinweis oder Statusänderung.
5. Lesen Sie das Ticket vor einem Schreibvorgang erneut; stoppen Sie, wenn sich seine Version geändert hat.
6. Enden Sie mit Schwere, Beweis, Unsicherheit und empfohlener nächster Aktion.

Diese Datei ist lesbar, überprüfbar und leicht zu revidieren, wenn sich die Triage-Richtlinie ändert. Eine verlinkte Referenz kann die Schwere-Rubrik enthalten, während die Hauptanweisungen kurz genug bleiben, um ohne das Ziehen eines Operations-Handbuchs in jeden Turn aktiviert zu werden.

Wie es in Hermes Agent läuft

Hermes Agents native MCP-Dokumentation beschreibt Startentdeckung, persistente Verbindungen, stdio und Streamable HTTP Transportschichten sowie namengeraumte MCP-Tools. Seine aktuelle Konfiguration filtert auch die Umgebung für stdio-Server und übergibt explizit konfigurierte Variablen, was eine nützliche Verteidigung gegen zufällige Geheimnis-Erbschaft ist.

In diesem Design entdeckt Hermes die vier Ticket-Tools, während die Incident-Skill nur für relevante Anfragen aktiviert wird. Das Modell folgt der Skill, der MCP-Server führt abgegrenzte Operationen aus und das Ticketsystem bleibt die letzte Autorität.

Wie es in OpenClaw läuft

OpenClaws Skills-Dokumentation folgt der Agent Skills Struktur und baut eine kompakte Liste qualifizierter Skills für das Modell. Derselbe Incident-Ordner kann die Kernprozedur tragen, mit einer kurzen host-spezifischen Referenz, die die verfügbaren Ticket-Tool-Namen erklärt.

Legen Sie nicht den Ticket-Token in die geteilte Skill. OpenClaw behandelt geteilte Skills explizit als Eingaben und nicht als Geheimnisspeicher, und Drittanbieter-Skills sollten als unzuverlässiger Code überprüft werden, bevor sie aktiviert werden.

Warum die Trennung Wandel überlebt

Wenn das Support-Team seine Schwere-Rubrik revidiert, aktualisieren Sie die Skill. Wenn der Ticket-Vendor Authentifizierung oder Paginierung ändert, aktualisieren Sie den MCP-Server ohne die Betriebsrichtlinie neu zu schreiben.

Wenn ein zweiter Agent-Host ankommt, kann er denselben MCP-Vertrag wiederverwenden und die kleine host-spezifische Schicht der Skill anpassen. Diese Trennung reduziert duplizierte Integrationslogik ohne jede prozedurale Bearbeitung in eine Service-Deployment zu verwandeln.

Ein fünfschrittiges Entscheidungsframework

Die folgende Sequenz ist zuverlässiger als das Auswählen des modischen Erweiterungs-Typs zuerst.

1. Identifizieren Sie die Single Source of Truth

Schreiben Sie alle Eingaben und Ausgaben auf, die der Workflow berührt. Statische Richtlinien, Repository-Dateien und benutzerbereitgestellte Dokumente neigen zu einer Skill; veränderbare entfernte Datensätze und autoritative Systeme neigen zu MCP.

Nicht jeder Zustand rechtfertigt einen Server. Ein lokales Build-Artefakt ist Zustand, aber eine existierende sandboxierte CLI kann bereits eine ausreichende Grenze bieten.

2. Lokalisieren Sie die Vertrauensgrenze

Markieren Sie, wo Anmeldeinformationen, Tenant-Identität, privilegierte Daten oder irreversibale Aktionen erscheinen. Wenn der Agent diese Linie überschreitet, führen Sie einen deterministischen Erzwingungspunkt ein, typischerweise einen MCP-Server mit Service-Autorisierung.

Behandeln Sie das Modell und die Skill als Request-Planer, nicht als Policy-Engines. Sie können eine erlaubte Aktion vorschlagen, aber sie sollten nicht in der Lage sein, Berechtigung durch Änderung ihrer eigenen Anweisungen neu zu definieren.

3. Trennen Sie Funktion von Politik

Nennen Sie Funktionen als schmale Verben mit getypeten Eingaben: Ein Ticket holen, einen Hinweis hinzufügen oder den Status ändern. Legen Sie die Bedingungen für die Auswahl dieser Verben, den Beweisstandard und die bevorzugte Sequenz in die Skill.

Einige Politik muss aus verschiedenen Gründen in beiden Schichten existieren. „Fragen Sie den Benutzer vor dem Deployment“ gehört in die Skill für Interaktionsqualität, während „Deployment ohne Approval-Token ablehnen“ in Code für Erzwingung gehört.

4. Schätzen Sie Kontext- und Betriebskosten

Erfassen Sie eine echte Prompt-Spur und zählen Sie die Skill-Metadaten, aktivierten Anweisungen, Tool-Definitionen und zurückgegebenen Daten. Fügen Sie dann die nicht-Token-Kosten eines MCP-Services hinzu: Deployment, Authentifizierung, Monitoring, Versionierung und On-Call-Eigentum.

Wenn ein 30-Tool-Katalog einen Workflow unterstützt, exponieren Sie eine aufgaben-spezifische Teilmenge oder teilen Sie den Server nach kohärentem Funktionsdomänen. Wenn eine Skill wiederholt eine 200-seitige Referenz lädt, erstellen Sie einen Abrufschritt oder kleinere Referenzen statt sich über progressive Offenlegung zu gratulieren.

5. Testen Sie die Grenze, dann das Verhalten

Testen Sie den MCP-Server als Software und die Skill als Agent-Verhalten. Sie versagen unterschiedlich, und ein einzelner Happy-Path-Chat-Transkript versteckt beide Defekt-Klassen.

Für Tool-Sicherheit empfiehlt die MCP-Spezifikation Eingabevalidierung, Zugriffskontrollen, Rate Limits, Ausgabe-Sanitization, Timeouts, Bestätigungen für sensible Operationen und Audit-Logging. Tool-Annotationen sind Hinweise, nicht vertrauenswürdiger Beweis, dass eine Operation read-only oder harmlos ist. Der A2A und MCP Agent-Sicherheitsleitfaden deckt das breitere Bedrohungsmodell einschließlich Prompt-Injection und Tool-Poisoning ab.

Sicherheitsregeln, die nicht in einen Slogan passen

Skills reduzieren den Bedarf an einigen Servern, aber sie entfernen Risiko nicht. Eine Skill kann Skripte enthalten und einen Agenten überzeugen, leistungsstarke Host-Tools aufzurufen, daher überprüfen Sie ihre Anweisungen und ausführbaren Dateien als Code, pinnen Sie vertrauenswürdige Versionen und beschränken Sie die dem Session verfügbaren Host-Tools.

MCP fügt eine weitere Grenze hinzu: Einen lokalen Subprozess oder entfernten Service mit seinen eigenen Abhängigkeiten, Eingaben, Ausgaben und Anmeldeinformationen. Wenden Sie Least Privilege an, validieren Sie Resource-Audience für entfernte Autorisierung, verwenden Sie HTTPS, sanitisieren Sie unzuverlässigen Inhalt und halten Sie Genehmigung für konsequente Schreibvorgänge sichtbar.

Am wichtigsten: Verwechseln Sie Entdeckbarkeit nicht mit Autorität. Ein in der Modell-Katalog erscheinendes Tool bedeutet nicht, dass der aktuelle Benutzer jede beschriebene Operation ausführen sollte.

Häufige Anti-Patterns

Verstecken eines entfernten API-Clients in einer Skill

Ein Shell-Skript, das einen statischen Bearer-Token liest und eine Produktions-API aufruft, kann in einer Demo funktionieren. Es mischt auch Prozedur, Anmeldeinformationen, Netzwerkverhalten und Autorisierung in einem Paket, das zum Kopieren und Lesen durch Agent-Hosts entworfen wurde.

Bewegen Sie die geschützte Integration hinter einen schmalen Server oder eine bestehende genehmigte CLI. Halten Sie nur den Workflow und Aufruf-Richtlinien in der Skill.

Kodifizieren des Workflows in Tool-Beschreibungen

Tool-Beschreibungen sollten dem Modell helfen, eine Funktion auszuwählen und ihre Schema zu füllen. Sie sind ein schlechter Ersatz für eine mehrstufige Betriebsprozedur mit Beispielen, Ausnahmen, Eskalationsregeln und Ausgabe-Konventionen.

Lange Beschreibungen inflatieren jeden Turn, in dem das Tool exponiert ist, und machen den Service-Vertrag schwerer zu wiederverwenden. Legen Sie die Prozedur in eine Skill und halten Sie Tool-Semantik präzise.

Bauen eines execute_anything Tools

Ein generisches Shell-, SQL- oder HTTP-Proxy kollabiert viele Berechtigungen in eine schwer zu auditierende Funktion. Es verschiebt Validierung zum Modell und macht Least Privilege weitgehend fiktional.

Exponieren Sie Operationen, die mit tatsächlichen Geschäftsaktionen übereinstimmen. Wenn Experten-Operatoren wirklich einen Ausweg brauchen, trennen Sie ihn, beschränken Sie ihn und fordern Sie stärkere Genehmigung und Logging.

Veröffentlichen eines Kitchen-Sink MCP-Servers

Ein Server mit Dutzenden unzusammenhängender Tools belastet Auswahl, Schema-Kontext, Berechtigungen und Wartung. Teilen Sie nach kohärenter Domäne oder lassen Sie den Host eine relevante Teilmenge für die aktuelle Aufgabe exponieren.

Hermes Agents FastMCP-Richtlinien machen eine sinnvolle Startempfehlung: Beginnen Sie mit ein bis drei hoch-wertigen Endpunkten und bevorzugen Sie einen dünnen Server mit klaren Namen und Schemas. Siehe die offizielle FastMCP Skill-Dokumentation.

Behandeln von Tool-Hinweisen als Sicherheitspolitik

Ein experimentelles allowed-tools Feld oder eine read-only Annotation eines Tools kann Host-Verhalten verbessern, aber keines ersetzt Sandboxing und serverseitige Autorisierung. Metadaten können veraltet, falsch konfiguriert oder von einem unzuverlässigen Component bereitgestellt sein.

Verwenden Sie Hinweise zur Verbesserung der Schnittstelle. Verwenden Sie Code und Infrastruktur zur Erzwingung der Grenze.

Verwenden von MCP für statisches Wissen

Wenn sich eine Prozedur oder Referenz nur mit dem Repository ändert, fügt ein entfernter Round Trip Deployment- und Verfügbarkeitskosten hinzu, ohne das Wissen autoritativer zu machen. Packen Sie prägnantes Material mit der Skill und versionieren Sie es mit dem Workflow.

Führen Sie einen Abrufdienst nur ein, wenn das Korpus groß ist, zugriffskontrolliert, unabhängig aktualisiert wird oder wirklich Such benötigt. Architektur sollte dem Datenlebenszyklus folgen, nicht dem Akronym.

Endgültige Entscheidung: Skill, MCP-Server oder beides?

Wählen Sie eine Agent Skill, wenn der schwierige Teil das Wissen ist, was zu tun ist. Wählen Sie einen MCP-Server, wenn der schwierige Teil das sichere Erreichen von etwas ist, das sich ändert, einem anderen Vertrauensdomänen gehört oder einen Vertrag erzwingen muss.

Wählen Sie beides, wenn ein echter Workflow Urteilsvermögen über einer geschützten Funktion braucht. Das ist keine Duplizierung: Die Skill macht den Agenten nützlich, der Server macht die Integration steuerbar und das zugrunde liegende System macht die endgültige Entscheidung autoritativ.

Für die meisten gehosteten Assistenten ist die beste erste Architektur bescheiden: Eine fokussierte Skill, eine kleine MCP-Oberfläche nur dort, wo Live-Zugriff es verlangt, und eine erfasste Prompt-Spur zur Verifizierung der Kontextkosten. Fügen Sie Komplexität hinzu, nachdem die Grenze klar ist, nicht vorher.

Referenzen

• Agent Skills Spezifikation
• Model Context Protocol Spezifikation
• MCP-Autorisierungsrichtlinie
• Hermes Agent native MCP-Dokumentation
• OpenClaw Skills-Dokumentation
• FastMCP Skill-Dokumentation