Authentication

Two ways in

https://api.vidrys.com/mcp accepts an API key, or — where your workspace has them switched on — a sign-in connection the member makes from the client itself. Both resolve to the same thing: one member, one workspace, one level of access.

API keys

Send the key as a bearer token. Clients that support headers (Claude Code, Codex, Cursor and most others) do this from configuration:

Authorization: Bearer $VIDRYS_API_KEY

A key acts as the admin who created it and can never do more than they can. It stops working when they leave the workspace, when the key is revoked, or when the plan drops below Grow — and it loses write access the moment they do, for instance by being moved to viewer. Access is read, or read-and-write on Scale and Custom. The full detail is in the API’s authentication guide — it is the same credential.

Sign-in connections

Assistants that can’t hold a header — claude.ai and ChatGPT connectors — sign in instead. The flow is the ordinary OAuth one, with the consent page on our side:

1. The client calls the server, is refused, and discovers where to sign in.
2. You sign in with your Vidrys account.
3. You choose which workspace the app may read, and read or read-and-write.
4. The connection appears under Connected apps on the Developers page, and the assistant gets a token bound to this MCP server and nothing else.

Sign-in connections have to be configured for your deployment. If the Developers page doesn’t offer the claude.ai & ChatGPT setup, that workspace is on keys only.

Revoking

Keys and connections are both revoked on the Developers page, and both are re-read from the database on every single call — so revoking stops the next tool call, not the next cache refresh. Every write a credential made is recorded against it.

Where each credential works

The separation is the point: a key must never become a way into internal endpoints that return fields this surface withholds.