The MCP server authenticates with the same API key as the REST API — but instead of a header you set on every request, your assistant passes it as a bearer token from its MCP config.
Generating an API key
You need a NeetoCal API key before you can connect an assistant. Learn how to generate your API key here.
How MCP authenticates
NeetoCal runs a hosted MCP server at https://connect.neetocal.com/mcp/messages. Your assistant sends the API key on every request in an Authorization header:
Authorization: Bearer <your-api-key>
YOUR_API_KEY, and the assistant sends the header from then on.
Each NeetoCal surface authenticates differently:
| How you authenticate |
|---|
| REST API | X-Api-Key header on every request |
| CLI | Sign in through your browser; credentials are stored locally |
| MCP | Authorization: Bearer <your-api-key> from your assistant’s config |
Keep your key safe
Treat your API key like a password. Generate a separate key per workspace — a key from one workspace won’t work in another.
Your API key grants access to your workspace’s scheduling data. Anyone who can read your assistant’s config can use it, so don’t commit it to shared repositories or paste it where others can see it.
When authentication fails
MCP doesn’t surface a 401 the way a raw API call does. A missing or invalid key shows up instead as one of these symptoms:
- The
neetocal tools never appear in your assistant.
- A tool call fails, and the assistant reports it couldn’t reach NeetoCal.
Both usually mean the Authorization header is wrong — a mistyped key, a key from a different workspace, or a key that’s been revoked. Verify or regenerate your key from the API Keys article, then work through Troubleshooting. 