Connect an agent
How Claude Code, Cursor and other MCP clients connect to orcakey.sh, and what the consent screen shows.
orcakey.sh is an MCP server. An AI agent, such as Claude Code or Cursor, can connect to it and ask about your keys: which ones exist, where each one is set, and, only if you allow it, what a value is. Each agent you approve gets a grant of its own, which you can see and revoke from Integrations → MCP.
An agent never uses your sign-in. It holds its own credential, limited to what you chose when you approved it, and never more than you can reach yourself.
The address
Integrations → MCP shows the address to give your client. It is the same for everyone on this orcakey.sh, and you never have to work it out or type one of your own.
Claude Code
claude mcp add --scope user --transport http orcakey <address from the MCP page>--scope user makes orcakey available in every project. Without it, Claude
Code adds it only to the directory you ran the command in.
Then run /mcp in Claude Code and choose to authenticate orcakey. A browser
tab opens on the consent screen.
Cursor
In mcp.json:
{
"mcpServers": {
"orcakey": {
"url": "<address from the MCP page>",
"auth": { "CLIENT_ID": "cursor" }
}
}
}cursor is the name this orcakey.sh already knows Cursor by, so copy it as it
is. The MCP page shows this snippet with your address filled in.
The consent screen
When a client connects, your browser opens orcakey.sh's consent screen. You are signed in as yourself, and it shows:
- Where access will be sent, first. Usually "a program on this computer", because clients like Claude Code and Cursor receive the approval on your own machine. If the address is anywhere else, the screen warns you in plain words. Approve only if you started this yourself: anyone can make a request that calls itself "Claude Code".
- The name the client gives itself, marked as its own claim. The name decides nothing.
- What it may reach. One project, the environments you tick, and optionally only some collections in each. You are only offered what you can reach yourself.
- Whether it may read values. Off unless you turn it on.
- How long it lasts. Thirty days unless you choose otherwise, and ninety at most. After that, the agent has to be approved again.
When you approve, your browser hands the client a one-time code, which it exchanges for its own credential. When you decline, nothing is created.
What an agent can do
An agent is read-only. It cannot create, change or delete anything.
With any grant, it can see, for the environments you approved:
- Key names, and the collections each key is filed in.
- Where each key is set, so it can answer "what does staging have that production doesn't?"
- When each key last changed, and whether its rotation is due.
With value reading turned on, it can also read one key's value at a time. Each value it reads is written to the audit log, one record per key, naming the agent, the client it was approved for, and you.
A value an agent has read cannot be taken back. It is in the agent's conversation from then on. Revoking the agent stops the next read, not the last one. That is why value reading is off by default, and why the consent screen says so before you turn it on.
What bounds an agent
- You. An agent never reaches more than the person who approved it can reach right now. If your role changes, your agents narrow with it on their next call. If you leave the organisation, they stop working.
- What you ticked. A grant never grows. A collection created later is not added to a grant that named its collections. Deleting an environment or collection it reached narrows it.
- The clock. It ends when it expires, and is not renewed past that.
Revoking
Integrations → MCP lists every agent you approved: which client, what it reaches, whether it reads values, when it last called and when it expires. Owners and Admins see everyone's.
Revoking takes effect on the agent's very next call, and the agent is told its access was revoked. It does not affect your own sign-in, your CLI sessions, your service tokens, or any other agent.
Clients that cannot connect yet
orcakey.sh accepts clients that describe themselves with a Client ID Metadata Document, as Claude Code does, and clients that this orcakey.sh has been configured to know in advance, as Cursor is. It does not offer Dynamic Client Registration, which the MCP specification now deprecates. A client that can only register dynamically cannot connect until whoever runs this orcakey.sh adds it to the deployment's configuration.