The MCP Server Admission Standard: Connect, Sandbox-Only, or Reject

This standard is for the engineer or platform lead who has been asked to approve a third-party MCP server for the team's coding or ops agents. Every reviewer follows the same trace (registry record, then artifact, then repo, then named humans), scores tools against purpose the same way, and picks from the same three verdicts: Connect, Sandbox-Only, or Reject. Each approval is tied to a hashed tool-definition baseline, so any later change forces a re-review instead of going unnoticed.

What does this standard decide, and why is a tool server not an ordinary dependency?

The standard gives a third-party MCP server one of three verdicts: Connect, Sandbox-Only, or Reject. It exists because a tool server carries three risks that a one-time library approval was never built to handle.

An MCP server is a local process or remote endpoint that exposes tools an AI agent can call through the Model Context Protocol. A tool definition is what the server returns for each tool when the agent calls tools/list: the name, title, description, inputSchema, outputSchema, and annotations such as readOnlyHint and destructiveHint.

Three things make admitting a tool server different from adopting a dependency:

• It runs with the agent's credentials. The server can reach every environment variable, file, and network destination the agent can reach. Its blast radius is the agent's, not the package's.
• Its tool descriptions are prompt surface. The model reads every description and may act on it. Tool poisoning means hiding instructions to the model inside a tool definition. It needs no code exploit.
• It can change after approval. A rug pull is a server that changes its tools or behaviour after it was approved. A remote server can do this without a new release. A local server does it by shipping a new version.

This standard covers admission only. Runtime monitoring belongs to a different control. The hash baseline at the end of the procedure is what connects the two.

What does the official MCP registry verify, and what does it not?

When a server is published, the official MCP registry checks two things: that the publisher controls the namespace, and that the package declares the server name it is published under. It does not inspect code, and it does not check that the listed repository belongs to the publisher.

Publishers prove namespace ownership with a GitHub, DNS, or HTTP challenge. An io.github.* namespace proves control of a GitHub account. A domain namespace proves control of a domain. How the package proves it belongs to that name depends on the package type:

Everything beyond those two checks is the reviewer's job. The registry's own documentation says it relies on the broader ecosystem to scan server code. The biggest gap is the repository field: repository.url is not verified against the authenticated identity, and the documentation calls it documentation, not proof. The registry API has also accepted entries whose repository is an empty object. Finally, mcp-publisher validate checks the schema only, not the ownership checks that publish runs. A record that validates tells you nothing about who owns it.

One practitioner pulled every record and counted how often the repository field disagrees with the publisher:

This table is a snapshot from one person's count, and the percentages are derived from that count. To check it yourself, pull the records from the registry API and compare the owner of each repository.url with the namespace login. Some mismatches have innocent explanations, such as forks or organisation transfers. That is why this standard requires the explanation in writing rather than an automatic reject.

Who is behind the server: tracing named humans and the vendor

A server can only be admitted when the trace ends at named people or a company whose history you have actually read. If the server wraps a vendor's service, the trace must also end at that vendor's own channels, because an impostor's account history can look perfectly legitimate.

The first documented malicious MCP server shows why. postmark-mcp was an npm package named after the Postmark email service. Versions 1.0.0 through 1.0.15 were clean. Version 1.0.16 added a hidden BCC that copied outgoing mail to giftshop[.]club, and later versions up to 1.0.18 kept it. The package had 1,643 downloads, and public warnings appeared 8 days after the malicious release. Its publisher appeared to be a legitimate software engineer from Paris with an established GitHub profile.

A maintainer-history check would have passed that publisher, and reading the code of the first fifteen versions would have passed every one of them. The check that fails it is the vendor check. Postmark has stated it never published a postmark-mcp library on npm, and the real server lived in the ActiveCampaign/postmark-mcp repository.

Code review would have passed fifteen releases. Asking whether the vendor publishes it would have failed the first.

What to read in maintainer history

Treat a change in who publishes as a hard signal. A new npm or PyPI publisher account, or a transfer of repo ownership, puts the server back into review no matter how long its history is.

The slow part of this step is getting from a GitHub login to a named person with an employer and a record you can check. Refolk does that lookup from a single plain-English question across GitHub, LinkedIn, and the open web. It returns the people along with the profiles and repo activity that connect them to the server.

Finding someone qualified to review

Do not expect to find this specialism by its label. In Refolk's index of professional profiles, the headline phrase "MCP server Model Context Protocol" matches very few people:

These counts show how few people describe themselves this way. They do not measure the size of the market, and a long-phrase headline match is very restrictive. The three US matches held the titles ".Net Solutions Architect" and "Senior Software Engineer", and one worked at Sandia National Laboratories. My reading is that the specialism has no settled label yet, so reviewers will turn up under adjacent titles. Search by activity rather than by title: people who have filed issues on the OWASP MCP material or worked on the registry's publisher validation. In Refolk, that is a single question about contributions, with no title guessing.

