Auth
Auth header problems in MCP clients
Fix Authorization header forwarding, bearer token formatting, and client-specific MCP auth configuration problems.
Symptom
The same endpoint works with curl but fails from an MCP client, local script, or hosted agent runtime.
First check
Capture or log the outgoing request and verify the client forwards Authorization: Bearer to the Astrail MCP URL.
Quick fix
Move the key into the client secret field or environment variable expected by the MCP adapter, restart the client, and retry initialize.
Compare curl to the client
A passing curl request proves the endpoint and key can work together. The next step is to verify the client sends the same method, URL, content type, and Authorization header. Many client bugs are config shape problems, not endpoint failures.
Avoid prompt-visible secrets
Do not ask the model to include the token in tool arguments. The Authorization header should be configured outside the prompt so agents cannot leak it through logs, memory, generated docs, or error messages.
Restart after config changes
Desktop MCP clients often cache configs at process start. After editing a JSON config or environment file, fully restart the client and any local proxy before retesting.
Check proxies and adapters
If you route hosted HTTP MCP through a local stdio bridge, confirm the bridge copies headers to the remote HTTP request. A bridge that only forwards the JSON body will make private endpoints look broken.
FAQ
Can I put the API key in the endpoint URL?
No. Use an Authorization header. Query-string keys are easier to leak through logs, browser history, screenshots, and analytics.
Why does the client still fail after I changed the key?
The client may be using a cached config or a different profile. Restart it and verify the active server entry points at the updated key.