THRONE
See report Verify server

mcp governance for ai agents

Govern the MCP servers your AI agents depend on.

Throne verifies MCP servers before they enter production: isolated execution, real client behavior, security review, policy decision, and sealed evidence.

See sealed report How Throne works

isolated execution · compatibility verdicts · sealed evidence receipts

Open public registry
public evidence layer 76 servers executed 31 fit to ship today registry live
For teams deciding which MCP servers can be allowed reviewed blocked certified

public ecosystem observed

Throne executes public MCP servers from the ecosystem and records what actually happened. Independent public records, not endorsements.

how it works

Execute. Decide. Seal.

Throne turns an MCP package, repo, or config into an approval record your team can act on.

01

Execute

Boot the target inside a disposable microVM, install it from source, and observe what it does before an agent ever touches it.

02

Decide

Compare real client behavior, inspect security findings, and classify the server as allow, review, or block.

03

Seal

Publish or keep a record with the scan id, timestamp, raw evidence, client verdicts, and evidence hash.

why the obvious fix is not enough

A passing CI badge does not fix this.

An MCP server can have green checks, a clean lint pass, and a maintainer who swears it works, and still hang Cursor on the third tool call or expose a filesystem write no one reviewed because it sat three layers inside a dependency. Code review checks the code. It does not execute the protocol against the clients your agents actually run.

why this becomes mandatory

Agents are about to call tools your company never certified.

Every MCP server is a supply-chain decision. It can read files, move data, call APIs, and shape model context. Throne gives engineering and security one shared release signal.

01

Client behavior diverges

A server can pass locally and still fail when Cursor streams, Claude Code reconnects, or a desktop client validates names differently.

02

Security sits inside the tool

MCP tools often touch files, secrets, shells, browsers, tickets, and databases. A README badge is not a security review.

03

Procurement needs evidence

Companies will not approve agent tools because a maintainer says they work. They need a repeatable record with traces.

live from /api/stats

State of MCP, measured by execution.

Live registry totals, top failure reasons, and security review split. No vanity numbers.

Fit to ship31
Needs key23
Inconclusive19
Not fit3
needs credentials16
needs arguments7
launch error6
clean12
review59
not run4

the cost of not knowing

7 of the servers we executed crash on launch.

Before they speak a word of the protocol. Public packages can sit live for weeks without anyone seeing the failure path. Your agents would find it in production on the first call.

7crash before the MCP handshake
2 liveclient profiles measured today
0self-reported listings we take on trust

who Throne is for

One record, four teams that need it.

platform

Platform engineers

Ship MCP servers without hand-testing every client before each release. Gate the merge on a real verdict.

security

Security teams

See what a server can actually do, file access, network, shell, before it is approved for internal use.

maintainers

OSS maintainers

A public record that your server works, with a badge that re-earns itself on every release.

leads

Engineering leads

Approve agent tools on evidence, not on "it worked when I tried it locally."

create evidence

Create a verification record.

Use the public verifier when you need proof for one server. The same evidence model becomes private allowlists, CI gates, scheduled rescans, and audit exports for teams.

published npm package · no signup · no card

live verification

Result renders as evidence, not a demo.
microVM execution
> throne verify @modelcontextprotocol/server-everything sealed
 
claude code PASS
cursor PASS
chatgpt desktopComing soon. Emulation profile pending real-traffic capture. COMING SOON
codex cliPlanned. Emulation profile not yet calibrated. PLANNED
zedPlanned. Emulation profile not yet calibrated. PLANNED 
{
  "client": "cursor",
  "step": "streaming",
  "status": "pass"
}
static scan / queued
VERDICT: FIT TO SHIP claude code + cursor / 0 failures / security clean / full report sealed by THRONE / evidence hash verified

public trust layer

A registry that is earned by execution.

Every public record is a product surface: verdict, client matrix, security review, evidence hash, and a badge maintainers can point to.

live registry 75 public records scan id, sealed timestamp, normalized target, security verdict, and evidence hash on every sealed record.
registry76 sealed
not-a-valid-urlinconclusivenpm@modelcontextprotocol/server-filesystemfitnpm@modelcontextprotocol/server-everythingfitnpmgithub.com/zcaceres/markdownify-mcpfitgithubn8n-mcpfitnpmgithub.com/punkpeye/awesome-mcp-serversinconclusivegithub@azure/mcpneeds keynpm

release workflow

Make MCP regressions fail before merge.

The public scan proves the surface. The GitHub Action turns it into a gate for every pull request, package update, and client drift event.

See pricing Read CI docs 
name: throne
on: [pull_request]

jobs:
  mcp-verdict:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: usethrone/throne-ci@v1
        with:
          target: ./mcp.config.json

enterprise governance

The allowlist for agent tools needs evidence behind it.

Security teams can approve MCP servers by record, not reputation: what ran, what failed, what was scanned, and what changed since the last release.

Talk to sales
allowfit to ship / security clean
reviewneeds key / medium finding
blockclient failure / high finding
auditscan id / sealed hash / raw traces