Before you install an MCP server, read its authority label

An engineer on your team has a clean demo: an internal coding agent, a chat box, and a small request to open a draft pull request that bumps a dependency. It works. So the next move is to point it at the real repos and add the official GitHub MCP server, the one published under @modelcontextprotocol that everyone treats as the reference implementation.

Installing it is a one-line change. Before approving it, someone on the call asks a different kind of question. Not "is this server trustworthy," which is a feeling. What can this server actually do once an agent can call it: write, mutate, spend, execute, send outbound? And what did it leave unspecified?

Nobody can answer from the README. They can list the tools, create_pull_request, create_issue, push_files, fork_repository, and that list is a menu of what the server offers. It says nothing about the authority you would be handing over.

A tool list is not an authority label

This is the gap Capframe is built around. Capframe describes itself as capability security for AI agents: it maps every tool an agent can reach, issues scoped revocable tokens for the calls it allows, and decides each call against policy with no model sitting in the decision path. The interesting part for anyone evaluating servers is not the runtime enforcement. It is the inventory step, because the inventory keeps surfacing the same thing. The list of tools a server exposes and the authority those tools carry are two different documents, and most servers only ship the first one.

To make the gap visible, Capframe published a leaderboard. As of its June 28, 2026 run it had scanned 90 MCP servers with an open scanner (mcp-recon v0.2.0) against an open findings schema. The scoring is deliberately boring: 100 is a clean surface, and findings subtract points by severity (critical 10, high 4, medium 2, low 1). The formula is public, the rules are open source, and there are no black boxes. You can argue with the weights. You cannot accuse it of hiding them.

The score that got attention belongs to the server in our install scene.

The 16/100 that is not a bug report

Capframe scored the official GitHub MCP server 16 out of 100, then spent a whole post on what that number is not: not a vulnerability, not a CVE, not an exploit. GitHub's server is not compromised, and nothing here calls it broken.

Here is what the scan actually did. It pulled @modelcontextprotocol/server-github@2025.4.8 into a node:20 container, connected over stdio, initialized, called tools/list, and classified the tools the server reported about itself. Thirty-four findings came back: zero critical, eight high, twenty-six medium. The twenty-six medium findings were one rule firing repeatedly. The eight high findings were a single, specific mismatch.

That mismatch is the whole story. The rule, R3, flags a tool whose name clearly implies it changes state while its schema declares no side effects. The eight tools that tripped it read like a list of consequential verbs: create_pull_request, create_repository, create_or_update_file, create_issue, update_issue, push_files, create_branch, fork_repository. Every one of them writes. None of them carries a machine-readable declaration that says so. A policy layer reading the schema sees an argument list and an absence where the authority should be.

Capframe's reading is that this points at the protocol's vocabulary, not at GitHub being uniquely careless. Current MCP schemas are good at listing arguments and poor at declaring authority in a form a policy layer can reason about. create_repository and a read-only search_issues arrive in the same shape, with the same silence about consequence. The score is low because the surface is large and the writes are unlabeled, not because the server misbehaves. It is a missing-label problem wearing the costume of a vulnerability scan.

That reframing is the useful part. If the issue is a missing label, the fix is not to distrust the server. The fix is to write the label down before you install it.

What an MCP authority label holds

A nutrition label did not make food safer by itself. It made one thing legible at the point of decision, so you could compare two boxes without a lab. An MCP authority label does the same job for a tool server, and it is a one-page artifact, not a program. You fill it out before the server reaches an agent. The fields:

• Server identity and version. The exact package and pinned version, the way Capframe scanned 2025.4.8 and not "latest." Authority changes between releases.
• Verbs. The tools, named. This is the part you already have.
• Write and mutate actions. Of those verbs, which ones change state in a system you care about. For the GitHub server, the eight R3 tools go here, plainly marked as writes.
• Declared side effects. What the schema actually says happens. When the answer is "nothing declared" next to a verb named create_, that blank is the finding.
• Spend and quantity bounds. Anything that can cost money or run away. A tool storm against a paid API is a budget event before it is a security event.
• Filesystem and network egress. What the server can read off disk and what it can send outbound. This is where a tool stops being a tool and becomes an exfiltration path.
• Credential scope. Which token the server holds and what that token can reach. A repo-scoped token and an org-admin token wear the same server name.
• Evidence trail. Whether calls leave a receipt you can read later. No forensic trail is one of the four failure modes Capframe names, alongside indirect prompt injection, runaway tool storms, and unbounded tool surface.
• Owner and review date. A human who owns this label and the date it was last looked at. The same field that goes stale on every wiki, here too.

Filled out, the label changes the install conversation from a feeling to a comparison. The GitHub server's label would show eight unlabeled writes, an org-or-repo credential depending on how you mint the token, and real egress. That is not a verdict so much as a basis for one: enough to decide whether this server goes behind an approval gate, gets a tighter token, or wires straight to production. Which is the decision you were quietly making anyway, now made in the open.

Why the powerful servers score low (and that is the point)

The leaderboard reads like a teaching artifact once you stop treating the number as a grade. In Capframe's broader scan of 84 servers, each run in an ephemeral sandbox or handshaked live and scored on its real tools/list output, the pattern is almost mechanical. Read-only documentation servers score in the 90s. Servers that scrape, automate, or execute code score from the 40s down into single digits. The line worth keeping is theirs: tool surface is attack surface. A server scores high mostly by doing less.

Which means the score cuts both ways, and Capframe says so. A high number is not a clean bill of health. It mostly means a smaller surface, and critical findings on the powerful servers still need a human to confirm them. A read-only docs server is not virtuous; it is just holding fewer verbs. The 16 is not a warning to avoid GitHub's server. It is a measurement of how much capability you are taking on, and capability is exactly the thing you wanted. You install the powerful server on purpose. The label is how you do it with your eyes open instead of closed.

This is also why the label belongs at install time and not later. There is a real cost to running MCP servers at all, the token overhead of loading every tool definition into context before the agent does anything, and that surface compounds with every server you add. Reading authority before install is the cheapest place to ask the question. Once an agent is calling the server in production, you are no longer reading a label. You are reaching for an external control point or a separate browser profile to put a boundary back around something already wired in.

None of this requires Capframe specifically. The leaderboard and the GitHub post are just the public artifacts that make an invisible thing visible: the verbs were always there, and the authority was always real, and the only thing missing was the line that wrote it down. Capframe's own open-source repo, MIT-licensed and built around find, bind, and guard, is one way to generate that line. A worksheet and a person who owns the answer is another. The format matters less than the habit.

Back to the engineer with the clean demo. The pull request to install the server is still one line. The thing that should sit next to it is a second document that names what the server can write, spend, execute, and send out, signed by someone who will own that answer in three months. If you can produce that page, install it. If you cannot, you do not yet know what you are installing.

Do not install the server until the verbs have a label. Bring us the one MCP server you are most nervous about, the one about to touch GitHub, a customer system, an internal tool, or a paid API, and we will map its authority label with you: verbs, write actions, declared side effects, spend bounds, egress, and credential scope, on one page, before it reaches an agent. Map one authority label.