Which integrations are available for this server?

Provides graphql_introspect tool to perform single introspection POST requests against GraphQL endpoints, returning schema summary and security observations. Provides phpggc_generate tool that wraps the phpggc CLI to generate PHP-deserialization gadget chains for security testing of PHP applications.

How do I use mcp-security-toolkit?

1. Click on "Install 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-security-toolkit Audit the MCP server I just built" 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-security-toolkit

by actions-marketplace-validations

Overview Schema Related Servers Score Discussions

Python

Local

mcp-security-toolkit

PyPI Python License: MIT Glama

Built by Redmai. For continuous autonomous API / agent security scanning, use Redmai.

Source / schema / prompt audit primitives for agent builders.

Plug into Claude Code / Cursor / Claude Desktop. Audit MCP servers, agent tool schemas, system prompts, JWTs, and HTTP-response diffs — locally, in the coding agent you already use. Atomic, auditable, no orchestration.

Why this exists

Most security-flavored MCP servers wrap an existing CLI (Burp, Shodan, CyberChef) or audit MCP configurations and tool descriptions. The primitives a developer reaches for when their own code ships an LLM feature — source-level audit of an MCP server, schema-level audit of an agent tool, static review of a system prompt — are thinly covered.

mcp-security-toolkit ships those primitives, plus the everyday pentest atoms an agent reaches for during AppSec work, so you can run one server instead of five.

Related MCP server: mcp-security-toolkit

Headline tools

`mcp_server_audit`

Heuristic AST audit of an MCP server's Python source. Enumerates @tool-decorated and imperatively-registered tools, then runs 13 detectors:

Detector	Category	Sev
Shell execution	`shell-exec`	high
Filesystem write/delete	`fs-write` / `fs-destructive`	med–high
Network egress	`network-egress`	medium
Code injection	`code-injection`	high
Over-broad params	`over-broad-param`	medium
Ambiguous/missing docstring	`ambiguous-description`	low–med
Secret read from env	`secret-in-env`	info
Path traversal	`path-traversal`	high
Prompt injection in docstring	`tool-description-injection`	medium
SSRF via URL param	`ssrf`	high
Resource URI → SQL injection	`mcp-resource-uri-sqli`	high
Tool shadowing (cross-tool)	`tool-shadowing`	medium

Tracks from X import Y [as Z] aliases so renamed dangerous imports don't slip through. Reports include a coverage.detectors_run list and limitations — absence of finding is NOT proof of safety.

Complements Snyk / Invariant Labs mcp-scan, which audits MCP configs and tool descriptions — this audits the source code of the server.

`agent_tool_risk_audit`

Takes a single agent tool's JSON schema and reports schema-level risks: over-broad params, ambiguous descriptions, missing constraints, exfil potential, dangerous defaults.

`prompt_injection_audit`

Static review of a system prompt / template for injection surface. Flags untrusted placeholders, missing delimiters, trust-boundary violations, dangerous-instruction patterns.

`owasp_llm_classify`

Map a finding or observation to OWASP LLM Top 10 (2025) with reasoning and severity. Useful in reports and ticket creation.

`http_diff`

Appsec-focused diff of two HTTP responses. For manual auth-bypass / IDOR triage. Highlights set/added/removed headers, status changes, body diffs, and security-relevant cookies.

`jwt_inspect`

Decode + audit a JWT. Flags alg:none, weak HS-secrets (small dictionary check), expiry, missing standard claims, suspicious kid (path traversal), external key URLs (jku, x5u).

Pentest pack (atomic primitives)

Bundled so an agent has the basics without needing five MCP installs. Each tool is one input → one output, no chaining.

default_creds_lookup — known default credentials by vendor / product (50+ products, aliases like fortigate, idrac, wp)
sensitive_files_list — curated sensitive paths per tech stack (common, php, wordpress, dotnet, java, node, python, k8s, docker, ci); returns paths only, does not probe
wordlist_gen — OSINT-driven wordlist generator (passwords / usernames / subdomains modes)
graphql_introspect — single introspection POST → schema summary + security observations
phpggc_generate — wraps phpggc CLI for PHP-deserialization gadget chains (graceful if binary missing)
interactsh_register / interactsh_poll / interactsh_stop — wraps interactsh-client CLI for OOB callback URL capture (blind SSRF / XXE / RCE confirmation). _stop terminates and cleans up the session; TTL gc runs on every register

Example output

Real output from three of the headline tools. Click to expand.

