DataGrout

Die meisten MCP-Clients übernehmen eine einzige Aufgabe: eine Anfrage senden, eine Antwort erhalten. Conduit ist für ein etwas anderes Problem gebaut – einen Agenten, der beweisen muss, wer er ist, über lange Sitzungen hinweg ohne manuelle Re-Authentifizierung weiterarbeiten muss und dabei innerhalb eines Kosten- oder Richtlinienbudgets bleiben soll. Das ist die Lücke, die dieses SDK füllt.

MCP-Client-Bibliothek mit integriertem mTLS, OAuth 2.1 und semantischer Tool-Erkennung. Verfügbar für Python, TypeScript, Rust, Elixir und Ruby.

Ein einziger Import-Austausch genügt, und ein bestehender Agent übernimmt zertifikatsbasierte Identität, Kostentransparenz und natürlichsprachliche Tool-Erkennung – keine weiteren Codeänderungen erforderlich.

Brauchen Sie das SDK oder nur den rohen Endpunkt?

Jeder DataGrout-Server stellt einen standardmäßigen MCP-Endpunkt bereit – jeder MCP-kompatible Client kann sich direkt mit nur einer URL und einem Bearer-Token verbinden, ohne SDK. Conduit ist für Fälle gedacht, in denen Sie mehr als das Minimum wollen:

• Sie möchten zertifikatsbasierte (mTLS) Identität, anstatt selbst ein Token zu verwalten

• Sie möchten Kostentracking bei jedem Aufruf, ohne es separat zu bauen

• Sie möchten semantische Erkennung, damit ein Agent das richtige Tool durch Beschreibung eines Ziels finden kann, statt den genauen Tool-Namen zu benötigen

• Sie integrieren in Rust, Elixir oder Ruby, wo das manuelle Erstellen von MCP-Transportlogik mehr Arbeit ist als in Python/TypeScript

Wenn nichts davon zutrifft – etwa, wenn Sie nur Claude Desktop mit einem DataGrout-Server verbinden – ist die einfache mcpServers-JSON-Konfiguration ausreichend und einfacher. Conduit ist für den Bau Ihres eigenen Agenten oder Ihrer Anwendung auf DataGrout, nicht für die grundlegende Client-Konfiguration.

Sprachunterstützung

Sprache	Paket	Installation
Python	datagrout-conduit	pip install datagrout-conduit==0.7.0
TypeScript	@datagrout/conduit	npm install @datagrout/conduit@0.7.0
Rust	datagrout-conduit	cargo add datagrout-conduit@0.7.0
Elixir	datagrout_conduit	{:datagrout_conduit, "~> 0.7.0"}
Ruby	datagrout-conduit	gem install datagrout-conduit -v 0.7.0

Einen Server erhalten, ohne sich vorher anzumelden

Sie haben noch kein DataGrout-Konto oder keinen Endpunkt? Das SDK kann beides direkt für Sie bereitstellen (Python gezeigt; derselbe Aufruf existiert in jedem Sprach-SDK – siehe die unten verlinkten sprachspezifischen Dokumentationen für die genaue Syntax):

from datagrout.conduit import ClientBuilder
from datagrout.conduit.onramp import OnrampOptions

client = await ClientBuilder().bootstrap_onramp(OnrampOptions(
    gateway="https://app.datagrout.ai",
    agent_name="my-agent",
    agent_type="claude-sonnet-4-6",
    intended_use="Summarise documents and extract entities.",
))
await client.connect()

Hinter diesem einzigen Aufruf: Das SDK registriert Ihren Agenten, tauscht ein kurzlebiges Token gegen OAuth-Anmeldedaten und eine Server-URL, generiert ein lokales Schlüsselpaar und lässt es von der DataGrout-CA signieren. Der private Schlüssel bleibt auf Ihrer Maschine. Jeder Lauf nach dem ersten verwendet die gespeicherte Identität automatisch wieder.

Bevorzugen Sie das Terminal gegenüber dem Schreiben von Code: invariant onboard.

Authentifizierung

Drei Methoden, identisch in allen fünf SDKs:

• Bearer-Token – einfachste Option, gut für schnelle Tests.

• OAuth 2.1 (Client-Anmeldedaten) – das SDK holt, cached und aktualisiert JWTs automatisch.

• mTLS – nach einem einmaligen Bootstrap authentifiziert das Zertifikat selbst jede Anfrage; keine Tokens mehr zu verwalten.

