Expose Trinity as a Claude remote MCP connector (OAuth 2.1 + Connectors Directory)

[vybe]

Summary

Make a Trinity deployment connectable to Claude as a remote MCP connector — the same model Descript uses (Claude → Customize → Connectors → add → OAuth consent), instead of a pasted trinity_mcp_* API key. Trinity already ships the right server shape (src/mcp-server/: FastMCP, Streamable HTTP, ~62 tools), so the work is adding an OAuth 2.1 authorization layer + public HTTPS discovery metadata in front of it — not building anything new.

Full technical research (current as of 2026-06-14, against MCP spec rev 2025-11-25, API beta mcp-client-2025-11-20, and the consolidated Anthropic Software Directory Policy): docs/planning/CLAUDE_CONNECTORS_DIRECTORY_INTEGRATION.md.

Context

Anthropic's Connectors Directory is an in-product marketplace of remote MCP servers. The static-bearer-token auth Trinity uses today is explicitly prohibited for connectors; tokens-in-query-params likewise. The single blocker between Trinity and "the Descript way" is OAuth 2.1 + spec discovery.

Trinity is sovereign/per-deployment, so two paths exist:

• Path A — Custom connector ("connect to your own Trinity"): no Anthropic review; each instance is its own resource server + AS; user pastes their instance URL. Recommended first — this is the real engineering and unlocks both paths.
• Path B — Directory listing: only makes sense for a hosted/multi-tenant Trinity (one global endpoint). Strictly additive on top of Path A; requires the submission package + review + Team/Enterprise org.

Acceptance Criteria

• Decision recorded (see open questions in the planning doc): hosted-listing vs custom-connector-only; AS build-vs-buy; registration approach (CIMD vs DCR vs Anthropic-held).
• MCP server implements Protected Resource Metadata (RFC 9728) at /.well-known/oauth-protected-resource[/mcp] and returns 401 + WWW-Authenticate: Bearer resource_metadata=... on unauthenticated requests.
• An OAuth 2.1 authorization server is available with PKCE/S256 advertised (code_challenge_methods_supported), AS metadata via RFC 8414 (or OIDC discovery), HTTPS-only endpoints, exact-match redirect URIs (incl. https://claude.ai/api/mcp/auth_callback and loopback for Claude Code), form-urlencoded token endpoint, short-lived access tokens, refresh-token rotation.
• MCP server validates token audience (RFC 8707) = canonical server URI; rejects foreign tokens; no token passthrough to upstream APIs; 403 + insufficient_scope on scope gaps.
• OAuth identity resolves to the correct Trinity McpAuthContext (user/agent/system scope); existing trinity_mcp_* keys keep working in parallel.
• Canonical MCP URL exposed over public HTTPS (reuse Cloudflare Tunnel); reachable from Anthropic egress 160.79.104.0/21; meets 10s/30s endpoint latency budgets.
• All ~62 tools in src/mcp-server/src/tools/*.ts carry title + readOnlyHint/destructiveHint, names ≤64 chars, descriptions matching behavior (annotation gaps are ~30% of directory rejections).
• "Add your Trinity instance to Claude" user doc + privacy policy page.
• (Path B only) Submission package assembled (listing copy, icon, test account, 3 prompt examples, 7 compliance acknowledgments) and submitted via the portal/form.

Technical Notes

• Keep three surfaces in sync (Invariant feat: SMARTS trading pipeline with Telegram notifications and Miro visualization #13: backend router / agent server / MCP tool).
• AS build-vs-buy is the cost center: Trinity already issues JWTs + email-OTP (src/backend/routers/auth.py), but PKCE + CIMD/DCR + refresh rotation + PRM are non-trivial — decide before implementing.
• Registration: CIMD recommended (no per-connection client records; mind SSRF + localhost-impersonation notes); DCR is a simpler MVP; Anthropic-held creds suit a Directory listing.
• Policy review: exclude/gate prohibited-category tools (image generation, payment-adjacent nevermined/paid) from any listed toolset; connectors must not query Claude memory/chat history/files.
• Messages-API MCP-client usage (mcp_servers + mcp_toolset) is a separate, orthogonal capability (and not ZDR-eligible) — noted in the doc, out of scope here.
• Full requirement breakdown + official source links: docs/planning/CLAUDE_CONNECTORS_DIRECTORY_INTEGRATION.md.