What are the verdict criteria for Connect, Sandbox-Only, or Reject?

Score the server on seven criteria. The verdict is the worst cell across all of them. Any single Reject cell rejects the server, and any Sandbox-Only cell caps it at Sandbox-Only.

Scoring capabilities against the stated purpose

Write the server's purpose in one sentence before you look at anything it requests. Then list three things and mark each item justified or flagged:

• Environment variables. Does the purpose need this secret? A server that sends email needs the email provider's key. It does not need cloud keys, the SSH agent, or the full environment.
• Filesystem access. Which paths does it read or write, and does the purpose require them?
• Network egress. Which domains does it contact? Any domain outside the service it integrates with needs an explicit reason.

Then read every tool description as though it were a prompt, because to the model it is one. A description should say what the tool does. Text that tells the model what to do (read other files, call other tools, hide output) is tool poisoning, and it is a Reject.

This scoring has a limit. postmark-mcp's BCC lived inside the function body, and its tool surface never changed. Reading tool definitions does not replace scanning the pinned code. That is why the provenance row allows a server without an attestation to reach Connect only once its pinned code has been scanned.

Why there is no percentage threshold

The published scans disagree too much to set a threshold, and none of them measures the two behaviours this standard cares about most.

Each study uses a different method, so the rates cannot be compared directly. No published scan isolates how many servers read broad secrets or send data to domains outside the service they integrate with. That is why the criteria above are written per server, not as percentiles. Popularity does not stand in for safety either: CVE-2025-6514 (CVSS 9.6) in mcp-remote affected a package with more than 437,000 downloads.

Where the OWASP MCP Top 10 fits

The OWASP MCP Top 10 is still a draft. Its project page puts it in a beta and pilot-testing phase, and its repository marks the document v0.1. Check the project page for the current status before you cite it in policy. The mapping below is my own derivation, not OWASP's:

MCP06, MCP08, and MCP10 mostly show up at runtime, so they fall outside admission.

The admission procedure, step by step

Run the eight steps in order and write each result into the decision record as you go. If a step fails, keep going anyway. The record is more useful when the reviewer can see every cell, not just the first failure.

Provenance tools check less than their names suggest

On npm, packages published through trusted publishing get provenance attestations automatically. But npm install never verifies attestations, and npm audit signatures checks the certificate chain and digest without checking who signed. So read the attested repository yourself and compare it with step 3. On PyPI, pypi-attestations verify pypi --repository checks whether that repository's Trusted Publisher signed the package. There is no public figure for how many MCP server packages carry attestations, so a missing attestation is not proof of anything bad. It just sends the server down the code-scan path.

Remote servers: what you can and cannot establish

The specification says servers must check that access tokens were issued for them specifically as the audience, and it forbids token passthrough. Newer revisions of the authorization spec make OAuth 2.0 Protected Resource Metadata (RFC 9728) mandatory, so check which revision the server declares. Authorization as a whole is still optional, which means a server can legally be reachable with no authentication at all.

What you cannot establish from public sources is who actually operates an endpoint, or how revocation works. No documented procedure for either exists. There are partial signals: a domain namespace passed a DNS or HTTP challenge, and the registry ties a remote URL to exactly one server name. Record those, and record that operator identity is unconfirmed.

SERVER (registry name):
NAMESPACE + challenge type (GitHub / DNS / HTTP):
PACKAGES (type, name, pinned version or image digest):
REMOTE ENDPOINTS (if any):
repository.url:
OWNERSHIP MARKER FOUND (mcpName / mcp-name / OCI annotation / fileSha256):
ARTIFACT PUBLISHER ACCOUNT:
REPO OWNER (from GitHub API):
IDENTITY CHAIN: AGREES / MISMATCH EXPLAINED / MISMATCH UNEXPLAINED
  Explanation:
VENDOR CHECK: listed by vendor / labelled unofficial / vendor disowns / not applicable
PROVENANCE: attestation names ____ / no attestation / names other repo
  Signing workflow identity:
  Code scan of pinned version (if no attestation): done by ____ / not done
NAMED HUMANS OR COMPANY:
  History notes (cadence, publisher changes, other packages):
PURPOSE (one sentence):
CAPABILITIES (item | justified or FLAG):
  env:
  filesystem:
  egress:
MODEL-DIRECTED TEXT IN DESCRIPTIONS: none / found (quote it)
REMOTE AUTH: no-token -> ___ | wrong-audience token -> ___ | PRM served Y/N
  Operator identity: confirmed / unconfirmed
DIGESTS (SHA-256 over canonicalized complete definition):
  <tool name>: <digest>
  whole tools/list: <digest>
VERDICT: CONNECT / SANDBOX-ONLY / REJECT
CRITERION THAT SET IT:
REVIEWERS (two):
RE-REVIEW TRIGGERS: any digest change, any new release, publisher or repo owner change, endpoint change or disappearance

