car-connectors 0.25.0

Remote MCP connectors for the Common Agent Runtime — connect to remote MCP servers over HTTP, register their tools, and route calls through CAR's governance layer (validator, policy, eventlog).
docs.rs failed to build car-connectors-0.25.0
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

car-connectors

Remote MCP connectors for the Common Agent Runtime — CAR as an MCP client. Lets users add remote MCP servers as tool sources, the way Claude and ChatGPT add connectors. This is the mirror of car-mcp, which is the server direction (exposing CAR's own tools to other MCP clients).

What it does

  1. Connects to a remote MCP server over the HTTP-streamable transport ([McpHttpSession], which implements car_engine::McpSession).
  2. Performs the initialize handshake, captures the Mcp-Session-Id, and discovers tools via tools/list.
  3. Translates each MCP tool's JSON Schema into a car_ir::ToolSchema (verbatim — ToolSchema.parameters already holds raw JSON Schema) and registers it as a ToolEntry with ToolSource::Mcp { server_name }.
  4. Routes tools/call back to the owning server through the engine's existing car_engine::McpToolExecutor, so connector tools share the stdio MCP path's routing + fallback.

Because connector tools register as ordinary ToolEntrys and dispatch through the standard executor, every call flows through CAR's validator, policy, and eventlog — the differentiator over calling connector tools directly.

Enablement gating

A freshly discovered tool is not routable and not registered until the user enables it. This is structural: a disabled tool has no route in the executor and no entry in any runtime registry, so it is invisible to the model and impossible to dispatch — no reliance on a permission flag.

Persistence & secrets

  • Connector configuration (slug, name, URL, enabled tools, auth-header names) persists to ~/.car/connectors.json.
  • Secret auth-header values are stored in the OS keychain via car-secrets, under connector:<slug>:<header> — never in the JSON.

Scope

  • Phase 1 — unauthenticated and static-auth-header servers over the HTTP-streamable transport.
  • Phase 2 — OAuth 2.1: Protected Resource Metadata (RFC 9728) + Authorization Server Metadata (RFC 8414) discovery, Dynamic Client Registration (RFC 7591), authorization-code + PKCE with an RFC 8707 resource indicator, and token refresh. Tokens + any client secret are kept in the OS keychain; access tokens auto-refresh on use.
  • Phase 3 — per-tool enable/disable, plus a deny_connector policy rule in the daemon (denies every mcp_{slug}_* tool).
  • Phase 4 — local stdio connectors (reusing car_engine::McpServer) and team-shareable, secret-free .car/connectors.toml project config seeded at boot.

Connector management is GUI-driven (CarHost via the connectors.* WS methods) — there is no CLI surface. Deferred items (trust levels, tools/list_changed push, FFI proxies) are tracked in docs/proposals/remote-mcp-connectors.md.

Daemon surface

The car-server daemon exposes connector lifecycle over WebSocket JSON-RPC under the connectors.* namespace (connectors.add, connectors.list, connectors.tools, connectors.enable_tools, connectors.refresh, connectors.remove). There is no FFI surface in Phase 1 — connector management is daemon-shared and interactive. See docs/websocket-protocol.md.