Pre-Connection MCP Server Vetting Checklists and Scoring Rubrics

Third-party MCP server risk scoring starts before connection, with checks on publisher identity, permissions, authentication, dependencies, and governance fit. A registry listing is not security approval. To guard against rug pulls, teams must approve a pinned version, review every upgrade, and enforce that decision at runtime before an agent makes a call.

Why the MCP protocol cannot be the last line of defense

A listing in the official MCP Registry can look like a safety signal, but its published moderation policy says consumers should assume minimal-to-no moderation. The registry verifies that publishers own the names they publish under. It removes illegal content, malware, spam, and servers that do not work. However, it explicitly does not remove servers simply because they have known vulnerabilities. A listed server can therefore meet the registry’s rules and still be unsuitable for production.

The MCP specification explicitly leaves security enforcement outside the protocol, reflecting its origins in local and trusted-network use, where the original specification made authentication and authorization optional. The specification has since added an OAuth 2.1 authorization framework for HTTP-based servers, but the organization that connects still has to decide which servers to trust. Tools for centralized control and audit, including MCP Manager, can enforce that decision as a policy so it no longer rests on an informal assumption. The organization needs this governance layer because support for the protocol and ownership of a namespace do not show that a server has had a security review.

What actually goes wrong when servers are not vetted before connection

The failures fall into four connected classes, namely tool poisoning, rug pulls, supply-chain compromise, and indirect prompt injection. Tool poisoning hides instructions in the descriptions that the model reads to learn how to use a tool. A rug pull changes a server after approval, exploiting the fact that most hosts reload tool descriptions without asking the user for consent again. These attacks require different checks, with description review addressing the first and version-specific approval addressing the second.

Invariant Labs’ GitHub MCP demonstration showed how a malicious public issue could cause an agent to copy private repository data into a public pull request. The SANDWORM_MODE campaign in February 2026 combined malicious npm packages with tool descriptions that instructed the model to read SSH keys, AWS credentials, npm tokens, and environment secrets without telling the user. The practical limit on the damage depended on what the server could reach, which credentials it held, and how the model responded.

Why an informal gut-check fails at enterprise scale

Anthropic’s count of more than 10,000 public MCP servers shows the size of the field organizations must evaluate. Servers reach developers through documentation, conference demos, repository READMEs, and internal Slack posts, often outside established software procurement paths. Without a registry entry or governance record, each server added has an identity the organization cannot account for. Individual judgment cannot make those decisions consistent, and a one-time review cannot cover later changes. A scoring rubric makes the criteria explicit and produces a record that another reviewer can apply to the next version.

Domain 1: Publisher identity and provenance

Publisher identity is the first gate because the rest of the review needs a known party to assess. Verify that the GitHub organization or package registry publisher belongs to the vendor whose product the server claims to wrap. The official MCP Registry’s namespace checks establish a narrower fact. Names under io.github.<user>/ require signing in to that GitHub account, while domain-based names require a DNS record or a file on that domain. Neither proves that a publisher represents the vendor suggested by a package name.

The postmark-mcp incident shows why that distinction matters. The malicious package copied an official Postmark Labs library name, but a publisher-match check would have flagged that the npm organization did not belong to Postmark Labs. A community wrapper may be legitimate, yet its users are trusting the wrapper developer’s code with their credentials. Examine commit history, contributor patterns, unusual recent activity, and modules containing obfuscation, encoded payloads, or suspicious imports. Smithery’s MCP-Scan results, shown on server pages since April 2025, and Glama’s license, quality, and maintenance grades can help build a shortlist, but cannot replace this review. An unverifiable publisher fails the gate regardless of other scores.

Domain 2: Tool surface and permission scope

Once the publisher is known, read every tool description before the model does. The core test is whether the requested access matches the stated purpose. A documentation MCP should not need filesystem access, a weather MCP should not run shell commands, and a read-only search tool should not change data. These distinctions separate the work a tool needs to do from the damage it could do with unnecessary permissions.

A clean description explains the tool’s capabilities, its parameters, and its return values. It has no model-directed commands, references to tools or files that have nothing to do with its purpose, hidden Unicode, or instructions to hide output from the user. SANDWORM_MODE used three harmless-sounding names, including index_project, lint_check, and scan_dependencies, while embedding prompt injection in their descriptions. A description audit would have exposed the mismatch between the advertised function and the instructions. Score access beyond the documented purpose or model-directed instructions as critical findings, and check new versions for added tools or permissions before upgrading.

Domain 3: Authentication model and credential handling

