Foundry Tool Search: Weniger MCP-Kontext, klare Rechte

Ein Agent kann Dutzende Tool-Definitionen erhalten, bevor er die eigentliche Frage bearbeitet. Geräteberichte, Ticket-Aktionen und Verzeichnisabfragen belegen dann schon einen Teil seines Kontexts.

Foundry Tool Search verändert, wie diese Definitionen zum Modell kommen. Ich zeige die Konfiguration und einen kleinen lokalen Größenvergleich. Ziel ist weniger unnötiger Kontext, ohne die passenden Tools oder die bestehenden Zugriffsgrenzen zu verlieren.

Die Produktangaben sind vom 20. Oktober 2026. Der Größenvergleich wurde lokal ausgeführt; er ist keine Messung eines laufenden Foundry-Deployments.

Zuerst die tatsächlich sichtbaren Tools prüfen

Tool Search wurde mit dem September-Update von Foundry allgemein verfügbar. Mit toolbox_search entdeckt der Agent Fähigkeiten über tool_search und ruft gefundene Operationen über call_tool auf. Er muss nicht sofort alle gewöhnlichen Definitionen erhalten. Release-Hinweis

Das ist beispielsweise bei einem Intune-Assistenten mit vielen Berichten interessant. Für die Compliance eines Geräts braucht er nicht gleichzeitig die vollständigen Schemas zur App-Erstellung, zum Export sämtlicher Berichte und zur Änderung von Gruppenmitgliedschaften.

Erfasse vor der Änderung die anfängliche Tool-Liste, eine typische Frage und die tatsächlich verwendeten Operationen. Modell, Anweisungen und Aufgabe bleiben beim Vergleich gleich. Sonst weißt du nicht, ob eine bessere Antwort von der Suche oder einem anderen Modell kommt.

Foundry Toolboxes bündeln und konfigurieren Tools. Damit wird nicht automatisch jede Operation hinter einer Verbindung zu einer passenden Fähigkeit für jeden Agenten. Toolbox-Überblick

Die Suche in einer eigenen Toolbox-Version aktivieren

Beginne mit einer separaten Lab-Toolbox, die nur freigegebene Leseoperationen enthält. Dieses Beispiel zeigt einen Ausschnitt für eine Toolbox-Version. Endpoint und Verbindungskennung musst du durch deine vorhandene Konfiguration ersetzen:

{
  "tools": [
    { "type": "toolbox_search" },
    {
      "type": "mcp",
      "server_label": "inventory",
      "server_url": "https://inventory.example/mcp",
      "project_connection_id": "inventory-readonly",
      "tool_configs": {
        "get_device_compliance": {
          "pin": true,
          "additional_search_text": "device compliance noncompliant device status"
        }
      }
    }
  ]
}

Verwende den Toolbox-Editor im Foundry Toolkit oder die dokumentierte Versions-API. Teste zuerst den versionsgebundenen MCP-Endpoint, bevor du die vom produktiven Agenten verwendete Version umstellst. Bei einer neuen Lab-Toolbox wird die erste Version deren Standard. Eine neue Ressource allein ist deshalb noch kein geprüfter Produktions-Rollout. Konfiguration und Prüfung

Die angeheftete Operation steht hier für eine fast immer benötigte Fähigkeit. Wer alles anheftet, stellt den ursprünglichen Zustand wieder her. Zusätzliche Suchbegriffe sollen Fachsprache erklären. Zugangsdaten, Kundenbeispiele oder private Daten gehören dort nicht hinein.

Tool-Suche und Berechtigungen getrennt prüfen

MCP trennt das Auflisten von Tools von deren Aufruf. Eine gute Beschreibung hilft bei der Auswahl. Eingabeprüfung und Zugriffskontrolle bleiben Aufgabe des Servers. Eine readOnlyHint-Annotation oder ein Suchtreffer ist keine Autorisierung. MCP-Tools-Spezifikation

Für einen kleinen Pilot würde ich drei Stellen kontrollieren:

Prüfstelle	Erwarteter Nachweis
Anfängliche Liste	Suchoperationen und erwartete angeheftete Tools statt des gesamten Katalogs
Suche	Passendes Tool für eine fachlich formulierte Frage
Aufruf	Erlaubter Zugriff mit begrenztem Umfang und nachvollziehbarem Ergebnis

