MCP-Server für Firmendaten: KI-Agenten anbinden

Wenn ein KI-Agent live lokale Business-Leads holen soll, ist der sauberste Weg, ihm diese Fähigkeit zu geben, ein Tool, das er aufrufen kann - und zunehmend wird dieses Tool über das Model Context Protocol (MCP) beschrieben. Ein MCP-Server exponiert eine Reihe von Tools, jedes mit einem Namen, einer Beschreibung und einem JSON Schema, die eine Agenten-Runtime selbstständig entdecken und aufrufen kann. Dieser Guide erklärt, was MCP ist, warum ein Firmendaten- und Lead-Tool eine natürliche Passung für die agenten-first-Welt ist, und wie biz collects OpenAPI-3.1-Spec, llms.txt, stabiles JSON und synchroner wait:true-Modus es trivial machen, es als MCP-artiges Tool zu umhüllen, das ein Agent aufruft, um aus einer Stadt und Stichworten strukturierte, verifizierte Firmendatensätze zu machen.

Was MCP ist

Das Model Context Protocol ist ein offener Standard zum Verbinden von KI-Agenten mit externen Tools und Daten. Statt dass jede Anwendung ihren eigenen Weg erfindet, einem Modell Fähigkeiten zu übergeben, definiert MCP eine gemeinsame Schnittstelle: Ein Server bewirbt eine Liste von Tools, und ein Client (die Agenten-Runtime) entdeckt sie, sieht ihre Schemata und ruft sie während einer Konversation oder Aufgabe auf.

Der wichtige Teil für Tool-Bauer ist, was eine Tool-Definition enthält. Jedes Tool, das ein MCP-Server exponiert, hat drei Dinge:

• Einen name, einen stabilen Identifikator, mit dem der Agent es aufruft, etwa search_local_businesses.
• Eine description, natürlichsprachigen Text, der dem Modell sagt, was das Tool tut und, entscheidend, wann es aufzurufen ist.
• Ein input_schema, ein JSON Schema, das die Argumente, ihre Typen und welche erforderlich sind beschreibt.

Das ist dieselbe Form, die für Tool-Definitionen über moderne Agenten-Runtimes hinweg genutzt wird. Entscheidet ein Agent, dass eine Aufgabe externe Daten braucht, liest er die verfügbaren Tool-Beschreibungen, wählt das richtige, füllt Argumente, die das Schema erfüllen, und ruft es auf. Die Runtime führt den Aufruf aus, gibt das Ergebnis zurück, und das Modell fährt fort. MCP standardisiert, wie dieser Tool-Katalog veröffentlicht und transportiert wird (üblicherweise über einen Streamable-HTTP-Endpunkt), sodass ein einzelner Server viele verschiedene Agenten bedienen kann.

Wollen Sie die konzeptionelle Definition für sich, deckt der Glossareintrag zu MCP-Server sie ab. Die offizielle Protokoll-Dokumentation lebt unter modelcontextprotocol.io.

Warum ein Firmendaten-Tool in den Agenten-Stack gehört

Sprachmodelle sind gut im Planen, im Deuten von Absicht und im Formatieren von Ergebnissen. Sie sind keine Live-Datenbank lokaler Betriebe und sollten nicht als solche behandelt werden. Bitten Sie ein Modell, "Zahnärzte in Austin" aus dem Gedächtnis aufzulisten, erhalten Sie plausibel wirkenden Text, keine operativen Daten, oft mit erfundenen Namen, veralteten Adressen und halluzinierten Telefonnummern.

Ein Lead- und Firmendaten-Tool schliesst genau diese Lücke. Es gibt dem Agenten eine Quelle der Wahrheit für zwei Dinge, die Modelle nicht zuverlässig selbst erzeugen können:

• Discovery. Welche Betriebe an einem Ort gerade tatsächlich existieren und zu einer Kategorie passen.
• Anreicherung. Die verifizierbaren Kontaktdaten für jeden: Website, Telefon, Adresse und E-Mails, extrahiert aus der eigenen Seite des Betriebs.

Das ist der Lehrbuchfall für Tool-Nutzung. Das Modell handhabt die Konversation, entscheidet, wonach zu suchen ist, validiert und scored die Ergebnisse und routet sie irgendwohin Nützliches. Das Tool handhabt deterministische Ausführung und liefert stabile Datensätze. Diese Verantwortungen zu trennen, macht einen Agenten testbar, günstiger zu betreiben und sicher zu vertrauen, weil die Daten nicht von der Fantasie des Modells abhängen. Der Begleitbeitrag zum Bau eines AI Lead Generation Agent durchläuft diese Planer-Tool-Validierung-Schreiber-Architektur im Detail. Wählen Sie, woher diese Live-Daten kommen sollen, siehe wie Google Places API, ein Scraper und eine Firmendaten-API sich vergleichen.

