Wallcheck

Name: Wallcheck
Author: CloudCorpRecords

作者：CloudCorpRecordsバージョン 0.5.0i★ –iパソコンで動く

レジストリ名io.github.CloudCorpRecords/wallcheck

インストール

概要

作者による説明（英語の原文）

Probe a URL and name the bot wall: vendor, verdict, and evidence. CLI plus stdio MCP server.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

利用者の声iレビューはまだありませんレビューは今後のステップで、アカウント機能と一緒に始まります
私たちの基本チェックi1項目中1項目に合格公開情報からチェック。コードはまだスキャンしていません
利用状況i未計測★ –

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

接続方法: パソコンで動く
トランスポート: stdio
カテゴリ: その他

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

基本チェック：1項目中1項目に合格
あなたのパソコンで、あなたのユーザーと同じ権限（ファイル、ネットワーク、アプリ）で動きます。
レジストリには、入力が必要なキーは載っていません。

必要なもの

DockerDockerのインストール

どのアプリを使っていますか？

ClaudeClaude CodeCursorVS CodeChatGPT

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます

{
  "mcpServers": {
    "wallcheck": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "ghcr.io/cloudcorprecords/wallcheck:0.5.0"
      ]
    }
  }
}

ターミナルでこれを実行します

claude mcp add wallcheck -- docker run -i --rm ghcr.io/cloudcorprecords/wallcheck:0.5.0

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "wallcheck": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "ghcr.io/cloudcorprecords/wallcheck:0.5.0"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "wallcheck": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "ghcr.io/cloudcorprecords/wallcheck:0.5.0"
      ]
    }
  }
}

これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック

✓ 合格
作者とリポジトリが一致
レジストリ名は、リポジトリを所有するGitHubアカウント CloudCorpRecords で確認済みです
… 未チェック
今もメンテナンスされている
このリポジトリはまだGitHubから読み取っていません
… 未チェック
ライセンスがある
このリポジトリはまだGitHubから読み取っていません
– 対象外
エンドポイントが応答する
これはパソコンで動くため、インターネット上のエンドポイントはありません
– 対象外
OAuthでサインイン
パソコンで動き、代わりにローカルの設定を使います
… 未チェック
ツールの説明に隠れた指示がない
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです

その他のほかのサーバーとの比較i

このカテゴリのほかの32433件のうち0%よりスターが多い
このカテゴリのほかの32433件のうち74%より最近レジストリに公開
基本チェックの結果が、このカテゴリのほかの32433件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

Wallcheckは安全ですか？

当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか？

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか？

あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません（サーバー自体がオンラインサービスを呼び出す場合を除きます）。

今もメンテナンスされていますか？

GitHubリポジトリの最終更新は–、最新バージョン（0.5.0）がレジストリに届いたのは13 日前です。

どのアプリで使えますか？

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにDockerも必要です。

代わりに使えるものは？

同じカテゴリには：Spec Driven Development, Remote Desktop Commander, Symantec Cloud DLP AIops

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方：★ GitHubスターi3つの柱：レビュー · チェック · 利用状況i更新＝最新バージョンをレジストリに公開した日i

Spec Driven Development

作者：formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

パソコンで動く★ 440MIT14 か月前更新

インストール

Remote Desktop Commander

作者：desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

クラウドで動く★ 211昨日更新

インストール

Symantec Cloud DLP AIops

作者：AIops-tools

Governed Symantec Cloud DLP — 14 MCP tools, read-only with audit.

パソコンで動く今日更新

インストール

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

wallcheck

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 --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 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).

Non-goals

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/ 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.

Usage

CLI

# 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 [--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_200

Exit 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 8799

Owner-side audit of your own site's agent-access posture:

PYTHONPATH=src python3 -m wallcheck audit example.com [--json]

Seven checks (robots.txt, llms.txt, sitemap, feed, API, signed-agent readiness, security contact) → per-check PASS/WARN/FAIL + evidence + a fix list, and a grade (out of 14 since the security-contact check was added; earlier grades were out of 12). 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.

Verdicts

verdict	meaning
`OPEN`	Served. An agent can read it.
`CHALLENGED`	An interactive human-verification challenge was presented (Cloudflare "Just a moment", a CAPTCHA page). Non-interactive agents stop here.
`WALLED`	A hard block page ("Sorry, you have been blocked", a deny page, a bare 403). No challenge is even offered.
`LOGIN_GATED`	Redirected to / served a login wall. Content exists, behind authentication.
`RATE_LIMITED`	HTTP 429 without a stronger wall signal. A throttle, not a wall.
`UNREACHABLE`	The fetch failed (DNS/TLS/timeout) or 5xx. No wall verdict is claimed.

MCP server

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.com

Or from this repo:

PYTHONPATH=src python3 -m wallcheck mcp

or, installed: wallcheck-mcp

Tools:

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 11 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).

Tests

Fully offline: recorded fixtures exercise the pure classifier:

python3 -m unittest discover -s tests -v

Contributing evidence

Captured 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.

Family

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.

License

MIT: see LICENSE.

Wallcheck

概要

PopNx MCPの3つの柱

できること

インストール

インストールの前に

できること

基本チェックi

作者とリポジトリが一致

今もメンテナンスされている

ライセンスがある

エンドポイントが応答する

OAuthでサインイン

ツールの説明に隠れた指示がない

その他のほかのサーバーとの比較i

よくある質問

代わりの候補

Spec Driven Development

Remote Desktop Commander

Symantec Cloud DLP AIops

作者のREADME

wallcheck

Non-goals

Usage

CLI

Or install the package:

Verdicts

MCP server

the same shim also forwards the CLI:

or, installed: wallcheck-mcp

Tests

Contributing evidence

Family

License