DataGrout

official

DataGrout - Discovery, governance, and orchestration layer for AI agents working across multiple MCP servers and integrations.

What can you do with DataGrout MCP?

  • Provision a DataGrout server and mTLS identity automatically — call bootstrap_onramp to register an agent, get OAuth credentials, and generate a signed certificate in one step.
  • Authenticate with mTLS, OAuth 2.1, or bearer tokens — configure the client with certificate-based identity, auto-refreshing JWTs, or a simple token for testing.
  • Discover and invoke tools using natural language — use the Intelligent Interface (discover/perform) to let an agent find and call tools by describing a goal instead of specifying exact tool names.
  • Track credit usage on every call — inspect the cost receipt returned with each response to monitor spending against policy or budget limits.
  • Walk through multi-step goals interactively — call client.guide(goal=...) to step through a guided workflow with the server.
  • Switch between Streamable HTTP, JSON-RPC, or WebSocket transports — select mcp, jsonrpc, or websocket transport without changing authentication setup.

Documentation

Most MCP clients handle one job: send a request, get a response. Conduit is built for a slightly different problem — an agent that needs to prove who it is, keep working across long sessions without re-authenticating by hand, and stay inside a cost or policy budget while it does it. That's the gap this SDK fills.

MCP client library with built-in mTLS, OAuth 2.1, and semantic tool discovery. Available for Python, TypeScript, Rust, Elixir, and Ruby.

Swap a single import and an existing agent picks up certificate-based identity, cost visibility, and natural-language tool discovery — no other code changes required.

Do you need the SDK, or just the raw endpoint?

Every DataGrout server exposes a standard MCP endpoint — any MCP-compatible client can connect to it directly with just a URL and a bearer token, no SDK required. Conduit is for cases where you want more than the bare minimum:

  • You want certificate-based (mTLS) identity instead of managing a token yourself

  • You want cost tracking on every call without building it separately

  • You want semantic discovery so an agent can find the right tool by describing a goal, rather than needing the exact tool name

  • You're integrating in Rust, Elixir, or Ruby, where hand-rolling MCP transport logic is more work than in Python/TypeScript

If none of that applies — say, you're just wiring up Claude Desktop to a DataGrout server — the plain mcpServers JSON config is simpler and sufficient. Conduit is for building your own agent or application on top of DataGrout, not for basic client configuration.

Language support

LanguagePackageInstall
Pythondatagrout-conduitpip install datagrout-conduit==0.7.0
TypeScript@datagrout/conduitnpm install @datagrout/conduit@0.7.0
Rustdatagrout-conduitcargo add datagrout-conduit@0.7.0
Elixirdatagrout_conduit{:datagrout_conduit, "~> 0.7.0"}
Rubydatagrout-conduitgem install datagrout-conduit -v 0.7.0

Getting a server without signing up first

Don't have a DataGrout account or endpoint yet? The SDK can provision both for you directly (Python shown; the same call exists in each language's SDK — see the per-language docs linked below for the exact 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()

Behind that single call: the SDK registers your agent, exchanges a short-lived token for OAuth credentials and a server URL, generates a local key pair, and gets it signed by DataGrout's CA. The private key stays on your machine. Every run after the first reuses the saved identity automatically.

Prefer the terminal to writing code: invariant onboard.

Authentication

Three methods, identical across all five SDKs:

  • Bearer token — simplest option, good for quick testing.

  • OAuth 2.1 (client credentials) — the SDK fetches, caches, and refreshes JWTs automatically.

  • mTLS — after a one-time bootstrap, the certificate itself authenticates every request; no tokens to manage afterward.

For mTLS, identity is auto-discovered in a fixed search order: an explicit override directory, CONDUIT_MTLS_CERT/CONDUIT_MTLS_KEY env vars, CONDUIT_IDENTITY_DIR, the default ~/.conduit/, then a local .conduit/ relative to the working directory. Running multiple agents on one machine means giving each its own identity directory.

Why a dedicated CA: machine identity has different requirements than browser identity — agents need certificates issued and rotated programmatically, without a human in the loop each time. The signing key lives in an HSM-backed AWS KMS key (FIPS 140-2 Level 2) and never leaves it. The CA certificate is public at ca.datagrout.ai/ca.pem for independent chain verification.

Transport options

TransportProtocolUse when
mcp (default)MCP over Streamable HTTP/SSEYou want full protocol support, streaming, notifications
jsonrpcJSON-RPC 2.0 over HTTP POSTYou want something simpler and stateless
websocketJSON-RPC 2.0 over WebSocketYou need the server to push events, not just respond

Auth works identically across all three — switching transport doesn't mean switching how you authenticate.

Key features

  • Intelligent Interface (on by default) — collapses the entire tool surface into two calls, discover and perform. The agent describes a goal in plain language instead of reasoning over hundreds of tool schemas. Disable with use_intelligent_interface=False to see raw tools.

  • Semantic discovery — available standalone too, for searching tools by meaning rather than exact name.

  • Cost visibility — every call returns a receipt with credit usage.

  • Guided workflows — client.guide(goal=...) walks through a multi-step goal interactively.

  • Cognitive Trust Certificates — cryptographic proof a workflow is cycle-free, type-safe, policy-compliant, and within budget, signed by the same CA as agent identities.

First-party namespaces

NamespaceWhat it's for
prismData transformation, charting, rendering, export
logicPersistent agent memory via a Prolog logic layer
wardenSafety checks, intent verification, multi-model consensus
deliverablesRegistering and retrieving finished work product
ephemeralsInspecting and managing cached results
flowWorkflow orchestration — routing, human approval, execution history

Flows can be saved as named, reusable skills (save_as_skill=True) or embedded inline as one-off steps via $compute. flow.route handles conditional branching; flow.request_approval/flow.request_feedback insert human checkpoints. Anything not covered by a namespace is reachable via a generic dg() call.

Where this connects to DataGrout's integrations

Conduit is the layer between your agent and any DataGrout server — including the Salesforce, QuickBooks, and Oracle Fusion Cloud integrations. A call_tool("salesforce@1/get_lead@1", ...) call works the same way regardless of which integrations that server has configured; the SDK doesn't need to know about a specific integration in advance.

Where to go next

  • Per-language docs: Python, TypeScript, Rust, Elixir, Ruby READMEs (GitHub)

  • Security details: app.datagrout.ai/security

  • Free, no-account tools: MCP Inspector and JSON-RPC Inspector, browser-based

  • Labs: research write-ups on trust certificates, semantic code analysis, policy enforcement, the credit model, and more

License

MIT