Der Grund, warum das jeden Monat mehr zählt: "agenten-first" wird zu einem echten Distributionskanal. Menschen bitten zunehmend einen Assistenten, die Arbeit zu erledigen, statt ein Dashboard zu öffnen. Ein Firmendaten-Produkt, das für einen Agenten leicht aufzurufen ist, ist ein Produkt, das in diesen Workflows auftaucht. Das Ziel, in unseren Worten: Nutzer mögen die App, und die KI ist verliebt in sie.

Was eine API trivial agenten-aufrufbar macht

Nicht jede API ist angenehm als Agenten-Tool zu umhüllen. Die, die es sind, teilen ein paar Eigenschaften, und biz collect wurde bewusst um sie herum gebaut.

1. Eine präzise OpenAPI-3.1-Spezifikation

biz collect veröffentlicht eine OpenAPI-3.1-Spec, die jeden Endpunkt, Parameter und jedes Antwortfeld beschreibt. Das ist der wichtigste Enabler für Agenten-Tooling, weil viele Runtimes und MCP-Server-Frameworks ein OpenAPI-Dokument einlesen und daraus automatisch Tool-Definitionen generieren können. Die Spec ist der Vertrag: Parametertypen, Pflichtfelder und Antwortformen sind alle maschinenlesbar, sodass das input_schema eines generierten Tools der echten API entspricht, ohne dass jemand es von Hand schreibt. Starten Sie bei den API-Docs für Spec und Endpunkt-Referenz.

2. Eine llms.txt, die Agenten zur Wahrheit weist

biz collect serviert eine llms.txt-Datei, einen einfachen, agentenlesbaren Index, der einem Modell sagt, wo die wichtige Dokumentation lebt. Landet ein Agent oder ein agentenbauender Entwickler auf der Domain, ist llms.txt ein schneller, tokenarmer Weg, die API-Oberfläche, die Docs und den Ablauf des Suchen-und-Pollen-Lebenszyklus zu entdecken, ohne Marketing-Seiten zu crawlen. Eine kleine Datei mit übergrossem Effekt darauf, wie leicht sich ein Agent orientieren kann.

3. Eine stabile, berechenbare JSON-Form

Ein Agenten-Tool ist nur so zuverlässig wie die Daten, die es liefert. biz collect liefert bei jedem Aufruf dieselben Feldnamen und dieselbe Struktur: Jeder Betrieb trägt name, address, phone, website und ein dedupliziertes emails-Array. Stabile Felder heissen, das Modell (und Ihr Validierungscode) kann sich ohne defensives Parsen darauf verlassen, und dieselbe Tool-Definition funktioniert weiter, während das Produkt wächst. Deduplizierung passiert, bevor die Antwort die API verlässt, sodass der Agent nie dieselbe Adresse dreimal bereinigen muss.

4. Ein synchroner wait:true-Modus

Das ist das Detail, das ein einzelnes sauberes Tool möglich macht. Standardmässig ist biz collect asynchron: Sie POSTen eine Suche, erhalten eine job_id und pollen /api/v1/jobs/:id, bis der Job fertig ist, das richtige Modell für grosse Jobs und für No-Code-Tools, die schleifen. Aber ein Modell zu bitten, eine Poll-Schleife zu managen, fügt Turns, Tokens und Fehlermodi hinzu.

Mit wait:true blockiert der Such-Request, bis der Job fertig ist, und liefert die Ergebnisse in derselben Antwort. Für einen Agenten fasst das den ganzen Erstellen-Pollen-Lesen-Lebenszyklus in einen Tool-Aufruf zusammen. Das Modell ruft ein Tool auf, bekommt angereicherte Leads zurück und fährt fort, keine Job-IDs, kein Poll-Status, keine Schleife zum Räsonieren. Für grössere Suchen können Sie weiterhin den Async-Pfad nutzen, aber für die typische Agenten-Anfrage hält der synchrone Modus die Tool-Definition einfach.

Zusammen bedeuten diese vier Eigenschaften, dass das Umhüllen von biz collect als MCP-Tool meist eine Sache davon ist, einen Generator auf die OpenAPI-Spec zu richten oder einen kleinen Handler um den wait:true-Endpunkt zu schreiben. Die Seite wie biz collect funktioniert zeigt den Request-Lebenszyklus, und die Integrationen-Seite listet die Oberflächen, in die es einsteckt.

Ein Beispiel für eine Tool-Definition

