Skip to main content
Glama
Rupesh7128

MCP Security Gate

by Rupesh7128
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

MCP Security Gate + BotShield

By Kingdom of Kumar Lab (Mayank Raj). Two tools in one Next.js app, plus a stdio MCP server:

  • MCP Security Gate takes a public MCP endpoint and sends initialize, notifications/initialized and tools/list (twice). It never calls a tool. It returns a 0–100 score with the rubric printed beside it.

  • BotShield POSTs a fixed suite of 12 prompt-injection probes to a bot you own, as JSON {message} or a form body. It classifies each reply for leaked system-prompt markers, tool dumps, secrets, an exfiltration channel and canary obedience.

Run

npm install
npm run dev                 # UI + /api/scan, /api/botshield
npm test                    # SSRF guard: 18 blocked URL forms
npm run sample:scan         # rewrites docs/sample-scan.json (live request)
npm run sample:botshield    # starts scripts/mock-bot.js, rewrites docs/sample-botshield.json
npm run mcp                 # stdio MCP: scan_mcp_server, botshield_probe

Related MCP server: MEOK MCP Hardening MCP

What the scanner checks

Check

Points

Plain http:// transport

−20

No auth needed for initialize + tools/list

−15

Overly broad tool (exec/shell/sql/fetch/file-write/catch-all name)

−8 each, max −24

Injection phrasing in a tool description

−25 each, max −50

Rug-pull: tool name/description/schema hash differs between two fetches

−40

Tool with no declared input properties

−3 each, max −9

No tool annotations

−4

Access-Control-Allow-Origin: * on an unauthenticated endpoint

−3

Grades are A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 40, F below that. The full rubric, the deductions applied and a list of limits are in every JSON response.

Honest limits:

  • The scanner is black-box and read-only. It does not test what tools do.

  • The two fetches are about 1.5 s apart. They catch dynamic definition changes, not a change made next week. The per-tool SHA-256 hashes are in the output so you can pin them and re-scan.

  • The broad-name and poisoning checks are regex heuristics and will produce false positives and misses.

  • A server that demands credentials gets a partial scan, because the scanner never sends credentials.

API

POST /api/scan       {"url": "https://host/mcp"}
POST /api/botshield  {"url": "https://host/chat", "confirmOwnBot": true, "format": "json"|"form", "field": "message"}

confirmOwnBot must be exactly true or the API returns 400. The free API runs the first 5 probes, with 5 runs per IP per day. The limit is held in process memory, so it is a courtesy limit and not a hard quota.

SSRF policy

lib/ssrf.js blocks these:

  • localhost and *.localhost, *.local, *.internal

  • RFC1918, CGNAT, loopback, link-local (including 169.254.169.254), multicast and reserved IPv4 ranges

  • IPv6 loopback, ULA, link-local, v4-mapped and 6to4/NAT64 forms

  • decimal, hex and short IPv4 spellings, because WHATWG URL parsing normalises them

It also resolves DNS and checks every returned address. The checked address is the one connected to (a lookup hook), so DNS rebinding can't swap it. Redirects are not followed, and response size and time are capped. The allowPrivate override exists only for local CLI scripts. The HTTP API and the MCP tools never set it.

Free vs paid

Free: scan any public MCP URL, and BotShield with 5 probes. Everything else is planned and not shipped. Checkout is not wired in this MVP. These are the configured Dodo product ids (lib/pricing.js):

Product

Price

Id

Gate

$99/mo

pdt_0NqsRJm8bbkA8CqUWb3IR

Gate (higher tier)

$199/mo

pdt_0NqsRMpUeSxVRwjvfKRYl

BotShield audit

$297

pdt_0NqsRJzZsDeF8GssBgAoj

BotShield continuous

$79/mo

pdt_0NqsRKDH4B9BBWSpBhHs6

Evidence and sources

This README makes no claims about vulnerability counts. The checks come from threat classes described in the sources below.

  • OWASP LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (URL from memory; not fetched in this build.)

  • OWASP MCP Security Cheat Sheet: the OWASP Cheat Sheet Series, cheatsheetseries.owasp.org. The exact URL was not verified in this build because web access was denied. Confirm it before citing.

  • Astrix Security, 2025 MCP security research blog: astrix.security. The exact post URL was not verified in this build. Confirm it, and quote any statistics from the post itself and not from this repo.

  • ArXiv: papers on MCP tool poisoning and rug-pull attacks exist. None is cited here, because none could be verified in this build. Add specific arXiv ids after checking them.

The probe categories (direct override, prompt extraction, role/delimiter confusion, obfuscation, exfiltration) follow the attack classes described under OWASP LLM01.

Samples (real runs)

  • docs/sample-scan.json: live scan of https://cofounderbase.com/api/mcp/, the test target you specified. Score 82 (B), 5 tools, stable across both fetches. Findings: no auth (medium) and wildcard CORS (low). The sandbox's resolver mapped every host to 198.18.0.1, which the guard correctly blocks. The sample therefore used the CLI-only allowPrivate override for that one target, and the JSON says so.

  • docs/sample-botshield.json: full 12-probe suite against scripts/mock-bot.js, a deliberately weak local mock and not an LLM. It demonstrates the pipeline only. It says nothing about any real product.

