Can a client sign in to your MCP server on its own?

When someone adds your Model Context Protocol (MCP) server to an AI client, the client has to find your sign-in by itself. If one step is missing, the user sees an error, and you don't.

A client finds each step on its own

A remote MCP server that asks callers to sign in uses OAuth, and the client discovers every step from published metadata. In order, it has to:

1. Find the server's protected resource metadata, which names the sign-in server.
2. Read the sign-in server's own metadata.
3. Confirm the sign-in server supports Proof Key for Code Exchange (PKCE), which makes a stolen sign-in code useless.
4. Register itself without a person, through a client ID metadata document or dynamic registration.
5. Check that the resource the metadata names covers the server's address.

The sign-in server's metadata carries most of it. Trimmed, it looks like this:

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "code_challenge_methods_supported": ["S256"],
  "client_id_metadata_document_supported": true
}

Drop S256 from that list, and clients that follow the MCP specification stop there. Nothing on your side breaks: the server still answers, and your own tests still pass with the token you already have.

Connector ready walks the same path

Netonica's MCP check follows the same discovery a client does: the link in the sign-in challenge, or else the standard addresses. Connector ready holds when the server is open, or when every step above works. New monitors leave it unticked, so tick it on servers people add as connectors.

Two changes stand out

• PKCE support removed raises an alarm, because without PKCE a stolen sign-in code works.
• Sign-in metadata lost is a notice, because a firewall that turns the scanner away now and then would otherwise page someone.

The same check offers pins for your MCP tool descriptions.