Ein Connic-Agent kann Hunderte Tools nutzen, ohne jedes Schema im Kontextfenster des Modells mitzuführen. Connic verwaltet durchsuchbare Tools in einem Katalog. Der Agent durchsucht diesen Katalog, sobald er eine Funktion braucht. Erst dann gelangen die passenden Schemas in seinen Kontext. Noch nicht abgerufene Schemas bleiben außerhalb des Modellkontexts.
Tool-Definitionen belegen Kontext, bevor die Arbeit beginnt
Für einen zuverlässigen Aufruf braucht ein Modell mehr als den Namen eines Tools. Dessen Schema beschreibt Zweck, Argumente, Typen und Pflichtfelder. Je mehr APIs und MCP-Server ein Agent nutzen kann, desto mehr Raum können diese Definitionen in jeder Anfrage einnehmen, selbst wenn die aktuelle Aufgabe nur ein oder zwei Tools benötigt.
Das Kontextfenster hat ein begrenztes Tokenbudget. Neben den Tool-Definitionen brauchen auch Anweisungen, Gesprächsverlauf, Aufgabendaten und Tool-Ergebnisse Platz. Die Dokumentation von Anthropic zum Tool-Kontext beschreibt, wie Definitionen und angesammelte Ergebnisse dieses Budget ausschöpfen können. Ein vollständig geladener Tool-Katalog lässt weniger Raum für die Informationen, die der Agent zur Erledigung seiner Aufgabe braucht.
Das Modell erhält ein Tool zum Suchen und eines zum Ausführen
Connic hält den Tool-Katalog außerhalb des Modellkontexts bereit. Ein Suchtool liefert passende Tools mit ihren Beschreibungen und benötigten Eingaben. Über ein zweites Tool kann das Modell ein gefundenes Tool ausführen lassen. Häufig benötigte Tools können direkt verfügbar bleiben; ihre Schemas erhält das Modell von Anfang an.
Angenommen, ein Agent hat 200 fachliche Tools, die alle für den Run verfügbar sind. Mit zwei direkt verfügbaren und 198 durchsuchbaren Tools erhält das Modell über vier Tool-Schemas zu Beginn Zugriff auf alle 200:
| Tool-Gruppe | Anzahl | Was das Modell erhält |
|---|---|---|
| Direkte fachliche Tools | 2 | Ihre Schemas von Beginn an |
| Durchsuchbare fachliche Tools | 198 | Passende Schemas bei Bedarf als Suchergebnis |
| Such- und Ausführungstool | 2 | Angaben zum Finden und Aufrufen von Katalog-Tools, von Beginn an |
Die übrigen 198 Funktionen bleiben über die Suche aufrufbar. Eine weitere durchsuchbare Funktion vergrößert den Katalog, ohne dass das Modell ihr Schema vorab erhalten muss.
Ein Schema gelangt bei der Suche in den Kontext
Bei einer Frage zum Zahlungsstatus kann ein Abrechnungsassistent seinen häufig benötigten Rechnungsabruf direkt aufrufen. Für einen monatlichen Rechnungsexport kann er dagegen das Suchtool nach einem passenden Export-Tool fragen.
Connic gleicht die Suchbegriffe mit Tool-Namen und Beschreibungen ab. Das Modell erhält passende, verfügbare Tools mit ihrem Namen, einer Beschreibung und den benötigten Eingaben. Standardmäßig liefert die Suche bis zu fünf Ergebnisse, höchstens sind 20 je Suche möglich.
Findet das Modell ein passendes Export-Tool, kann es das Ausführungstool bitten, einen Export für August 2026 zu starten. Dafür gibt es die im Suchergebnis beschriebenen Eingaben an. Connic führt das gewählte Tool aus und gibt dessen Ergebnis zurück.
Das Modell hat damit die Angaben für diesen Schritt erhalten. Noch nicht abgerufene Schemas bleiben im Katalog. Gefundene Tools werden weiterhin über dasselbe Ausführungstool aufgerufen.
Die Suche hängt von den Wörtern in Tool-Namen und Beschreibungen ab. Beschreibungen wie „Create a monthly invoice export“ geben dem Agenten passende Suchbegriffe. Bei Synonymen oder Anfragen in einer anderen Sprache kann eine andere Formulierung nötig sein, um einen Treffer zu finden. Nach einem leeren Ergebnis kann der Agent seine Suche präzisieren oder mitteilen, dass die angeforderte Funktion nicht verfügbar ist.
Lokale Funktionen, API-Operationen und MCP-Tools teilen einen Katalog
Derselbe Mechanismus funktioniert für Python-Funktionen, aus OpenAPI-Spezifikationen generierte Tools und Tools von MCP-Servern. In einer bestehenden LLM-Agentenkonfiguration wählt tools die direkt verfügbaren Funktionen aus, discoverable_tools die Funktionen für den Katalog:
system_prompt: |
Answer customer billing questions using the available tools.
Search the tool catalog when a task needs an additional capability.
Read the returned schemas and use the execution tool to call a match.
If no suitable tool is available or a call fails, explain the limitation.
tools:
- billing.get_invoice_status
- support.find_customer
discoverable_tools:
- reporting.*
- exports.create_invoice_export: context.exports_enabled == true
- api:billing_admin.invoices_*Die Anwendungsfunktionen dienen als Beispiel. Die Python-Funktionen müssen unter tools/ vorhanden sein; reporting.* wählt öffentliche Funktionen aus tools/reporting.py aus. Der Artikel zum Run Context enthält das Beispiel für den Rechnungsabruf. Der Eintrag api:billing_admin.invoices_* setzt eine importierte OpenAPI-Spezifikation namens billing_admin voraus, deren generierte Tool-Namen zum Muster passen. Name, Version, Beschreibung und Modell des Agenten gehören in die umgebende Konfiguration.
Ein MCP-Server wird mit discoverable: true in den Katalog aufgenommen. Das folgende Beispiel erwartet einen Server mit den beiden genannten Tools; Endpunkt und Token sind als Umgebungsvariablen des Projekts hinterlegt. Die Liste tools beschränkt, welche Server-Tools in den Katalog gelangen.
mcp_servers:
- name: finance-tools
url: "${FINANCE_MCP_URL}"
headers:
Authorization: "Bearer ${FINANCE_MCP_TOKEN}"
tools:
- invoice_search
- supplier_lookup
discoverable: trueConnic verbindet sich mit dem Server und lädt dessen Tool-Katalog vor der Modellausführung. Diese Schemas bleiben bei Connic, bis eine Suche sie an das Modell zurückgibt. Die Anleitung zur MCP-Konfiguration beschreibt die Verbindung im Detail. Das MCP-Tutorial zum Rechnungsagenten behandelt die andere Richtung: Ein Connic-Agent wird für externe Clients aufrufbar.
Bedingungen begrenzen den verfügbaren Katalog je Run
Ein Tool kann im konfigurierten Katalog bleiben und für eine bestimmte Anfrage dennoch nicht verfügbar sein. Im Beispiel gibt context.exports_enabled == true Rechnungsexporte nur frei, wenn die Anwendung sie über den Run Context aktiviert. Bedingungen können über input.* auch Felder der JSON-Eingabe lesen.
Connic prüft die Bedingungen, nachdem die vorbereitende Middleware vor dem Modellaufruf gelaufen ist. Ist eine Bedingung nicht erfüllt, entfernt Connic das Tool aus den Suchergebnissen und blockiert seine Ausführung. Spätere Kontextänderungen führen während dieses Runs nicht zu einer Neuberechnung der Verfügbarkeit. Die Referenz zur Agenten-YAML dokumentiert diese Bedingungen und die Regeln für Tool-Listen. Dazu gehört, Überschneidungen zwischen direkt verfügbaren und durchsuchbaren Funktionen zu vermeiden. Kontoberechtigungen muss weiterhin das Tool oder die dahinterliegende API durchsetzen.
Mehr Kontext bleibt für die eigentliche Aufgabe
Wenn Schemas erst nach einem Suchabruf in Modellanfragen erscheinen, bleibt mehr Kontext für die Kundenfrage, relevante Dokumente und Ergebnisse vorangegangener Schritte.
Das Kontextfenster des Modells bleibt begrenzt. Zurückgegebene Schemas und Tool-Ergebnisse werden Teil des Gesprächsverlaufs und können sich ansammeln, bei einer persistenten Sitzung auch über mehrere Runs hinweg. Eine Grenze für die Ergebnisanzahl begrenzt nicht die Tokenzahl. Die optionale Kontextkomprimierung von Connic verkleinert einen wachsenden Verlauf. Die Tool-Suche begrenzt dagegen den Umfang des vorab übergebenen Tool-Katalogs. In den Run-Traces zeigen Suchergebnisse, aufgerufenes Tool und Modellaufrufe, wie diese Trennung bei einer konkreten Aufgabe funktioniert.
Mache spezielle Tools über die Suche verfügbar. Connic verwaltet den Katalog und die Aufrufe, damit dein Agent sie nutzen kann, ohne alle Schemas vorab zu laden.
Starte mit Connic