MCP Security Intake Sheet: Eight Questions Before a Third-Party Server

Pick any MCP server running in your company today. Can you name who approved it, which exact build is installed, and what it can reach on the network? If the answer takes more than a minute, the approval was a click, not a decision.

This page gives you eight questions to ask before a third-party MCP server touches company data. Each answer earns 0, 1 or 2 points, for a top score of 16. Answer for a server that runs in production, or that will within a month. Give 2 points only when an artefact backs the answer: a config line, a log, a ticket, a vendor reply in writing. The checks follow the protocol project's own security best practices page, which tracks the 2026-07-28 revision of the specification. Wording and details move between revisions, so reread the current page before you rely on a specific rule.

The eight-question intake sheet

Ask	Score 0	Score 1	Score 2
A. Where does it execute, and what is the literal launch command?	Nobody looked	Local or remote is known, command unread	Full command, arguments included, stored on the request
B. Who publishes it, and which exact build did you review?	Unknown author, moving tag	Known author, tag still moves	Author and immutable version or digest recorded
C. Did anyone read the code or inspect the traffic, rather than trust its popularity?	Stars and badges were the evidence	Skimmed the readme	A named reviewer read the code paths that touch data, notes attached
D. Does it require authentication, and does it reject tokens minted for another service?	No auth, or no answer	Auth exists, token checks unknown	Vendor states audience validation in writing
E. Which scopes does it ask for, and does it start small?	Wildcard or full catalogue	Trimmed, still broad	Baseline scope only, step-up per operation
F. If it fronts another API, does it get consent per client and match redirect URIs exactly?	No answer	Partial answer	Documented, or confirmed by the vendor
G. Can it call arbitrary URLs from where it runs?	Open outbound access	Blocked on some hosts	Default-deny egress, with a test that proves it
H. Does it have an owner, call logs, and a written removal step?	None of the three	One or two	All three, removal rehearsed once

Reading your total

• 0 to 5, approved by reflex. Pause the rollout. You cannot yet say what the server runs or whom it trusts.
• 6 to 11, partly checked. You have caught the obvious items. The usual holes are token handling (D) and outbound reach (G).
• 12 to 16, checked with evidence. You hold a record that an incident responder or an auditor can use.

The bands are an editorial convention. The MCP project publishes no scoring scheme, so do not cite them as a standard.

Cheapest fixes, by band

Low band

1. Copy the launch command into the ticket. The specification requires a client that offers one-click local setup to show the exact command, untruncated, and to get explicit approval, as the best practices page sets out.
2. Replace any floating tag with an immutable version or digest, so the code you read is the code that runs.
3. Run the server in a container with no home directory mount and no credentials beyond its own.

Middle band

1. Ask the vendor how the server validates the audience of each token. Record the reply verbatim.
2. Cut scopes to a read-only baseline and let write scopes arrive through step-up challenges.
3. Put the server behind an egress proxy that refuses private and metadata addresses.

High band

1. Schedule a re-score for every new release, since a new build voids the review of the old one.
2. Tie log entries to the server name and the identity used, then alert on first use of a new tool.
3. Rehearse removal in a test tenant, including revoking every credential the server held.

For the identity side of D and E, see the token audience and confused deputy article. For pinning and signing, read the supply chain pinning guide.

What the evidence says about each question

Ask A comes from the page's local server compromise section, which lists arbitrary code execution, no visibility into commands and data loss, and recommends sandboxing with minimal default privileges (MCP security best practices). Ask E comes from the scope minimization section, which warns that publishing every scope and issuing wildcard scopes enlarge the damage from one stolen token.

Ask D rests on one rule: servers must not accept any token that was not explicitly issued for them. The page names audience validation failures and token passthrough as the two halves of the problem. Ask F follows from its confused deputy section, where a proxy with a static client ID, dynamic client registration and a consent cookie can hand an authorization code to the wrong party.

Ask G follows from the SSRF section. During OAuth discovery a malicious server can point a client at internal addresses and cloud metadata endpoints. The page recommends blocking private ranges, validating every redirect hop and using an egress proxy, and it says not to hand-write the IP checks, because encoding tricks defeat custom parsers.

The 2026-07-28 revision also changed the session model. The protocol no longer has protocol-level sessions, so a server that keeps state mints a handle and receives it back as a tool argument. The page tells servers never to treat holding a handle as authentication and to bind it to the verified user. If a vendor still describes server-assigned session IDs, ask which revision it implements. Our write-up of the 2026-07-28 security changes covers the shift.

Asks B, C and H are editorial judgement, not specification text. The combination to avoid is the one Simon Willison calls the lethal trifecta: private data, untrusted content and a way to send data out. A third-party server can supply two of those by itself.

Stop awarding points for popularity

Most intake forms quietly reward a large star count, a verified badge or a recent commit. The data does not support that habit. Trend Micro crawled 9,695 distinct MCP servers between November 2025 and March 2026 and, in a post dated 24 June 2026, reported 2,259 servers with confirmed issues, after setting aside servers whose only flaw was missing authentication. Average issues per server barely moved across star tiers, commit tiers or verified status, according to the same vendor study.

That is why question C exists and why it scores zero for stars. A popular server is not safer, and it has more users to hurt when it fails. The call: treat a registry badge as a discovery aid and give it no weight in the score. Read the code paths that touch your data, or do not approve the server for production.

Two cases cut against this call. First, if your organisation runs its own vetted registry with signed builds and a review step you control, the registry badge then is your evidence and it deserves points. Second, Trend Micro is a security vendor with a commercial interest in this finding, and its crawl covers public servers, not your private ones. Weigh it as one dated study, and check whether newer data shifts the picture.

Limits of this score

A high score proves you asked and recorded. It does not prove the server is free of flaws, that the vendor answered truthfully, or that the next update is safe. It replaces neither a code review nor a penetration test. Hand production decisions to qualified security staff.

Have the requester fill in the evidence column and a second person sign the total. Where a vendor will not answer, write down that it would not answer. That entry will be worth more than a guess during an incident.

Common questions on approving MCP servers