mcp-gateway-scan
This server performs a read-only static scan of a repository or directory for MCP/agent-gateway production-readiness anti-patterns across 7 dimensions, returning a per-dimension red/yellow/green score with structured evidence.
What it scans for:
D1 – RBAC/Tool-access governance: authorization expressed in prompts, missing policy layer
D2 – Fail-close posture: error handlers that silently allow, missing timeouts
D3 – Supply chain pinning: unpinned
:latestimages,@mainrefs, unverified packagesD4 – Observability: missing OTel tracing, raw prompts in logs
D5 – Routing & cost controls: missing
max_tokens, budget limits, rate limitingD6 – Secrets & identity: inline secret literals (location only — values always redacted); rewards secret manager and IDP/OIDC wiring
D7 – Production readiness: missing kill-switches, feature flags, 429 handling, eval/red-team gates
Key behaviors:
Returns per-finding evidence with
file:linelocations for every flagged issueAccepts an optional
ci: trueparameter to include a CI gate verdict (fails on any red dimension)100% read-only — never executes code, makes network calls, or reveals secret values
Click on "Install 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., "@mcp-gateway-scanscan ./my-gateway"
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.
mcp-gateway-scan
Read-only static scanner for MCP / agent-gateway production-readiness anti-patterns. Point it at a repo, get a 7-dimension red/yellow/green score in seconds.
Built by the team behind the Provenwright MCP Gateway Readiness Audit — a full cited audit with evidence index, scored gap matrix, and 90-day roadmap. Full audit: provenwright.com/audit
npx mcp-gateway-scan ./path/to/your/gatewayIt scans your code and config for the failure modes that turn an MCP gateway from a demo into an incident — authorization decided by the model, error handlers that fail open, unpinned supply chains, dark traces, unbounded spend, inline secrets, and missing operational levers — and prints exactly where each one lives.
100% read-only. It only reads files. It never executes your code, never makes network
calls, and never prints a secret value — for inline-secret hits it reports the location
only (<file:line>), with the value redacted.
Install
# one-off
npx mcp-gateway-scan <path>
# or global
pnpm add -g mcp-gateway-scan
mcp-gateway-scan <path>Requires Node ≥ 18.
Related MCP server: trust-security
Usage
mcp-gateway-scan <path> [options]
Options:
--json Machine-readable JSON instead of the terminal report
--ci Compact, no-color output for pipelines; exits 1 on any RED
--no-color Disable ANSI colors
-h, --help Show help
-v, --version Print version
Exit codes:
0 no red dimensions
1 one or more red dimensions
2 usage / IO error"Should I connect to this server?" — the connect verdict
Before you wire a third-party MCP server into an agent that holds real credentials,
point connect at it and get a single top-line verdict — CONNECT, REVIEW, or
DO-NOT-CONNECT — over the same 7 dimensions, with the single worst finding surfaced first.
# the server's repo checkout
mcp-gateway-scan connect ./some-mcp-server
# its MCP client config entry (.mcp.json / claude_desktop_config.json)
mcp-gateway-scan connect ./.mcp.json
# its package manifest
mcp-gateway-scan connect ./package.jsonThe verdict reduces the dimension scores into one decision:
Verdict | When | Exit |
DO-NOT-CONNECT | any S1 (full-compromise-class) dimension is red | 1 |
REVIEW | concrete-or-possible risk (red S2/S3 or any yellow) | 1 |
CONNECT | every dimension green on the static checks | 0 |
Same scan engine, same --json / --ci flags, same read-only / secret-redaction guarantees —
connect only re-frames the output as a connect/no-connect decision. A green CONNECT is a good
signal, not a guarantee: a static scan cannot vouch for the publisher or runtime behavior.
Run it inside Claude Code / Cursor (MCP server)
The same package can also run as an MCP server so your agent runs the scan conversationally — just ask it to "scan this repo for gateway-readiness".
Claude Code (one command):
claude mcp add gateway-scan -- npx -y mcp-gateway-scan mcpCursor / any MCP client — add to your .mcp.json:
{
"mcpServers": {
"gateway-scan": {
"command": "npx",
"args": ["-y", "mcp-gateway-scan", "mcp"]
}
}
}Then ask your agent to run the scan_gateway tool:
Input:
{ "path": "<repo or dir>", "ci": false }(cioptional — adds the CI gate verdict).Output: a per-dimension 🟢🟡🔴 summary + the structured result. Read-only; scans only the path you give it; secret values stay redacted (location only, never the value).
Same package, two modes —
mcp-gateway-scan mcpis the server (use it from your agent); the defaultmcp-gateway-scan <path>is the CLI (run it directly in a terminal or CI). Themcpsubcommand does not change the CLI behavior.
Or find it on Glama
mcp-gateway-scan is listed on the Glama MCP directory,
where you can inspect its tool schema, Try it in the browser, or deploy the containerized
server straight from the listing. The build spec and release process are documented in
docs/glama-release.md.
Example output
[RED] D2 Fail-close / fail-open posture S1
Error handlers on the call path return allow/true/ok or pass — the
system fails OPEN. A degraded auth/policy check silently becomes
'allow'. Launch blocker.
✗ gateway.ts:23 fail-open on error path return { allowed: true };
[GREEN] D6 Security, secrets & identity S1
No inline secrets; credentials referenced from a manager/env and
IDP/OIDC identity wiring is present.
✓ docker-compose.yml:7 secret-manager / env reference DATABASE_URL: op://Production/gateway-db/url
SCORE
┌────────┬──────────────────────────────────────────┬─────────┬──────────┐
│ Dim │ Title │ Status │ Severity │
├────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D1 │ Tool-access governance & RBAC │ RED │ S1 │
│ ... │ ... │ ... │ ... │
└────────┴──────────────────────────────────────────┴─────────┴──────────┘
0 green 0 yellow 7 redWire it into CI
--ci prints a compact, greppable summary and exits non-zero on any red dimension, so a
regression (a new fail-open handler, an unpinned image, a committed secret) fails the build:
# .github/workflows/gateway-readiness.yml
- name: MCP gateway readiness scan
run: npx mcp-gateway-scan ./gateway --ciRED D2 S1 Fail-close / fail-open posture (findings=1)
RESULT green=4 yellow=2 red=1
VERDICT FAIL — red dimension(s) present; see findings above.The 7 dimensions
Dim | Checks for |
D1 Tool-access / RBAC | Authorization expressed in prompts; absence of a gateway policy layer |
D2 Fail-close |
|
D3 Onboarding / supply chain |
|
D4 Observability | Presence/absence of OTel / |
D5 Routing / cost | Missing |
D6 Secrets / identity | Inline secret literals (location only, value redacted); rewards |
D7 Prod-readiness | Missing kill-switch / feature-flag, 429 / rate-limit, eval / red-team gate |
Each dimension is scored 🟢 green / 🟡 yellow / 🔴 red with a severity tag, plus the matched
evidence (file:line). The methodology behind the rubric maps to OWASP Top 10 for LLM
Applications, the MCP spec (2025-06-18), and OpenTelemetry GenAI semantic conventions.
Try it on the bundled fixtures
mcp-gateway-scan fixtures/secure # mostly green
mcp-gateway-scan fixtures/vulnerable # mostly redThe fixtures/vulnerable tree contains only fake, non-functional placeholder secrets
(sk-EXAMPLENOTREAL…, AKIAEXAMPLE…) so you can see the redacted-secret output safely.
Accuracy
Every finding is meant to be defensible to a skeptical senior engineer. The scanner
distinguishes prompt content (a system-message string / YAML prompt field) from code
that merely documents a pattern — so a doc comment quoting rg 'only use|if the user is admin' is not flagged as authorization-in-prompt, while the same words inside a real
system prompt are. Comment lines and grep-recipe / regex documentation are suppressed
across all dimensions, and "control present" signals are matched in code/config, not prose.
What this is (and isn't)
This is a fast, free heuristic wedge — a static pattern scanner. A green score is a good signal, not a guarantee; a red score is a concrete pointer to fix. It does not run fault-injection, inspect your live IAM/IDP, or read your traces. That depth is what a full MCP Gateway Readiness Audit provides: a cited Gap Matrix and a sequenced 90-day remediation roadmap.
This scanner (free, MIT) | Full MCP Gateway Readiness Audit (paid) | |
Method | static pattern checks | read-only review of your live codebase |
Live tests | — | fault-injection (F1–F5), trace verification |
Evidence | matched line | per-finding |
Output | 7-dimension score | cited gap matrix + severity + sequenced 90-day roadmap |
Delivery | instant, automated | expert engagement + live review session |
Need the full audit? This scanner is a free heuristic wedge. The Provenwright MCP Gateway Readiness Audit goes deeper: read-only assessment of your live codebase, per-finding evidence (file + line), a cited Gap Matrix, and a sequenced 90-day remediation roadmap.
See a sample report: provenwright.com/sample/
Full audit info: provenwright.com/audit
Book a 15-min call: cal.com/willianpinho
Email: me@willianpinho.com
License
MIT © Willian Pinho
Available Tools
1 toolscan_gatewayScan MCP / agent-gateway for production-readiness anti-patternsARead-only
Read-only static scan of a repo/directory across 7 gateway-readiness dimensions (RBAC, fail-close, supply-chain pinning, observability, routing/cost, secrets, prod-readiness). Returns a per-dimension 🟢🟡🔴 summary plus the structured result. Never executes target code; secret values are redacted (location only, never the value).
| Name | Required | Description | Default |
|---|---|---|---|
| ci | No | If true, also report the CI gate verdict (would fail on any RED). | |
| path | Yes | Repository or directory path to scan (required). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds critical behavioral details: secret values are redacted (location only, never the value), no code execution, returns per-dimension summary plus structured result. This goes beyond annotations.
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?
Two sentences, front-loaded with action and scope. Every sentence adds value: first defines the tool, second adds safety and output detail. No fluff.
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?
Despite no output schema, the description adequately explains the return format (per-dimension summary + structured result). The 7 dimensions are listed, and the redaction behavior is clarified. The tool is simple, and the description covers its operation fully.
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 has 100% description coverage for both parameters. The description adds value by explaining the effect of 'ci' (reports CI gate verdict) and confirming 'path' is required. Baseline 3 is elevated to 4 due to added clarity.
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 title and description clearly state the tool's purpose: scanning a repo/directory for production-readiness anti-patterns across 7 dimensions. The verb 'scan' and resource are specific, and the 7 dimensions are listed, making the scope unambiguous.
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 safe usage by stating 'Read-only static scan' and 'Never executes target code', but does not explicitly contrast with alternatives (though no siblings exist). The CI gate verdict behavior is explained, providing context for when to use the 'ci' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly described and distinct from any other potential tools.
The single tool name 'scan_gateway' follows a clear verb_noun pattern. Naming consistency is perfect as there is only one name.
One tool for a domain that covers 7 dimensions feels slightly thin; a more granular breakdown into separate tools for each dimension might improve flexibility, but the single tool is comprehensive.
The tool covers all 7 gateway-readiness dimensions comprehensively, providing a full static scan without obvious gaps. It is read-only, which is appropriate for scanning.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Scan any website or MCP server for agent readiness: 0-100 score, a fix per failing check. Free.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Related MCP Servers
AlicenseCqualityAmaintenanceCP server for RAD Security, providing AI-powered security insights for Kubernetes and cloud environments. This server provides tools for querying the Rad Security API and retrieving security findings, reports, runtime data and many more.653726MIT- AlicenseNot gradedqualityAmaintenanceDetect live website vulnerabilities and security flaws in GitHub repositories using automated DAST and SAST scanning. Safeguard applications by identifying exposed secrets, insecure dependencies, and common code patterns prone to exploitation. Receive structured fix plans with precise code remediation steps to resolve identified risks and improve security posture.2MIT
- AlicenseNot gradedqualityDmaintenanceA frontend security dependency auditing tool that identifies vulnerabilities in local and remote repositories using the Model Context Protocol. It provides detailed audit information like CVSS scores and dependency chains, generating standardized markdown reports.25MIT
- AlicenseAqualityCmaintenance14 atomic MCP tools for AppSec and AI Security engineers: source/schema/prompt audit primitives, JWT inspect, HTTP diff, pentest atoms (default creds, GraphQL introspect, phpggc, interactsh OOB), and a defensive helpers library that fixes the bugs the detectors flag. SARIF output, PyPI Trusted Publishing with Sigstore provenance.14MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/willianpinho/mcp-gateway-scan'
If you have feedback or need assistance with the MCP directory API, please join our Discord server