Permission review establishes what a server may do, while authentication review establishes whose authority it can use. The MCP authorization specification builds on OAuth 2.1. The server acts as an OAuth resource server, advertises its authorization server through protected resource metadata, and validates that each access token’s audience is that specific server. It must not accept tokens issued for other services, a shortcut called token passthrough. It must also not treat a session ID as authentication.

CVE-2025-49596 in Anthropic’s MCP Inspector shows the cost of a no-auth default. The vulnerability carried a CVSS 9.4 score, and missing authentication could be chained with a browser flaw and CSRF to run code on a user’s machine after a visit to a malicious website. The review should therefore check how authentication works on the deployed server as well as whether the server claims protocol support. Prefer official remote MCP servers that authenticate through OAuth rather than requiring locally stored, long-lived API tokens. If a local server needs a token, verify minimum permissions and storage in a secrets manager. No authentication, token passthrough, session-ID authentication, and long-lived tokens in config files each warrant a critical finding.

Domain 4: Supply chain integrity and dependency scanning

Even with a clean top-level repository, the review must cover dependencies because they share the trust placed in the server. Typosquats and impersonated packages need their own checks because a name that looks familiar does not prove where a package came from. OX Security’s August 2026 debrief showed how the official MCP Registry was used to distribute V.A.P.E., a listed server advertised as a cryptocurrency chain security tool.

Pin an exact version in place of the latest release, and put each addition to the organization’s allowlist through security review. Unpinned versions, unscanned dependencies, and dependencies flagged as typosquats or impersonations each count as critical findings. However, dependency scans do not cover every infrastructure risk. GitGuardian found a June 2025 path traversal flaw in Smithery’s deployment platform that could expose Docker authentication credentials in .docker/config.json, granting control over more than 3,000 hosted applications, with potential API key interception through network traffic. The flaw was fixed within days, and no evidence of exploitation was found.

Domain 5: Governance fit — data boundaries, logging, and organizational policy

Technical approval does not establish that a server fits a particular deployment. A server can pass the earlier checks and still break the rules for data residency, audit, or access policy. The decisive data-boundary question is whether an agent can combine private data, untrusted input, and a channel for sending data out. No single agent should have all three capabilities at the same time. This check examines the arrangement around the server.

That arrangement also needs visibility and a named owner. Record every tool call with enough detail to reconstruct what the agent accessed, and document the approving AppSec or platform reviewer, approved version, and review date. The approval must explicitly specify which agents or users may invoke which tools. Real-time access monitoring, which MCP Manager provides, can help teams stop unauthorized access before data is exposed, so they have more than a post-incident audit to rely on. Governance belongs in the operating infrastructure because a written permission boundary has little value if nothing enforces it.

What tools exist to vet and score MCP servers before connection

Published rubrics offer different ways to turn these checks into a verdict. MCP Grade’s 2026 framework awards 100 points across six enterprise readiness categories. Authentication and schema quality carry 25 points each because secure deployment for multiple users requires both. A critically low score signals that the server is not ready for enterprise deployment without a complete security wrapper.

Blue Headline Benchmark’s 2026 model uses 50 points across five equally weighted pillars, namely Identity & Auth, Permission Scope, Prompt Defense, Data Boundary, and Observability. Scores of 41–50 are production-ready with mature controls, while 31–40 are deployable with guardrails. Scores of 21–30 are pilot-only, and 0–20 are high-risk and should not touch sensitive systems. These models make the outcome legible, but their totals express different criteria and should not be treated as interchangeable.

It covers source review, maintainer identity, dependency scans, minimized permissions, network behavior, secrets, logging, sandbox tests, and AppSec approval. Those binary gates work for pass/fail approval, while weighted models help teams compare candidates. A good total score should not hide an identity failure or a critical access finding. Scoring and enforcement also serve different jobs, so governance tools such as MCP Manager complement a rubric and its evidence.

Building a repeatable pre-connection workflow that produces an auditable record

The workflow should follow the five domains in order, moving from provenance to tool surface, authentication, dependencies, and governance fit. The reviewer then records the score and documents approval or rejection. Each approved inventory entry should contain the server name, pinned version, approver, permitted agents or users, permitted tools, and review date. Another team member can then repeat the same review without reconstructing the original reviewer’s assumptions.

For rug-pull protection, that record must govern what can connect after approval. Treat every upgrade as a new vetting event, compare its tools and permissions with the approved version, and maintain an allowlist that the workflow updates and the runtime enforces. A gateway enforcing that allowlist at the connection layer prevents unapproved servers from connecting and flags version drift before a call. MCP Manager’s centralized registry and access-policy engine provide one way to keep those decisions enforced after an update. The rubric gives teams a defensible basis for saying yes to production with controls in place.