{
  "file": "sample_mcp_server.py",
  "tools_found": 4,
  "summary": {"high": 1, "medium": 5, "low": 1, "info": 1},
  "tools": [
    { "name": "safe_echo", "findings": [] },
    {
      "name": "run_cmd",
      "findings": [
        {"category": "ambiguous-description", "severity": "low",
         "message": "docstring is very short (4 chars) — risk of LLM misuse"},
        {"category": "over-broad-param", "severity": "medium",
         "message": "parameter `cmd`: command-like parameter typed as bare `str`"},
        {"category": "shell-exec", "severity": "high",
         "message": "calls `subprocess.run`"}
      ]
    },
    {
      "name": "read_anything",
      "findings": [
        {"category": "ambiguous-description", "severity": "medium",
         "message": "tool has no docstring — the LLM cannot reason about when to use it"},
        {"category": "over-broad-param", "severity": "medium",
         "message": "parameter `path`: path-like parameter typed as bare `str` (no allow-list)"}
      ]
    },
    {
      "name": "write_log",
      "findings": [
        {"category": "over-broad-param", "severity": "medium",
         "message": "parameter `path`: path-like parameter typed as bare `str` (no allow-list)"},
        {"category": "fs-write", "severity": "medium",
         "message": "opens file for writing (mode='a')"}
      ]
    }
  ],
  "file_level_findings": [
    {"category": "secret-in-env", "severity": "info",
     "message": "reads secret from env `SECRET_API_KEY` — ensure it is documented in README and never logged"}
  ]
}

{
  "tool_name": "shell_exec",
  "detected_format": "mcp",
  "findings": [
    {"category": "ambiguous-description", "severity": "medium", "path": "<tool>",
     "message": "description is very short (5 chars) — high risk of LLM misuse"},
    {"category": "risky-name-vague-desc", "severity": "medium", "path": "<tool>",
     "message": "tool name suggests it executes ('exec') but description is brief — agent may misuse"},
    {"category": "over-broad-param", "severity": "high", "path": "cmd",
     "message": "command-like param `cmd` is bare string — agent can execute arbitrary commands"},
    {"category": "over-broad-param", "severity": "high", "path": "url",
     "message": "url-like param `url` is bare string with no `pattern` — agent can reach arbitrary hosts (SSRF / exfil)"},
    {"category": "dangerous-default", "severity": "medium", "path": "verify_ssl",
     "message": "safety-related param `verify_ssl` defaults to `False` — disables a safeguard by default"},
    {"category": "exfil-shape", "severity": "medium", "path": "<tool>",
     "message": "tool accepts both a URL-like destination and a data-like payload — classic exfil shape"}
  ]
}

{
  "valid_structure": true,
  "header": {"alg": "HS256", "typ": "JWT"},
  "payload": {"sub": "1234567890", "name": "John Doe", "iat": 1516239022},
  "weak_secret": "your-256-bit-secret",
  "findings": [
    {"category": "missing-claim", "severity": "medium",
     "message": "no `exp` claim — token never expires"},
    {"category": "missing-claim", "severity": "low", "message": "no `iss` claim"},
    {"category": "missing-claim", "severity": "low", "message": "no `aud` claim"},
    {"category": "weak-secret", "severity": "high",
     "message": "signature verifies with common weak secret: 'your-256-bit-secret'"}
  ]
}

Recommended companion MCP servers

For deeper coverage in adjacent areas we explicitly recommend (and do not duplicate):

PortSwigger/mcp-server — Burp Suite
ChromeDevTools/chrome-devtools-mcp — Chrome DevTools
invariantlabs-ai/mcp-scan — MCP config / tool-description audit (complementary to our source-level audit)
mukul975/cve-mcp-server — full 27-tool CVE intelligence server

Install

pip install mcp-security-toolkit

{
  "mcpServers": {
    "sec": { "command": "mcp-security-toolkit" }
  }
}

Developing locally

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
pytest
ruff check .

End-to-end MCP smoke test (boots the server over stdio, lists tools, calls two of them):

python scripts/smoke_mcp.py

Defensive helpers — fix what we detect

The tools above find unsafe patterns in MCP servers. The mcp_security_toolkit.helpers package is the inverse: drop-in primitives an MCP author imports to make their tools safe by construction.

from mcp_security_toolkit.helpers import (
    safe_path, safe_filename, safe_url, safe_sql_identifier, evaluate_expression,
)

@mcp.tool()
def read_log(name: str) -> str:
    p = safe_path(name, root="/var/log/myapp", must_exist=True)
    return p.read_text()

@mcp.tool()
def save_upload(filename: str, data: bytes) -> str:
    name = safe_filename(filename)                          # basename-only
    (Path("/var/uploads") / name).write_bytes(data)
    return name

@mcp.tool()
def fetch_url(url: str) -> str:
    url = safe_url(url)                                     # blocks SSRF
    return httpx.get(url, timeout=5).text

ALLOWED_TABLES = {"users", "orders", "events"}

