MCP Server Validator & Security Audit 2026 avatar

MCP Server Validator & Security Audit 2026

Pricing

from $50.00 / 1,000 mcp server audits

Go to Apify Store
MCP Server Validator & Security Audit 2026

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

Daniel Craig

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

8 days ago

Last modified

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/discover and advertised protocol versions;
  • modern per-request _meta protocol version;
  • modern resultType values;
  • final HeaderMismatch behavior: HTTP 400 + JSON-RPC -32020;
  • MCP-Protocol-Version required/mismatch behavior;
  • Mcp-Method required/mismatch behavior;
  • response _meta server identity;
  • list-result cache hints such as ttlMs and cacheScope;
  • deterministic first-page tools/list ordering;
  • JSON-RPC envelope validity;
  • JSON and Streamable HTTP SSE parsing;
  • legacy 2025 initialize detection;
  • unexpected legacy Mcp-Session-Id use 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-Authenticate challenge presence;
  • one unique high-entropy invalid-token server/discover probe that verifies invalid credentials are rejected with HTTP 401;
  • passive HTTP 403 validation for a Bearer insufficient_scope challenge and minimum-scope signal;
  • challenge scope signals and obvious over-broad scopes;
  • RFC 9728 Protected Resource Metadata discovery;
  • required resource and 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 S256 support;
  • 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_access and 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 Bearer prefix.
  • 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:

InputDefaultPurpose
serversrequired1-25 public remote MCP HTTP(S) endpoints
bearerTokenemptyOptional Apify secret Bearer token
protocolVersion2026-07-28Target modern revision
compatibilityProbetrueDetect responding 2025-era servers
originSecurityProbetrueTest rejection of an unrelated Origin
headerComplianceProbetrueTest required/matching MCP routing headers
validateAuthorizationDiscoverytruePassive RFC 9728 + RFC 8414/OIDC checks
includeInventorytrueInclude bounded capability summaries
timeoutSecs15Per-request inactivity and absolute deadline
maxResponseBytes1000000Per-response byte cap
maxListPages5Pagination cap
maxItemsPerCapability500Inventory cap
concurrency3Endpoint concurrency, hard-capped at 5
allowInsecureHttpfalsePublic 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.