Werkzeuge gegen Fähigkeiten gegen MCP: Drei Ebenen eines KI-Agenten
Tools machen Aktionen sichtbar, Fähigkeiten kodieren Arbeitsabläufe, und MCP standardisiert externe Verbindungen. Ein klares mentales Modell zur Gestaltung von Agent-Architekturen, ohne die Schichten zu vermischen.
Verständnis der Bausteine von KI-Agenten
Die Welt der Agenten verändert sich ständig.
Frühere Debatten befassten sich hauptsächlich mit Prompt-Formulierung, Grundmodellen und Abrufpipelines. Aktuelle Designs erwarten von Agenten, dass sie auf APIs zugreifen, Workflows steuern, Datenbanken abfragen, mit Codebasen arbeiten und mit SaaS-Systemen kommunizieren.
Drei Begriffe dominieren diese Designs:
Werkzeuge. Fähigkeiten. MCP.
Verwandte Begriffe, unterschiedliche Aufgaben.
Klare Grenzen machen Architekturen einfacher darstellbar und diskutierbar.
Das einfache mentale Modell
Eine kompakte Vergleichstabelle hilft vor dem Eintauchen in die Details:
| Concept | Primary purpose | Simple question |
| ---------- | ------------------------------------------------ | ----------------------------------------- |
| **Tools** | Give the agent capabilities/access | *What can the agent access or do?* |
| **Skills** | Give the agent instructions/workflows | *How should the agent perform a task?* |
| **MCP** | Standardize connections to external capabilities | *How can the agent connect to a service?* |
Oder noch kürzer:
Werkzeuge ermöglichen Abläufe. Fähigkeiten leiten die Vorgehensweise. MCP verbindet externe Systeme.
Im weiteren Verlauf wird jede Ebene genauer erläutert.
- Was sind Tools?
Ein Tool ist eine Operationsoberfläche, auf die der Agent zugreifen kann, um etwas zu ändern oder etwas zu lesen. Allein die Textgenerierung reicht nicht aus; wenn eine Aktion einen Nebeneffekt erfordert, wählt das Modell ein Tool aus.
Stellen Sie sich einen Programmierassistenten mit solchen Operationen vor:
readFile()
writeFile()
runTests()
searchCode()
runCommand()
Das Modell kann zu dem Schluss kommen:
Ich muss diese Datei überprüfen.
Dann ruft es folgendes auf:
readFile("lib/features/login/login.dart")
Das Tool wird ausgeführt und gibt sein Ergebnis an das Modell zurück.
Tools können mit internen Systemen verbunden werden
In einem Unternehmen können Tools auf folgende Ressourcen zugreifen:
- Private HTTP-Dienste
- Datenspeicher
- Entwicklungs- und Veröffentlichungspipelines
- Ticket-Tracker wie Jira
- Quellcodeverwaltungssysteme
- Observability-Stacks
- Plattformen für den Versand und die Rollout-Verwaltung
- Wissensbasen
Beispiele:
getEmployeeDetails()
createJiraTicket()
triggerBuild()
checkDeploymentStatus()
queryCustomer()
Der wichtige Aspekt
Hausgemachte Tools bedeuten in der Regel, dass Sie die Integration selbst übernehmen.
Ihre Aufgaben umfassen in der Regel:
- Implementierung
- Authentifizierung
- Autorisierung
- Sicherheit
- Fehlerbehandlung
- Überwachung
- Wartung
- Versionierung
Die Tools sind leistungsstark, erzeugen aber auch eine anhaltende ingenieurtechnische Belastung.
2. Was sind Fähigkeiten?
Fähigkeiten beantworten eine andere Frage.
Fähigkeit ist eine Anleitung: Sie zeigt dem Agenten ein konkretes Verfahren oder Workflow.Denken Sie an wiederverwendbare Anleitungen statt an rohe APIs.
Nehmen wir an, eine Fähigkeit trägt den Namen:
releaseFlutterApp
Sie könnte Schritte wie folgt kodieren:
1. Check the current version.
2. Verify the changelog.
3. Run unit tests.
4. Run static analysis.
5. Build the release artifact.
6. Upload to the testing environment.
7. Verify the deployment.
8. Generate the release summary.
Die Fähigkeit muss nicht die Rohfähigkeiten bereitstellen. Sie weist dem Agenten an, wie die verfügbaren Fähigkeiten zu einem Ziel kombiniert werden sollen. Diese Trennung ist wichtig.
Ander ausgedrückt: Ein Tool bewirbt eine verfügbare Operation; eine Fähigkeit legt die bevorzugte Reihenfolge zur Erledigung einer Aufgabe fest.
3. Fähigkeiten sind keine Integrationen
Verwirrung entsteht oft hier.
Nehmen wir an, ein Agent verfügt bereits über:
runCommand()
readFile()
writeFile()
searchCode()
Diese Einträge sind Fähigkeiten.
Fügen wir nun eine Fähigkeit hinzu:
Flutter Release Workflow
Diese Fähigkeit kann den Agenten anweisen, zu:
read project configuration
↓
run tests
↓
run analyzer
↓
build application
↓
verify artifact
↓
prepare release
Fähigkeiten enthalten Orchestrierungswissen. Sie kodieren das Handbuch zur Ausführung.
Kurz gesagt:
Tool = was ausgeführt werden kann
Fähigkeit = wie es abgewickelt wird
4. Was ist MCP?
Die dritte Schicht ist MCP (Model Context Protocol).
Es standardisiert, wie KI-Anwendungen auf externe Systeme und Fähigkeitsserver zugreifen.
Anstelle von einmaligen Adaptern für jedes Produktpaar stellt MCP ein gemeinsames Protokoll bereit, um Fähigkeiten an Kunden anzubieten.
Die vereinfachte Struktur sieht wie folgt aus:
AI Application
│
│ MCP
▼
MCP Server
/ | \
/ | \
▼ ▼ ▼
GitHub DB Jira
Die KI-App kommuniziert mit einem MCP-Server; dieser Server stellt Fähigkeiten aus einem externen Service bereit.
Ein MCP-Server kann Oberflächen bereitstellen, die sich auf Folgendes beziehen:
GitHub
PostgreSQL
Slack
Jira
Google Drive
Internal APIs
Die genaue Anzahl der Oberflächen hängt vom Server ab.
- Warum MCP wichtig ist
Fehlt ein gemeinsames Protokoll, neigen Teams dazu, für jede KI-App und jede SaaS-Oberfläche eigene Adapter zu entwickeln.
Dieses Muster führt dazu, dass:
AI Agent
│
├── Custom GitHub integration
├── Custom Jira integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Internal API integration
Mehr Dienste bedeuten mehr maßgeschneiderte Verbindungsmechanismen.
Ein gemeinsames Protokoll bietet ein einheitliches Kommunikationsmodell.
Konzeptionell gesehen:
AI Client
│
MCP
│
┌─────────┴─────────┐
│ │
MCP Server MCP Server
│ │
GitHub Database
Der KI-Klient und die Dienstimplementierung bleiben voneinander getrennt und übersichtlicher.
6. Tools vs Skills vs MCP
Eine nebeneinander angeordnete Darstellung, die bei Design-Reviews weiterhin nützlich ist:
| | Tools | Skills | MCP |
| ------------------ | -------------------- | ------------------------ | ---------------------------------------- |
| Main purpose | Provide capabilities | Provide procedures | Standardize external connections |
| Focus | **Action** | **Instructions** | **Integration protocol** |
| Answers | "What can I do?" | "How should I do it?" | "How do I connect?" |
| Example | `run_tests()` | Flutter release workflow | GitHub MCP server |
| Usually created by | Developers | Developers/teams | Service/integration providers |
| Maintenance | You may own it | You own the instructions | Often handled by the MCP server/provider |
Echte Systeme verwischen die Grenzen, doch das mentale Modell hilft weiterhin bei der Gestaltung von Agenten.
7. Ein praktisches Beispiel: KI-gestützte Flutter-Entwicklung
Basiert das Modell auf einem Assistenten des Flutter-Teams.
Die gewünschte Anfrage des Benutzers könnte lauten:
„Vorbereiten Sie die App für die nächste QA-Veröffentlichung.“
Der Agent könnte mehrere Tools bereitstellen:
read_file()
search_code()
run_flutter_test()
run_flutter_analyze()
build_android()
upload_to_firebase()
Dann wird eine Fähigkeit definiert:
Flutter QA Release
Die Fähigkeit könnte Anweisungen geben:
1. Check the current branch.
2. Read pubspec.yaml.
3. Determine the current version.
4. Run flutter analyze.
5. Run tests.
6. Build the QA APK.
7. Upload the APK.
8. Verify the upload.
9. Generate a release summary.
Dann kann eine MCP-Verbindung auf Git-Hosting, Tickets, einen Datenspeicher oder jeden MCP-Server zugegriffen werden, den das Team veröffentlicht.
Das Ergebnis könnte wie folgt aussehen:
AI Agent
│
┌────────────┼────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
QA Release Flutter CLI External
Workflow Build/Test Services
Der Agent ist dann kein Q&A-Bot mehr.
Es kann eine Aufgabe interpretieren, Anleitungen befolgen, lokale Tools nutzen und externe Systeme ansteuern.
Diese Architektur ist der Punkt, an dem agiles Produktmanagement wirklich greifbar wird.
8. Eine weitere Möglichkeit, den Unterschied zu merken
Stellen Sie sich die Einarbeitung eines neuen Entwicklers vor.
Tools sind seine Ausrüstung
Laptop
Terminal
Git
Database
CI/CD
APIs
Ausrüstung ermöglicht Handlungen.
Fähigkeiten sind sein Wissen
How to release an app
How to debug a production issue
How to investigate a crash
How to review Flutter code
How to troubleshoot CI/CD
Wissen erklärt wie die Arbeit durchgeführt wird.
MCP ist die standardisierte Verbindungsstufe
Es handelt sich um den konsistenten Kanal, über den die KI-Anwendung auf externe Systeme zugreifen kann, die MCP-Fähigkeiten bereitstellen.
9. Warum dieser Unterschied für Entwickler wichtig ist
Entwickler, die diese drei Ebenen miteinander verwechseln, schaffen versehentliche Komplexität.
Ein klarerer Ablauf:
Schritt 1 – Die Fähigkeit identifizieren
Fragen Sie sich:
„Was muss der Agent können, um seine Aufgabe zu erledigen?“
Die Antwort darauf ist ein möglicher Tool.
Schritt 2 – Den Workflow identifizieren
Fragen Sie:
„Wie sollte der Agent die Aufgabe bewältigen?“
Die Antwort darauf ist eine mögliche Fähigkeit.
Schritt 3 – Externe Systeme identifizieren
Fragen Sie:
„Ist dazu Zugang zu einem externen Service erforderlich?“
Falls ja, könnte eine MCP-basierte Integration geeignet sein.
10. Das Gesamtbild
Das gängige Muster besteht darin, sich von:
Prompt
↓
LLM
↓
Response
nach Layouts umzustellen, die eher wie:
┌───────────────┐
│ AI Agent │
└───────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
Workflows Actions External
Services
Zusammen führen sie dazu, dass Systeme von der Erstellung von Prosa zur Durchführung strukturierter Aufgaben übergehen.
Für Ingenieurdienstleister ist das der bedeutende Wandel.
Fazit
Erinnern Sie sich an das Trio so: Tools ermöglichen Aktionen, Skills kodieren Playbooks, und MCP standardisiert die Verbindung mit externen Systemen.
Sie ersetzen einander nicht.
Ein robuster Entwurf nutzt sie in der Regel kombiniert: Skills beschreiben das Playbook, Tools führen die Schritte aus, und MCP kann eine einheitliche Brücke zu Drittsystemen bieten.
Dieses Vokabular wird wertvoller, je mehr Produkte den reinen Chat verlassen und agierende Ingenieurarbeiten durchführen.