Zum Hauptinhalt springen
Der querying.ai MCP-Server stellt die API als Tools des Model Context Protocol bereit. Er nutzt dieselben Engines, dieselbe Warteschlange, dieselben Ergebnisformen und dieselben API-Schlüssel wie die REST-API und speichert weder Ihren Schlüssel noch Ihre Tasks.

​
Einen Client verbinden

Legen Sie Ihren Schlüssel zuerst in der Umgebungsvariablen QUERYING_API_KEY ab. Einen Schlüssel erhalten Sie unter API-Schlüssel.
Behalten Sie die einfachen Anführungszeichen bei. Mit doppelten Anführungszeichen setzt Ihre Shell den Schlüssel einmalig ein, und Claude Code speichert den Wert in seiner Konfigurationsdatei.
Jeder andere Streamable-HTTP-Client funktioniert, wenn er bei jeder Anfrage diese Header sendet:
Eine Anfrage ohne Bearer-Header liefert 401. Ein ungültiger Schlüssel wird beim ersten Tool-Aufruf als Tool-Fehler gemeldet.

​
Tools

Tools, die Tasks einreichen, kosten so viel wie der entsprechende API-Aufruf. Lesende Tools sind kostenlos.

​
Tasks und Recherche

run_prompt und submit_prompt nehmen taskType, prompt sowie optional country, idempotencyKey, include und page (1 bis 10, für GOOGLE_SERP und NAVER_SERP). Engines und Preise finden Sie unter Engines, die Recherche-Eingaben unter Prompt Research. Für COMMERCE_SERP senden Sie site und query statt prompt, optional mit limit (1 bis 40); siehe Commerce Search. read_product nimmt url sowie optional country und idempotencyKey; siehe Commerce Product. run_product_lookup nimmt product, country sowie optional competitors, prompts, engines und idempotencyKey; siehe Product Lookup. Es liefert eine Zusammenfassung: pro Produkt die Engines, die es zeigen, seine Preisspanne, die 10 wichtigsten Händler und zitierten Websites und eine Zeile pro Engine; pro Shopping-Prompt die Produkte, die jede Engine gezeigt oder genannt hat. Das ist etwa ein Zehntel der vollständigen Antwort. Übergib detail: "full" für jedes Listing, jede zitierte Seite und jede Task-id.

​
GEO-Monitore

Jedes Monitor-Tool führt einen API-Aufruf mit Ihrem Schlüssel aus; Eigentümerschaft, Schlüsselbereich und Tariflimits gelten also wie bei REST. Siehe GEO-Monitoring.

​
Timeouts

run_prompt, scrape_page, read_product und research_prompts pollen, bis der Task fertig ist. Sie warten timeoutSeconds (Standard 180, maximal 900). Läuft der Task danach noch, liefert das Tool einen TASK_TIMEOUT-Fehler mit der taskId. Der Task läuft weiter; rufen Sie get_task mit dieser id auf, um ihn abzuholen. run_product_lookup pollt die Abfrage auf dieselbe Weise. Es wartet standardmäßig 210 Sekunden, damit der Aufruf innerhalb eines Client-Timeouts von 240 Sekunden endet, und die meisten Abfragen sind in 2 bis 3 Minuten fertig. Läuft die Abfrage danach noch, liefert das Tool einen LOOKUP_TIMEOUT-Fehler mit der lookupId; rufe damit get_product_lookup auf. Stellen Sie den Tool-Timeout Ihres Clients länger als timeoutSeconds ein. Das Codex-Beispiel verwendet tool_timeout_sec = 240 für den Standard von 180 Sekunden. Erlaubt Ihr Client nur kurze Tool-Aufrufe, verwenden Sie submit_prompt und danach get_task.

​
Fehler

Tool-Fehler kommen als JSON im Tool-Ergebnis zurück:

​
Abrechnung

Jeder Tool-Aufruf wird dem Konto berechnet, dem der Schlüssel gehört, zu denselben Preisen wie die REST-API. Schlüsseleinstellungen gelten: Ein Engine-Bereich oder ein tägliches Credit-Limit am Schlüssel begrenzt, was der Agent ausgeben kann. Geben Sie einem Agenten einen eigenen, eingeschränkten Schlüssel mit Tageslimit.