Probe completed within a reasonable wall-clock budget
Authored by Stanley Hong · AgentReserve (founder).
The full `initialize` + `tools/list` + (best-effort) `resources/list` / `prompts/list` walk completed in under 15 seconds. The 10-second per-call timeout still applies; this rule surfaces the aggregate budget across all calls. A probe that consistently takes longer than 15 seconds is either tarpitting (slow-roll responses to drive up scanner cost) or running on a misconfigured deployment.
When this rule runs
Requires a successful MCP `initialize` / `tools/list`. Skipped on perimeter-only scans where the server refused or failed the MCP handshake.
Why it matters
Tarpit servers are a published evasion: respond just slowly enough that the client times out before reading the dangerous tool definitions, then serve them only to clients with longer budgets. This rule turns the probe's own duration into a diagnostic — a server that takes 14 seconds to answer a passive walk is operationally suspect.
Pass condition
Probe wall-clock duration is under 15000 ms.
Fail condition
Probe wall-clock duration is at least 15000 ms.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"durationMs": 18512, "thresholdMs": 15000}
Remediation
Investigate why the MCP endpoint takes more than 15 s to answer two list calls. Real servers respond in well under a second; multi-second responses point at synchronous DB calls, cold-start serverless, or deliberate slow-roll behavior.
Methodology
This rule belongs to the Transport security dimension. How the server is reached on the wire. Covers TLS and protocol-level confidentiality of probe traffic.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.