Type to search across all pages
Use this checklist to decide whether an MCP assessment really covers transports, tools, prompt-to-tool risk, connected resources, OAuth boundaries, and the evidence your reviewers will expect.
Built from the same public MCP checklist, vulnerable lab, and proxy tooling Appsecco uses in real assessments.
MCP servers are not just another API surface. They sit where model output can trigger tool execution, read connected data, and reuse credentials or approval assumptions that were never designed for prompt-facing behavior.
That means a generic web, API, or even broad AI security engagement can still miss the protocol-specific questions that matter: how each tool is exposed, what the transport trusts, how untrusted content re-enters the model, what connected resources can be reached, and whether OAuth or token handling creates tenant or workflow confusion.
A buyer checklist is useful because it turns vague MCP claims into concrete scope questions. If the vendor cannot explain tool-by-tool testing, prompt-to-tool attack paths, connected-resource boundaries, and evidence quality before the statement of work is signed, the assessment is probably too shallow.
Use this as a scoping and vendor-evaluation checklist. A strong product security team can cover some of these areas, but MCP-specific depth should be visible and explicit.
May mention HTTP or auth at a high level.
Tests stdio, HTTP, or SSE trust boundaries, message handling, and unsafe transport assumptions.
May test one or two visible flows.
Exercises every exposed tool and parameter for injection, traversal, SSRF, unsafe parsing, and authorization gaps.
Often framed only as prompt injection examples.
Traces how prompts, tool descriptions, retrieved content, and outputs can change behavior or trigger unsafe actions.
May note the existence of files, APIs, or databases.
Maps what each tool can actually reach and whether file, tenant, database, or API boundaries hold under adversarial use.
May review auth at the app layer only.
Checks scopes, token storage, refresh paths, logs, revocation, and cross-user or cross-tenant credential confusion.
Dependency scanning only.
Verifies package provenance, server authenticity, tool registration integrity, and malicious-server assumptions.
Summary findings without protocol-specific structure.
Includes tool matrices, prompt-to-tool narratives, connected-resource notes, and retest-ready remediation guidance.
Generic app or AI test Broader coverage, but often light on protocol-specific MCP detail | MCP-specific security review Purpose-built for server, tool, auth, and data-path behavior | |
|---|---|---|
| Transport coverage | May mention HTTP or auth at a high level. | Tests stdio, HTTP, or SSE trust boundaries, message handling, and unsafe transport assumptions. |
| Tool-by-tool testing | May test one or two visible flows. | Exercises every exposed tool and parameter for injection, traversal, SSRF, unsafe parsing, and authorization gaps. |
| Prompt-to-tool risk | Often framed only as prompt injection examples. | Traces how prompts, tool descriptions, retrieved content, and outputs can change behavior or trigger unsafe actions. |
| Connected resource boundaries | May note the existence of files, APIs, or databases. | Maps what each tool can actually reach and whether file, tenant, database, or API boundaries hold under adversarial use. |
| OAuth and token handling | May review auth at the app layer only. | Checks scopes, token storage, refresh paths, logs, revocation, and cross-user or cross-tenant credential confusion. |
| Supply chain and trust | Dependency scanning only. | Verifies package provenance, server authenticity, tool registration integrity, and malicious-server assumptions. |
| Report evidence | Summary findings without protocol-specific structure. | Includes tool matrices, prompt-to-tool narratives, connected-resource notes, and retest-ready remediation guidance. |
The right question is not whether the vendor says they cover MCP. It is whether they can show the checklist, tools, and deliverables that make MCP-specific depth visible before work begins.
This checklist works best when it is used as a buying and scoping tool, not as a marketing comparison worksheet. The goal is to surface whether the assessment will match the real MCP risk in your environment.
List the servers, exposed tools, connected resources, auth model, and where assistants can take action or retrieve data.
Confirm that transports, tool parameters, prompt-to-tool chains, connected-resource access, OAuth, and supply chain trust are explicitly in scope.
Look for a public checklist, testing client, vulnerable lab, or equivalent practitioner assets that show how the team thinks about MCP before the engagement starts.
Ask what the final report will contain. MCP work should leave behind tool-by-tool coverage, attack-path narratives, and evidence your engineering team can act on.
A good engagement ends with a fixed statement of work, clear boundaries, and a retest expectation before any testing begins.
Why this guide is worth using
Teams usually use this guide when they need a practical way to judge whether an MCP assessment really covers transports, tools, auth, and connected resources. The proof path behind the checklist should be just as easy to inspect.
Written by
Founder & CEO
Akash leads Appsecco's product security testing practice and the public research work behind its buyer guidance. The aim is to make scope, proof, and report quality easier to inspect before a statement of work exists.
Public proof buyers can inspect before they scope work.
These are the public MCP artifacts and buyer assets that make the checklist easier to trust and easier to use in internal review.
MCP Pentesting Checklist
The public checklist Appsecco maintains for MCP tool safety, prompt injection, auth, and connected-resource review.
Vulnerable MCP Servers Lab
Intentionally vulnerable MCP servers that make protocol-specific attack paths inspectable before a client engagement begins.
Universal MCP Client and Proxy
Interception and exercise tooling for stdio-based MCP servers and protocol behavior during security reviews.
Sample Report
See the reporting standard Appsecco uses before asking for a scoped quote.
If you need the closest proof path or commercial route next, start there instead of opening a generic contact thread.
See MCP server testingCommercial overview of MCP testing scope, methodology, pricing, and next steps.
Glossary entry covering MCP clients, servers, tools, transports, and authorization boundaries.
Broader product-security route for AI applications, agents, MCP tools, prompts, and connected data flows.
Clarify when the risk lives in the agent workflow, the MCP server boundary, or both.
Where behavior testing fits versus broader product and system security work.
Not always, but the scope must still explicitly cover MCP transports, tools, prompt-to-tool behavior, connected-resource access, and OAuth or token handling. If those questions stay implicit, the protocol-specific risk is easy to miss.
Yes. Many teams need one assessment that covers the MCP servers together with the AI application, agent workflow, or customer-facing feature that uses them. The important part is that the statement of work preserves MCP-specific depth instead of flattening it into a generic app review.
At minimum: tool-by-tool coverage, prompt-to-tool attack narratives, connected-resource and auth boundary notes, and remediation guidance tied to the actual MCP implementation. That is what makes the results defensible for engineering and internal reviewers.
Source access can improve depth, but a strong assessment can still start from a controlled black-box or gray-box setup if the tools, transports, and auth paths can be exercised realistically. The right choice depends on how custom the implementation is and what evidence you need.
Usually a staging or sandbox environment with realistic tools, connected resources, and scoped credentials. If production validation is required, the exact methods and boundaries should be agreed before work begins so the testing stays predictable and non-disruptive.
Explore the MCP security surface
Continue from the concept into testing scope, implementation risks, tools, and adjacent AI security topics.
Product security testing for AI apps, agent workflows, MCP tools, prompts, and connected data sources.
Direct commercial overview of Appsecco MCP testing scope, methodology, pricing, and next steps.
Clarify when the risk lives in the agent workflow, the MCP server boundary, or both.
How malicious instructions enter prompts through users, documents, retrieved content, and tool output.
Security controls for agents that use tools, memory, approvals, and connected workflows.
Risks and controls for LLM applications, RAG systems, embeddings, and model-connected workflows.
Open-source checklist for reviewing MCP server security, tool safety, auth boundaries, and data exposure paths.
Appsecco testing client and proxy for exercising MCP servers during security reviews.
Intentionally vulnerable MCP servers for learning attack paths and validating defensive controls.
Safe next step
Share what your MCP servers can reach, how assistants use them, and what kind of evidence your reviewers need. We will help turn that into a fixed, protocol-specific assessment scope.
Talk through MCP scopeor Preview a sample report first