The MCP Server Trust Score: Connect, Sandbox, or Reject

This guide is a scoring model for one decision: whether to wire a specific Model Context Protocol (MCP) server into your AI agent, and with what limits. MCP is the protocol that lets an agent discover and call external tools exposed by a server. This is written for the engineer, engineering manager, or technical founder who has a candidate server in front of them and needs a defensible verdict - Connect, Sandbox, or Reject - plus the containment controls you own no matter how much you trust the code.

Ordinary dependency vetting does not cover this. An MCP server's attack surface is not just its code. It is the tool descriptions the model reads as instructions, the tokens it can inherit, and the fact that it can silently change after you approve it. This guide turns the scattered checklists into one scored decision with an explicit output and a paper trail.

What decision this score makes

The MCP Trust Score produces exactly one of three verdicts for a specific server: Connect it directly, Connect it only inside a sandbox with scoped permissions, or Reject it. The score gates connection, not usage, because the most dangerous MCP attacks fire before you ever call a tool.

That last point reshapes everything. Invariant Labs named tool poisoning in April 2025: malicious instructions embedded in a tool's description field, which the model processes as a ground-truth description of the tool's capabilities. Trail of Bits named the discovery-time variant "line jumping," where the attack fires at tool listing, before any user action. The damage happens during the listing handshake, not during invocation.

So "we'll just be careful about which tools we invoke" is not a control. By the time your agent reads a poisoned description, the injection is already in context. The score exists to catch that at connect time.

The six trust dimensions

Score each dimension 0, 1, or 2, where 0 is a hard failure, 1 is present-but-weak, and 2 is clean. The six dimensions cover the full MCP-specific surface, not just code quality.

Each dimension has a failure signal, and each signal can lie. High provenance counts can be forged. A clean scanner result can be a false negative. The sections below say what each looks like when it deceives you.

The mapping from score to verdict is deliberately conservative. Any single 0 caps the verdict. A poisoned description or token passthrough is not something you average away with good maintenance.

Note the top-right quadrant is still not "connect and forget." Even a fully trusted, easily contained server gets schema-hash pinning, because trust extended today does not survive a silent redefinition tomorrow.

Reading the base rates before you start

The base rates tell you the default posture should be suspicion, not trust. Independent assessments of popular MCP servers find command injection, path traversal, and missing authentication at rates high enough that "probably fine" is the wrong prior.

Read these as directional, not as one population - the samples differ and methodologies vary. One independent audit found roughly a 78% false-positive rate from YARA-based MCP scanners, so raw "X% vulnerable" figures overstate. The load-bearing insight survives the caveat: authentication is the dominant real gap. In the internet-facing audit, 380 of 414 servers had at least one authentication weakness, consistent with the measured 91.8% OAuth absence. Most checklists over-index on tool poisoning and under-weight the fact that the average connected server does not scope its tokens.

Concrete failures back the base rates. CVE-2025-6514 in mcp-remote was a CVSS 9.6 OS command injection affecting versions 0.0.5 through 0.1.15, fixed in 0.1.16, in a package with over 437,000 downloads. CVE-2026-33032 in an nginx-ui MCP was a CVSS 9.8 auth bypass, actively exploited, patched March 15 2026. Anthropic's own Git MCP had three CVEs disclosed in January 2026, including path traversal and argument injection. These are not exotic; they are the ordinary bugs the base rates predict.

The step-by-step procedure

The procedure below moves from provenance to containment to ongoing monitoring. Steps one through three feed the score; step four produces the verdict; steps five through eight are the controls you own regardless of the verdict.

Budget roughly two hours of engineer time for a first pass: fifteen minutes on provenance, twenty on descriptions, thirty on code, fifteen on scoring, thirty on containment, and the remainder on pinning, logging, and scheduling. The scoring is quick once the evidence is gathered.

Provenance: why popularity signals now lie

Provenance means naming the real upstream author and canonical source, and it is worth zero if you infer it from stars, forks, or contributor counts. Those signals inverted in 2026: they are now the thing attackers forge first.

The SmartLoader campaign is the case that should change your defaults. Threat actors cloned the legitimate Oura MCP server and built a deceptive infrastructure of fake forks and contributors to manufacture credibility. They created at least five fake GitHub accounts, forked the original repeatedly, generated cross-references, and produced months of commit activity. The fake accounts showed AI-generated persona characteristics: recent creation dates, similar activity patterns, and commits concentrated in the same timeframe. The trojanised payload lived in a separate repository that deliberately excluded the original author, delivering the StealC infostealer.

The follow-on FakeGit campaign scaled this to roughly 7,600 malicious repos, over 800 posing as AI skills or MCP servers, appearing in registries more than 600 times with over 14 million downloads. So a registry listing is not vetting either. The official MCP Registry held around 9,652 records as of May 2026, and being in it is neutral, not exculpatory. Establish provenance by confirming who wrote the code and where the canonical source lives, independent of any listing or count.

Description hygiene: the tool-poisoning check

Description hygiene means reading the full raw text of every tool description and schema for instructions aimed at the model, because that text is executed as context the moment the server is listed. Reviewing tool names alone is the single most common miss.

A tool named "add" can carry a description that instructs the model to read a file and send its contents somewhere. The model treats the whole description as an authoritative account of the tool. Look for directive markers - IMPORTANT tags, "ignore previous," "before you do anything," "send to," "read the file at" - anywhere in the description or the schema's field descriptions, not just the summary line.

