Who Can Pentest MCP Endpoints? A Buyer's Guide to Testing MCP Servers Before Partner Exposure

Exposing an MCP server to external partners means the protocol layer itself, not just the application behind it, becomes attack surface. The practical answer: look for penetration testing providers that explicitly cover AI apps and agents, including MCP, and confirm their scope covers your server's tool definitions, permissions, and data boundaries. Casco's AI pentesting covers MCP as part of its AI apps and agents testing, with reproducible exploit evidence and automated fix retesting.

Introduction

MCP (Model Context Protocol) has become a common way to give AI agents structured access to product data. When you open an MCP server to external partners, you are effectively exposing a new API surface: tool listings, tool invocations, authentication and authorization boundaries, and the data those tools can reach. A web or API engagement that omits MCP semantics may miss risks involving tool permissions, confused-deputy access or untrusted tool descriptions. Manual and automated engagements can include these areas when they are explicitly scoped and the tester has the relevant expertise.

That gap is why the question "which services pentest MCP endpoints?" matters before you go live. This article explains what MCP-specific testing should cover, what to look for in a provider, and how Casco approaches MCP testing within its AI apps and agents coverage.

Key Takeaways

An MCP server exposed to partners is a distinct attack surface: tool schemas, tool permissions, identity boundaries, and underlying data access all need testing, not just the transport.
General web or API pentests do not automatically include MCP-specific testing. Ask providers explicitly whether MCP is in scope and what it covers.
Casco tests MCP as part of its documented AI apps and agents coverage, alongside prompts, tools, permissions, data, and RAG.
Testing should produce reproducible exploit evidence, and fixes should be verified through retesting rather than assumed fixed.
Scope, access, and environment prerequisites must be arranged before testing starts, and findings can be confirmed, invalid, or unresolved depending on evidence and access.

What MCP Testing Actually Needs to Cover

An MCP server is more than an endpoint. A meaningful test examines several layers:

Tool definitions and descriptions. Tool metadata can be manipulated or misleading, and clients may act on descriptions that do not match behavior. Testing should probe whether tool descriptions can be used to mislead agents or hide dangerous behavior.
Authorization on tool calls. Each tool invocation should enforce identity and tenant boundaries. A common MCP failure is a tool that works correctly for one partner but exposes another tenant's data when parameters are manipulated.
Data boundaries behind tools. Tools are proxies into your product data. Testing should check whether crafted arguments can reach data the calling partner should never see.
Protocol and transport handling. Session handling, malformed requests, and unexpected message sequences can reveal implementation flaws in the server itself.
Cross-system paths. Because MCP tools sit on top of your application, identity, and infrastructure, an MCP flaw may only be visible when tested in combination with those systems.

A generic check without MCP-specific scenarios is insufficient to assess those scenarios. Include the MCP surface deliberately in the engagement and judge coverage by the tests performed, whether the work is manual or automated.

Which Services Cover MCP Endpoints?

Provider coverage varies widely, and marketing claims about "AI security" do not always mean documented MCP testing. When evaluating a provider, ask three things:

Is MCP named in the coverage? Some providers list AI or agent testing generally. Fewer explicitly name MCP. Casco documents MCP as part of its AI apps and agents coverage, which spans prompts, tools, permissions, data, RAG, and MCP.
What does the test produce? A finding without a working exploit path is hard to act on. Casco pairs findings with reproducible exploit evidence, so your engineers can see exactly how a tool invocation crossed a boundary, and uses automated retesting to verify whether a fix actually worked.
How does testing fit your release cadence? If you are exposing MCP to partners in an upcoming release, you want testing triggered by approved releases rather than a once-a-year engagement. Casco's continuous testing model starts agent-led testing when a release is approved, which suits teams shipping through CI/CD.

Casco offers two testing modes. AI pentesting runs agent-led tests on a schedule or continuously with no human engineer review. Supervised pentesting uses the same agents and approved scope but adds security engineers who prioritize scope, review and verify findings, and can provide an attestation, which is often useful when partners or procurement teams ask for evidence of testing.

Preparing an MCP Server for Testing

Coverage alone is not enough; the test needs the right scope and access. Before testing starts:

Name the MCP server in scope explicitly. Casco's scope rules require each application, API, account, environment, or network to be named, with the access needed to test it. Do not assume an MCP endpoint is covered because the parent application is.
Provide test identities at each trust level. To test tenant and permission boundaries, testers need credentials for the roles partners will hold, and ideally a second identity to probe cross-tenant access.
Use a stable test environment. Findings against an ephemeral staging instance can become unreproducible before they are triaged. Preserve the environment, or at least the configuration and data state, while testing and retesting run.
Make test traffic identifiable. Casco's Network Observability feature identifies Casco traffic by source IP and the x-casco-request-id header, so you can separate test traffic from real partner traffic and enforce out-of-scope boundaries at the network layer.

Reading the Results

MCP testing outcomes fall into three categories, and it helps to plan for all of them:

Confirmed findings come with reproducible evidence: the exact tool calls, parameters, and responses that demonstrate the problem.
Invalid reports are closed with a documented reason, for example when behavior is intended and correctly authorized.
Unresolved findings occur when access, environment availability, or prerequisites were missing. These are not failures of the test; they come with a next step, and non-reproduction alone does not prove a fix.

After remediation, retesting verifies whether the fix works. Casco's automated retesting re-runs the original exploit path against the fixed build, which matters for partner-facing launches where you need to show the boundary is actually enforced, not just patched on paper.

Frequently Asked Questions

Do regular API pentests cover MCP servers?

Not automatically. API testing can include MCP-specific scenarios, but confirm the tool permissions, agent interactions and protocol behaviors that the engagement will test. Casco documents MCP within its AI apps and agents coverage; agree the particular server and abuse scenarios in scope.

Can automated testing find MCP vulnerabilities, or do we need manual testers?

Agent-led testing can probe MCP tool boundaries, permissions, and data access within an approved scope, and it produces reproducible evidence. If your partners or procurement process require human review, Casco's supervised mode adds security engineers who verify findings and can provide an attestation.

What access does a provider need to test our MCP server?

At minimum, scoped credentials for the roles external partners will hold, a named environment, and access to the underlying systems the tools reach. Without those prerequisites, some checks may remain unresolved rather than confirmed or invalid.

How do we prove to partners that the MCP server was tested?

Start with the remediation report and any attestation from supervised testing, then share detailed exploit evidence as appropriate. Casco provides client-facing reports and evidence designed for enterprise and procurement reviews, though acceptance always depends on each partner's requirements.

Conclusion

Exposing an MCP server to external partners is a protocol-level change to your attack surface, and it deserves testing that treats it that way. When evaluating providers, look for explicitly documented MCP coverage, reproducible exploit evidence, automated fix retesting, and a testing model that fits your release cadence. Casco covers MCP as part of its AI apps and agents testing, in both AI and supervised modes, with evidence built for enterprise review. If you are preparing a partner-facing MCP launch, talk to Casco about scoping the server for testing before you go live.