Arcade.dev vs Keycard

Arcade.dev

Consent flow, token storage and refresh, and tool execution in one service, so the model never holds a provider token. The terms of 15 July 2025 call the service an early version provided as is, with no uptime commitment below Enterprise.

Keycard

Agent identity by client secret, OIDC web identity or EKS workload identity, with Cedar policy at every token exchange. Early Access with sign-up by request, and no terms of service page.

Arcade.dev

1. Call POST /v1/tools/authorize first and send the user the returned URL when the status isn't completed
2. Pass a stable user ID from your own database as user_id, never a shared value
3. Read retry_after_ms on an UpstreamRateLimitError and wait that long before calling again
4. Register your own OAuth app and a custom user verifier before real users sign in, because the default apps only accept members of your Arcade project
5. Revoke a user's access with DELETE /v1/admin/user_connections/{id}

Keycard

1. Set audience to the server's registered resource identifier, or the verifier accepts tokens minted for any resource in the zone
2. Check AccessContext.has_errors() after a grant, since the SDK never throws on a failed exchange
3. Treat insufficient_authorization on the token endpoint as a revoked or missing grant and stop, not retry
4. Keep credentials short-lived, because revocation only stops the next issuance
5. Pin keycardai-mcp to a major version, since 1.0.0 and 2.0.0 shipped a day apart