Documentation
All Other MCP Clients
Use the generic Milkey remote HTTP MCP configuration in any compatible client.
Most MCP-compatible agents ultimately need the same three Milkey details: a server name, the remote MCP URL, and a Bearer authorization header.
If your client is not documented individually, start with the generic configuration below and then adapt field names to match the client’s schema.
Configure All Other MCP Clients
The client-specific work here is mostly about where the config lives and which field names the client expects.
- Look for a raw MCP config file such as `mcp.json`, `mcp_config.json`, or a tool-specific settings file.
- If the client exposes an MCP settings UI, create a remote HTTP server and paste the Milkey URL plus Bearer header there.
mcp.json
{ "mcpServers": { "milkey": { "url": "https://mcp.vexelityai.com/mcp", "headers": { "Authorization": "Bearer mk_sk_your_api_key_id_your_secret" } } }}Verify the connection
- Confirm the client discovers the Milkey tools after saving the config.
- If the client supports health or server status views, use them before running a full workflow.
- Run a concrete prompt that should obviously require a live skill lookup.
Test prompt
Use Milkey to resolve the right testing strategy skill for this project and tell me which page I should read next.Operational tips
- If your client distinguishes between `url` and `serverUrl`, use the same Milkey endpoint in whichever field the client expects for remote HTTP servers.
- When in doubt, compare the client’s shape against Cursor, Windsurf, or Copilot examples to map field names cleanly.