White paper · figures as of 2026-10-22

Agents act on your accounts with no stated limit

27% of listed MCP servers declare a tool that can send, delete or move money, and the protocol gives none of them a field in which to declare a limit on it.

Summary

The Model Context Protocol (MCP) is how AI agents reach email, files, databases and payment systems. A server tells a client which tools it has. The protocol has no field for a cap, an expiry, a way to switch access off or a log.

The Leash Index reads every server in the official MCP registry and publishes what each one declares. It lists 22,849 servers from 15,912 publishers, declaring 364,885 tools. Of those servers, 6,130 declare a send, delete or money tool, and 10,455 mark none of their tools with the protocol's safety hints.

Leash closes the gap in two steps. The index shows anyone what a server declares it can do to their account before they connect it. The grant puts a time-boxed, capped limit in front of the server, checks every call against it, and leaves a receipt for each decision.

The gap in the protocol

An MCP server can say what its tools are. It cannot say how much they may be used. A server answers one request, tools/list, with each tool's name, description and input schema. A tool is either exposed or it is not.

The only safety information the protocol carries is four optional hints. The specification says clients must treat them as untrusted unless the server is trusted, because the server being described writes them.

This is a property of the protocol and not a fault of any server's authors. A careful author has no field in which to be careful. A product may provide such controls outside MCP, where a manifest has no way to show them.

The question grows when one agent mounts several servers. A tool that brings outside content in, such as a web page or an email, sits beside tools on other servers that send or delete. The stack check shows both sides for your own config.

What the index counts

Every listed server declares no cap, no expiry and no off switch, because the protocol has no field for them. What differs between servers is what they declare they can do.

The servers with a delete, send or money tool come from 4,813 of the 15,912 publishers. On safety hints, 10,455 servers (46%) mark none of their tools read-only or destructive, so the index has to classify those tools from their names.

By exposure score, 7,991 servers are low, 6,828 moderate, 5,227 elevated and 2,803 high. The full breakdown is in the report.

How a server is read

Every record comes from one input: the server's own answer to tools/list. No tool is ever called, and nothing is taken from source code, documentation or observed behaviour. The full rules are on the methodology page.

1. Collect. Every server in the official MCP registry is read once a week. A public endpoint gets a handshake and one tools/list request, without signing in, one host at a time.
2. Run packages in isolation. A server that ships only as a package runs at the exact version the registry names, in a container with no network, a read-only file system, no privileges and placeholder credentials.
3. Classify. Each tool is read as read, write, send, delete or pay. Each reading records its basis: declared by the server's hint, inferred from a verb in the name or description, or assumed. An assumed tool is recorded as a write.
4. Score. Each tool adds a weight for its action, times the share of controls it lacks. The sum becomes a 0 to 100 exposure score on a curve that flattens, so a very large server does not pin the scale.
5. Keep the history. When a server's manifest changes, the earlier record is kept and the difference is published in a dated changelog.

An endpoint that does not list its tools is not scored. In the crawl of 2026-10-21, 30,959 endpoints were asked and 17,068 listed their tools. What each of the other 13,891 returned is recorded on the unanswered ledger; most ask for sign-in. Any maintainer can dispute a reading, and the correction is published with the record.

The grant model

A grant is a customer's stated limit on an agent: which tools, until when and how many times. Leash checks every call against it before the call reaches the server.

1. The agent calls a tool.
2. The gate checks the call against the grant the customer set.
3. Within the limits, the server runs the call. Outside them, the call is blocked and the agent is told why in plain words.
4. Either way, a receipt is written.

• Deterministic. The gate is a pure function. A model does not override a block, and a test fails if the gate ever imports a clock, a network call or a model.
• Recorded by construction. The function that returns a verdict returns its record with it, so no decision can be made without one.
• About agents, never people. A record names the agent, the tool and the vendor. It holds no end user's name, email or address.

A receipt says what happened in plain words: “Blocked: send on email.outbox. The limit you set had been reached.” Receipts are chained by hash, so a customer can read and export them and can tell if one was changed.

Leash Guard: the same limits on your own machine

Leash Guard is a free, MIT-licensed proxy that puts those limits in front of any MCP server with one command. It is published on npm as @leashkit/guard, has no dependencies and needs no account.

Every limit can be changed per server or per tool. Guard also records the tools a server declared when it was wrapped and flags a server that later changes them, and it writes each allowed or blocked call to a hash-chained log on the user's machine.

Guard Team gives every machine in a team the same limits and writes every machine's receipts to storage the team controls.

Leash Grant: the customer sets the limits

Leash Grant is for a product whose agent acts on its customers' accounts. The product sends its customer to a consent page on this site, and the customer decides what the agent may do before it does anything.

1. Ask. The product states which tools its agent wants, how many times and for how long.
2. The customer chooses. The page describes each capability in Leash's own words. The customer can drop a line, lower a cap, shorten the time or decline. A choice can only take away.
3. Sign. Leash signs the limits the customer chose and hands the grant to the product. Leash keeps no copy.
4. Enforce. The product's agent checks every action against the grant with the same gate Guard uses.
5. Switch off. The customer keeps a private link that switches the grant off at any time. The product can learn of it within 60 seconds.

The customer needs no account, and Leash is not told who the customer is.

A product can also send the receipts its gate writes, and the customer then reads what the agent did from their own grant page: each action that was allowed, blocked or held for approval, and why. A log entry holds a time, the decision, the tool and the kind of action; an entry that holds anything else is refused. Logs are deleted 30 days after the grant ends.

A customer can mark a capability “ask me each time”. The gate then holds that action, the product leaves a request, and the customer approves or refuses it from their grant page. A request names a tool and an action and cannot carry a message, so the customer reads the same words as on the consent page. An approval is for one action, and every other limit still applies to it. Leash does not know who the customer is, so the product tells them a request is waiting.

Leash is not in the path of the agent's calls. A grant holds an agent only where the product checks it.

Limits

A score describes what a server declares. It does not describe what the server does.

• Declared, not observed. No tool is called. A server may enforce limits on its own side that a manifest has no way to show.
• Not a verdict on safety. A score is not a certification, a penetration test or a vulnerability report. Two servers with the same score can differ greatly in how carefully they are built.
• Words, not intent. Classification reads names and descriptions. The delete class includes archive, close and cancel, which are often reversible, so the index errs toward overstating.
• Unanswered servers are not counted. 45% of the endpoints asked on 2026-10-21 did not list their tools without sign-in.
• Servers are not products in use. One publisher can register thousands of near-identical servers, so counts by publisher are given beside counts by server.
• A receipt shows the log was not edited. It does not show the agent behaved well.
• A log shows what a product reported. The chain shows that nothing sent was changed afterwards. It cannot show an action the product did not report.

Leash is not insurance, a bank, an escrow service or a dispute court. A dollar limit in a grant blocks a call; Leash never holds, moves or settles money.

What is available today

© 2026 Media Yard LLC. All rights reserved. This paper may be quoted with a link to this page; it may not be republished in full without permission.