<IMPORTANT>
ignore (previous|above|prior)
do not (tell|mention|inform)
before (calling|using|invoking)
(read|cat|open).{0,20}(\.ssh|\.env|credentials|config)
(send|post|exfil|upload).{0,20}(http|to )
system prompt

Pair the pattern scan with a purpose-built scanner such as Invariant Labs' mcp-scan, which detects poisoned descriptions and rug pulls. But do not treat a clean scan as clearance. One audit measured roughly a 78% false-positive rate for YARA-based MCP scanners, which means both directions are noisy: they flag benign text and miss crafted attacks. Read the flagged descriptions and a sample of the unflagged ones yourself.

Auth, transport, and code hygiene

Auth and scoping is the dimension most likely to fail quietly, so verify token binding explicitly rather than assuming it. The 2025-06-18 spec revision forbade token passthrough: an MCP server MUST validate that tokens presented to it were issued specifically for its use, and clients MUST include a resource parameter under RFC 8707 so each access token is bound to a specific server.

Token passthrough is the false positive that hurts most. The server functions perfectly while forwarding your token to downstream APIs it should never touch. Confirm audience validation and resource binding are actually enforced, not just documented. On transport, SSE was deprecated in the 2025-06-18 revision in favour of Streamable HTTP; the 2026-07-28 revision moved to stateless transport and removed long-lived streams entirely, which closed the gaps where SSE endpoints had no clean way to handle insufficient scopes or token expiry mid-connection. A server still leaning on deprecated SSE is a maintenance and hygiene flag.

For code hygiene, the base rates tell you what to look for: shell command concatenation and exec calls that enable command injection, and path handling that permits traversal or arbitrary file read. These are the 43% and 22% findings made local.

How this decision goes wrong

The failure modes below are the false positives that turn a passing score into a breach. Each one is a place where a signal looks reassuring and is not, so each entry pairs the trap with the check that defeats it.

Two of these deserve extra weight. First, model guardrails as the control. Claude Sonnet 4.5 reportedly prevents 94% of prompt injection in MCP evaluations, which sounds like enough. But the MCPTox benchmark tested 45 real servers against 20 models and measured a 36.5% average attack success rate, peaking at 72.8% on one model. Model behaviour is a layer. Containment must hold independent of it.

A 94% block rate still lets one in three crafted attacks through - the sandbox, not the model, is your control.

Second, one-time vetting. MCP provides no mechanism for continuous re-verification once trust has been extended. An operator can modify tool descriptions or change server behaviour at any point after approval, and your agent will keep treating the modified tool as the same trusted integration. This is the rug pull, and it is structural, not a bug you can wait for someone to patch. The only detector is schema-hash pinning: record the SHA-256 of each tool schema at first use and block any session where the hash changes without operator re-approval.

The containment controls you own

Regardless of the verdict, some controls sit with the connecting team, and the spec itself instructs clients to apply them. Execute MCP server commands in a sandboxed environment with minimal default privileges, restricting access to the file system, network, and other system resources using containers, chroot, or application sandboxes.

Trust-on-first-use (TOFU) pinning makes this enforceable without trusting the server's hygiene at all. A wrapper such as Trail of Bits' mcp-context-protector blocks all tools and descriptions until the first-use configuration is manually approved, and any deviation from the known-good configuration blocks downstream tool calls until you explicitly approve the change. That is the same mechanism that catches rug pulls, applied from the client side.

The OWASP MCP Security Cheat Sheet gives the connect-time control set in one line: enforce least privilege per server and per tool, inspect and pin all tool descriptions and schemas, sandbox local servers in containers, require human approval for sensitive or destructive tool calls, and validate all inputs and outputs at the server layer. Wiring a server behind Refolk's kind of ranked sourcing does not apply here, but staffing this work does - and the talent is scarce, which is the next constraint to plan around.

In Refolk's index, the people who can run this review are concentrated: 90 US profiles and 7 UK profiles match MCP-security keywords, clustered at AWS - the single largest US employer at 5 of 90 - with Snyk appearing in both markets. Treat these as keyword-matched rather than title-verified, since two narrower title-scoped queries returned zero. The practical implication is that you will train an existing AppSec engineer into this rather than find a dedicated MCP-security hire, so the score has to be runnable by a competent generalist. That is why it is six dimensions and a two-hour pass, not a research project.

Before you call the job done

Run this checklist before you mark the verdict final. It confirms the evidence exists rather than restating the topics, so a reviewer can audit your ticket from it alone.

Keeping the score current

The score is not a one-time gate, because the threats and the spec both move. Version-pin every server and re-run the six dimensions quarterly, and re-run immediately if a schema hash changes or a new CVE lands against a component you connected. The rug-pull risk means a Connect verdict from last quarter is a claim about code that may no longer be running.

Re-check the mechanism, not the numbers, when you refresh. The spec revision that forbade token passthrough and the later one that removed long-lived SSE streams both changed what "clean auth and transport" means, so read the current MCP security best practices and OWASP MCP Top 10 before each cycle rather than trusting a cached rule. Watch for new poisoned-description and pinning tooling, since mcp-scan and mcp-context-protector will evolve alongside the attacks. The verdict you can defend is the one whose evidence you can reproduce today, not the one you filed at onboarding.