@mcp.tool()
def count_rows(table: str) -> int:
    table = safe_sql_identifier(table, allow=ALLOWED_TABLES)
    return db.execute(f"SELECT COUNT(*) FROM {table}").scalar()

@mcp.tool()
def evaluate_formula(expr: str, price: float, qty: int) -> float:
    return evaluate_expression(expr, variables={"price": price, "qty": qty})

Pure functions, no I/O, no globals. Each fixes the corresponding mcp_server_audit finding category in one line.

GitHub Action

Drop into any repo to run mcp_server_audit in CI, upload SARIF to the Security tab, and fail the build on configured severity:

# .github/workflows/mcp-audit.yml
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v5
      - uses: x0base/mcp-security-toolkit@v0.3
        with:
          path: src/my_mcp_server.py
          fail-on-severity: high

CLI

# Default (no args): start the MCP stdio server — what your client config invokes
mcp-security-toolkit

# Audit every MCP server your local Claude / Cursor / Claude Desktop is configured to launch
mcp-security-toolkit scan-installed
mcp-security-toolkit scan-installed --sarif > findings.sarif

# Zero-install run, via uv
uvx mcp-security-toolkit scan-installed

Treat tool outputs as untrusted data

Some tools return content from attacker-controlled sources: http_diff quotes target response bodies, interactsh_poll returns raw OOB requests, graphql_introspect returns target-controlled schema names. If such a string contains "ignore previous instructions...", an LLM agent reading it may follow the embedded instruction — classic indirect prompt injection. MCP clients should render tool outputs inside delimiters (<tool_output>...) and not flow them silently into the next prompt. See THREAT_MODEL.md.

Non-goals

No orchestration, chaining, or decision logic across tools — primitives only.
No reimplementation of full-featured offensive CLIs (sqlmap, ghauri, dalfox); where wrapping a small, focused CLI is a natural fit (phpggc, interactsh-client), we wrap it directly with a graceful "binary not found" path.
No novel offensive research — all referenced techniques cite public sources.

License

MIT.

Available Tools

14 tools

agent_tool_risk_auditA

Statically audit a single agent tool definition for schema-level risks.

Accepts OpenAI function-calling, Anthropic tool-use, MCP tool, or a bare JSON Schema. Reports:

over-broad params (bare-string paths/commands/URLs)
missing constraints (enum/pattern/min/max/maxLength/maxItems)
dangerous defaults (suspicious paths, disabled safeguards)
exfil-shape (URL-destination + data-payload in the same tool)
ambiguous descriptions vs risky tool names

Args: schema: A tool definition as a dict.

Returns: Structured AuditReport. Pure function, no I/O, no chaining.

ParametersJSON Schema

Name	Required	Description	Default
`schema`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It explicitly states 'Pure function, no I/O, no chaining' and lists input formats and report categories, offering good transparency. Could mention error handling for malformed schemas.

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?

Description is front-loaded with purpose and structured with a list of reports, Args, and Returns. It is moderately concise, though the bullet points are presented as plain text, which is acceptable but slightly less readable.

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 complexity (auditing for schema risks) and absence of output schema, the description provides substantial context: input format, output type, and behaviors checked. It is sufficiently complete for an agent to understand usage.

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 schema has no description for the parameter, but the description explains 'schema: A tool definition as a dict', adding meaning beyond the schema's bare 'object' type. It clarifies acceptable formats (OpenAI, Anthropic, etc.).

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 verb 'audit' and the resource 'a single agent tool definition', and lists specific risk categories it checks, distinguishing it from siblings like mcp_server_audit or prompt_injection_audit.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it compares to sibling tools.

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

default_creds_lookupA

Return known default credentials for a vendor / product / service.

Accepts a short product name (cisco, tomcat, idrac, mongo), a full key (router:cisco, db:mongodb), or a substring match. Returns every credential pair across all matching keys.

Pure data lookup — no network, no scanning.

Args: query: vendor / product / service identifier (case-insensitive).

Returns: LookupReport with matched_keys and credentials.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

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 carries full burden. It transparently states it performs no network activity or scanning, indicating safe, read-only behavior. No side effects or rate limits are mentioned, but for this tool, that's acceptable.

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 concise and well-structured: a clear purpose sentence, bullet-like input explanation, and a behavioral note. Every sentence adds value with no 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?

Despite no output schema, the description mentions the return type (LookupReport with matched_keys and credentials) and explains input formats comprehensively. For a simple lookup tool, it provides sufficient context.

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?

Only one parameter 'query' with 0% schema coverage. The description compensates by explaining it accepts short product names, full keys, or substrings, adding significant meaning beyond the schema's type-only 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?

