Cursor
Connect Anlyon to Cursor: governed actions and approvals over MCP, with OAuth or a scoped API key
Anlyon executes named production actions on an agent’s behalf and routes sensitive ones to a human reviewer first. Connect a workspace to list its actions, invoke one, request approval, and, with the decide permission, approve or deny pending requests. A tool your own code calls directly is not routed through Anlyon and is not governed by it.
Connect
Cursor connects to Anlyon’s hosted MCP endpoint (streamable HTTP) and signs you in with OAuth (“Login with Anlyon”). There is no API key to paste.
Add the server through Cursor’s settings, “Add MCP server”, with this URL:
https://api.anlyon.com/mcp
Or add it to an MCP configuration file: .cursor/mcp.json in a project for that project only, or ~/.cursor/mcp.json for every project:
{
"mcpServers": {
"anlyon": {
"url": "https://api.anlyon.com/mcp"
}
}
}
Cursor then asks you to sign in to the server. A browser opens. Sign in to Anlyon or create an account (a new account gets a free workspace during sign-in), and choose permissions. If you belong to more than one workspace, Anlyon first asks which workspace and environment Cursor acts in. With one workspace, the connection is bound to its default environment. “Approve on your behalf” is off unless you turn it on. Cursor sees only the tools the permissions you granted cover.
Cursor’s settings and configuration format change between releases. If the steps above do not match your version, check Cursor’s MCP documentation.
Running without a browser
OAuth needs a browser once. Where that is not possible, use the self-hosted server with an API key instead, scoped to what Cursor should be able to do:
{
"mcpServers": {
"anlyon": {
"command": "npx",
"args": ["-y", "@anlyonhq/mcp-server"],
"env": { "ANLYON_API_KEY": "anlyon_live_..." }
}
}
}
Put this in ~/.cursor/mcp.json, not in a project file that is committed. The key’s scopes are exactly what Cursor can do. The self-hosted server exposes the governed tools only.
Tools
By default the server exposes the governed set and nothing else:
| Tool | What it does |
|---|---|
list_actions |
List the workspace’s actions and say which require approval |
invoke_action |
Invoke an action by name. Actions also appear as tools named action_<name> |
request_approval |
Ask a human to decide something outside an action |
check_approval |
Read an approval’s status once |
wait_for_approval |
Wait for a reviewer’s decision, up to 120 seconds a call, 60 by default. Returns the still pending approval if nobody has decided |
list_pending_approvals, decide_approval |
Review and decide. On the hosted endpoint, shown only with “Approve on your behalf”. With an API key, the key needs approvals:decide |
list_workspaces, select_workspace |
Choose which workspace and environment Cursor acts in. Switching is OAuth only and needs “Switch between your workspaces” |
Actions and approvals
Cursor lists the workspace’s actions and invokes them as tools named action_<name>. The model never sees a credential: an action references {{secret:NAME}} and Anlyon resolves it at dispatch. This covers credentials in the Anlyon vault, not a key your own process already holds. An action that requires approval waits for a reviewer, and Cursor can wait with wait_for_approval. Anlyon does not retry an action invocation. Where a request may have reached the destination and the outcome cannot be confirmed, the invocation is recorded as unknown and you reconcile before retrying.
With “Approve on your behalf” granted, list_pending_approvals and decide_approval let you review from Cursor. Your decision is recorded against your name and counts as one user toward an N-of-M rule. A connection cannot decide an approval it requested itself. Decide those from the dashboard or another connection.
Project rules
To tell Cursor how this project uses Anlyon, add a rule file such as .cursor/rules/anlyon.mdc. For example:
## Anlyon
- Production calls go through Anlyon actions, not direct API calls. List them with the Anlyon `list_actions` tool and invoke one through its `action_<name>` tool.
- Never ask for, print or store a provider credential. Actions reference `{{secret:NAME}}`; Anlyon resolves it at dispatch.
- If an action needs approval, call `wait_for_approval` with the `apr_` id and report the decision.
- An invocation with status `unknown` may have taken effect. Do not retry it; tell me so I can reconcile.
- Docs: https://docs.anlyon.com/llms.txt
To set up a project to call Anlyon from its own code with the SDK, paste the agent setup prompt into Cursor instead.
Prefer a terminal?
The Anlyon CLI lists actions, invokes them and decides approvals from a shell, with the same permissions as the API.
Connect a second tool
An approval one tool requests can be reviewed from another. Connect the second one to the same workspace and environment.
Claude Code
claude mcp add --transport http anlyon https://api.anlyon.com/mcp # then run /mcp to sign in
Codex: add the server to ~/.codex/config.toml, then sign in:
[mcp_servers.anlyon]
url = "https://api.anlyon.com/mcp"
codex mcp login anlyon
