Detects Akamai bot-wall and deny-page signals when probing a URL, classifying the response as WALLED, CHALLENGED, or related verdicts with supporting evidence.
Detects Cloudflare challenge and wall signals, such as 'Just a moment' pages, when probing a URL and classifies what stopped an agent with evidence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wallcheck what's blocking agents at example.com/downloads?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Point an agent at a URL. Find out what actually stops it: with receipts.
0.5.0: stamped final at the ship-readiness pass (release candidate at Wave 9). Not yet published; the launch hold stands. What is proven, what is not, and what the ship decision still needs: campaign/LAUNCH-READINESS.md.
Agents die silently on bot walls. A fetch returns 403, a browser session
churns through environment after environment, an upload never starts :
and nothing can say what stopped it, whose wall it was, or show the
evidence. wallcheck probes a URL once, honestly, and classifies what an
agent really hits: OPEN, CHALLENGED, WALLED, LOGIN_GATED,
RATE_LIMITED, or UNREACHABLE: naming the vendor (Cloudflare,
PerimeterX, DataDome, Akamai, Imperva, AWS WAF, Microsoft Azure WAF,
Kasada, AWS CloudFront) and the exact signals
that prove it.
No LLM anywhere in the verdict: the classifier is a deterministic pure
function of (status, headers, body). Same response in, same verdict
out: which is what makes the results safe to put in CI, in an incident
report, or in the public Bot Wall Index.
New in v0.2: signed agent identity. wallcheck keygen mints an
RFC 9421 signing key and wallcheck probe <url> --sign key.json
attaches a real HTTP Message Signature (hmac-sha256,
tag="web-bot-auth") to the probe: an agent with a name, not an
anonymous bot. wallcheck verify-server --key key.json runs a tiny
server that honors only correctly signed requests, so site owners can
test their side. The hmac-sha256 variant covers
bilateral agent↔owner setups; Ed25519 (v0.4) covers the public
directory case: see
validation/wave2/SIGNING.md.
New in 0.5.0: the owner-side audit joins the MCP server as
the audit tool (up to 10 honest GETs per call, same bounded-fetch
discipline as probe_url), the docs pass in Wave 9 corrected every
stale count against measured reality, and the suite stood at 120
tests at the Wave 9 stamp. Waves 10-17 took it to 428 tests (the
Wave 17 audit's 423 predates the W17-007 live fix's 5 fixtures :
see validation/wave17/STABILITY-12.md);
Wave 18's battery v10 plus the W18-007 live fix took it to 481.
Wave 19's battery v11 took it to 532; Wave 20's battery v12 took
it to 571; Wave 21's battery v13 took it to 608; Wave 22's
battery v14 took it to 638; Wave 23's battery v15 took it to
674; Wave 24's battery v16 took it to 710; Wave 25's battery
v17 took it to 747; Wave 26's battery v18 took it to 788;
Wave 27's battery v19 took it to 831.
New in v0.5: the classifier learned the territory the Wave 5 expansion measured: Microsoft Azure WAF, Kasada, and AWS CloudFront detection; the Akamai reference-token deny page; a verdict rule for status 444 (a dropped request is a refusal, never an OPEN); and the end of the false-challenge species where a served page merely embeds a reCAPTCHA/hCaptcha loader for its own forms. All five Wave 5 defects are fixed test-first from live captures (PROBLEMS.md). The index now covers 500 sites (Waves 6-7 expansion, Wave 18 row 500), and Wave 5 ran the first signed-vs-unsigned experiment with the shipped signer (SIGNED-EXPERIMENT.md): an unregistered key changed no verdict anywhere: the measured baseline the campaign's identity front has to move. For owners, the Fix Kit turns audit findings into vendor-verified remediation steps.
New in v0.4: Ed25519 signed identity. The signer now implements
Ed25519 per RFC 8032 in pure Python stdlib (verified against the
official RFC 8032 §7.1 test vectors), so wallcheck keygen --alg ed25519 mints a directory-compatible Web Bot Auth key: the public
half publishes in a /.well-known/http-message-signatures-directory
document, and probe --sign auto-detects the key's algorithm.
Wave 4 also took the index's third data point and ran the first
signed-agent-directory census of all 154 index domains
(DIRECTORY.md).
New in v0.3: the owner-side audit. wallcheck audit <domain>
grades a site's agent-access posture across six checks: robots.txt
AI-agent directives, llms.txt sanity (an HTML soft-404 fails),
sitemap, feed discovery, API discovery, and Web Bot Auth
signed-agent readiness: each PASS/WARN/FAIL with evidence and a
concrete fix, rolled into an A-F grade. First live audits
(validation/wave3/AUDITS.md): our own
properties grade D/F: the audit found real work on our own sites
before anyone else's. v0.3 also adds AWS WAF detection to the
classifier and merges the census into the
Bot Wall Index working table (499 sites after the
Waves 6-7 expansion).
wallcheck will never solve CAPTCHAs, spoof fingerprints or user
agents, or bypass/evade a wall, rate limit, or access control. The probe
identifies itself (wallcheck/<version> user agent). The combat is
detection + evidence + standards: a wall an agent can name is a bug
report; signed agent identity (Web Bot Auth, RFC 9421: prototype
shipped in v0.2, see SPEC.md) is how agents stop being
anonymous in the first place.
Related MCP server: agent-safe-webscan
# No install needed beyond Python 3.11+ (standard library only):
PYTHONPATH=src python3 -m wallcheck probe https://www.upwork.com
# Or install the package:
pip install . # then: wallcheck probe <url> [--json]Example output (a real run: see DOGFOOD.md for the full set):
https://example.com -> OPEN
status: 200
vendor: none detected
elapsed: 87ms
evidence:
- STATUS_200Exit codes: 0 for OPEN, 1 for any other verdict, 2 for usage
errors: CI-ready. --json prints one stable object:
{url, final_url, status, verdict, vendor, evidence[], elapsed_ms, redirect_chain[]}.
Signed probes and owner-side verification:
PYTHONPATH=src python3 -m wallcheck keygen --out wallcheck-key.json
PYTHONPATH=src python3 -m wallcheck probe https://example.com --sign wallcheck-key.json
PYTHONPATH=src python3 -m wallcheck verify-server --key wallcheck-key.json --port 8799Owner-side audit of your own site's agent-access posture:
PYTHONPATH=src python3 -m wallcheck audit example.com [--json]Six checks (robots.txt, llms.txt, sitemap, feed, API, signed-agent
readiness) → per-check PASS/WARN/FAIL + evidence + a fix list, and a
grade. Exit 0 for grade A/B, 1 otherwise.
Exposure scan of the page a site serves (opt-in, same single fetch):
PYTHONPATH=src python3 -m wallcheck probe https://example.com --exposure [--json]Classifies the key-like material the page itself hands an anonymous
visitor — CANDIDATE_EXPOSURE (server-secret classes that should
never be public), PUBLIC_BY_DESIGN (frontend keys, app IDs),
VISITOR_TOKEN (short-lived JWTs). Findings are fingerprint-only:
pattern, class, length and a SHA-256 prefix, never the value. The
method and its disclosure rules live in
campaign/EXPOSURE-LAYER.md.
verdict | meaning |
| Served. An agent can read it. |
| An interactive human-verification challenge was presented (Cloudflare "Just a moment", a CAPTCHA page). Non-interactive agents stop here. |
| A hard block page ("Sorry, you have been blocked", a deny page, a bare 403). No challenge is even offered. |
| Redirected to / served a login wall. Content exists, behind authentication. |
| HTTP 429 without a stronger wall signal. A throttle, not a wall. |
| The fetch failed (DNS/TLS/timeout) or 5xx. No wall verdict is claimed. |
From npm (no install, needs Node 20+ and Python 3.11+ on PATH; the package is a thin launcher over the same Python stdlib code):
npx -y @reneturcios/wallcheck mcp
# the same shim also forwards the CLI:
npx -y @reneturcios/wallcheck probe https://example.comOr from this repo:
PYTHONPATH=src python3 -m wallcheck mcp
# or, installed: wallcheck-mcpTools:
probe_url(url, timeout?): live fetch → classification object.
classify(status, headers, body): offline classification of a
response you captured yourself. No network.
scan_exposure(url, timeout?): live fetch → classification object
plus an exposure section (key-like material the page serves,
classified, fingerprint-only). One honest GET, same discipline
as probe_url; covers the probe's 64 KB body sample.
audit(domain, timeout?): owner-side agent-access audit: grade
plus per-check PASS/WARN/FAIL. Up to 10 honest GETs to the one
domain, same bounded-fetch discipline as probe_url.
Add to an MCP client config as a stdio server running either command,
or via Docker with the GHCR image
ghcr.io/cloudcorprecords/wallcheck:0.5.0 (see Dockerfile).
Fully offline: recorded fixtures exercise the pure classifier:
python3 -m unittest discover -s tests -vCaptured responses under validation/ are evidence, and evidence
is scrubbed before it is published: run
python3 scripts/scrub_captures.py on any new capture wave first.
Served pages embed other sites' key material; the scrubber's
redaction table is the exposure scanner's own pattern table, so
anything the scanner can find, the scrubber removes. Private
disclosure material (validation/monster-finding/) and unreleased
candidate findings (validation/exposure-wave*/) are never
published — both paths are gitignored on purpose.
By Rene Turcios: sibling of greenlight (know before you claim an issue: GO/NO-GO with evidence) and mcpaudit (audit any MCP server, scored). Same house rules: deterministic core, named issues, evidence over vibes, dogfood on real targets before claiming anything.
Full product spec, roadmap (Web Bot Auth signing shipped as the
v0.2 prototype; the owner-side audit shipped in v0.3), and the Bot
Wall Index plan: SPEC.md. Validation waves live in
validation/: Wave 2 added depth probing of 77 platform paths
(PATHS.md) and the signing prototype
(SIGNING.md); Wave 3 added the
stability re-probe, the 154-site index, and the audit's first live
runs (AUDITS.md). Wave 4 added the
third stability data point (STABILITY-2.md),
the signed-agent directory census
(DIRECTORY.md), and Ed25519. Wave 5
added the territory growth, the signed-vs-unsigned experiment, and
the owner fix kit; Wave 6 hardened the classifier against 25
adversarial shapes; Wave 7 took the index to 499 sites, ran the
second directory census (4 adopters) and an audit sweep; Wave 8
probed paths on 46 more platforms and took the front-doors file to
65 platforms. Wave 9 stamped 0.5.0-rc and added the audit MCP tool;
Waves 10-28 ran nineteen more stability rounds (rounds 6-24)
and adversarial batteries v2-v20, took the suite to 885 tests,
and kept the launch hold.
MIT: see LICENSE.
Owner-side agent-access audit of a domain: robots.txt AI-agent directives, llms.txt sanity, sitemap, feed discovery, API surface, and Web Bot Auth directory, each PASS/WARN/FAIL with evidence and fixes, rolled into an A-F grade. Read-only. Makes up to 10 honest GETs to the one domain (homepage, robots, llms, sitemap, declared sitemap if any, two OpenAPI paths, /api and /developers only when no spec is found, the signed-agent directory path), each with the probe's timeout and bounded body sample, no retries. Budget the call accordingly.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly: it declares read-only behavior, the exact set of paths probed, up to 10 GETs, bounded body samples, per-probe timeout, no retries, and the need to budget the call accordingly. This gives an agent unusually complete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: it opens with the audit purpose and output format, then adds read-only status and probing behavior. The long parenthetical about exact paths is detailed but earns its place for a network-audit tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description explains the output nature well: each check yields PASS/WARN/FAIL with evidence and fixes, rolled into an A-F grade. It also details request behavior, though it leaves some parameter-level detail and auth expectations implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for both parameters. It clarifies that 'domain' is a single domain and that 'timeout' belongs to each probe, but it does not specify the domain format, timeout unit, valid range, or default, leaving important parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: an owner-side agent-access audit of a domain, and enumerates the checks and output format. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like probe_url or scan_exposure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for comprehensive domain-level audits and warns to budget the call because it may make up to 10 GETs. However, it does not explicitly say when to use this instead of probe_url, classify, or scan_exposure, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offline classification of a captured HTTP response (status, headers, body sample). No network. Returns verdict, vendor, and evidence codes.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| status | Yes | ||
| headers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses that the tool makes no network calls and returns verdict, vendor, and evidence codes. It does not explain behavior for a null status, error conditions, or the set of possible verdicts, which are important gaps for a classifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core operation, followed by the key behavioral constraint and the return values. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the primary documentation. It says what is returned at a high level but does not enumerate verdict values, describe evidence codes, or cover null/error handling, leaving meaningful gaps for a classification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does mention status, headers, and body sample, mapping to all three parameters and clarifying that body is only a sample. It still omits format details, such as the shape of headers or why status is nullable despite being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: offline classification of a captured HTTP response, with the inputs it consumes and the outputs it produces. 'No network' implicitly distinguishes it from probe_url, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'offline ... No network' implies this should be used on already-captured responses rather than live probing, which hints at the probe_url alternative. However, there is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL once with an honest wallcheck user agent and classify what an agent actually hits: OPEN, CHALLENGED, WALLED, LOGIN_GATED, RATE_LIMITED, or UNREACHABLE, with the wall vendor and evidence codes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses a single fetch, an honest wallcheck user agent, and explicit outcome classes including RATE_LIMITED. It still omits operational details such as HTTP method, redirect behavior, and exactly how timeout affects the request.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted phrasing. It efficiently packs the action, user-agent behavior, and classification outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description usefully names the return classifications plus wall vendor and evidence codes. However, it leaves the timeout parameter unexplained and provides no sibling routing, so it is only minimally complete for a network probe tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for both parameters. It implies the URL parameter through 'Fetch a URL once', but the timeout parameter is never explained, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Fetch a URL once') and states the classification output, so the core purpose is clear. It does not explicitly differentiate itself from the sibling 'classify' tool, leaving some ambiguity about when this probe is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying it classifies what an agent hits, but it gives no explicit when-to-use guidance, no exclusions, and no comparison to siblings such as audit, classify, or scan_exposure. An agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL once with an honest wallcheck user agent — one honest GET, no retries — classify the wall, and scan the served page for key-like material: CANDIDATE_EXPOSURE (server-secret classes that should never be public), PUBLIC_BY_DESIGN (frontend keys and app IDs), and VISITOR_TOKEN (short-lived JWTs). Findings carry pattern, class, value length and a SHA-256 fingerprint prefix — never the value itself. The scan covers the probe's bounded body sample (64 KB), so material served past the cap is out of reach of this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: exactly one GET, an honest wallcheck user agent, no retries, a bounded 64 KB body sample, and a clear statement that findings expose only pattern, class, value length and a SHA-256 fingerprint prefix — never the value itself. It also warns that material beyond the cap is out of reach, which is exactly the kind of limitation an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The action is front-loaded and every clause adds substantive information about behavior, findings, or limits. It is dense with em dashes and runs long, but there is little that could be removed without losing required context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations or output schema, the description covers network behavior, scanning scope, finding shapes, and the 64 KB limitation well. The remaining gap is the timeout parameter and any error/timeout behavior, which are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It implies the url argument through 'fetch a URL once' but says nothing about the timeout parameter or its default of 15, leaving a meaningful operational parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource chain — fetch a URL once, classify the wall, scan the served page for key-like material — and names the finding classes. It is clear what the tool does, but it never distinguishes itself explicitly from siblings like probe_url or classify, which overlap with the fetch and classification steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by describing the scan and the categories it reports, so an agent can infer this is for exposure hunting on a single URL. However, there is no explicit when-to-use guidance, no when-not, and no mention of when probe_url or classify would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.0auditclassifyprobe_urlscan_exposureScored across 4 tools
probe_url and scan_exposure both perform a single honest GET and classify the wall, so their boundary is fuzzy; the scan_exposure description does clarify it adds secret-scanning, which helps, but an agent wanting wall classification alone has two plausible choices. audit is clearly domain-level and classify is clearly offline, so those two are distinct.
Two names are bare verbs (audit, classify) and two use verb_noun (probe_url, scan_exposure), so there is no single predictable pattern. All are snake_case and readable, but the convention is mixed.
Four tools is a sensible, tightly scoped surface for a read-only agent-access wall checker. The only redundancy is that scan_exposure subsumes probe_url, so one tool is arguably not earning a fully independent place.
The surface covers domain-level audit, single-URL probing, secret/exposure scanning, and offline classification of captured responses, which is good lifecycle coverage for a diagnostic tool. Minor gap: no batch or multi-URL operation despite the probes being read-only and cheap, forcing repeated single calls.
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.
AI-search-visibility tools: check crawler access, generate llms.txt, lint robots.txt, census data.
Public web tools for agents: product extraction, claim checks, webpage QA and ranked audits.
WAF-bypass web scraper and passive URL mapper for AI agents with zero pay-on-fail.