MCP-Tools auswählen: Welche braucht dein KI-Assistent?

Die Auswahl der MCP-Tools legt fest, welche Aufgaben ein KI-Assistent tatsächlich übernehmen kann. Zusätzliche Funktionen schaffen Überschneidungen, weitere Zugriffswege und mehr Prüfaufwand. Ein Assistent braucht daher genau die Werkzeuge für seinen festgelegten Arbeitsablauf.

Mit einem MCP-Tool ist hier eine aufrufbare Funktion gemeint, die ein MCP-Server bereitstellt: etwa einen Supportfall lesen, einen Kontakt suchen oder einen Datensatz aktualisieren. Wie viele solcher Funktionen sinnvoll sind, lässt sich nicht mit einer pauschalen Obergrenze beantworten. Eine belastbare Regel gibt es trotzdem: Jedes freigegebene Tool braucht einen konkreten Prozessschritt und einen prüfbaren Anwendungsfall.

Beginne beim Arbeitsergebnis, nicht beim MCP-Server

Die Tool-Auswahl beginnt häufig mit einer technischen Bestandsaufnahme: Welche Systeme sind vorhanden, welche Schnittstellen lassen sich anbinden und welche Funktionen könnte der Server anbieten? Das produziert schnell eine lange Liste, beantwortet aber noch nicht, was der Assistent erledigen soll.

Formuliere stattdessen zuerst das gewünschte Arbeitsergebnis in einem Satz. Für die Vorbereitung eingehender Supportanfragen könnte es beispielsweise lauten:

Der Assistent sammelt zu einem neuen Supportfall die freigegebenen Kunden- und Projektinformationen und erstellt einen Antwortentwurf. Er verändert keine Daten und versendet keine Nachricht.

Dieser Satz grenzt den Werkzeugsatz bereits deutlich ein. Der Assistent muss den Supportfall lesen, passende Kontextinformationen finden und den Entwurf ausgeben können. Er muss weder Kontakte bearbeiten noch Fälle schließen oder E-Mails verschicken.

Entscheidend ist die Formulierung des Ergebnisses. „Support unterstützen“ wäre zu offen. „Einen Antwortentwurf mit freigegebenem Kontext erstellen“ lässt sich dagegen in einzelne Arbeitsschritte zerlegen und später testen.

Leite die Tools aus den tatsächlichen Prozessschritten ab

Zerlege den gewünschten Ablauf so weit, dass jeder Schritt eine beobachtbare Aufgabe beschreibt. Für das Supportbeispiel könnte die Folge so aussehen:

1. Den Inhalt und Status des neuen Supportfalls abrufen.
2. Den zugeordneten Kunden und das betroffene Projekt ermitteln.
3. Freigegebene Projekthinweise oder Wissensartikel suchen.
4. Aus diesen Informationen einen Antwortentwurf erstellen.

Nur die ersten drei Schritte benötigen möglicherweise MCP-Tools. Der vierte Schritt kann innerhalb des KI-Assistenten stattfinden, sofern dafür keine weitere Datenquelle abgefragt werden muss. Nicht jede Aktivität im Ablauf muss also als eigenes Tool modelliert werden.

Gehe anschließend jedes geplante Tool mit einer einfachen Frage durch: Welcher konkrete Prozessschritt wäre ohne dieses Tool nicht möglich? Fehlt darauf eine klare Antwort, gehört das Tool vorerst nicht in den Werkzeugsatz.

Unterscheide Lesen, Schreiben und Auslösen

Der Name eines Tools sagt wenig darüber aus, welche Folgen sein Aufruf hat. Für die Auswahl ist deshalb wichtig, die angebotenen Funktionen nach ihrer Wirkung zu unterscheiden:

• Lesende Tools rufen vorhandene Informationen ab, etwa einen Auftrag, einen Termin oder einen Supportfall.
• Schreibende Tools verändern bestehende Daten oder legen neue Datensätze an, beispielsweise eine interne Notiz oder einen Kontakt.
• Auslösende Tools starten eine nach außen wirksame Aktion, etwa den Versand einer Nachricht, die Veröffentlichung eines Inhalts oder die Erstellung einer Bestellung.

Diese Unterscheidung verhindert, dass eine scheinbar kleine Ergänzung unbemerkt den Verantwortungsbereich des Assistenten erweitert. Ein Antwortentwurf und eine versendete Antwort liegen fachlich nah beieinander, sind für den Prozess aber grundverschieden. Beim Entwurf kann ein Mensch vor dem Versand prüfen. Ein Versand-Tool verlagert diesen Kontrollpunkt.

Schreibende oder auslösende Funktionen sind nicht grundsätzlich falsch. Sie sollten jedoch nur verfügbar sein, wenn das gewünschte Arbeitsergebnis sie ausdrücklich voraussetzt. Eine Bestätigung vor dem Aufruf kann zusätzlich sinnvoll sein, ersetzt aber keine saubere Begrenzung der Berechtigungen.

Vermeide mehrere Tools für dieselbe fachliche Entscheidung

