DataGrout

官方

DataGrout - 面向跨多个MCP服务器和集成工作的AI代理的发现、治理与编排层。

GitHub试用此 MCP赞助

你可以用 DataGrout MCP 做什么？

  • 自动配置 DataGrout 服务器和 mTLS 身份 — 调用 bootstrap_onramp 一步完成代理注册、获取 OAuth 凭据并生成签名证书。
  • 使用 mTLS、OAuth 2.1 或 bearer 令牌进行身份验证 — 使用基于证书的身份、自动刷新的 JWT 或简单令牌进行测试来配置客户端。
  • 使用自然语言发现并调用工具 — 使用智能接口（discover/perform）让代理通过描述目标来查找和调用工具，而无需指定确切的工具名称。
  • 跟踪每次调用的信用使用情况 — 检查每次响应附带的成本回执，以监控支出是否符合策略或预算限制。
  • 以交互方式完成多步骤目标 — 调用 client.guide(goal=...) 与服务器一起逐步完成引导式工作流。
  • 在 Streamable HTTP、JSON-RPC 或 WebSocket 传输之间切换 — 选择 mcp、jsonrpc 或 websocket 传输，无需更改身份验证设置。

文档

大多数 MCP 客户端只处理一件事：发送请求，获取响应。Conduit 则是为略有不同的问题而构建——一个需要证明自身身份、在长时间会话中无需手动重新认证即可持续工作，并在此过程中保持在成本或策略预算之内的代理。这正是此 SDK 所填补的空白。

内置 mTLS、OAuth 2.1 和语义工具发现的 MCP 客户端库。支持 Python、TypeScript、Rust、Elixir 和 Ruby。

只需替换一个 import，现有代理即可获得基于证书的身份、成本可见性和自然语言工具发现——无需其他代码更改。

你需要 SDK，还是只需要原始端点？

每个 DataGrout 服务器都暴露一个标准 MCP 端点——任何兼容 MCP 的客户端都可以仅凭 URL 和 bearer 令牌直接连接，无需 SDK。Conduit 适用于你希望获得超出最低限度能力的场景：

  • 你希望使用基于证书的（mTLS）身份，而不是自行管理令牌

  • 你希望每次调用都有成本跟踪，而无需单独构建

  • 你希望进行语义发现，让代理通过描述目标来找到正确的工具，而无需知道确切的工具名称

  • 你在 Rust、Elixir 或 Ruby 中进行集成，在这些语言中手工编写 MCP 传输逻辑比在 Python/TypeScript 中更费力

如果以上都不适用——比如你只是将 Claude Desktop 连接到 DataGrout 服务器——那么普通的 mcpServers JSON 配置更简单且足够。Conduit 用于在 DataGrout 之上构建你自己的代理或应用程序，而非用于基本客户端配置。

语言支持

语言包安装
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

无需先注册即可获取服务器

还没有 DataGrout 账号或端点？SDK 可以直接为你同时配置这两者（以 Python 为例；每种语言的 SDK 中都有相同的调用——具体语法请参阅下方链接的各语言文档）：

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()

这一行调用的背后：SDK 会注册你的代理，将短期令牌兑换为 OAuth 凭据和服务器 URL，生成本地密钥对，并由 DataGrout 的 CA 为其签名。私钥始终保留在你的机器上。首次运行之后的每次运行都会自动复用已保存的身份。

更喜欢用终端而不是写代码：invariant onboard。

认证

三种方法，在全部五种 SDK 中完全一致：

  • Bearer 令牌——最简单的选项，适合快速测试。

  • OAuth 2.1（客户端凭据）——SDK 自动获取、缓存并刷新 JWT。

  • mTLS——一次性引导之后，证书本身即可认证每个请求；之后无需管理任何令牌。

对于 mTLS，身份按固定搜索顺序自动发现：显式覆盖目录、CONDUIT_MTLS_CERT/CONDUIT_MTLS_KEY 环境变量、CONDUIT_IDENTITY_DIR、默认的 ~/.conduit/，然后是相对于工作目录的本地 .conduit/。在一台机器上运行多个代理时，需要为每个代理分配各自的身份目录。

为什么需要专用 CA： 机器身份与浏览器身份的要求不同——代理需要以编程方式签发和轮换证书，无需每次都有人工介入。签名密钥存放在基于 HSM 的 AWS KMS 密钥（FIPS 140-2 Level 2）中，且永远不会离开该密钥。CA 证书公开于 ca.datagrout.ai/ca.pem，可进行独立的证书链验证。

传输选项

传输方式协议适用场景
mcp（默认）基于 Streamable HTTP/SSE 的 MCP需要完整的协议支持、流式传输和通知
jsonrpc基于 HTTP POST 的 JSON-RPC 2.0需要更简单、无状态的方案
websocket基于 WebSocket 的 JSON-RPC 2.0需要服务器推送事件，而不仅仅是响应

三种传输方式的认证机制完全相同——切换传输方式并不意味着改变认证方式。

主要特性

  • 智能接口（默认开启）——将整个工具面收敛为两个调用：discover 和 perform。代理用自然语言描述目标，而无需在数百个工具模式中推理。使用 use_intelligent_interface=False 可禁用，以查看原始工具。

  • 语义发现——也可独立使用，用于按语义而非精确名称搜索工具。

  • 成本可见性——每次调用都会返回包含信用额度使用情况的收据。

  • 引导式工作流——client.guide(goal=...) 以交互方式逐步完成多步骤目标。

  • 认知信任证书——以密码学方式证明工作流无循环、类型安全、符合策略且在预算之内，由与代理身份相同的 CA 签名。

第一方命名空间

命名空间用途
prism数据转换、图表、渲染、导出
logic通过 Prolog 逻辑层实现代理持久记忆
warden安全检查、意图验证、多模型共识
deliverables注册和检索已完成的工作成果
ephemerals检查和管理缓存结果
flow工作流编排——路由、人工审批、执行历史

流程可以保存为具名的可复用技能（save_as_skill=True），也可以通过 $compute 以内联方式嵌入为一次性步骤。flow.route 处理条件分支；flow.request_approval/flow.request_feedback 插入人工检查点。任何未被命名空间覆盖的功能都可以通过通用的 dg() 调用访问。

这与 DataGrout 的集成如何衔接

Conduit 是连接你的代理与任何 DataGrout 服务器之间的层——包括 Salesforce、QuickBooks 和 Oracle Fusion Cloud 集成。无论服务器配置了哪些集成，call_tool("salesforce@1/get_lead@1", ...) 调用的工作方式都相同；SDK 无需预先了解特定集成。

后续方向

  • 各语言文档：Python、TypeScript、Rust、Elixir、Ruby README（GitHub）

  • 安全详情：app.datagrout.ai/security

  • 免费、无需账号的工具：MCP Inspector 和 JSON-RPC Inspector，基于浏览器

  • 实验室：关于信任证书、语义代码分析、策略执行、信用模型等的研究文章

许可证

MIT