Authenticating to the MCP server
There is no authentication on the Connect MCP server, because there is nothing private behind it. No token is read, no OAuth flow exists, no WWW-Authenticate challenge is ever sent, and no scope can be requested. What the server does check is the Origin header, and that is a browser-safety control rather than a credential.
Configure your client for no auth#
In an MCP client, add the server as a remote endpoint with the URL https://connectbyjbrh.com/mcp and the authentication option set to none. If the client insists on a credential, any value works and none is consulted; a header you send is simply not read. Nothing is stored, so nothing needs rotating.
| Thing a client may look for | Present? |
|---|---|
| Bearer token or API key | No — none is issued and none is read |
| OAuth authorisation flow | No |
/.well-known/oauth-protected-resource metadata | No |
| Dynamic client registration | No |
WWW-Authenticate challenge on 401 | No — the server never answers 401 |
| Scopes or consent screen | No |
Origin validation | Yes — a present, unrecognised Origin is 403 |
| Per-address rate limiting | Yes — 120 requests per minute |
What the Origin check is for#
The MCP specification requires a server to validate a *present* Origin and answer 403 when it is invalid. That is not about identifying a caller. It is about a page on an unrelated website being able to drive an MCP server through a visitor's browser — the same class of problem as DNS rebinding against a local service. A desktop MCP client sends no Origin at all, and a request with no Origin is allowed.
So the check produces exactly two outcomes worth knowing: a browser-based client served from an unrecognised origin is refused with 403 and the message *Origin not allowed*, and everything else proceeds. A refusal here is not a sign that you need a credential — there is none to get.
Why there is no credential#
The specification's rule is that authentication is required for anything that is not public. Everything this server exposes is public: the ten tools read the generated documentation corpus, the four resources are files the website already serves to anonymous visitors, and there is no workspace scope for a token to carry. Adding a credential would protect nothing and would create a secret for somebody to leak.
This is not an oversight waiting to be corrected in a client's settings. The authenticated half that a business platform's MCP server is often assumed to have does not exist here at all: see Workspace MCP tools for the tool registry and the boundary behind it.
Revocation, rotation and abuse#
There is no credential to revoke and no session to end. The only control on a client that misbehaves is the rate limit: 120 requests per minute per client address, after which the server answers HTTP 429 with JSON-RPC code -32603 and a message naming the limit. The counter is a sliding window over the last sixty seconds, held in the server process, so it resets by itself as older requests age out.
Two consequences follow for a client author. Retrying a 429 immediately makes it worse, because the window is still full; wait, then retry with a widening delay. And because the limit is per address, several clients behind one gateway share a budget — if you are building something that fans out, cache the documentation you have already fetched instead of re-reading it per question.
Questions#
My client requires a token field. What do I put in it?
Anything, or leave it blank if the client allows that. The server never reads an authorisation header. Prefer a client setting of *no authentication* so that no value is stored anywhere on your side.
Will an authenticated endpoint appear later if I keep checking?
This page describes what is running today and makes no claim about what comes next. Check /.well-known/mcp.json, which is generated alongside the server and lists its tools and its authentication position.
Is the connection encrypted?
The endpoint is served over HTTPS at connectbyjbrh.com, so the transport is protected in the ordinary way. That is separate from authentication: encryption protects the request in flight, and there is still no identity being asserted at either end.