Which integrations are available for this server?

Submits Bitbucket repository URLs for security analysis, returning a score and risk level. Submits GitHub repository URLs for security analysis, returning a score and risk level. Submits GitLab repository URLs for security analysis, returning a score and risk level.

How do I use MCP Hub Security?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Hub Security scan https://github.com/user/repo for vulnerabilities" 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 Hub Security

Official

by mcp-hub-corp

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Version Python License MCP Hub

Quick install · Claude Code setup · How it works · Tools reference · Get API key

What is this?
Features
Quick install
MCP client configuration — includes watchdog setup for Claude Code
How it works
Environment variables
Available tools
Examples
Troubleshooting

Related MCP server: airlock

What is this?

MCP Hub Security is an MCP server that acts as a security gate for your AI agent workflows. Before your agent runs an MCP server from a Git repository — or loads a Claude Code Skill — it can call this server to get a full vulnerability analysis from mcp-hub.info.

It detects 14 vulnerability classes including:

Prompt injection & instruction override
Secret and credential exposure
Tool poisoning & shadow tools
SSRF and unsafe network calls
Dangerous capabilities (exec, file write, env access)
Data exfiltration vectors
...and more mapped to the OWASP MCP Top 10

Skills support: Claude Code Skills (SKILL.md files) are scanned by 17 dedicated analyzers covering 61 rules — detecting instruction overrides, capability abuse, prompt injection hooks, and more.

Features

MCP server scanning — submit any GitHub, GitLab, or Bitbucket repository and get a security score (0–100), risk level, capabilities list, OWASP coverage, and full findings.
Skill scanning — scan a SKILL.md by content or URL; get a pass/fail verdict under configurable policy.
Policy engine — configure minimum score, maximum risk level, and denied capabilities via environment variables. The server enforces policy and returns allowed: true/false with clear reasons.
Proactive watchdog hook — a Claude Code PostToolUse hook that automatically scans any SKILL.md you create or edit and warns you immediately.
Credit-aware — each scan costs 5 credits; cached results (same commit SHA) are free. Balance is always returned.
Zero install steps — uvx fetches and runs the server on first use; no virtualenv to manage. The server itself talks to the API with the Python stdlib (no httpx/requests); the only runtime dependency is fastmcp.

Quick install

No installation needed. All configs below use uvx — it fetches and runs the server automatically on first use.

The only thing you need: an API key → mcp-hub.info/accounts/dashboard/ → API Tokens tab.

MCP client configuration

Before you start: get your API key at mcp-hub.info/accounts/dashboard/ → API Tokens. You will need to replace YOUR_API_KEY in the configs below — that is the only thing you need to change.

Claude Code is the only client with full support: the MCP tools for on-demand scanning AND the proactive Skill watchdog that automatically scans any SKILL.md you write or edit.

1. Get your API key

👉 mcp-hub.info/accounts/dashboard/ → API Tokens → Create token. Copy the key.

2. Add the MCP server — paste into ~/.claude.json (global) or .mcp.json in your project:

{
  "mcpServers": {
    "mcp-hub-security": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Replace YOUR_API_KEY with your key. That's it for the MCP server.

3. Add the Skill watchdog — paste into ~/.claude/settings.json (global) or .claude/settings.json (project):

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "uvx --from git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1 mcp-hub-skill-watchdog",
            "env": {
              "MCPHUB_API_KEY": "YOUR_API_KEY"
            }
          }
        ]
      }
    ]
  }
}

Replace YOUR_API_KEY with the same key. Putting the key in the env block avoids quoting bugs and keeps it out of the shell process list. The watchdog runs automatically — no other config needed.

What the watchdog does:

Every time Claude writes or edits a .md file that looks like a skill (name: + description: frontmatter), the watchdog scans it immediately and shows the verdict:

✅ Safe — brief notice with score and risk, no interruption.
🚫 Blocked — error with the exact policy violation. Claude Code stops.

Run claude — both the server and watchdog are active.

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "mcp-hub-security": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Restart Claude Desktop. Note: the proactive Skill watchdog is not available in Claude Desktop (no hooks support).

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to .vscode/mcp.json in your workspace (or ~/.vscode/mcp.json globally):

