# 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.

- **Status:** Available
- **Audience:** developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/developers/mcp-authentication/

## 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](/developers/mcp-workspace-tools/) for the tool registry and the boundary behind it.

> **Note** Integration keys are a real mechanism inside Connect, on a different surface entirely. They grant nothing on this endpoint, and a request to `/mcp` carrying one behaves identically to a request without.

## 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.

## Related

- [The Connect MCP server](https://connectbyjbrh.com/developers/mcp-server/)
- [Workspace MCP tools](https://connectbyjbrh.com/developers/mcp-workspace-tools/)
- [MCP error shapes](https://connectbyjbrh.com/developers/mcp-errors/)
- [Integration keys](https://connectbyjbrh.com/developers/integration-keys/)
- [MCP security](https://connectbyjbrh.com/docs/protocols/mcp-security/)
- [OAuth for agents](https://connectbyjbrh.com/docs/protocols/oauth-for-agents/)

## What this page is based on

- `backend/app/mcp_server.py` — _origin_ok, _rate_ok, mcp_discovery
- MCP specification 2026-07-28 — https://modelcontextprotocol.io/specification/2026-07-28
- Connect capability registry (docs-source/facts.py)