Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Provider Compatibility

Provider compatibility is a test and configuration layer around MCP. It does not add provider SDKs to broker, risk, auth, audit, backend, or MCP core crates, and it does not change broker execution semantics.

Supported targets:

  • generic MCP inspector over stdio
  • Cursor MCP client over stdio
  • Continue MCP client over stdio
  • OpenAI remote MCP over HTTP with OAuth bearer auth
  • Anthropic MCP connector over HTTP with OAuth bearer auth

Local clients use the same stdio command shape:

ibkr-agent mcp serve --transport stdio --describe --json
ibkr-agent mcp serve --transport stdio

Use --describe only for smoke checks. Real local clients should omit it so the command stays attached to stdio. Local discovery is filtered by enabled scopes, and every tool call is audited.

Example client configuration files are available under examples/mcp-clients/:

  • generic-inspector.json
  • cursor.json
  • continue.json

These examples reference IBKR_CONFIG only. They must not embed IBKR credentials, Client Portal Gateway cookies, OAuth tokens, refresh tokens, broker session ids, or local absolute paths.

Remote provider connectors should use the remote MCP HTTP endpoint documented in docs/remote-mcp-oauth.md. The provider receives the gateway protected resource metadata and sends an OAuth bearer token for the MCP request. The gateway validates issuer, audience, expiry, signature, and tool scope before any broker access. MCP bearer tokens are never forwarded to IBKR and are never written to audit payloads.

Provider-specific behavior belongs in src/internal/provider_compat/ tests or examples. Core implementation stays provider-neutral; compatibility is proven through:

  • schema snapshots generated from the broker MCP tool registry
  • auth denial snapshots for missing token and missing scope
  • redaction snapshots for provider-visible outputs and example configs
  • dependency checks that forbid provider SDK dependencies in production crates

The provider compatibility harness exercises representative tool discovery, schema, redaction, auth denial, and provider-visible output behavior. Order preview, paper order, and live trading provider flows remain governed by their own policy, approval, scope, idempotency, risk, kill-switch, and audit gates.