{
  "servers": {
    "mcp-hub-security": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mcp-hub-security": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Restart Cursor after saving.

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to ~/.windsurf/mcp.json:

{
  "mcpServers": {
    "mcp-hub-security": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to ~/.config/zed/settings.json under "context_servers":

{
  "context_servers": {
    "mcp-hub-security": {
      "command": {
        "path": "uvx",
        "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
        "env": {
          "MCPHUB_API_KEY": "YOUR_API_KEY"
        }
      }
    }
  }
}

🔑 Get your API key first: mcp-hub.info/accounts/dashboard/ → API Tokens. Replace YOUR_API_KEY below.

Add to .continue/config.json:

{
  "mcpServers": [
    {
      "name": "mcp-hub-security",
      "command": "uvx",
      "args": ["--from", "git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1", "mcp-hub-security"],
      "env": {
        "MCPHUB_API_KEY": "YOUR_API_KEY"
      }
    }
  ]
}

Environment variables

MCP servers

Variable	Required	Default	Description
`MCPHUB_API_KEY`	yes	—	API token from mcp-hub.info/accounts/dashboard/
`MCPHUB_API_URL`	no	`https://api.mcp-hub.info/api/v1`	API base URL (override for self-hosted)
`MCPHUB_MIN_SCORE`	no	`80`	Minimum security score (0–100). Scans below this are blocked.
`MCPHUB_MAX_RISK`	no	`low`	Maximum risk level: `none` \| `low` \| `medium` \| `high` \| `critical`
`MCPHUB_DENIED_CAPABILITIES`	no	(none)	Comma-separated capabilities to always block. E.g. `file_write,process_exec,secret_access,code_eval,env_access,db_access,network_egress`
`MCPHUB_POLL_INTERVAL`	no	`2`	Seconds between status polls while scan is running
`MCPHUB_POLL_TIMEOUT`	no	`300`	Maximum seconds to wait for a scan result
`MCPHUB_FAIL_MODE`	no	`open`	What happens when the hub is unreachable / returns a malformed response: `open` (warn + allow, backward compatible), `closed` (block tool / hook, exit 2), `cached` (reuse last verdict for the same content hash; fall back to `closed` on cache miss).
`MCPHUB_CACHE_DIR`	no	`~/.cache/mcp-hub-security`	Where cached verdicts are stored for `MCPHUB_FAIL_MODE=cached`.
`MCPHUB_CERT_FINGERPRINT_SHA256`	no	(unset)	When set, pins the hub TLS leaf certificate to this SHA-256 fingerprint (hex, optional `:` separators). Adds an extra TLS handshake per request — only enable in high-assurance deployments.

Skills

Variable	Required	Default	Description
`MCPHUB_SKILL_MIN_SCORE`	no	`70`	Minimum skill score (0–100). Skills below this are blocked.
`MCPHUB_SKILL_MAX_RISK`	no	`medium`	Maximum skill risk level: `none` \| `low` \| `medium` \| `high` \| `critical`

Skills use a tighter analyzer (17 analyzers, 61 rules) that is separate from the MCP server scanner. Using different thresholds for each is intentional.

Optional vars: if you do not want to override a default, omit the variable entirely. Do not set it to the empty string. (The server normalizes "" to the default, but some MCP clients refuse to forward empty-string env entries at all, leading to confusing behavior.)

How it works

MCP server scan pipeline

check_mcp_safety(url) runs four steps automatically:

1. POST /scans/          →  submit repo URL, receive check_token
2. GET  /scans/checking/{token}/  (poll every 2 s, up to 5 min)
3. GET  /scans/{id}/verdict/      →  score, risk, capabilities, findings
4. Policy engine         →  evaluate against your env vars → allowed: true/false

Cached results (same repo + same commit SHA) skip steps 1–3 and cost 0 credits.

Skill scan pipeline

check_skill_safety and check_skill_safety_url are synchronous — no polling needed. The API analyses the SKILL.md content immediately and returns the result in a single request.

Policy engine

The policy engine runs locally after every scan. It blocks if any of these conditions are true:

Condition	Controlled by
`security_score` < minimum	`MCPHUB_MIN_SCORE` / `MCPHUB_SKILL_MIN_SCORE`
`risk_level` > maximum	`MCPHUB_MAX_RISK` / `MCPHUB_SKILL_MAX_RISK`
Any detected capability is in the deny list	`MCPHUB_DENIED_CAPABILITIES` (MCP only)
Critical findings detected when max risk is `low` or below	`MCPHUB_MAX_RISK`

When blocked, the response includes allowed: false, a human-readable reason, and blocked_by_policy with the list of violations.

Risk levels are ordered: safe = none < low < medium < high < critical.

Why MCPs and Skills have separate thresholds

The MCP server scanner and the Skill scanner are different analyzers with different scoring scales and sensitivity levels. Skills get slightly more permissive defaults (min_score: 70, max_risk: medium) because the skill analyzer is purpose-built for SKILL.md structure and has fewer false positives than the general-purpose MCP scanner. You can tighten skill policy independently of MCP policy.

Credits

Operation	Cost
New scan (MCP or Skill, new commit)	5 credits
Cached scan (same commit SHA already scanned)	0 credits
`get_verdict`, `get_scan_result`, `get_skill_scan`	0 credits

Available tools

MCP server tools

Tool	Credits	Description
`check_mcp_safety(url)`	5 (cached=0)	Full pipeline: scan → poll → verdict → policy. Main entry point.
`get_verdict(scan_id)`	0	Re-evaluate policy on an existing scan with current env vars.
`get_scan_result(scan_id)`	0	Full raw result for an existing scan (findings, file paths, CWEs).
`get_credit_balance()`	0	Current credit balance and account email.

Skill tools

Tool	Credits	Description
`check_skill_safety(content)`	5 (cached=0)	Scan a `SKILL.md` provided as a string. Returns verdict + policy.
`check_skill_safety_url(url)`	5 (cached=0)	Fetch a raw `SKILL.md` from a URL and scan it.
`get_skill_scan(scan_id)`	0	Retrieve a previous skill scan result by UUID.

Examples

Scan an MCP server before installing it

"Before we add the Playwright MCP, check if it's safe: https://github.com/microsoft/playwright-mcp"

Claude will call check_mcp_safety and report the score, capabilities, OWASP risks, and whether it passes your policy.

allowed: true
security_score: 91
risk_level: low
capabilities: [browser_control, network_egress]
owasp_risks: []
credits_consumed: 0   ← cached result, same commit

Block a server that exceeds your policy

If a repo returns risk_level: high and your MCPHUB_MAX_RISK is low:

allowed: false
reason: "MCP server blocked by security policy: Risk level 'high' exceeds maximum 'low'"
blocked_by_policy: ["Risk level 'high' exceeds maximum 'low'"]

Scan a Skill before running it

"Check if this skill is safe before loading it"

check_skill_safety(content="---\nname: my-skill\ndescription: ...\n---\n...")

Returns:

allowed: true
score: 92
risk_level: low
finding_count: 0
has_critical: false

Re-evaluate policy on an existing scan

Change your policy env vars and re-apply them to a previous scan without consuming credits:

get_verdict(scan_id="550e8400-e29b-41d4-a716-446655440000")

Check your credit balance

get_credit_balance()
# → {"credits": 285, "email": "you@example.com"}

Troubleshooting

Claude Code says "Failed to connect"

That four-word message is everything Claude Code shows by default when an MCP server fails to start. The real error is captured in a debug file but you have to ask for it.

Step 1 — run a health check yourself. From your terminal, run the same command Claude Code runs, but skip stdio and just print the diagnostic table:

MCPHUB_API_KEY=your-key uvx --from git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1 mcp-hub-security --health

This prints every MCPHUB_* env var the server sees, validates them, and ends with status: OK or status: UNHEALTHY. Exit code 0 means the server can start; exit code 2 means a config problem (missing API key, invalid risk level, malformed URL).

Step 2 — capture the full stderr. Start Claude Code with --debug-file=/tmp/claude.log:

claude --debug-file=/tmp/claude.log

Then tail -f /tmp/claude.log to see every stderr line from every MCP server — including the actual exception that Claude Code is hiding.

Step 3 — for Claude Desktop, logs go to ~/Library/Logs/Claude/mcp-server-mcp-hub-security.log on macOS.

`ModuleNotFoundError` or stale uvx cache

If you ran an older version once, uvx may have a broken wheel cached. Force a fresh fetch:

uv cache clean mcp-hub-security

Then re-run the original uvx --from git+...@v2.0.1 … command — it will resolve the pinned tag again.

`MCPHUB_API_KEY is required`

The server now fail-fasts when the API key is missing instead of silently breaking. Set it in the env block of your MCP config (not inline on the command). Get a key at mcp-hub.info/accounts/dashboard/.

Heads-up on empty strings: for any optional MCPHUB_* variable, leave it out entirely instead of setting it to "". Empty strings are normalized to the default, but tooling that round-trips JSON may interpret them inconsistently.

What version am I running?

uvx --from git+https://github.com/mcp-hub-corp/mcp.git@v2.0.1 mcp-hub-security --version
# → mcp-hub-security 2.0.1

Available Tools

7 tools

check_mcp_safetyA

Scan a Git repository for security vulnerabilities before running it as an MCP server.

Performs a full security analysis against 14 vulnerability classes including prompt injection, secret exposure, tool poisoning, SSRF, and more.

Automatically consumes 5 credits from your MCP Hub account for new scans. Returns instantly using a cached result if the repository was already scanned at the same commit.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Git repository URL (GitHub, GitLab, or Bitbucket). Example: https://github.com/org/mcp-server

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description discloses credit cost (5 credits for new scans) and caching behavior (instant return for re-scans). No annotation contradiction. It does not describe side effects beyond credit deduction, which is acceptable for a read-like 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?

The description is five sentences, with the main action front-loaded. Every sentence provides necessary information without redundancy.

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?

The description covers purpose, usage, behavior, and parameter effectively. Since an output schema exists, it is not required to detail return values. Minor gap: could mention that scanning checks multiple vulnerability classes, but already listed.

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

Parameters4/5

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

The single parameter 'url' is already well-described in the schema (100% coverage). The description adds value by specifying supported platforms (GitHub, GitLab, Bitbucket) and providing an example.

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

Purpose5/5

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

The description clearly states it scans a Git repository for security vulnerabilities before running as an MCP server, and lists specific vulnerability classes. It differentiates from sibling tools which focus on 'skill' safety.

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

Usage Guidelines4/5

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

The description indicates when to use (before running as MCP server) and mentions credit consumption and caching. However, it does not explicitly state when not to use or provide alternatives, though siblings cover different domains.

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

check_skill_safetyA

Scan a Claude Code Skill (SKILL.md) provided as a string for security vulnerabilities.

Analyses the skill against 17 analyzers covering 61 rules including instruction override, capability abuse, prompt injection hooks, and more.

Automatically consumes 5 credits for new scans. Returns instantly for cached content.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw SKILL.md content (the full file text).
`skill_name`	No	Human-readable name for the skill. Defaults to "unnamed".	unnamed

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses credit consumption (5 credits per new scan), caching behavior, and the scope of analysis (17 analyzers, 61 rules, specific vulnerability types). This adds significant behavioral context beyond the basic purpose.

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

Conciseness4/5

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

The description is concise with three sentences, front-loading the main action. It avoids redundancy but could be slightly more streamlined without losing clarity.

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?

Given the presence of sibling tools and an output schema, the description covers core functionality, credit usage, and caching. It lacks mention of prerequisites or alternative scenarios, but overall provides sufficient context for an agent.

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?

Schema coverage is 100% with both content and skill_name described adequately. The description adds minimal extra meaning beyond the schema, like the term 'raw SKILL.md text', but does not enhance understanding of parameter usage.

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

Purpose5/5

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

The description clearly states the tool scans a Claude Code Skill (SKILL.md) as a string for security vulnerabilities, which is a specific verb+resource. It distinguishes from sibling tools like check_skill_safety_url (URL input) and check_mcp_safety (different target).

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 description implies usage for string content but does not explicitly state when to use this tool versus alternatives like check_skill_safety_url. There is no 'when not to use' guidance or comparison to siblings, leaving the agent to infer context.

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

check_skill_safety_urlA

Fetch a SKILL.md from a URL and scan it for security vulnerabilities.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL pointing to raw SKILL.md content (e.g. a GitHub raw URL).
`skill_name`	No	Human-readable name for the skill. Defaults to "unnamed".	unnamed

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states the action (fetch and scan) without disclosing behavioral traits such as rate limits, authentication requirements, potential side effects (e.g., network requests), or handling of malformed URLs.

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?

The description is a single, efficient sentence with no redundant words. It front-loads the main action and resource, achieving high information density.

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

Completeness3/5

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

For a simple tool with an output schema, the description captures the core function. However, it omits details like what types of vulnerabilities are scanned, error handling, or any prerequisites, which would be helpful for an agent.

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?

Schema coverage is 100%, with clear descriptions for both parameters (URL format and human-readable name). The description adds no further meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the action (fetch and scan), the resource (SKILL.md from a URL), and the purpose (security scanning). It distinguishes from siblings like check_skill_safety which likely operates on an already-fetched skill, and check_mcp_safety which is for MCP safety.

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 description implies usage when a URL to SKILL.md is available, but does not explicitly state when to use this tool versus its siblings, nor provides when-not-to-use scenarios or alternatives like check_skill_safety.

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

get_credit_balanceA

Check your current MCP Hub credit balance.

Returns: credits (float): Current credit balance. email (str): Account email address.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the tool as a read-only check (returns credits and email) but does not mention potential authentication requirements, rate limits, or other behavioral traits. It is adequate for a simple query but lacks deeper context.

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?

The description is extremely concise: one sentence for purpose and a bullet list of returns. No unnecessary words, and key information is front-loaded.

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?

Given the tool's simplicity (no params, straightforward output), the description is nearly complete. It explains the return values (credits and email) and the output schema exists. However, it lacks context about prerequisites (e.g., authentication) which could be assumed but not stated.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the description does not need to add parameter details. The description does not conflict with the schema and is sufficient for an empty input.

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

Purpose5/5

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

The description clearly states the tool checks the current MCP Hub credit balance, which is a specific verb+resource. It distinguishes itself from sibling tools (security checks) by its focus on account balance.

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

Usage Guidelines4/5

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

It explicitly says 'Check your current MCP Hub credit balance,' indicating when to use it. Although no alternatives or when-not-to-use are provided, the sibling tools are distinctly different, so confusion is unlikely.

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

get_scan_resultA

Get the full security scan result for a previously submitted scan.

Returns complete findings with file paths, line numbers, CWE IDs, and remediation guidance. Auto-unlocks the report (consuming 5 credits) if not already unlocked.

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes	Scan UUID returned by a previous check_mcp_safety() call.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

Discloses side effect: auto-unlocking report consuming 5 credits. Given no annotations, this adds important behavioral context. However, does not specify behavior if already unlocked or other potential costs.

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 concise sentences conveying purpose, return contents, and side effect. No wasted words, front-loaded with key action.

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?

Given simple input schema (1 param) and presence of output schema, description is sufficient. Covers purpose, credit consumption, and links to sibling. Could mention output format but schema covers that.

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

Parameters4/5

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

Schema coverage is 100% with description of scan_id. The description adds context by linking to sibling check_mcp_safety() call, which helps agent understand parameter origin beyond schema definition.

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

Purpose5/5

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

Clearly states it retrieves full security scan results for a previously submitted scan. The verb 'Get' and resource 'full security scan result' are specific, and it distinguishes from siblings like check_mcp_safety (submission) and get_verdict (different outcome).

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?

Implies usage after submission but does not explicitly say when to use or avoid. Mentions credit consumption but no alternatives or exclusions. Adequate but lacks explicit guidance.

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

get_skill_scanB

Retrieve a previous skill scan result by its UUID.

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes	Scan UUID returned by a previous check_skill_safety() call.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior, but it only states the action without mentioning side effects, read-only nature, error cases, or performance characteristics.

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?

The description is a single concise sentence (9 words) that captures the core function without extraneous detail.

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

Completeness3/5

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

Given the presence of an output schema and a single parameter, the description is adequate but minimal. It does not explain what a skill scan is or how the result is structured beyond the schema.

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?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the parameter's own description in the schema.

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?

The description clearly states the verb 'retrieve' and resource 'previous skill scan result' using a UUID. However, it does not explicitly differentiate from similar siblings like 'get_scan_result'.

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 description implies usage after a 'check_skill_safety()' call via the parameter description, but lacks explicit when-to-use/not-to-use guidance or alternatives.

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

get_verdictA

Get the security verdict for a previously scanned repository and evaluate policy.

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes	Scan UUID returned by a previous check_mcp_safety() call.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description must carry full behavioral burden. It states the tool returns a verdict and evaluates policy, but does not disclose if it's a read-only operation, error handling (e.g., invalid scan_id), rate limits, or authentication requirements.

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?

The description is a single 13-word sentence, front-loaded with the core purpose, and contains no superfluous information.

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

Completeness3/5

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

Given the simple interface (1 param, output schema exists), the description provides minimal context. It lacks error condition details or prerequisites (e.g., must have called check_mcp_safety), but the output schema may compensate for return value explanation.

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?

The input schema has 100% description coverage for the single parameter (scan_id). The description mentions 'previously scanned repository' but adds no significant meaning beyond the schema's explanation. Baseline 3 applies.

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

Purpose5/5

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

The description clearly states the tool retrieves a security verdict for a previously scanned repository and evaluates policy, distinguishing it from sibling tools like check_mcp_safety (which initiates scans) or get_scan_result (likely provides raw results).

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 description implies usage requires a prior scan ID, but does not explicitly specify when to use this tool versus alternatives like get_scan_result or when not to use it. No exclusion or preference context is provided.

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.

7 tool updatesv2.0.0May 12, 2026
- First observedcheck_mcp_safety
- First observedcheck_skill_safety
- First observedcheck_skill_safety_url
- First observedget_credit_balance
- First observedget_scan_result
- First observedget_skill_scan
- First observedget_verdict

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

A3.9/5.0

Scored 2026-05-12 17:15 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: scanning repos vs skills (string or URL), retrieving results, checking credits, and getting verdicts. No overlap in functionality.

Naming Consistency4/5

Names follow a consistent verb_noun pattern (check_*, get_*). The only minor deviation is 'check_skill_safety_url' appending a source descriptor, but it remains clear.

Tool Count5/5

Seven tools cover the core scanning workflow without bloat. Each tool serves a necessary function for the security analysis domain.

Completeness4/5

The tool surface covers scanning (repo and skill), result retrieval, credit management, and verdicts. A minor gap might be a bulk list of scans, but the set supports full cycles for the intended use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
skill-audit-mcp A
io.github.eltociear
Scan agent skills and MCP servers for malicious patterns before you load them
Security Penetration Testing
1116
gatewayOAuth
ai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security Agent Orchestration
11

Related MCP Servers

SkillGuard
Security Penetration Testing
epistemedeus
A
license
A
quality
D
maintenance
Enables scanning of Claude Code skills, plugins, or MCP servers for malware before installation via static analysis.
Updated 3 months ago (2026-06-24 07:43 UTC)
1
6 npm
MIT
airlock
Security Penetration Testing
ByJH
A
license
A
quality
C
maintenance
A security gate MCP server that audits agent extensions (skills, MCP servers, tools) by scanning for risks, adversarial analysis, and sandbox execution, returning a trust verdict of allow, quarantine, or block.
Updated 2 months ago (2026-07-07 03:21 UTC)
1
MIT
ToolBastion
Security Developer Tools
MaharMuavia
A
license
Not graded
quality
A
maintenance
A zero-trust security gateway for MCP tool calls, inspecting tool identity, arguments, execution decisions, and returned content before risk reaches your coding agent.
Updated 2 months ago (2026-07-21 16:34 UTC)
Apache 2.0
mcp-fortress
Security Penetration Testing
mcp-fortress
A
license
Not graded
quality
D
maintenance
Scans MCP servers for security vulnerabilities, prompt injection, and tool poisoning, providing risk scores and protection.
Updated 5 months ago (2026-04-20 13:24 UTC)
4
MIT

Table of Contents

What is this?

Features

Quick install

MCP client configuration

Environment variables

MCP servers

Skills

How it works

MCP server scan pipeline

Skill scan pipeline

Policy engine

Why MCPs and Skills have separate thresholds

Credits

Available tools

MCP server tools

Skill tools

Examples

Scan an MCP server before installing it

Block a server that exceeds your policy

Scan a Skill before running it

Re-evaluate policy on an existing scan

Check your credit balance

Troubleshooting

Claude Code says "Failed to connect"

ModuleNotFoundError or stale uvx cache

MCPHUB_API_KEY is required

What version am I running?

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`ModuleNotFoundError` or stale uvx cache

`MCPHUB_API_KEY is required`