Understand browser-origin restrictions
Cross-origin rules only matter when the MCP client runs in a browser. A client running on a server or as a desktop application sends no Origin header and is unaffected by anything on this page.
The default is closed
Allowed CORS origins in the MCP settings is empty by default. With it empty, no browser origin is permitted.
A request carrying an Origin that is not on the list receives no CORS headers, so the browser blocks the response. The server does not reject the request with an error message the user will see — the browser simply refuses to hand the result to the page, which is why this failure looks silent from the client side.
Requests with no Origin header are unaffected and proceed normally.
Allowing an origin
Add one origin per line in Settings → POM AI → MCP server → Runtime limits → Allowed CORS origins:
https://app.example.com
https://tools.example.orgMatching is exact and complete: scheme, host and port must all agree. https://app.example.com does not permit http://app.example.com, https://www.app.example.com, or the same host on another port. There is no wildcard.
What an allowed origin gets
For a permitted origin the server returns the origin itself in Access-Control-Allow-Origin, the methods appropriate to the endpoint, a Vary: Origin header, a 600-second preflight cache, and these allowed headers:
Authorization, Content-Type, Accept,
MCP-Protocol-Version, Mcp-Session-Id, X-POM-AI-MCP-API-KeyOPTIONS preflight requests are answered with 204.
The same handling applies to the MCP endpoint, the OAuth endpoints and the two discovery documents, so a browser client can complete the whole flow.
Think before adding one
Allowing an origin means pages served from that origin may make authenticated requests to your MCP server from a user's browser. Consider:
- Do you control the origin? Never allowlist an origin you do not operate.
- Could the credential leak? A browser client has to hold a token or key where page scripts can reach it. That is a materially weaker position than a server-side client.
- Is there another way? A server-side client avoids CORS entirely and keeps credentials off the browser.
The safest configuration is an empty list, and it is the right one for most sites.
Origins are not authentication
Allowlisting an origin does not authenticate anyone. Every request still needs a valid token or API key, and still passes the scope, capability, write-gate and schema checks.
Conversely, allowlisting does not grant anything: it only stops the browser discarding responses. See MCP security model.
Diagnosing
| Symptom | Likely cause |
|---|---|
| Browser console reports a CORS error | The origin is not allowlisted, or differs in scheme or port |
| Preflight fails | Something upstream is intercepting OPTIONS |
| Works from a terminal, fails in a browser | Confirms it is a CORS issue, not authentication |
| Works locally, fails in production | The production origin was never added |
The terminal comparison is the quickest way to separate a CORS problem from an authentication problem: if a request succeeds with the same credentials outside a browser, the credentials are fine.
Proxies and CDNs
A CDN or proxy in front of the site must forward Origin, Access-Control-Request-Method and Access-Control-Request-Headers, and must not cache MCP responses.
Caching a response that carries Access-Control-Allow-Origin for one origin and serving it to another is a real risk. The MCP paths are sent with no-store and Vary: Origin for that reason; exclude them from caching anyway. See MCP requirements.
Changing the list
Edit the setting and save. It takes effect on the next request — no rewrite flush or reconnection needed.
Review the list periodically and remove origins that are no longer used, in the same spirit as reviewing authorized domains or open write gates.