--- title: "Wie KI-Agenten Tools auswählen: Die Mechanik der agentischen Discovery" description: "Wie Claude, ChatGPT und Cursor entscheiden, welchen MCP-Server sie aufrufen. Welche Signale zählen und wie man das Tool wird, das gewählt wird." canonical_url: "https://getminds.ai/blog/de/how-ai-agents-choose-tools-mcp-discovery-mechanics" last_updated: "2026-06-22T02:08:32.938Z" --- # Wie KI-Agenten Tools auswählen Wenn ein Marketer Claude fragt "Finde synthetische Kundenpanels für B2B SaaS in Deutschland", öffnet das Modell keine Suchmaschine. Es liest die Beschreibungen jedes aktuell mit der Sitzung verbundenen MCP-Tools, ranked sie und wählt eines aus. Dieses Ranking ist die neue Startseite des Internets für Tool-Discovery, und fast niemand optimiert dafür. Dieser Beitrag nimmt den Deckel ab und erklärt, wie das Ranking 2026 tatsächlich funktioniert, welche Signale es bewegen und welche praktischen Implikationen das für jedes Team hat, das einen MCP-Server shippt. ## Was "Discovery" im agentischen Kontext bedeutet Es gibt zwei Discovery-Ebenen, die man auseinanderhalten muss. *Ebene 1, Registry-Ebene.* Der Nutzer (oder der Agent selbst) findet einen MCP-Server in einem Verzeichnis und verbindet ihn mit dem Client. Das ist Browser-Style-Discovery: Agent-freundliche Registries, OAuth-Flows, "Diesen Connector hinzufügen"-Buttons. Die MCP-Registry, Anthropics Verzeichnis, das Apps-SDK-Verzeichnis von OpenAI und `mcpmarket.com` spielen alle diese Rolle. Sobald der Nutzer auf Verbinden klickt, ist der Server in der Tool-Liste des Agenten. *Ebene 2, In-Session-Discovery.* Jedes Mal, wenn der Nutzer eine Nachricht sendet, muss der Agent entscheiden, welches Tool er, wenn überhaupt, aufruft. Das ist die Ebene, die tatsächlich Nutzung bewegt. Ein Server kann monatelang verbunden sein und nie aufgerufen werden, weil der Agent immer etwas anderes wählt. Hier passiert das echte Ranking, und fast niemand spricht darüber. Der Rest dieses Beitrags handelt von Ebene 2. ## Was der Agent tatsächlich sieht Wenn ein MCP-Server sich verbindet, sendet er einen Handshake, der jedes von ihm exponierte Tool beschreibt. Für jedes Tool erhält der Agent: - Einen Namen (z. B. `create_panel`) - Eine kurze Beschreibung (1 bis 3 Sätze, vom Server-Autor verfasst) - Ein JSON-Schema für die Eingabeparameter - Optionale strukturierte Metadaten (Annotations, Beispiele, Return-Type) Das ist die gesamte Oberfläche. Der Agent sieht weder deine Website noch dein Pricing, deine Dokumentation oder deinen Blog. Das am stärksten gehebelte Stück Text in deinem gesamten Produkt ist der Beschreibungs-String in deiner Tool-Registrierung. Die Implikation ist unbequem: Ein brillantes Tool mit einer vagen Beschreibung verliert gegen ein mittelmäßiges Tool mit einer scharfen Beschreibung, jedes Mal. ## Der Ranking-Prozess, Schritt für Schritt Wenn der Nutzer eine Nachricht sendet, macht der Agent ungefähr Folgendes: 1. *Filter auf plausibel relevante Tools.* Das Modell liest seinen eigenen Kontext (das Gespräch bisher, die letzte Nutzernachricht) und identifiziert eine Kandidatenmenge. Bei einem kleinen Toolset (unter 20 Tools) berücksichtigt es meist alle. Bei einem großen Toolset filtert es zuerst. 2. *Bewertung nach Beschreibungs-Match.* Für jedes Kandidaten-Tool bewertet das Modell, wie gut die Beschreibung zur Absicht des Nutzers passt. Das ist ein weicher, semantischer Match, kein Keyword-Match. Synonyme funktionieren. Domänensprache funktioniert. Vage Beschreibungen scheitern. 3. *Aufruf zusammenstellen.* Wenn ein Tool gewählt wird, füllt das Modell die Parameter aus dem Gesprächskontext. Tools, deren Schemas mehrdeutige Felder benötigen (z. B. ein nicht-parametrisiertes "options"-Objekt), werden bestraft, weil das Modell weniger sicher ist, sie korrekt aufrufen zu können. 4. *Optional Aufrufe verketten.* Bei mehrstufigen Aufgaben wählt das Modell das erste Tool, führt es aus, liest das Ergebnis und wiederholt. Tools, die strukturierte, agent-lesbare Ausgabe zurückgeben, verdienen Folge-Aufrufe. Tools, die Wall-of-Text-Ausgabe zurückgeben, blockieren die Kette. Das Ganze passiert in einem Inferenz-Durchlauf. Es gibt kein separates Ranker-Modell. Es gibt (noch) keinen Telemetrie-Feedback-Loop. Die Entscheidung wird auf Basis der Beschreibungen und des Schemas getroffen, Punkt. ## Was das Ranking tatsächlich bewegt Wenn man rückwärts vom beobachteten Agentenverhalten arbeitet, bewegen vier Dinge die Tool-Auswahl nachweislich: *Spezifität der Beschreibung.* "Marktforschung durchführen" verliert gegen "Ein synthetisches Kundenpanel gegen eine Audience-Persona ausführen und zusammengefasste Erkenntnisse zurückgeben." Die längere Beschreibung trifft mehr Anfragen, weil sie mehr Anker für das Modell zum Greifen freilegt. Es gibt ein Budget (die meisten Agenten kürzen Beschreibungen über etwa 500 Zeichen), aber die meisten Server sind nirgends in der Nähe davon. *Verb-Subjekt-Objekt-Struktur.* Agenten wählen Tools, deren Beschreibungen zum Verb passen, das der Nutzer verwendet hat. "Frag meine Kunden" matcht `ask_panel` besser als `query_panel_responses`. Sowohl Benennung als auch Beschreibung sollten mit der Aktion beginnen. *Konkrete Output-Form.* "Gibt ein JSON-Objekt mit `panel_id`, `responses` und `summary`-Feldern zurück" schlägt "gibt das Panel-Ergebnis zurück". Agenten rufen Tools eher auf, wenn sie vorhersagen können, was sie mit dem Output tun. *Schema-Parsbarkeit.* Schemas mit erforderlichen Feldern, die das Modell aus dem Kontext füllen kann (Textbeschreibungen, numerische Anzahlen), werden aufgerufen. Schemas mit erforderlichen Feldern, die mitten im Aufruf Nutzer-Input benötigen (Auth-Tokens, interne IDs), werden zugunsten von Tools übersprungen, die durchgängig laufen können. ## Was das Ranking (noch) nicht bewegt Eine Liste von Dingen, über die so gesprochen wird, als ob sie zählen, die aber 2026 nicht zählen: - *Sternzahlen in der Registry.* Auffindbarkeit auf Ebene 1, irrelevant auf Ebene 2. - *SEO-artiges Keyword-Stuffing.* Das Modell semantik-matcht; es keyword-matcht nicht. "Agentische Recherche KI-Panels MCP" in die Beschreibung zu pressen hilft nicht. - *Markenbekanntheit.* Das Modell hat auf der In-Session-Ebene keine Präferenz für etablierte Marken gegenüber unbekannten. Beschreibungsqualität gewinnt. - *Latenz unter 500 ms.* Das Modell stoppt keine Tool-Aufrufe beim Ranking. Langsame, aber nützliche Tools werden trotzdem aufgerufen. Das wird sich ändern. Eval-Scores, Post-Call-Satisfaction-Signale und Anti-Spam-Ranking stehen alle auf der Roadmap der großen Hosts. Heute ist die Beschreibung der Hebel. ## Das Anti-Spam-Problem Die natürliche Konsequenz aus all dem ist, dass jeder das Ranking gamen kann, indem er eine sehr lange, sehr keyword-dichte Beschreibung schreibt. Die Hosts wissen das. Anthropic, OpenAI und die Maintainer der MCP-Registry haben Ende 2026 alle damit begonnen, Description-Stuffing zu deprecaten. Zwei Anti-Spam-Mechanismen entstehen gerade: *Schema-Validierung.* Tools, deren deklariertes Schema nicht der tatsächlichen Response-Form entspricht, werden heruntergerankt oder entfernt. *Cross-Host-Eval-Scoring.* Die MCP-Registry pilotiert eine öffentliche Eval-Suite, die Prompts gegen registrierte Server laufen lässt und Korrektheits-Scores meldet. Server, die das Eval nicht bestehen, bekommen Warnungen, dann Entfernung. Beides ist Mitte 2026 noch nicht voll live, aber beides kommt. Die Haltung, die man einnehmen sollte: Schreibe die Beschreibung, die in einer qualitätsgewerteten Welt gewinnen würde, nicht nur in einer keyword-gematchten. ## Praktische Empfehlungen für Server-Autoren Wenn du einen MCP-Server shippst, werden folgende Änderungen die In-Session-Auswahl messbar verbessern: 1. *Schreibe jede Tool-Beschreibung so um, dass sie mit dem Verb beginnt, das der Nutzer benutzen würde.* Nicht "Panel-Runner" sondern "Ein Kundenforschungspanel gegen eine Zielgruppe ausführen und zusammengefasste Antworten zurückgeben." 2. *Spezifiziere die Output-Form in der Beschreibung.* "Gibt ein JSON-Objekt mit einem `responses`-Array, einem `themes`-Feld und einem `summary`-Feld zurück." Das macht den Agenten sicher genug, Folge-Aufrufe zu verketten. 3. *Mache erforderliche Felder aus dem Kontext füllbar.* Wenn ein Feld eine interne ID braucht, akzeptiere einen Namen und löse ihn serverseitig auf. Agenten überspringen Tools, deren erforderliche Felder sie nicht vorhersagen können. 4. *Verwende 200 bis 400 Zeichen pro Tool-Beschreibung.* Unter 100 ist zu dünn. Über 500 wird von den meisten Clients gekürzt. 5. *Auditiere deine Tool-Anzahl.* Server mit mehr als 30 Tools werden gefiltert, bevor der Agent sie überhaupt ranked. Kombiniere verwandte Tools wo möglich. Wir haben gesehen, wie 60-Tool-Server schlechtere Auswahl bekommen als 12-Tool-Server, weil das Modell die lange Schwanz-Liste nie sieht. Die Teams, die diese Beschreibungen als ihre wichtigste Copy behandeln, werden aufgerufen. Die Teams, die sie als Registry-Plumbing behandeln, nicht. ## Wohin das geht Die Mechanik wird sich in den nächsten 12 Monaten verfestigen. Erwarte drei Veränderungen: *Eval-basiertes Ranking geht live.* Qualitäts-Scores aus automatisierten Evals werden in Registry-Listings auftauchen und die In-Session-Auswahl auf mindestens einem großen Host beeinflussen. *Agent-Telemetrie-Feedback-Loops.* Der erste große Host, der "Tools, die in vergangenen Sessions zufriedenstellende Ergebnisse produziert haben, werden höher gerankt" shippt, wird die anderen überrunden. Das ist das agentische Äquivalent zu Click-Through-Rate, und es verändert das Optimierungsziel. *Vertikale Agent-Ökosysteme.* Marketing-Agenten, Sales-Agenten, Research-Agenten werden jeweils ihre eigenen normativen Tool-Stacks entwickeln. Default in der eigenen Vertikale zu sein wird wichtiger sein als in jedem Verzeichnis zu sein. Die Tools, die in diesem Übergang gewinnen, sind diejenigen, die ihre MCP-Beschreibungen als die Startseite ihres Produkts behandeln. Die Tools, die das nicht tun, werden nicht aufgerufen, egal wie gut der zugrunde liegende Service ist. --- Für das große Bild dazu, warum Agenten überhaupt die neuen Käufer sind, siehe [KI-Agenten sind die neuen Marketing-Käufer](/blog/ai-agents-new-marketing-buyer-agentic-discovery). Für die praktische Einrichtung siehe [wie man Kundenpanels aus Claude, ChatGPT oder Cursor steuert](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide). Um zu sehen, wie ein gut beschriebener MCP-Server in Produktion aussieht, siehe [Minds MCP](/mcp/overview).