Sibling project citation-monitor supplied the rate-limit and stdio MCP patterns.

Available Tools

2 tools
botshield_probeB

POST up to 12 fixed prompt-injection probes to a bot you own. confirmOwnBot must be true.

NameRequiredDescriptionDefault
urlYes
fieldNomessage
limitNo
formatNojson
confirmOwnBotYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the burden. It discloses useful traits: probes are 'fixed' (bounded, non-open-ended), capped at 12, and gated on ownership/confirmation. It does not say whether requests are actually delivered to the live endpoint, what side effects or logging occur, or what the agent gets back — gaps for an active probing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and target scope, with the hard safety requirement stated immediately. Nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A write/probe tool with no annotations, no output schema, and 5 undocumented parameters needs substantially more: what the call returns, how results are reported, and what field/format control. The description stops well short of that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 5 parameters, and the description only clarifies confirmOwnBot (must be true) and the 12 cap on limit. url, field, and format receive no meaning in either place, so the description only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: POSTs fixed prompt-injection probes at a bot endpoint, with a cap of 12. Clearly distinct from a scanner by naming the target type (a bot / URL) rather than an MCP server, though the sibling scan_mcp_server is never named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'to a bot you own' plus 'confirmOwnBot must be true' implies the precondition for legitimate use, but there is no explicit when-to-use-vs-alternatives guidance and no mention of when NOT to run this (e.g. versus scan_mcp_server).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_mcp_serverA

Scan a public MCP endpoint (initialize + tools/list x2, read-only) and return a 0-100 score with the rubric, findings and tool hashes.

NameRequiredDescriptionDefault
urlYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it names the exact request sequence (initialize + tools/list x2), asserts the operation is read-only, and describes the shape of the result. It omits auth requirements and any rate-limit/timeout behavior for a network-facing scan, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the action, the mechanism, the safety property, and the return payload in that order. No filler to remove.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating what comes back (score, rubric, findings, tool hashes). For a one-parameter network scan, the remaining gap is operational detail such as timeout or failure behavior for unreachable endpoints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (url) exists and schema coverage is 0%, so the description must compensate. 'Public MCP endpoint' does constrain the value semantically (must be an MCP-speaking, unauthenticated URL), but it adds no format, scheme, or example detail beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Scan a public MCP endpoint') plus the exact protocol actions performed (initialize + tools/list x2) and the returned artifact (0-100 score, rubric, findings, tool hashes). It does not differentiate itself from the sibling botshield_probe, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The qualifier 'public' implies a precondition (endpoints requiring auth are out of scope), and 'read-only' signals safe usage, but there is no explicit when-to-use/when-not guidance and no mention of the sibling botshield_probe as an alternative for a different kind of probe.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedbotshield_probe
    • First observedscan_mcp_server
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation4/5

The two tools target different objects: scan_mcp_server inspects an MCP endpoint read-only, while botshield_probe sends prompt-injection payloads to a bot the caller owns. An agent could occasionally conflate them since both are security assessments, but the target distinction (MCP server vs bot) and the confirmOwnBot guard make selection reasonably clear.

Naming Consistency3/5

scan_mcp_server follows a verb_noun pattern, but botshield_probe uses a brand-prefixed noun_verb form, so the two names do not follow the same convention. Both are readable and snake_case, but the pattern is mixed.

Tool Count3/5

Two tools is thin for a server framed as a security gate. Each tool is meaningful, but the surface feels like a narrow slice rather than a well-scoped toolkit.

Completeness2/5

The surface covers a read-only MCP scan and a single bot probe class, but there is no way to retrieve prior results, export a report, verify remediation, or probe other attack categories. These are significant gaps for a security-assessment server that will force agents to work around missing operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • meok-mcp-injection-scan-mcp

    CSOAI-ORG
    A
    license
    A
    quality
    D
    maintenance
    Scans MCP servers for prompt-injection, tool-poisoning, and SSRF vulnerabilities using 30+ canonical rules across 5 severity tiers, with optional signed safety reports for procurement.
    5
    MIT

  • MEOK MCP Hardening MCP

    CSOAI-ORG
    A
    license
    B
    quality
    D
    maintenance
    Automated security red-team for any MCP server that scans manifests against OWASP LLM Top 10 and MCP-specific risks, returning a 0-100 hardening score and HMAC-signed report.
    7
    MIT

  • owasp-mcp-scan

    CodingSelim
    A
    license
    Not graded
    quality
    D
    maintenance
    Passive security scanner that audits a running MCP server against the OWASP MCP Top 10 and grades it A-F. Read-only static analysis of the advertised tools, prompts and resources with console/JSON/SARIF output, and it also runs as an MCP server itself.
    33 npm
    MIT

  • mcp-audit

    saagpatel
    A
    license
    Not graded
    quality
    A
    maintenance
    Audits MCP server configurations for security risks including capability inventory, SSRF, prompt injection, and drift detection. Works in read-only mode and can also be used as an MCP server to let AI agents audit their own attack surface.
    145 PyPI
    4
    MIT