What & why

Registers two new OAuth-authenticated external MCP servers so Cedar's agent can call their tools:

• Pylon , https://mcp.usepylon.com/
• Mintlify , https://mcp.mintlify.com

Both authenticate exactly like the existing Notion MCP driver: Dynamic Client Registration (DCR) + PKCE, public client, no pre-registered secret. Verified from each vendor's /.well-known/oauth-authorization-server.

Approach

• Extract a driver factory. createDcrPkceMcpDriver(config) captures the full DCR → PKCE(S256) → code-exchange → refresh-grant pattern. notion.ts refactors onto it (142→13 lines); pylon.ts / mintlify.ts are ~10-line configs with endpoints + scopes.
• Unify the provider-id allowlist. The ['mcp','notion'] literal was hardcoded in 6 places that decide which connections the agent can use , a missed site silently makes a connection dead. All now reference MCP_PROVIDER_IDS, so future providers are one line in constants.ts.
• Generalize the frontend card. The bespoke 146-line Notion card becomes a config-driven OAuthMcpIntegrationCard + cluster, rendered in settings / playground / onboarding.
• Env vars PYLON_REDIRECT_URI / MINTLIFY_REDIRECT_URI; proper display names; fixed the hardcoded NOTION_REDIRECT_URI error string.

Design doc: docs/design/mcp-oauth-pylon-mintlify.md.

One behavior change to a live path

The factory registers grant_types: [authorization_code, refresh_token] for all providers; Notion previously registered only authorization_code. Only new Notion connects re-register. Verified live: a DCR POST to https://mcp.notion.com/register with the new body returns 201 and echoes both grant types. It's also strictly more correct , Notion already uses the refresh grant it didn't previously register for.

Testing

• vitest oauth-drivers.test.ts , 11/11 (DCR body, S256 authorize URL + scope, code exchange, refresh grant, invalid_grant permanent-vs-transient, registry resolution).
• Live registration: DCR POST to all three real vendor register endpoints → 201 + client_id with correct scopes. Proves endpoints/body/scopes short of a human clicking "Allow".
• @zero/server + @zero/mail types clean on touched files; pnpm deps:check clean.

Deploy step (required before it works): set on the server env ,

PYLON_REDIRECT_URI=https://<api-host>/oauth/pylon/callback
MINTLIFY_REDIRECT_URI=https://<api-host>/oauth/mintlify/callback

Under DCR the redirect URI is submitted at registration time, so there is no vendor-side app registration. Pylon requires a Member/Admin seat to authorize.

Risk notes (from Libra pre-commit check)

1. Connections-route overlap with a known prod "Unexpected end of JSON input" failure. This PR's only change to that path is widening the listMcpConnections WHERE providerId IN (...) filter , it adds no new response parsing/serialization. Worth a glance before deploy but not a new parse surface.
2. No route-level integration test for the connect/callback flow, token persistence, reconnect, or actual MCP invocation for Pylon/Mintlify , driver-level coverage only. The full round-trip is unverifiable without a real browser login (see deploy step); tier-3 manual validation is the gate.

Open question

Mintlify scope is docs:read offline_access (read-only docs). Widen in mintlify.ts if the agent should also deploy/edit docs or read analytics.

🤖 Generated with Claude Code

Greptile Summary

The PR adds DCR-and-PKCE OAuth support for Pylon and Mintlify, extracts the shared OAuth driver used by Notion, and exposes all three providers throughout connection management and agent MCP loading.

• Adds provider drivers, redirect-URI environment settings, registration tests, and a shared provider allowlist.
• Replaces the Notion-specific frontend card with a configuration-driven OAuth MCP card cluster.
• Expands agent and connec