Hier ist, wie ein einzelnes Such-Tool aussieht, ausgedrückt als JSON-Schema-Tool-Definition, dieselbe Form, die ein MCP-Server bewerben und eine Agenten-Runtime konsumieren würde. Beachten Sie, wie die Beschreibung sagt, wann das Tool aufzurufen ist, was messbar verbessert, wie zuverlässig ein Agent danach greift:

{
  "name": "search_local_businesses",
  "description": "Search for local businesses in a city or area and return structured records with website, phone, address, and deduped contact emails. Call this whenever the user asks to find, list, or collect businesses in a place by category (for example 'dentists in Austin' or 'roofing contractors near Denver'). Returns verified data, not estimates, so prefer it over answering from memory.",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City, region, postal code, or address to search around."
      },
      "keywords": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Business categories or search phrases, such as 'dentist' or 'roofing contractor'."
      },
      "radius_km": {
        "type": "number",
        "description": "Search radius in kilometers."
      },
      "scrape_emails": {
        "type": "boolean",
        "description": "Whether to extract deduped contact emails from each business website."
      },
      "wait": {
        "type": "boolean",
        "description": "If true, block until results are ready and return them in one response instead of an async job_id."
      }
    },
    "required": ["location", "keywords"]
  }
}

Der Handler hinter diesem Tool ist klein. Er POSTet die Argumente an /api/v1/search mit wait:true und gibt das strukturierte Businesses-Array zurück. Kein Polling, keine State-Machine. Der Agent erhält Datensätze wie diese:

{
  "businesses": [
    {
      "name": "Example Dental Studio",
      "address": "123 Main St, Austin, TX 78701",
      "phone": "+1 512-555-0101",
      "website": "https://exampledentalstudio.com",
      "emails": ["hello@exampledentalstudio.com", "office@exampledentalstudio.com"]
    }
  ]
}

Für eine umfassende Beschreibung der Parameter und Antwortfelder ist die OpenAPI-Referenz in den Docs die Quelle der Wahrheit, und ein generiertes MCP-Tool entspricht ihr Feld für Feld.

Die Agenten-Schleife mit einem Live-Daten-Tool

Mit definiertem Tool ist die Agenten-Schleife unkompliziert. Eine typische Anfrage und die interne Trajektorie des Agenten sehen so aus:

1. User: "Find independent law firms within 15 km of Zurich and collect their emails."
2. Agent plans: location = "Zurich, Switzerland", keywords = ["law firm"],
   radius_km = 15, scrape_emails = true, wait = true.
3. Agent calls search_local_businesses with those arguments.
4. The tool handler POSTs to /api/v1/search?wait=true and returns the businesses array.
5. Agent validates: required fields present, results match the requested category.
6. Agent filters: keep records with an email when email outreach is the goal,
   keep phone-bearing records otherwise.
7. Agent writes approved records to the CRM, a sheet, or a webhook, or summarizes them.

Ein paar Praktiken halten diese Schleife robust:

• Lassen Sie die Runtime das Tool aufrufen; bitten Sie das Modell nicht, sich Ergebnisse zu "merken". Das Tool-Ergebnis gelangt als Daten in den Kontext, über die das Modell räsoniert, nicht als etwas, das es rekonstruieren muss.
• Halten Sie die Tool-Oberfläche eng und explizit. Ein gut beschriebenes Such-Tool schlägt fünf überlappende. Brauchen Sie ein Job-Status-Tool für den Async-Pfad, ergänzen Sie es separat und halten Sie sein Schema knapp.
• Validieren Sie vor dem Handeln. Selbst mit stabilen Feldern: Bestätigen Sie, dass die Datensätze zur nächsten Aktion passen, und deduplizieren Sie gegen Ihre eigenen Systeme über normalisierte Domains, Telefone und Adressen. Der Glossareintrag zu Data Enrichment deckt ab, was Anreicherung garantiert und was nicht.
• Gaten Sie Nebenwirkungen. Daten sammeln und Ansprache senden sind verschiedene Systeme. Verlangen Sie Freigabe vor Erstkontakt, respektieren Sie Sperrlisten und loggen Sie, was der Agent tat. Dies ist keine Rechtsberatung; Compliance mit DSGVO, Schweizer revDSG und geltenden US-Datenschutzgesetzen liegt bei Ihnen.

Für Agenten, die in No-Code-Tools statt einer Code-Runtime laufen, gilt dieselbe Erstellen-und-Lesen-Form als visuelle Schritte. Der n8n Lead Generation Workflow zeigt die Async-Version dieser Schleife als Nodes, das richtige Muster, wenn Sie einen langlaufenden Job statt eines einzelnen synchronen Aufrufs wollen.

Async vs. synchron: Den richtigen Modus wählen

Die Wahl zwischen Async-Job-Modell und wait:true ist die eine Design-Entscheidung, die man für einen Agenten richtig treffen sollte.

