Documentation
Authorization
The shared authentication model for every Milkey MCP client.
Every Milkey MCP client authenticates the same way: by sending your API key in the Authorization header using the Bearer scheme.
Bearer header
The minimum valid header shape is:
HTTP
Authorization: Bearer mk_sk_your_api_key_id_your_secretIf the header is missing, Milkey returns 401. If the header is present but malformed, Milkey returns 400 and expects the format Bearer <token>.
Where to store keys
Keep the real key in a secure store and let the client inject it into the MCP config whenever possible.
- Use environment variables when the client supports interpolation in config files.
- Use a password manager or secrets manager for manual copy-and-paste setups.
- Use one key per machine, IDE, or automation environment so revocation is surgical.
Do not treat MCP config as harmless text
An MCP config file that contains a real Milkey key is effectively a credential file. Do not commit it to Git, paste it into browser code, or share it in screenshots.
Common errors
- 401 Unauthorized: the header is missing, the key is revoked, or the token value is wrong.
- 400 Bad Request: the header exists but is not in the exact
Bearer <token>format. - Works in one client, fails in another: the value is often fine, but the client-specific config wrapper is wrong, such as using `url` instead of `serverUrl`, or forgetting `requestInit.headers` in Copilot IDE configs.
Why auth is centralized
The right UX is to keep copyable auth in the setup snippets, but keep the full explanation of auth behavior in one canonical page.
- Agent pages stay focused on the client-specific config and verification flow.
- The central auth page becomes the source of truth for storage, rotation, and error handling.
- Quickstart can link here without repeating the whole auth model in multiple places.