Govern a remote MCP server
List its tools, see the risk of each one, and adopt only what you choose. Your agent gets those tools as actions and never the server's credential, and a tool that changes is not called until you adopt it again.
- list_tablesReadadopted
- run_selectWriteadopted
- run_migrationWriteadopted
- delete_rowsDestructivenot adopted
- drop_tableDestructivenot adopted
Connect an agent straight to an MCP server and it gets every tool on it. Including the ones nobody reviewed, and whatever they become.
The server's credential sits with the agent, and so does every tool the server lists, reviewed or not. A tool's description is text the server writes and the model reads, and the server can change it after you decided to trust it.
Without Anlyon
A tool nobody chose
The agent needed to read tables. The same server also offers to drop them.
A definition that changed
The tool you reviewed last month says something else today, and the next call goes out anyway.
A credential in every client
Each agent and laptop that connects holds the key, and each call leaves no receipt of its own.
Adopt tool by tool. Registering a server lets an agent call nothing.
Anlyon lists the server's tools and suggests a class for each from what the server says about them. The suggestion is yours to overrule: what a server says is untrusted, so nothing is applied until you choose it.
Tool
Suggested
Why
You chose
list_tablesReadThe name "list_tables" says "list": a word for reading.
Adoptedrun_selectWriteThe input takes a statement or command to run (input.sql), which can change anything it can reach.
Adopted, approval on every callrun_migrationWriteThe input takes a statement or command to run (input.sql), which can change anything it can reach.
Adopted, approval on every calldelete_rowsDestructiveThe name "delete_rows" says "delete": a word for removing or ending something.
Not adopteddrop_tableDestructiveThe name "drop_table" says "drop": a word for removing or ending something.
Not adopted
- Read
- Looks at data and changes nothing.
- Write
- Creates or changes something.
- Irreversible
- Does something that cannot be taken back once it has run.
- Destructive
- Deletes or overwrites data.
When a tool changes. The call stops before it leaves.
Before every call Anlyon lists the server's tools and compares the tool with the definition you adopted. If it differs, the tool is not called, the receipt says so, and the console marks it Changed for you to read and adopt again. An approval waiting on the old definition can't run the new one. A call that does run grades acknowledged: the server accepted it, and nothing read it back.
{ "id": "eff_01JABCDEF", "action": { "name": "db-run_migration", "versionId": "acv_01JABCDEF" }, "outcome": "failed", "partialEffect": "none", "grade": "failed", "evidence": [{ "source": "system", "impliedOutcome": "failed", "summary": "The tool changed since it was adopted, so it was not called.", "details": { "code": "tool_changed" } }]}Why it pays. Less risk, less cost, less effort.
Less risk
A tool you skip can't be called through Anlyon. A tool you adopt can wait for an approval bound to the exact request and the definition you reviewed.
Less cost
No adapter, pack or gateway of your own to write and keep up.
Less effort
Paste an address, tick the tools. Each one appears on your MCP endpoint and SDKs as an action, with no new client to set up.
Add a server in the console. Then call what you adopted, by name.
Adopting a tool adds what an agent can do, so it stays a person's step in the console. Check a server's tools on anlyon.dev first, if you like: both read them with the same engine.
# The tool run_migration on a server you registered as "db"curl -X POST https://api.anlyon.com/api/v2/actions/db-run_migration/invoke \ -H "Authorization: Bearer $ANLYON_AGENT_KEY" \ -H "Anlyon-End-User: user_123" \ -H "Content-Type: application/json" \ -d '{ "input": { "sql": "alter table orders add column note text" } }'# Over Anlyon's MCP server, an agent sees it asaction_db-run_migration