• Nutzen Sie wait:true für interaktive Agenten-Anfragen. Wartet ein Nutzer auf eine Antwort und ist die Suche normal gross, ist ein synchroner Aufruf das sauberste Erlebnis: ein Tool, ein Ergebnis, keine Poll-Logik im Prompt. Das ist die Standardempfehlung für ein MCP-artiges Such-Tool.
• Nutzen Sie das Async-Job-Modell für grosse oder Hintergrundarbeit. Ist die Suche breit, laufen Sie viele Suchen im Batch, oder passiert die Arbeit nach Zeitplan ohne wartenden Menschen, ist das job_id-plus-Poll-Muster robuster und lässt den Agenten (oder Ihre Orchestrierung) anderes tun, während der Job läuft. Kombinieren Sie es mit einem zweiten Tool, das den Job-Status prüft, oder mit einem Webhook, sodass der Agent bei Fertigstellung benachrichtigt wird statt zu pollen.

Beide Modi treffen dieselbe Suchmaschine und liefern dieselbe stabile Datensatzform, sodass Sie beide als Tools exponieren und den Agenten (oder Ihr Design) nach der Anfrage wählen lassen können. Der ehrliche Kompromiss ist Latenz gegen Einfachheit: wait:true hält die Verbindung offen, bis Ergebnisse bereit sind, während der Async-Pfad sofort zurückkehrt und das Warten ins Polling verschiebt. Für die meisten Agenten-Konversationen gewinnt der synchrone Pfad bei Entwickler- und Modell-Einfachheit.

Ehrlich über das, was das Tool liefert

Ein Agenten-Tool ist nur vertrauenswürdig, wenn es ehrlich über Abdeckung ist, also gelten dieselben Vorbehalte, die für Website-E-Mail-Extraktion gelten, auch hier.

• E-Mail-Abdeckung ist teilweise. Manche Betriebe veröffentlichen nur ein Kontaktformular, und manche rendern ihre Adresse als Bild. Diese Datensätze kommen mit Website und Telefon, aber ohne E-Mail zurück, was korrekt ist, kein Bug. Bauen Sie die Filterung des Agenten um "Datensätze mit E-Mail, wenn E-Mail nötig ist", statt anzunehmen, jeder Betrieb habe eine.
• Die Daten spiegeln, was öffentlich ist. biz collect liefert verifizierte Kontaktdaten, extrahiert aus Live-Quellen und den eigenen Websites der Betriebe. Es erfindet keine Felder, um Lücken zu füllen, genau die Eigenschaft, die es sicher macht, es einem Modell zu geben.
• Andere Fähigkeiten werden fair beschrieben. Viele Tools lassen sich für Agenten umhüllen; was ein Firmendaten-Tool leicht macht, ist die Kombination aus präziser OpenAPI-Spec, stabiler JSON-Form, synchronem Modus und llms.txt. Jede API mit diesen Eigenschaften ist angenehm zu umhüllen; biz collect liefert einfach alle vier.

Diese Ehrlichkeit lässt einen Agenten auf die Ergebnisse handeln, ohne dass ein Mensch jeden Datensatz nachprüft, was der ganze Sinn davon ist, einem Agenten ein echtes Daten-Tool zu geben.

Loslegen

Einem KI-Agenten Live-Firmendaten zu geben, verlangt keine massgeschneiderte Integration. Es verlangt ein Tool mit klarem Namen, einer Beschreibung, die sagt, wann es aufzurufen ist, und einem Schema, das einer echten API entspricht, plus ein Backend, das stabile, verifizierte Datensätze liefert. biz collect liefert das Backend: eine OpenAPI-3.1-Spec, aus der Sie Tools generieren, eine llms.txt, die Agenten schnell orientiert, eine stabile JSON-Antwort und einen wait:true-Modus, der den ganzen Such-und-Anreicherungs-Lebenszyklus in einen synchronen Tool-Aufruf verwandelt.

Definieren Sie ein search_local_businesses-Tool, richten Sie es auf den wait:true-Endpunkt, und Ihr Agent kann eine Stadt und eine Kategorie in einem Roundtrip in angereicherte, deduplizierte lokale Business-Leads verwandeln. Es ist gratis zu starten mit 200 Startguthaben und ohne Kreditkarte, genug, um das Tool zu bauen, es in Ihre Runtime zu verdrahten und einen Agenten es durchgehend aufrufen zu sehen.

Öffnen Sie die API-Docs für die OpenAPI-Spec, prüfen Sie die Integrationen, sehen Sie sich die Preise an und geben Sie Ihrem Agenten noch heute ein Live-Firmendaten-Tool.