This page is part of our MCP Security Center, within The MCP Guide. Want a second opinion on your setup? Request a free MCP readiness review.
An MCP vendor security questionnaire is a set of written questions you send to any company whose MCP server will touch your data. It asks how the server handles sign-in, tokens, permissions, tool changes, logging and security fixes. Below are 35 questions you can copy, plus guidance on what a good answer looks like.
Generic SaaS questionnaires miss MCP-specific risks. They rarely ask whether a server validates token audiences, whether tool descriptions can change after approval, or how a local install is sandboxed. Those are the gaps attackers have used.
The questions follow the MCP Security Best Practices and authorization specification for the 2026-07-28 spec, checked on 28 October 2026.
Key Takeaways
- Ask every vendor the same questions in writing so you can compare answers line by line.
- The most important answers concern token audience, scopes and whether the server ever forwards your token.
- Ask how tool descriptions are versioned, because a trusted server can change after you approve it.
- Ask which MCP SDK version the server uses, since several SDK flaws were fixed only by upgrading.
- Vague answers like "we follow best practices" should count as no answer.
How to send it
Paste the questionnaire into a doc or your procurement tool. Ask for written answers and evidence where it exists, such as documentation links or a sample log. Give vendors two weeks.
Pair it with your MCP RFP template if you are buying a custom build. Put the key answers into the contract later, using our guide to MCP development contract terms.
The questionnaire
Copy everything in the box. Delete sections that do not apply, such as section C for remote-only servers.
MCP VENDOR SECURITY QUESTIONNAIRE
Vendor: [name] Product / server: [name and version]
Completed by: [name, role] Date: [date]
Answer each question. Attach or link evidence where available.
A. PRODUCT AND PUBLISHER
A1. What is the exact package name, registry listing or server URL?
A2. Is the server listed in the official MCP Registry? Under which namespace?
A3. Which MCP specification versions does the server support?
A4. Which MCP SDK and SDK version does it use? How fast do you
upgrade after an SDK security release?
A5. Is the server open source? If yes, link the repository.
B. AUTHENTICATION, TOKENS AND SCOPES
B1. How do users sign in (OAuth, API key, other)?
B2. Does the server validate that every access token was issued
for this server (audience validation)?
B3. Does the server ever forward a client's token to another API?
B4. List every OAuth scope the server can request. Which are
required, and which are optional?
B5. Can we run the server read-only?
B6. Does the server request extra scopes only when a privileged
action is first attempted (step-up), or all up front?
B7. Where are tokens and secrets stored, and how are they encrypted?
B8. Are tokens ever placed in URLs or query strings?
B9. How do we revoke all access for one user? For all users?
B10. Do you support our identity provider, or the Enterprise-Managed
Authorization extension?
C. LOCAL INSTALLS (skip if remote only)
C1. What exact command installs and starts the server?
C2. Does it use stdio, or does it open a network port?
C3. If it opens a port, which interface does it bind to, and does it
require a token?
C4. What file system and network access does it need? Can it run in
a container or sandbox?
D. REMOTE SERVERS (skip if local only)
D1. Is every endpoint authenticated? Is there any unauthenticated mode?
D2. Do you validate the Origin header on incoming connections?
D3. How do you keep one customer's data and state separate from
another's?
D4. Do you rate limit tool calls?
E. TOOLS AND CHANGES
E1. List every tool, and mark which ones write, delete or send data.
E2. How do you notify customers before tool names, descriptions or
behavior change?
E3. Can we pin a version so tools cannot change without our action?
E4. Which tools fetch external content (web pages, emails, tickets)
that could carry hidden instructions?
F. LOGGING
F1. What do you log for each tool call?
F2. Can we export those logs? In what format, and how quickly?
F3. How long do you keep logs, and who can access them?
F4. How do you keep secrets and personal data out of logs?
G. VULNERABILITIES AND INCIDENTS
G1. How do researchers report vulnerabilities to you? Link the policy.
G2. Have you published security advisories or CVEs for this product?
Link them.
G3. How quickly will you notify us of an incident affecting our data?
G4. Do you produce a software bill of materials (SBOM) and sign
releases?What a good answer looks like
Use this table when scoring. It covers the questions that separate careful vendors from careless ones.
| Question | Good answer | Why it matters |
|---|---|---|
| B2 audience validation | "Yes, every token is checked." | The authorization spec says servers "MUST NOT accept or transit any other tokens." |
| B3 token forwarding | "Never. We use a separate token per downstream API." | Token passthrough is explicitly forbidden and breaks audit trails. |
| B4/B6 scopes | A short list, with step-up for risky actions | The best practices list "publishing all possible scopes" and wildcard scopes as common mistakes. |
| B8 tokens in URLs | "No, tokens go in the Authorization header." | The authorization spec says access tokens "MUST NOT be included in the URI query string." |
| C3 local port | "stdio only," or "127.0.0.1 with a token" | The spec recommends stdio, or a token if HTTP is used locally. |
| D1/D2 remote auth | "All endpoints authenticated; Origin checked." | The Streamable HTTP spec requires Origin validation to block DNS rebinding. |
| E2/E3 change control | Versioned releases, change notices, pinning | Tool descriptions can change after approval (a "rug pull"). |
| G1/G2 disclosure | A public policy and a list of past advisories | A vendor with fixed, published advisories is usually more mature, not less. |
Examples from the incident tracker show why some questions are there. One server's HTTP mode accepted unauthenticated calls and leaked the operator's access token in error messages, according to its GitHub advisory. Another wrote MCP tokens from URL query strings into logs, per its advisory.
SDK versions matter too. The official TypeScript SDK shipped without DNS rebinding protection on by default before version 1.24.0, per its advisory. A vendor who knows its SDK version, and why it matters, is paying attention.
Red flags
Treat these answers as reasons to pause:
- "We request all scopes so users don't see repeated prompts."
- "The local server binds to 0.0.0.0 for convenience."
- "Logs are not available to customers."
- "We don't publish advisories" with no disclosure policy at all.
- No answer to B2 or B3, or an answer that shows they do not know the terms.
A red flag is not always a deal breaker. It may mean you need compensating controls, such as a gateway, a sandbox or tighter scopes on your side. Our guide to MCP gateways covers what a gateway can add.
Scoring the replies
Give each answered question a score from 0 to 2.
| Score | Meaning |
|---|---|
| 0 | No answer, or an answer that adds risk |
| 1 | Partly addressed, or depends on configuration |
| 2 | Clearly addressed, with evidence |
Weight sections B and E double. They cover the risks most specific to MCP. Ask the top two vendors to walk you through their weakest answers on a call.
Next step
If you would like help reviewing vendor answers, our MCP readiness audit can score them against your setup. For a broader view of the risks behind each question, start at the MCP security center.
Frequently asked questions
Is this questionnaire only for paid vendors?
No. Use it for open-source servers too, by answering the questions yourself from the repository and docs. If you cannot answer B2, B3 or C3 from public material, treat that as a gap.
How many questions should we send?
All 35 for servers that touch sensitive data or can write. For a read-only server on public data, sections A, B and G are often enough. Keep the same subset for every vendor in a comparison.
What if a vendor refuses to answer?
That is an answer. Ask what they can share under NDA. If they still decline, look for a vendor that will answer, or limit the server to non-sensitive data.
Should we ask about the MCP Registry?
Yes. The official registry verifies that a publisher controls its namespace through GitHub or DNS. It does not scan code for security issues, so a listing is a starting signal, not a security review.
Can we reuse our standard SaaS questionnaire instead?
Use both. Your standard questionnaire covers hosting, encryption and company controls. This one adds the MCP-specific questions those forms usually miss.