Probleme entstehen häufig durch Überschneidungen. Angenommen, ein Assistent kann zwischen Kunde suchen, Kontakt finden und Konto nachschlagen wählen. Wenn alle drei Funktionen ähnliche Datensätze liefern, muss das Modell aus Beschreibungen erraten, welcher Weg im aktuellen Fall gemeint ist.

Prüfe solche Überschneidungen aus fachlicher Sicht:

• Bearbeiten die Tools dasselbe Objekt unter verschiedenen Namen?
• Liefern sie ähnliche Ergebnisse mit unterschiedlichen Feldern?
• Kann ein allgemeineres Tool die Aufgabe eindeutig abdecken?
• Gibt es einen nachvollziehbaren Grund, warum beide Funktionen getrennt bleiben müssen?

Eine Zusammenlegung ist sinnvoll, wenn die Funktionen fachlich dasselbe leisten. Getrennte Tools sind besser, wenn sie unterschiedliche Rechte, Datenquellen oder Folgen haben. So können etwa Supportfall lesen und Supportfall schließen bewusst getrennt bleiben, obwohl beide dasselbe Objekt betreffen.

Zu breite Universalwerkzeuge lösen das Problem ebenfalls nicht. Ein allgemeines Tool wie Datensatz bearbeiten ist zwar flexibel, verschiebt aber die fachliche Entscheidung in frei formulierte Parameter. Klar abgegrenzte Funktionen lassen sich leichter beschreiben, berechtigen und mit konkreten Fällen prüfen.

Gib jedem Tool einen eindeutigen Auftrag

Auch ein kleiner Werkzeugsatz wird unzuverlässig, wenn Namen, Beschreibungen und Eingaben mehrdeutig sind. Die Tool-Beschreibung ist keine technische Dekoration. Sie ist ein Teil der Entscheidung, ob und wie der Assistent die Funktion verwendet.

Eine brauchbare Definition beantwortet knapp:

• Welches fachliche Objekt bearbeitet das Tool?
• Welche Aktion führt es aus?
• In welcher Situation soll es verwendet werden?
• Welche Pflichtangaben werden benötigt?
• Welche Informationen liefert es zurück?
• Verändert es Daten oder löst es weitere Aktionen aus?

Ein Name wie get_data lässt fast alles offen. Supportfall anhand der Fallnummer lesen beschreibt Objekt, Aktion und benötigte Zuordnung deutlich besser. Die technische Bezeichnung darf kompakter sein, doch ihre Beschreibung sollte denselben eindeutigen Auftrag vermitteln.

Verlasse dich außerdem nicht auf stillschweigendes Kontextwissen. Wenn ein Tool eine Projekt-ID benötigt, sollte dieser Parameter klar benannt sein. Der Assistent sollte nicht raten müssen, ob eine Kundennummer, ein Projektkürzel oder eine beliebige Suchanfrage erwartet wird.

Begrenze den Werkzeugsatz auf die aktuelle Arbeitsphase

Ein längerer Prozess benötigt nicht in jeder Phase dieselben Funktionen. Bei einer Supportanfrage unterscheiden sich beispielsweise Sichtung, Bearbeitung und Abschluss. Während der Sichtung werden Informationen gelesen. In der Bearbeitung kann eine interne Notiz entstehen. Beim Abschluss werden Status und Kommunikation verändert.

Wenn deine technische Umgebung eine kontextabhängige Freigabe unterstützt, kannst du Tools passend zur jeweiligen Phase bereitstellen. Andernfalls kann eine Trennung in verschiedene Assistenten oder klar abgegrenzte Abläufe sinnvoll sein. Ein Assistent für die Vorbereitung muss nicht automatisch dieselben Rechte besitzen wie ein Assistent für den Abschluss.

Diese Aufteilung folgt der fachlichen Verantwortung. Sie verhindert zugleich, dass ein einziger Assistent für jede denkbare Variante eines Gesamtprozesses ausgerüstet wird. Der Wunsch nach einem universellen Helfer klingt bequem, führt aber schnell zu unklaren Zuständigkeiten.

Teste die Auswahl mit Arbeitsfällen statt Einzelaufrufen

Ein erfolgreich ausgeführter Tool-Aufruf beweist nur, dass die technische Verbindung funktioniert. Für die Tool-Auswahl musst du prüfen, ob der Assistent im gesamten Ablauf die passenden Funktionen verwendet und seine Grenzen einhält.

Definiere dafür wenige, aber unterschiedliche Arbeitsfälle:

1. Normalfall: Alle benötigten Angaben sind vorhanden und eindeutig.
2. Mehrdeutiger Fall: Mehrere Kunden, Projekte oder Datensätze könnten passen.
3. Unvollständiger Fall: Eine notwendige Kennung oder Information fehlt.
4. Leerer Fall: Das Tool findet keinen passenden Datensatz.
5. Grenzfall: Die Anfrage verlangt eine Änderung oder Aktion, für die kein Tool freigegeben ist.