Für mTLS wird die Identität in einer festen Suchreihenfolge automatisch erkannt: ein explizites Überschreibungsverzeichnis, CONDUIT_MTLS_CERT/CONDUIT_MTLS_KEY-Umgebungsvariablen, CONDUIT_IDENTITY_DIR, das Standardverzeichnis ~/.conduit/, dann ein lokales .conduit/ relativ zum Arbeitsverzeichnis. Wenn Sie mehrere Agenten auf einer Maschine ausführen, geben Sie jedem ein eigenes Identitätsverzeichnis.

Warum eine dedizierte CA: Maschinenidentität hat andere Anforderungen als Browseridentität – Agenten benötigen Zertifikate, die programmatisch ausgestellt und rotiert werden, ohne jedes Mal einen Menschen in den Prozess einzubeziehen. Der Signaturschlüssel liegt in einem HSM-gestützten AWS-KMS-Schlüssel (FIPS 140-2 Level 2) und verlässt ihn nie. Das CA-Zertifikat ist öffentlich unter ca.datagrout.ai/ca.pem für unabhängige Kettenverifizierung.

Transportoptionen

Transport	Protokoll	Verwendung, wenn
mcp (Standard)	MCP über Streamable HTTP/SSE	Sie volle Protokollunterstützung, Streaming, Benachrichtigungen möchten
jsonrpc	JSON-RPC 2.0 über HTTP POST	Sie etwas Einfacheres und Zustandsloses möchten
websocket	JSON-RPC 2.0 über WebSocket	Sie möchten, dass der Server Ereignisse pusht, nicht nur antwortet

Die Authentifizierung funktioniert bei allen drei identisch – den Transport zu wechseln bedeutet nicht, die Authentifizierungsmethode zu wechseln.

Hauptfunktionen

• Intelligente Schnittstelle (standardmäßig aktiviert) – reduziert die gesamte Tool-Oberfläche auf zwei Aufrufe: discover und perform. Der Agent beschreibt ein Ziel in natürlicher Sprache, statt über Hunderte von Tool-Schemas zu argumentieren. Deaktivieren Sie mit use_intelligent_interface=False, um rohe Tools zu sehen.

• Semantische Erkennung – auch eigenständig verfügbar, zum Suchen von Tools nach Bedeutung statt nach exaktem Namen.

• Kostentransparenz – jeder Aufruf gibt eine Quittung mit Guthabenverbrauch zurück.

• Geführte Workflows – client.guide(goal=...) führt interaktiv durch ein mehrstufiges Ziel.

• Cognitive Trust Certificates – kryptografischer Beweis, dass ein Workflow zyklenfrei, typsicher, richtlinienkonform und innerhalb des Budgets ist, signiert von derselben CA wie Agentenidentitäten.

First-Party-Namespaces

Namespace	Wofür es ist
prism	Datenumwandlung, Diagrammerstellung, Rendering, Export
logic	Persistenter Agentenspeicher über eine Prolog-Logikschicht
warden	Sicherheitsprüfungen, Absichtsverifizierung, Multi-Modell-Konsens
deliverables	Registrieren und Abrufen fertiger Arbeitsprodukte
ephemerals	Inspizieren und Verwalten gecachter Ergebnisse
flow	Workflow-Orchestrierung – Routing, menschliche Genehmigung, Ausführungsverlauf

Flows können als benannte, wiederverwendbare Fähigkeiten gespeichert (save_as_skill=True) oder inline als einmalige Schritte über $compute eingebettet werden. flow.route übernimmt bedingte Verzweigungen; flow.request_approval/flow.request_feedback fügen menschliche Prüfpunkte ein. Alles, was nicht von einem Namespace abgedeckt ist, ist über einen generischen dg()-Aufruf erreichbar.

Wo dies mit DataGrout-Integrationen verbunden ist

Conduit ist die Schicht zwischen Ihrem Agenten und jedem DataGrout-Server – einschließlich der Salesforce-, QuickBooks- und Oracle-Fusion-Cloud-Integrationen. Ein call_tool("salesforce@1/get_lead@1", ...)-Aufruf funktioniert unabhängig davon, welche Integrationen dieser Server konfiguriert hat; das SDK muss keine spezifische Integration im Voraus kennen.

Wo es weitergeht

• Sprachspezifische Dokumentationen: Python-, TypeScript-, Rust-, Elixir-, Ruby-READMEs (GitHub)

• Sicherheitsdetails: app.datagrout.ai/security

• Kostenlose Tools ohne Konto: MCP Inspector und JSON-RPC Inspector, browserbasiert

• Labs: Forschungsberichte zu Vertrauenszertifikaten, semantischer Codeanalyse, Richtliniendurchsetzung, dem Guthabenmodell und mehr

Lizenz

MIT