How the hash baseline triggers re-review

An approval is attached to a set of digests, not to a server name. Those digests are one SHA-256 per tool over its complete canonicalized definition, one over the whole tools/list, and the pinned package version or image digest. If any of them changes, the approval no longer covers what is running.

The OWASP MCP Security Cheat Sheet says to hash the complete tool definition, including inputSchema, outputSchema, and annotations, not only the description. A more detailed procedure was proposed in OWASP CheatSheetSeries issue #2756: canonicalize with the RFC 8785 JSON Canonicalization Scheme, then hash with SHA-256, keeping one digest per tool keyed by tool name plus one over the whole list, recorded at approval and re-checked every session. I have not confirmed whether the canonicalization detail made it into the published cheat sheet. I adopt it anyway, because without canonicalization the same definition can hash differently just from key order.

Re-review is triggered by events, not by a calendar. Any of these sends the server back to step 1:

• Any per-tool or whole-list digest changes.
• A new package version is published, even if every tool digest still matches.
• The publisher account or repo owner changes.
• A remote endpoint changes domain, or disappears and comes back.
• tools/list adds or removes a tool.

There is a real disagreement about where to put the effort. OWASP's guidance starts with verifying the source. Focused Labs argues for binding each approved tool to a capability manifest and diffing live tool definitions against it, which makes runtime diffing the primary control. This standard does both, on purpose. The provenance trace is what catches impersonation before anything runs, and the digest diff is what catches change after approval. Neither one would have stopped postmark-mcp on its own: the trace catches the copycat, and only the artifact pin catches a code change hidden behind an unchanged tool surface.

How admission goes wrong: failure modes and false positives

Most failed admissions do not come from skipping a check. They come from a check that passed and proved less than the reviewer assumed. Each failure below is paired with the check that closes it.

1. The namespace check passes on a copycat. Looks like: a valid io.github namespace and a clean package. What it proves: only who controls the account. Check: the npm publisher, the repo owner, and the vendor's official channels must all agree. postmark-mcp fails here.
2. repository.url is taken as proof. Looks like: the record links to a respectable repo. What it proves: nothing, because the field is only checked for shape, and 498 records point at a repo owned by someone else. Check: the GitHub API owner equals the namespace login, or a fork relationship is documented.
3. A provenance attestation is treated as a safety verdict. Looks like: a green provenance badge. What it proves: where the package was built, not whether it is safe. Check: the attested repo matches step 3, and the code is still scanned.
4. Only the description is hashed. Looks like: a working pin that never fires. What it misses: a changed readOnlyHint, destructiveHint, or outputSchema passes untouched, which makes it the cheapest rug pull available. Check: hash name, title, description, both schemas, and annotations after canonicalization.
5. Definition pins are assumed to cover code. Looks like: digests match, so the reviewer moves on. What it misses: pinning tool definitions catches metadata changes, not hidden code changes. postmark-mcp's tool surface did not change at 1.0.16. Check: pin the package version or image digest as well.
6. A clean release history is trusted. Looks like: months of uneventful versions. What it misses: postmark-mcp had 15 clean versions before the backdoor. Check: every new release goes back into review, and versions are never left floating.
7. "Auth present" on a remote server is taken as enough. Looks like: the server returns 401 without a token. What it misses: some servers accept tokens minted for a different audience. Check: present a token issued for another resource and expect a 401.

False positives that should not trigger a Reject

• Repo owner mismatch caused by a fork or organisation transfer. Record the relationship and move on. Only an unexplained mismatch is a Reject.
• No attestation. Nobody has published how often MCP server packages carry attestations, so a missing one is not evidence of malice. It routes the server to a code scan.
• A remote server that disappears. In one study, 41.6% of previously confirmed live servers were gone three days later. A vanished endpoint is churn until shown otherwise, but it still triggers re-review when it comes back.
• A thin personal profile on a genuine community server. That caps the server at Sandbox-Only. It does not reject it, unless the server uses a vendor's name and the vendor disowns it.

Keeping the standard and the allowlist current

Keep an allowlist of admitted servers, each with its verdict, pins, and digests, and block everything else by default. A server not on the list is a shadow server, the risk OWASP's MCP09 names.

Three inputs to this standard change over time, so re-check them whenever you revise the policy, not on a fixed schedule:

• Registry behaviour. Find out whether repository.url is now verified against identity, and re-pull the records to see whether the mismatch count has moved.
• OWASP status. Check whether the MCP Top 10 has left draft and whether the cheat sheet now specifies canonicalization.
• Authorization spec revision. Confirm which revision your remote servers declare, and whether it makes Protected Resource Metadata mandatory.

When a reviewer leaves, the allowlist must still make sense. That is the test of whether the decision records are complete. If someone new cannot reproduce the verdict from the record alone, the record is missing a cell.