The description explicitly states the tool returns known default credentials, explains input formats (short product name, full key, substring), and output structure, clearly distinguishing it from sibling tools like 'sensitive_files_list' or 'wordlist_gen'.

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 notes 'Pure data lookup — no network, no scanning,' indicating when to use it (passive lookup) and when not (for active scanning). It does not explicitly name alternatives but provides clear context.

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

graphql_introspectA

Run a GraphQL introspection query against url and summarize the schema.

Single HTTP POST. Read-only. Will not mutate state on the server.

By default, requests resolving to private / loopback / link-local / cloud-metadata addresses are blocked (SSRF protection). Set allow_private=True to override — useful when explicitly auditing internal infrastructure.

Redirects are disabled (an HTTP 3xx from the target raises HTTP-error: redirects disabled). This prevents a public endpoint from redirecting the request to a private address after the pre-flight check.

Residual risk: DNS rebinding. The pre-flight resolution and the actual HTTP request happen in separate syscalls and the OS may resolve the hostname twice. A hostile DNS that returns a public IP for the check and a private IP for the request can defeat the guard. For high-stakes environments, run this tool inside a network namespace / egress proxy that enforces address restrictions independently.

Args: url: Full GraphQL endpoint URL (e.g. https://api.example.com/graphql). timeout: Network timeout in seconds (clamped to [1, 60]). insecure: Skip TLS verification (for self-signed certs in test envs). allow_private: Permit requests to private / internal addresses. Default False.

Returns: IntrospectReport summarizing the schema and security observations. If the URL resolves to a private address and allow_private is False, returns {"error": "blocked-private-address", ...}.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`timeout`	No
`insecure`	No
`allow_private`	No

TDQS

A4.8/5.0

Behavior5/5

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

No annotations provided, so description fully carries the burden. It discloses that it is a single HTTP POST, read-only, has SSRF protection with override, redirects disabled, and residual DNS rebinding risk. This is comprehensive and leaves no ambiguity about behavior.

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?

Well-structured with paragraphs and bullet points. Every sentence adds value without redundancy. The length is appropriate for the complexity, and key information is front-loaded.

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

Completeness5/5

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

No output schema exists, but the Returns section summarizes the return type and error case. All aspects (purpose, behavior, parameters, security, errors) are covered, making the description complete for the tool's complexity.

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

Parameters5/5

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

Schema coverage is 0%, but the Args section describes each parameter in detail: url, timeout (clamped), insecure (for self-signed certs), allow_private (default False). This adds significant meaning beyond the bare schema properties.

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 runs a GraphQL introspection query against a URL and summarizes the schema. The verb 'run' and resource 'GraphQL introspection query' are specific, and the tool is clearly distinguished from sibling tools which cover different security audit tasks.

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?

Provides clear context for when to use (introspect GraphQL APIs) and includes guidance on SSRF protection and the allow_private flag for internal audits. Does not explicitly list exclusions or alternatives, but sibling tools cover different areas making the use case obvious.

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

http_diffA

Diff two HTTP responses with security-relevant findings.

Inputs may be raw HTTP response strings (status line + headers + body) or dicts shaped {"status": int, "headers": list|dict, "body": str}.

Reports:

status transitions classed as auth-bypass-likely / idor-possible / etc.
header diffs with security-header and auth-header tagging
cookie attribute diffs (HttpOnly / Secure / SameSite removal flagged high)
body diff: size, content-type shift, error-leak hints, unified diff excerpt

Stateless. Two inputs in, one report out.

ParametersJSON Schema

Name	Required	Description	Default
`response_a`	Yes
`response_b`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully covers behavioral traits: stateless operation, input format options (strings or dicts), and detailed report content including status transitions, header diffs, cookie attribute diffs, and body diff. It is transparent about what the tool does.

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 well-structured with line breaks and bullet points. It front-loads the main purpose and uses clear, efficient language. Every sentence adds value.

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

Completeness5/5

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

Given there is no output schema, the description fully explains the report contents (status transitions, header diffs, cookie diff, body diff). Input formats are well-specified. The tool is simple (stateless, two inputs) and the description covers all needed context.

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

Parameters5/5

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

The input schema provides only generic titles for parameters. The description adds crucial meaning: 'Inputs may be raw HTTP response strings (status line + headers + body) or dicts shaped...' This clarifies the expected structure beyond the schema.

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 diffs two HTTP responses with security-relevant findings. It specifies the resource (HTTP responses) and the action (diff). No sibling tool duplicates this function, so it distinguishes effectively.

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 implies when to use (comparing HTTP responses for security analysis) and notes statelessness. It doesn't explicitly state alternatives or when not to use, but the unique functionality makes the context clear.

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

interactsh_pollA

Read captured OOB interactions for a previously-registered token.

Args: token: token returned by interactsh_register.

Returns: PollReport with all interactions captured so far.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description carries burden. States it 'Reads' interactions and returns a PollReport, which implies non-destructive read. However, no mention of whether polling consumes data, rate limits, or other behavioral traits.

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?

Extremely concise: two sentences plus structured Args/Returns. No fluff, front-loaded with purpose. Every sentence earns its place.

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?

Adequate for a simple tool with one parameter. Includes return description (PollReport). Lacks detail on what PollReport contains, but acceptable given low complexity.

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 has 0% description coverage, but description adds crucial context: token is 'returned by interactsh_register'. This links it to the registration process, adding value beyond 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?

Clearly states verb 'Read' and resource 'OOB interactions for a previously-registered token'. Purpose is well-defined, but does not explicitly differentiate from sibling tools like interactsh_register or interactsh_stop.

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 registration (token from interactsh_register), but lacks explicit when-to-use or when-not-to-use guidance. No alternatives mentioned despite related siblings.

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

interactsh_registerA

Spawns interactsh-client detached, captures the assigned callback URL, and persists a session descriptor for later polling. Returns a token that pairs with interactsh_poll.

Args: server: interactsh server hostname (default interact.sh public). timeout: seconds to wait for the client to emit its URL.

Returns: RegisterReport with callback_url and token.

ParametersJSON Schema

Name	Required	Description	Default
`server`	No		interact.sh
`timeout`	No

TDQS

A4.3/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 key behaviors: spawning a detached process, capturing the URL, persisting a session descriptor, and returning a token. It does not detail cleanup, rate limits, or error handling, but covers the main operation sufficiently.

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 concise and front-loaded, with no unnecessary words. Each sentence earns its place: purpose, behavior, return value, and parameters.

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 complexity (spawning a CLI, persisting state, returning a token), the description covers the main aspects: what it does, parameters, and return type. No output schema exists, so the description's mention of RegisterReport with callback_url and token is helpful. Missing error conditions or prerequisites, but adequate overall.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It explains both parameters (server and timeout) with their purposes and defaults, adding meaning beyond the schema's type definitions.

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 tool registers a callback URL via interactsh-client, naming the verb and resource. It hints at the workflow by mentioning the returned token pairs with interactsh_poll, but does not explicitly differentiate from siblings like interactsh_poll or interactsh_stop.

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 provides clear context by stating the token pairs with interactsh_poll, implying the sequential use of register then poll. No exclusions or when-not-to-use guidance are given, but the workflow hint is valuable.

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

interactsh_stopA

Stop a previously-registered interactsh-client session and clean up.

Terminates the spawned interactsh-client process (best-effort) and removes the session descriptor. The log file is removed by default (set delete_log=False to keep it for post-mortem).

Args: token: token returned by interactsh_register. delete_log: also remove the session log file (default True).

Returns: {"stopped": bool, "log_removed": bool, "note": str | None}

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes
`delete_log`	No

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It states termination of the process (best-effort) and removal of session descriptor and log file (by default). This is fairly transparent, though it does not mention graceful vs forceful termination or other side effects.

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 concise (four sentences) with a clear structure: main purpose, details, then Args and Returns. Every sentence adds value with no redundancy.

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

Completeness5/5

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

For a simple stop/cleanup tool with 2 parameters (1 required) and no output schema, the description covers the action, inputs, and return format completely. The returns are explicitly described in a structured note.

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

Parameters5/5

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

Schema coverage is 0%, but the description adds significant value: token is described as 'token returned by interactsh_register', and delete_log is described as 'also remove the session log file (default True)'. This fully explains the parameters' purposes.

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 explicitly states the tool stops a previously-registered interactsh-client session and cleans up. It uses specific verbs ('stop', 'clean up') and resource ('interactsh-client session'). The sibling tools include interactsh_register and interactsh_poll, making this distinct.

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 use after registration and polling, but does not explicitly state when to use this tool versus alternatives (e.g., interactsh_register, interactsh_poll). No when-not or alternative guidance is provided.

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

jwt_inspectA

Decode and audit a JWT.

Reports algorithm issues (none, weak HS*), expiry, missing standard claims (exp, iat, iss, aud), suspicious kid values that look like path traversal or SQL, and (optionally) checks the signature against a small dictionary of common weak HS256/384/512 secrets.

Args: token: The JWT string (three dot-separated base64url segments). check_weak_secrets: If True, attempt a small dictionary of common secrets against the signature for HS* algorithms. Default True.

Returns: Structured inspection report (see JwtInspection schema).

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes
`check_weak_secrets`	No

TDQS

A4.1/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses all behavioral traits: decoding, auditing specific claim issues, and optional weak secret checking. It states it returns a structured report. However, it does not mention if the tool has any side effects or is purely read-only.

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 front-loaded with the purpose and uses bullet-style listing for details. Although slightly verbose, each sentence adds value. It could be tightened but remains well-structured.

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 complexity of JWT inspection, the description covers most essential aspects. However, the lack of an output schema means the agent does not know the exact structure of the returned inspection report, which is a gap.

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

Parameters5/5

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

With 0% schema coverage, the description adds essential meaning: token is described as 'JWT string (three dot-separated base64url segments)' and check_weak_secrets explains its default and behavior. This fully compensates for the missing schema descriptions.

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 explicitly states 'Decode and audit a JWT' and lists specific checks (algorithm issues, expiry, missing claims, suspicious kid, weak secret check), making the purpose clear and distinct from sibling tools like graphql_introspect or owasp_llm_classify.

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?

While the description implies usage for JWT analysis, it does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on preconditions like token format validation.

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

mcp_server_auditA

Statically audit an MCP server Python source file.

Enumerates tools registered with FastMCP-style @*.tool() decorators (and imperative mcp.tool()(fn) calls) and reports risk findings per tool: shell execution, filesystem writes, network egress, code injection, over-broad parameter types, and ambiguous/short descriptions.

Args: path: Absolute path to a Python file defining an MCP server. max_bytes: Reject files larger than this (default 5 MB). Prevents DoS via huge input. Pass a larger value if you need to audit a big monolith, but consider splitting it first.

Returns: Structured audit report (see AuditReport schema). Does NOT execute the target file. Includes a coverage block and limitations list — absence of finding is NOT proof of safety.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_bytes`	No

TDQS

A4.3/5.0

Behavior5/5

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

The description explicitly states it performs static analysis ('Does NOT execute the target file'), enumerates risk categories (shell execution, filesystem writes, etc.), and warns that absence of findings is not proof of safety. This exceeds what annotations would provide (none exist).

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 and front-loaded with the core action. The prose is clear and avoids redundancy, though it could be slightly more terse by removing parenthetical clarifications.

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

Completeness5/5

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

Given the simplicity (2 parameters, no output schema, no annotations), the description is complete: it covers parameters, behavior, return structure (coverage/limitations), and key constraints. No critical information is omitted.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates: it explains 'path' as an absolute path to a Python file and 'max_bytes' as a DoS protection mechanism with default value and advice for large files.

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's purpose: 'Statically audit an MCP server Python source file.' It specifies the exact resource and action, and distinguishes from siblings (e.g., agent_tool_risk_audit) by focusing on FastMCP-style decorators and risk findings.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance is provided. The description does not mention sibling tools or alternative scenarios, leaving the agent to infer usage solely from the purpose.

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

owasp_llm_classifyA

Map a finding or observation to OWASP LLM Top 10 (2025) categories.

Pure rule-based: keyword and regex patterns with weights per category. Returns the top top_n matching categories with the matched evidence snippets and a confidence score.

Args: observation: Free-form text describing a finding, scan result, bug report, threat model entry, or security observation. top_n: Number of matches to return (default 3).

Returns: ClassifyReport with ranked matches. If nothing matches, unmatched is True and matches is empty.

ParametersJSON Schema

Name	Required	Description	Default
`top_n`	No
`observation`	Yes

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 fully explains the behavioral traits: it is rule-based using keyword and regex patterns with weights, and returns top matches with evidence snippets and confidence. It also clarifies the return format when no matches are found.

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 concise (9 lines) and front-loaded with the core purpose. Every sentence adds value, with no redundant or filler content.

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 no output schema, the description adequately explains the return type (ClassifyReport with matches and unmatched flag). It covers input constraints and expected output, though additional details on confidence scoring could be useful.

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 description coverage is 0%, but the description compensates by explaining both parameters: 'observation' as free-form text describing findings, and 'top_n' as the number of matches with a default of 3. This adds meaning beyond the schema.

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 maps findings to OWASP LLM Top 10 categories, with a specific verb and resource. It distinguishes itself from sibling tools, which are unrelated security audit tools.

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 provides clear context for when to use the tool (mapping observations to OWASP categories) and lists example inputs. It does not explicitly state when not to use it, but the sibling tools cover different tasks, making the intent clear.

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

phpggc_generateA

Generate a single PHP unserialize gadget chain via phpggc.

Args: chain: Gadget chain identifier (e.g. Laravel/RCE9, Symfony/RCE4, Monolog/RCE1). Run phpggc -l locally to enumerate. command: Shell command to embed in the chain (e.g. id, curl ...). encoding: One of raw, base64, url, json, soft. fast_destruct: Adds --fast-destruct (triggers without await). extra_args: Extra raw arguments to pass through.

Returns: PhpggcReport with the generated payload (string). If phpggc is not installed, available is False.

ParametersJSON Schema

Name	Required	Default
`chain`	Yes
`command`	Yes
`encoding`	No	base64
`extra_args`	No
`fast_destruct`	No

TDQS

A4/5.0

Behavior2/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 mentions returning a PhpggcReport and that `available` is False if phpggc is missing, but fails to disclose behavioral traits like executing shell commands, security implications, or potential side effects of generating exploit payloads.

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 concise, with a clear Args section and Returns section. Every sentence is informative, and there is no 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?

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is fairly complete. It explains inputs, output structure (PhpggcReport with payload and available flag), and a note on installation. However, it could benefit from mentioning potential risks.

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 description coverage is 0%, but the description compensates by explaining each parameter: chain (with example), command, encoding (listing options), fast_destruct (adding raw argument), and extra_args. It adds meaning beyond the schema's type/constraints.

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 starts with a specific verb ('Generate') and resource ('PHP unserialize gadget chain via `phpggc`'), clearly distinguishing the tool from its siblings which are unrelated security tools.

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 lists all parameters and explains how to use them, including a hint to run `phpggc -l` locally. It implicitly covers when to use (generating gadget chains) but does not explicitly state when not to use or provide alternatives.

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

prompt_injection_auditA

Statically analyze a system prompt / template for prompt-injection surface.

Reports:

placeholders (jinja {{x}}, fstring {x}, dollar ${x}, percent %(x)s) with a trust classification (untrusted / trusted / unknown)
missing-delimiter findings: untrusted placeholders not wrapped in XML tags / triple-backticks / triple-quotes / [START]..[END] etc.
dangerous-instruction patterns (ignore previous instructions, role overrides, trust-boundary violations, system-prompt leakage hints, special-token sequences)
precedence-inversion: untrusted content placed near the end with no instruction reinforcement after it

Pure function. No LLM call, no I/O, no chaining.

Args: prompt: The system prompt or template text.

Returns: Structured AuditReport.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes

TDQS

A4/5.0

Behavior4/5

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

The description explicitly states it is a pure function with no LLM call, no I/O, and no chaining, which is valuable transparency given no annotations. It also details the analysis types, though it lacks explanations of performance or size limits.

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 concise and well-structured: a one-sentence overview, bullet-point list of reports, and a final line for behavioral traits. Every part adds value with no 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?

Given the tool has one parameter, no output schema, and no annotations, the description is mostly complete. It covers purpose, behavior, and return format (Structured AuditReport). Minor omissions like prompt length limits are acceptable.

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?

With 0% schema description coverage, the description must compensate. It provides a basic definition for the single parameter 'prompt: The system prompt or template text.' This is adequate but does not add format or length constraints.

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's purpose: statically analyze a system prompt for prompt-injection surface. It lists specific reports (placeholders, missing delimiters, dangerous patterns, precedence inversion), making it distinct from siblings like owasp_llm_classify.

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 security analysis of prompts but does not explicitly state when to prefer this tool over siblings or provide exclusions. The context from sibling names gives some guidance, but direct advice is missing.

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

sensitive_files_listA

Return curated sensitive-path lists for a given tech stack.

Args: stack: Comma-separated stack hints. Supported keys: common, php, wordpress, dotnet, java, node, python, k8s, docker, ci. include_common: If True (default), always include the common set.

Returns: FilesReport with paths (each {path, why}). No network is performed.

ParametersJSON Schema

Name	Required	Description	Default
`stack`	No		common
`include_common`	No

TDQS

A4.6/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. It discloses that no network is performed and describes the return format (FilesReport with paths). This provides good transparency about the tool's behavior and non-destructive nature.

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 concise, with a clear summary line followed by structured argument definitions. Every sentence adds information without redundancy or fluff.

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

Completeness5/5

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

Given the simple nature of the tool (2 parameters, no output schema), the description covers all necessary aspects: input parameters, default behavior, return structure, and side-effect information (no network). It is complete for an agent to use correctly.

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

Parameters5/5

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

The schema has 0% description coverage, but the description fully explains both parameters: stack lists supported keys, and include_common describes its default and effect. This adds significant value beyond the schema's type and default fields.

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 'Return curated sensitive-path lists for a given tech stack,' specifying the verb, resource, and context. It effectively distinguishes this tool from siblings like graphql_introspect or http_diff, which have different purposes.

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 explains how to use the stack and include_common parameters, and notes that no network is performed. While it doesn't explicitly list when not to use the tool or alternatives, the provided context is sufficient for typical usage.

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

wordlist_genA

Generate a wordlist tailored to the target surface.

Modes:

passwords: combine brand / keyword seeds with leet substitution, capitalization variants, common suffixes and year suffixes.
usernames: combine person names into common patterns (first, last, first.last, flast, firstl, …).
subdomains: combine brand + keywords with a curated list of common environment / service subdomain labels.

Pure function. No network.

Args: mode: One of passwords, usernames, subdomains. brand: Target organization brand (used in all modes). names: List of person names ("Jane Doe") for usernames mode. keywords: Additional seed words for passwords / subdomains. years: Year strings to append (passwords mode). max_size: Hard cap on returned entries.

Returns: GenReport with sample (the wordlist itself, up to max_size).

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes
`brand`	No
`names`	No
`years`	No
`keywords`	No
`max_size`	No

TDQS

A4.6/5.0

Behavior4/5

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

Without annotations, the description carries the full burden. It explicitly states 'Pure function. No network.' which is a key behavioral trait. It also describes the return type (GenReport with sample) and the hard cap via max_size. However, it doesn't mention if there are any limits on input sizes or potential errors.

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 highly concise and well-structured: a one-line summary, then bulleted mode descriptions with clear transformations, followed by a parameter list. Every sentence adds value, and the format is easy to parse for an AI agent.

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

Completeness5/5

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

Given 6 parameters, no output schema, and no annotations, the description covers all essential aspects: purpose, mode details, parameter roles, behavioral traits (pure, no network), and return type. There are no obvious gaps that would hinder correct invocation.

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

Parameters5/5

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

The input schema has no descriptions (0% coverage), but the tool description fully compensates by explaining each parameter: mode enum, brand used across modes, names for usernames, keywords for passwords/subdomains, years for passwords, and max_size as a cap. This provides all necessary semantic context beyond the raw schema.

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's purpose: 'Generate a wordlist tailored to the target surface.' It lists three distinct modes (passwords, usernames, subdomains) with specific transformations, making it easy to understand the output. The tool's function is well-differentiated from sibling tools which focus on audits, creds lookup, etc.

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 provides explicit usage scenarios by mode (e.g., combine brand/keywords with leet substitution for passwords). It doesn't state when to avoid using the tool, but the mode descriptions implicitly guide appropriate contexts. No explicit alternatives are given, but the sibling tools are clearly different.

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. Dates show when Glama detected each change.

14 tool updatesv0.3.1Jul 5, 2026
- First observedagent_tool_risk_audit
- First observeddefault_creds_lookup
- First observedgraphql_introspect
- First observedhttp_diff
- First observedinteractsh_poll
- First observedinteractsh_register
- First observedinteractsh_stop
- First observedjwt_inspect
- First observedmcp_server_audit
- First observedowasp_llm_classify
- First observedphpggc_generate
- First observedprompt_injection_audit
- First observedsensitive_files_list
- First observedwordlist_gen

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, from auditing agent tool schemas to generating PHP gadget chains. No two tools overlap in functionality or target domain.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a domain-specific prefix (e.g., graphql_introspect, jwt_inspect, wordlist_gen), making them predictable and easy to distinguish.

Tool Count5/5

14 tools is a well-scoped collection for a security toolkit. Each tool serves a distinct purpose without redundancy, and the count is neither too small nor too large for the domain.

Completeness3/5

The toolkit covers a wide range of security utilities, but there are notable gaps for a generic security toolkit (e.g., no port scanning, exploitation beyond PHP gadget chains, or vulnerability scanning). The focus seems skewed toward MCP and LLM security, but the presence of generic tools like default_creds_lookup suggests a broader scope, which is not fully covered.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
Helixar Security A
ai.helixar
Security tools for AI agents: scan MCP servers, validate HDP delegation chains, audit releases.
Security Penetration Testing
2
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
1
StackResolve C
dev.stackresolve
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Developer Tools
151

Related MCP Servers

agent-audit
Penetration Testing Security
piiiico
A
license
Not graded
quality
C
maintenance
Security scanner for MCP servers. Detects prompt injection, command injection, auth bypass, and excessive permissions across tools, resources, and prompts.
Updated 4 months ago (2026-05-04 22:47 UTC)
26
2
MIT
mcp-security-toolkit
Penetration Testing Code Analysis
x0base
A
license
A
quality
C
maintenance
14 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.
Updated a month ago (2026-08-02 19:53 UTC)
14
MIT
owasp-mcp-scan
Security Penetration Testing
CodingSelim
A
license
Not graded
quality
B
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.
Updated a month ago (2026-08-01 07:46 UTC)
85
MIT
mcp-audit
Security Penetration Testing
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.
Updated 4 days ago (2026-09-02 09:54 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/actions-marketplace-validations/x0base_mcp-security-toolkit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server