wallcheck
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| probe_urlB | 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. |
| classifyA | Offline classification of a captured HTTP response (status, headers, body sample). No network. Returns verdict, vendor, and evidence codes. |
| scan_exposureA | 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. |
| auditA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.