Govern the MCP tools your agents call

Connect an agent straight to an MCP server and it gets the server's credential and every tool on it. That includes the tools nobody on your team read, and whatever those tools become after you decided to trust them. A tool's description is text the server writes and the model reads. The server can change it tomorrow, and the next call goes out anyway.

Today you can put a remote MCP server behind Anlyon instead. Anlyon lists the tools and adopts none. Each tool you adopt gets approvals and receipts. Your agent never holds the key.

In one sentence: an adopted MCP tool is governed at the call, with approval bound to the exact request and the reviewed tool definition, and a receipt graded acknowledged. A tool that changes is refused until re-adopted.

How it works

1. Register the server. Give Anlyon the address of a remote MCP server, in one environment. Anlyon lists its tools and suggests a risk class for each from what the server says about it. Registering a server lets an agent call nothing.
2. Adopt tools one by one. A person picks the tools your agent may call, and which of them wait for approval. Each adopted tool becomes an action. A tool you skip can't be called through Anlyon.
3. Your agent calls the action. The tool delete_issue on a server you named tracker becomes the action tracker-delete_issue. Over Anlyon's MCP endpoint your agent sees it as action_tracker-delete_issue, and from the SDKs and the CLI you invoke it like any other action. Anlyon holds the credential, checks the tool, waits for approval when you asked for it, makes the call and keeps the receipt.

Why it cuts risk, cost and effort

Less risk. Through Anlyon, your agent reaches only the tools a person adopted. A risky call waits for an approver, and the approval covers these arguments to this definition of this tool. The credential stays in Anlyon, out of the agent's config and context.

Less cost. There is no adapter, pack or gateway of your own to write and keep up. A server you register is enough.

Less effort. Your agent can do the setup. It can register the server and ask to adopt tools from a CLI login or an API key. You make the decision at one link. The adopted tools show up on the MCP endpoint and SDKs you already use, with no new client to set up.

A tool that changes 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, or the server no longer lists it, the tool is not called and nothing is sent. The receipt says why:

{
  "action": { "name": "tracker-delete_issue" },
  "outcome": "failed",
  "partialEffect": "none",
  "evidence": [{
    "source": "system",
    "summary": "The tool changed since it was adopted, so it was not called.",
    "details": { "code": "tool_changed" }
  }]
}

The tool stays refused until a person reads the change and adopts it again. An approval waiting on the old definition can't run the new one.

Adopting stays a person's step

Adopting a tool adds what an agent can do, so it stays a person's step. Your agent can ask:

anlyon mcp adopt tracker list_issues delete_issue

That prints a sign-off link and adopts nothing. A workspace admin opens it, reads each tool's definition and suggested class, and approves or rejects. No API key, CLI login or MCP session can approve the request, including the one that asked. If the server's listing changes between the request and the decision, approving fails and nothing is adopted.

The suggested class is a suggestion. It comes from what the server says about its own tools, and server text is untrusted, so nothing is applied until a person chooses it. By default, a tool suggested as irreversible or destructive waits for approval on every call.

Your users sign in with their own accounts

Many remote servers sign people in with OAuth. Register one with --oauth, and each of your users connects their own account through a connect link your server creates. Your server confirms the connection for the user signed in to your app, so a forwarded link cannot attach someone else's account.

When your server makes a call for one user, Anlyon uses that user's own account at the server. One user's session is never reused for another. Your app stores no token, runs no refresh job and builds no approval backend. So an assistant in your product can file an issue in each customer's own tracker, under the approvals you set, with a receipt for every call.

Linear. Linear publishes a remote MCP server at https://mcp.linear.app/mcp. Register it with anlyon mcp add https://mcp.linear.app/mcp --oauth --name linear. Anlyon signs in with its own client, so there is no OAuth app to register with Linear. Each of your users connects their own Linear account. A comment your agent posts for one of them goes through the tool you adopted, waits for the approval you set, and leaves a receipt graded acknowledged.

Coding agents too

The same holds for Claude Code and Cursor. Run npx @anlyonhq/cli setup claude-code or npx @anlyonhq/cli setup cursor in your project. It adds Anlyon to the project's MCP config, with a URL and no secret in it, and lists the servers your agent can still reach directly. Register those servers with Anlyon, adopt the tools you want, and remove the direct routes. A call to a tool that needs approval waits for you, and each call leaves a receipt.

What it covers

• Remote servers. Anlyon speaks MCP's Streamable HTTP transport to an https address, and the older SSE transport too. A server your agent starts as a local process over stdio can't go behind Anlyon.
• Receipts grade acknowledged. The server accepted the request, and nothing read it back. These receipts never grade confirmed.
• Calls that go through Anlyon. A tool your agent calls directly is not routed through Anlyon and is not governed by it. Take the server out of the agent's config and the token out of its reach.
• Two requests, one session. The check and the call are two requests in one session, so a change made between them is not caught on that call.
• Schemas. Anlyon checks each call's input against the tool's JSON Schema before anything is sent. A tool whose schema it cannot check in full can still be adopted, marked loosely checked: approval on every call is suggested for it, and an approval shows its arguments in full.

Start

Add a server in the console at console.anlyon.com/mcp-servers/new, or have your agent run anlyon mcp add with the server's address. The step-by-step guide is How to put a remote MCP server behind Anlyon. The reference is in the docs: Govern a remote MCP server and Put your coding agent behind Anlyon.

Want to see what a server's tools can do before you register it? anlyon.dev classifies a server's tools with the same engine the console uses.