MCP Server Validator & Security Audit 2026
Pricing
from $50.00 / 1,000 mcp server audits
MCP Server Validator & Security Audit 2026
Validate remote MCP servers for current protocol compatibility, OAuth, headers, schemas, capabilities, tools/resources inventories, and production security without invoking tools.
Pricing
from $50.00 / 1,000 mcp server audits
Rating
0.0
(0)
Developer
Daniel Craig
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
8 days ago
Last modified
Categories
Share
A non-destructive Apify Actor for validating remote Model Context Protocol (MCP) servers against the final MCP 2026-07-28 protocol and producing deterministic deployment-readiness reports.
The defining safety rule is simple: the Actor never sends tools/call and never executes a discovered MCP tool. It performs discovery/list operations and narrow protocol, transport, Origin, OAuth, and schema probes only.
Why developers use it
A server can be reachable and still fail when a modern MCP client, gateway, load balancer, or OAuth flow depends on it. The July 28, 2026 protocol introduced major changes including a stateless core, server/discover, header-based routing, cacheable list results, and authorization hardening.
Use this Actor for:
- pre-production MCP validation;
- CI/CD regression checks after deployments or SDK upgrades;
- migration checks from 2025-era MCP servers;
- gateway/reverse-proxy header validation;
- OAuth discovery troubleshooting;
- safe capability inventory without tool execution;
- recurring deployment-readiness checks.
What it checks
MCP 2026 protocol and transport
server/discoverand advertised protocol versions;- modern per-request
_metaprotocol version; - modern
resultTypevalues; - final
HeaderMismatchbehavior: HTTP 400 + JSON-RPC-32020; MCP-Protocol-Versionrequired/mismatch behavior;Mcp-Methodrequired/mismatch behavior;- response
_metaserver identity; - list-result cache hints such as
ttlMsandcacheScope; - deterministic first-page
tools/listordering; - JSON-RPC envelope validity;
- JSON and Streamable HTTP SSE parsing;
- legacy 2025
initializedetection; - unexpected legacy
Mcp-Session-Iduse on 2026 responses; - Content-Type, HSTS, server/cookie disclosure, TLS, and certificate observations.
OAuth and authorization readiness
For protected endpoints, passive checks include:
- Bearer
WWW-Authenticatechallenge presence; - one unique high-entropy invalid-token
server/discoverprobe that verifies invalid credentials are rejected with HTTP 401; - passive HTTP 403 validation for a Bearer
insufficient_scopechallenge and minimum-scope signal; - challenge scope signals and obvious over-broad scopes;
- RFC 9728 Protected Resource Metadata discovery;
- required
resourceand exact resource matching; - non-empty
authorization_servers; - safe public HTTPS authorization-server URLs;
- RFC 8414 / OpenID Connect authorization-server metadata discovery;
- exact issuer consistency;
- authorization, token, JWKS, and registration endpoint URL safety;
- PKCE
S256support; - authorization-code response/grant signals;
- implicit-flow warnings;
- RFC 9207 authorization-response issuer support signal;
- Client ID Metadata Document (
client_id_metadata_document_supported) readiness and DCR-deprecation guidance; - optional protected-resource cross-checks;
offline_accessand broad-scope warnings.
The Actor does not log in, register an OAuth client, redeem an authorization code, request a token, or execute a protected tool.
Capability/schema inventory
The Actor can safely list and summarize:
- tools;
- resources;
- resource templates;
- prompts.
It checks duplicate identifiers, tool schema shape, x-mcp-header mappings, recommended tool-name form, and MCP tool risk annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Missing hints use conservative defaults in the report. Contradictory hints are flagged.
Tool-description security flags are deliberately heuristic and are never presented as proof of malicious behavior.
Safety and security model
No tool execution
Production source contains no tools/call invocation. The test suite includes a 500-full-audit stress test that verifies zero tool calls.
SSRF and network protections
- HTTPS required by default.
- Private/internal/local hostnames blocked.
- Loopback, RFC1918, link-local, CGNAT, documentation, multicast, reserved IPv4, unique-local/link-local/multicast/reserved IPv6, and mapped-private targets blocked.
- DNS checked before a request and rechecked by the lookup used by the actual HTTP/TLS socket, reducing DNS-rebinding/TOCTOU risk.
- Redirect targets revalidated.
- Cross-origin redirects blocked by default.
- HTTPS-to-HTTP downgrade redirects blocked.
- URL usernames/passwords, fragments, credential-like query parameters, oversized URLs, and common sensitive/non-HTTP infrastructure ports blocked.
- OAuth metadata URLs use the same safe URL validation.
Credential protections
bearerToken is an Apify isSecret: true input.
- Token syntax is validated before use.
- Only the token value is accepted, not a
Bearerprefix. - Authenticated multi-endpoint runs must stay on one origin.
- Authorization/cookie/proxy-authorization headers are never transmitted over plaintext HTTP in production.
- Cross-origin redirects do not receive credentials.
- Exact supplied secrets, concrete Authorization Bearer header values, JWT-looking values, and common credential assignments are redacted before persistence without rewriting safe protocol prose.
- Reflected-token leakage from a hostile/broken server is covered by automated tests.
- Resource/resource-template URIs are reduced before persistence: embedded userinfo, sensitive query values, and fragments are redacted.
- Untrusted output is bounded and copied into null-prototype objects to prevent prototype-pollution keys from mutating sanitized output.
Resource and abuse controls
- maximum 25 endpoints per run;
- maximum concurrency 5;
- bounded request deadlines with both inactivity and absolute wall-clock limits;
- bounded response bytes and response-header count;
- response compression requested as
identity; - bounded redirects, pagination, cursor size, and inventory size;
- repeated pagination cursors terminate the list walk;
- no browser, shell, arbitrary proxy, external LLM, analytics service, or third-party validation API.
See SECURITY.md for the complete threat model and limitations.
Why direct secret input is used instead of an MCP Connector
Apify MCP Connectors are valuable when an Actor needs to use another MCP service while keeping its credential behind Apify's MCP Proxy. This Actor needs to measure the target server's own HTTP status codes, redirects, Origin behavior, MCP headers, and OAuth metadata. Routing the core audit through a proxy would cause some checks to measure the proxy rather than the upstream server.
For audit fidelity, authenticated checks therefore use an optional Apify secret Bearer input with the protections above. The Actor still never executes tools.
Input
Safe no-secret example:
{"servers": [{"url": "https://mcp.apify.com","name": "Apify hosted MCP"}]}
Authenticated example:
{"servers": [{ "url": "https://YOUR-MCP-HOST.example/mcp" }],"bearerToken": "<TOKEN>","includeInventory": true}
Important inputs:
| Input | Default | Purpose |
|---|---|---|
servers | required | 1-25 public remote MCP HTTP(S) endpoints |
bearerToken | empty | Optional Apify secret Bearer token |
protocolVersion | 2026-07-28 | Target modern revision |
compatibilityProbe | true | Detect responding 2025-era servers |
originSecurityProbe | true | Test rejection of an unrelated Origin |
headerComplianceProbe | true | Test required/matching MCP routing headers |
validateAuthorizationDiscovery | true | Passive RFC 9728 + RFC 8414/OIDC checks |
includeInventory | true | Include bounded capability summaries |
timeoutSecs | 15 | Per-request inactivity and absolute deadline |
maxResponseBytes | 1000000 | Per-response byte cap |
maxListPages | 5 | Pagination cap |
maxItemsPerCapability | 500 | Inventory cap |
concurrency | 3 | Endpoint concurrency, hard-capped at 5 |
allowInsecureHttp | false | Public development HTTP only; credentials/private targets remain blocked |
Output
Each endpoint produces one dataset item with:
- server and detected protocol era;
- supported protocol versions;
- server identity/capabilities when present;
- authorization discovery results;
- inventory counts and optional bounded inventory;
- safe request observations;
- stable findings with status, severity, evidence, and remediation;
- deterministic overall/protocol/security scores and letter grade.
A compact run summary is also stored under the default key-value-store OUTPUT key.
Example finding:
{"id": "MCP_PROTOCOL_HEADER_MISMATCH_ACCEPTED","category": "protocol","status": "fail","severity": "high","title": "Protocol-version header/body mismatch was not rejected","detail": "Expected HTTP 400 and JSON-RPC -32020; observed HTTP 200.","remediation": "Validate MCP-Protocol-Version against io.modelcontextprotocol/protocolVersion in request _meta."}
CI usage
Start the Actor through the normal Apify Actor API and fail a deployment when, for example:
summary.fail > 0;detectedEra != "modern-2026";summary.protocolScore < 90;- a specific stable finding ID is present.
Accuracy boundary
This is a remote, non-destructive deployment-readiness audit, not a penetration test or certification. It cannot prove server-side token audience validation, prove absence of token passthrough, inspect source code, verify OAuth state/redirect internals, or test tool-handler authorization without invoking tools.
A passing result means the observable checks performed by this Actor passed. It does not mean the deployment is guaranteed secure.
Use only on endpoints you own or are authorized to assess.
