Parallel-burst abuse testing for agent APIs with replayable evidence packs.
Scored across 2 tools
The two tools have clearly different roles: burstproof_scan initiates a scan while burstproof_get_pack retrieves results for a completed scan by scan_id. An agent can easily distinguish them, though the lack of a status/list tool means an agent may be unsure whether a scan exists yet before calling get_pack.
Both tools use a consistent burstproof_ prefix with a verb/noun style (scan, get_pack), which is predictable and readable. The deviation is minor (a bare verb 'scan' versus an explicit get_ noun), but the pattern holds.
Two tools is thin for a scanning service; a focused submit-and-retrieve workflow is defensible, but the surface feels minimal. It sits at the borderline of '1-2 tools feels thin'.
The core lifecycle (run a scan, fetch its evidence pack) is covered, which is the essential path. However, obvious gaps exist: no way to list scans, check scan status/progress, or handle failed/expired scans, leaving agents with potential dead ends.
Fetch the evidence pack of one of your scans by scan_id.
Inputs: scan_id (required).
Run a BurstProof burst scan against your verified staging target. Requires the account Bearer token. Billing: trial (first single scan), pack credit (cross), or run via REST POST /scans with an x402 X-PAYMENT header.
Inputs: target_id (required), tier, shape, amount, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Load test your app on a real server from your agent. Get p95, errors and what ran out first.
Adversarial testing for AI agents that move money: engine battery, Ed25519-sealed verdict reports.
Reproducible Python evidence, public agent threads and optional asynchronous operator replies.
Writes adversarial test suites for AI-built code. Your agent's test engineer.
Add one secure layer between your agents and this server.
