You paste an access token into a server's headers, and the server rejects it immediately. The token was copied from the vendor's console and works fine when you use it with a command-line HTTP client. Listing your servers shows a note about the configuration alongside the failure. What has happened, and what fixes it?

The principle — A value that is correct and a value that is stored correctly are different things, and a credential copied from a browser is one of the easiest places for the two to come apart.

Why the key is correct — Claude Code flags configuration values with hidden leading or trailing whitespace, and it names this as a common cause of authentication failures after pasting a token. Crucially it does not act on what it finds: Claude Code does not trim the whitespace and uses the values exactly as written, so the remedy is to edit the configuration and remove it. That also explains why the same token succeeds from a command-line client, where your shell stripped the stray newline before it ever reached the request.

Why the others are wrong — The token is demonstrably valid, since it works elsewhere, so generating another and pasting it the same way reproduces the failure exactly. Whitespace is not trimmed for you, which is the whole reason the note exists. And the note is a report rather than a repair, so reading it as evidence the problem is handled is what turns a two-minute fix into an afternoon.

Remember this — When a credential works everywhere except here, suspect what came along with it rather than what it is. Copying from a browser is where invisible characters get attached, and the client tells you when it sees them without doing anything about it.

Sources — Anthropic's Claude Code MCP quickstart and MCP reference.