Lege für jeden Fall vorab fest, welches Verhalten akzeptabel ist. Bei einer unklaren Projektzuordnung sollte der Assistent beispielsweise nachfragen, statt mehrere Datensätze zusammenzumischen. Verlangt ein Nutzer den direkten Versand, obwohl nur ein Entwurf vorgesehen ist, muss der Ablauf an dieser Grenze enden.

Jedes Tool sollte in mindestens einem solchen Arbeitsfall notwendig sein. Bleibt ein Tool in allen realistischen Tests ungenutzt, ist das ein gutes Signal, es vorerst zu entfernen.

Erweitere erst bei einem belegten Bedarf

Ein zusätzlicher Zugriff sollte ein konkretes Hindernis beseitigen. Ein vager Hinweis wie „Das könnte später praktisch sein“ reicht dafür nicht aus. Besser ist ein dokumentierter Fall: Der Assistent kann wiederholt keine passende Antwort vorbereiten, weil ihm eine bestimmte freigegebene Information fehlt.

Vor der Erweiterung solltest du klären:

• Welcher bestehende Arbeitsfall scheitert oder bleibt unnötig manuell?
• Welche Information oder Aktion fehlt genau?
• Kann ein vorhandenes Tool den Bedarf mit einer eindeutigeren Ausgabe abdecken?
• Welche zusätzlichen Daten oder Änderungen werden dadurch zugänglich?
• Mit welchem Testfall wird die Erweiterung geprüft?

So wächst der Werkzeugsatz aus beobachteten Anforderungen. Er wird nicht zum technischen Lagerraum für jede Funktion, die der MCP-Server theoretisch anbieten könnte.

Dokumentiere die Auswahl auf einer Seite

Für einen überschaubaren Assistenten genügt meist eine kurze Arbeitsdefinition. Sie sollte das gewünschte Ergebnis, die erlaubten Quellen und die Grenzen zusammenhalten. Folgende Angaben sind dafür hilfreich:

• Arbeitsablauf: Welchen Vorgang unterstützt der Assistent?
• Ergebnis: Was soll am Ende konkret vorliegen?
• Werkzeuge: Welche MCP-Tools sind dafür freigegeben?
• Zugriffsart: Liest, schreibt oder löst jedes Tool etwas aus?
• Grenzen: Welche Änderungen darf der Assistent ausdrücklich nicht vornehmen?
• Prüffälle: An welchen typischen und schwierigen Fällen wird die Auswahl getestet?

Diese Dokumentation hilft bei späteren Änderungen. Wenn ein neues Tool vorgeschlagen wird, lässt sich prüfen, ob es zum vereinbarten Ergebnis gehört oder den Aufgabenbereich still erweitert. Auch fachliche Verantwortliche können die Auswahl nachvollziehen, ohne die Implementierung des MCP-Servers kennen zu müssen.

Die richtige Anzahl ergibt sich aus dem Ablauf

Für MCP-Tools gibt es keine allgemein passende Höchstzahl. Ein klar begrenzter Ablauf kann mit wenigen Funktionen auskommen, während ein umfangreicher Prozess mehr Werkzeuge benötigt. Die Zahl allein ist deshalb keine sinnvolle Qualitätskennzahl.

Entscheidend ist, ob jedes Tool einen notwendigen Prozessschritt abdeckt, sich fachlich von den übrigen Funktionen unterscheidet und in einem Arbeitsfall geprüft wird. Beginne mit dem kleinsten vollständigen Werkzeugsatz. Ergänze ihn erst, wenn ein konkreter Ablauf an einer fehlenden Fähigkeit scheitert. So bleibt der KI-Assistent nützlich, ohne zum unübersichtlichen Fernzugriff auf sämtliche Unternehmenssysteme zu werden.

Häufige Fragen

Kurz beantwortet, damit du schneller einschätzen kannst, was für dein Projekt wichtig ist.

Wie viele MCP-Tools sollte ein KI-Assistent erhalten?

Dafür gibt es keine feste Obergrenze. Jedes Tool sollte jedoch einen notwendigen Schritt im festgelegten Arbeitsablauf abdecken und durch einen konkreten Prüffall begründet sein.

Sollte ein KI-Assistent zunächst nur lesende MCP-Tools bekommen?

Lesende Tools sind für viele vorbereitende Abläufe ein sinnvoller Ausgangspunkt. Schreibende oder auslösende Tools kommen hinzu, wenn das gewünschte Arbeitsergebnis diese Aktionen ausdrücklich verlangt und passende Kontrollen vorgesehen sind.

Wann sollten zwei ähnliche MCP-Tools zusammengelegt werden?

Eine Zusammenlegung bietet sich an, wenn beide Tools fachlich dieselbe Aufgabe erfüllen und vergleichbare Ergebnisse liefern. Unterschiedliche Rechte, Datenquellen oder Auswirkungen sprechen dagegen für getrennte Funktionen.

Woran erkenne ich ein überflüssiges MCP-Tool?

Wenn du keinen konkreten Prozessschritt und keinen realistischen Prüffall dafür benennen kannst, ist das Tool wahrscheinlich nicht erforderlich. Es kann später ergänzt werden, sobald ein belegter Bedarf entsteht.