Vergleiche einen frischen Testbenutzer und einen regelmäßig genutzten Benutzer getrennt. Foundry dokumentiert auch das automatische Anheften häufig verwendeter Tools. Eine spätere Liste kann deshalb berechtigt anders aussehen. Halte fest, welche Tools du explizit angeheftet hast und welche durch die Nutzung auftauchen.

Bei einem Intune-Bericht muss das Backend den erlaubten Geräteumfang selbst ableiten. „Nimm die Gruppe mit allen Geräten“ im Prompt darf diese Grenze nicht erweitern. Ein Tool mit dem Namen get_device_compliance ist nur dann lesend, wenn seine Implementierung keine Änderungen ausführt.

Payload-Größe messen, ohne Token-Ersparnis zu erfinden

Speichere das Beispiel als payload_check.py und starte es mit python3 payload_check.py. Es braucht keine Zugangsdaten und ruft kein Modell auf:

import json

def size(value):
    return len(json.dumps(value, separators=(",", ":")).encode())

def tool(i):
    return {
        "name": f"read_report_{i:02}",
        "description": "Read one authorized device report. Never modify devices.",
        "inputSchema": {
            "type": "object",
            "properties": {"group_id": {"type": "string"}},
            "required": ["group_id"],
        },
    }

catalogue = [tool(i) for i in range(40)]
meta = [{"name": "tool_search"}, {"name": "call_tool"}]
print({"eager_bytes": size(catalogue),
       "initial_bytes": size(meta),
       "with_two_tools_bytes": size(meta + catalogue[:2])})
assert size(meta + catalogue[:2]) < size(catalogue)

Das sind synthetische Definitionen, einschließlich vereinfachter Suchtools. Die Zahlen beschreiben dieses Beispiel, nicht das genaue Request-Format von Foundry. UTF-8-Bytes sind keine Tokens. Ein kleinerer erster Request ist noch kein Abrechnungsergebnis.

Für einen echten Vergleich würde ich die gemeldete Eingabenutzung über die gesamte Aufgabe erfassen: Suche, geladene Definitionen, Tool-Ergebnisse und Wiederholungen. Dazu kommen erfolgreiche Aufgabenerledigung und Latenz. Findet die Suche die richtige Operation nicht, hilft die kleinere anfängliche Tool-Liste wenig.

Einen kleinen Testsatz für die Suche anlegen

Teste die Formulierungen deiner Kollegen, nicht nur den exakten technischen Operationsnamen.

Anfrage	Erwartetes Verhalten
„Warum ist DEMO-01 nicht compliant?“	Freigegebene Compliance-Abfrage finden
„Welche Regel schlägt auf dem Laptop fehl?“	Dieselbe Fähigkeit trotz anderer Formulierung finden
„Entferne die fehlerhafte Richtlinie“	Kein schreibendes Tool in dieser lesenden Toolbox
„Prüfe die Geräte eines anderen Kunden“	Geräteumfang ablehnen, auch wenn ein passendes Tool existiert
„Zeige das Ergebnis von gestern“	Messzeitpunkt nennen oder fehlende Historie erklären
Fachfremde Anfrage	Fehlende Fähigkeit benennen statt eine ungeeignete Aktion auszuführen

Speichere die erwartete Operation und das Berechtigungsergebnis pro Test. Suche und abschließender Aufruf werden getrennt bewertet. Eine plausibel klingende Antwort belegt noch keine korrekte Tool-Auswahl.

Mit einer Aufgabe statt dem ganzen Katalog starten

Ich würde mit einem Gerätebericht beginnen und danach eine zweite Aufgabe mit anderen Tools ergänzen. Wiederhole den Testsatz, wenn sich Name, Beschreibung, Schema, Verbindung oder Toolbox-Version ändern.

Halte die vorherige Toolbox-Version und Agentenkonfiguration für einen Rollback bereit. Wird die Suche schlechter, prüfe zuerst Anfrage, Beschreibung und Treffer. Alle Tools wieder in den ersten Kontext zu laden, sollte eine bewusste Rückfalloption bleiben.

Mein Beitrag zu Skills und MCP beschreibt den Unterschied zwischen Anweisungen und Integrationen. Hier geht es um die engere Frage, welchen Teil der verfügbaren Tools das Modell für eine konkrete Aufgabe überhaupt sehen muss.