How mcpscore handles your sign-in

1. mcpscore reads the server’s published OAuth metadata to find its authorization server.
2. Your browser goes to that authorization server. You sign in and approve there; mcpscore never sees your password.
3. The authorization server sends your browser back to mcpscore with a one-time code. mcpscore exchanges it for an access token, runs the audit, and then asks the authorization server to revoke the token.

mcpscore identifies itself with a public client ID document at https://mcpscore.dev/api/v1/oauth/client.json, so the approval screen names mcpscore. Authorization servers that do not support client ID documents get a dynamically registered client instead.

• It is held in memory by one server process only. It is never written to the database, the cache, logs or analytics, and it never reaches your browser.
• It goes only where the audit needs it. mcpscore sends it to the audited server to list its capabilities, and to the authorization server only to ask for it to be revoked. mcpscore also requests an OAuth resource indicator (RFC 8707) for that server; whether the issued token is restricted to it depends on the authorization server.
• It is used for one audit, typically under a minute. mcpscore asks only for the scopes the server itself requests. If the authorization server also issues a refresh token, mcpscore asks for it to be revoked along with the access token.
• Then mcpscore asks for it to be revoked through the authorization server’s revocation endpoint (RFC 7009), when it offers one. The report states the outcome: revoked, not supported by the authorization server, or failed. When it offers no revocation, the token expires on the authorization server’s schedule, and you can remove mcpscore’s access in your account settings with that provider.

The PKCE secret that the one-time code depends on also stays in that process’s memory. The code itself passes through our internal message channel and the address bar once; on its own it cannot be exchanged for a token. Our CDN’s access logs record that address, so the code is removed from each log file within seconds of the file being written.

The same as any audit: it lists the tools, resources, resource templates and prompts the signed-in account can see and checks them against the published rules. It never calls a tool, reads a resource’s contents or resolves a prompt.

The report is marked as an authenticated audit and is public, like every mcpscore report: anyone with its link can view it, and until a newer audit of the same server replaces it, it is also the latest report anyone sees when they look that server up on mcpscore.dev (/servers?url=), along with its badge. It names the tools and prompts the signed-in account can see: the server defines those names, but which ones appear can depend on your account’s permissions. The names, titles and addresses of resources and resource templates belong to your account, so the report replaces them with placeholders such as [resource 3]. It never contains the token or anything from your account profile. See the Terms & Privacy for how long reports are kept.

A signed-in audit covers what that account can see. Another account with different permissions can get a different result, so compare authenticated audits only with each other.

If you find a weakness in how mcpscore handles sign-ins, email feedback@mcpscore.dev. Please do not include tokens or credentials in the message.