Connecting a client to a server URL does not give it access to protected account data. OAuth lets the client request delegated access through an authorization server, the service that issues the token.
The MCP authorization specification defines this flow for HTTP transports. Authorization is optional for MCP implementations. Local stdio servers use a separate credential arrangement.
How does the client find where to sign in?
The client reads the MCP server's protected-resource metadata to discover its authorization server.
Under the discovery rules, a server can supply that metadata URL in a WWW-Authenticate header on a 401 response. Clients also support discovery through well-known metadata paths.
The metadata's authorization_servers field identifies the available authorization servers. The client retrieves the selected server's metadata to find its endpoints and supported capabilities.
How does the client identify itself?
The client obtains a client ID through a registration mechanism supported by the authorization server.
The MCP registration rules prefer existing pre-registered client information when available. Otherwise, clients can use Client ID Metadata Documents when the server advertises support.
A Client ID Metadata Document is a JSON document at an HTTPS URL describing the client. The URL acts as its client ID.
Those rules deprecate dynamic client registration, which lets a client request an ID through a registration endpoint. The specification retains the mechanism for compatibility with authorization servers that lack metadata-document support.
How does the client obtain the token?
The client exchanges an authorization code for an access token after the authorization server approves the grant.
The authorization-code protection rules require PKCE, which binds the exchange to the client that initiated it. The client creates a secret verifier and sends a derived challenge with its authorization request. It supplies the verifier when redeeming the code, helping prevent an intercepted code from being used by another caller.
What do scopes and the target resource control?
Scopes describe the requested permissions. The target resource identifies the server for which the client requests a token.
The scope-selection rules direct clients to use the challenge's scope value when supplied. A client should request the access its operation needs.
The client includes the resource parameter in authorization and token requests. It sends the resulting token in the Authorization header on protected HTTP requests. The receiving server checks that the token was issued for it.
Permission to invoke a tool does not establish that a particular invocation matches the user's task. The host still decides whether to proceed with the proposed action.
How do I authorize a client to use Bird?
You add Bird's hosted MCP URL to a compatible client and complete its browser sign-in.
Bird's documented handshake uses dynamic client registration. That describes Bird's connection flow separately from the specification's preferred metadata-document mechanism.
On the consent screen, choose the workspace or organization permissions to delegate. The grant is limited by what the client requests, what you approve and what you hold.
The client's displayed name is self-asserted, so confirm that it matches the client you launched. You can revoke its grant from Connected apps in your profile.
A tool can remain listed when your grant lacks permission to invoke it. A successful whoami call confirms the signed-in identity. The requested operation still needs its own permissions.
For a local bird mcp process, the server reuses the CLI's stored login. The MCP setup guide describes that separate path.