This server provides security auditing primitives and pentesting utilities for AI agents and developers, covering static analysis, network reconnaissance, and attack-preparation tools.
Security Auditing
mcp_server_audit — Statically audit MCP server Python source code (AST-based) for 13+ risk categories: shell execution, path traversal, SSRF, code injection, secret reads, tool shadowing, and more
agent_tool_risk_audit — Analyze agent tool JSON schemas for over-broad parameters, dangerous defaults, missing constraints, and exfiltration shapes
prompt_injection_audit — Review system prompts/templates for injection surface, untrusted placeholders, missing delimiters, dangerous instructions, and precedence inversions
owasp_llm_classify — Map security findings to OWASP LLM Top 10 (2025) categories with confidence scores and reasoning
HTTP & Auth Analysis
jwt_inspect — Decode and audit JWTs; flags alg:none, weak algorithms, missing claims (exp, iss, aud), suspicious kid values, and external key URLs
http_diff — Security-focused diff of two HTTP responses to assist with auth-bypass and IDOR triage; highlights status, headers, cookies, and body changes
Pentest Primitives
default_creds_lookup — Look up known default credentials for 50+ vendors/products (e.g., Cisco, Tomcat, MongoDB)
sensitive_files_list — Get curated sensitive file path lists for various stacks (PHP, WordPress, .NET, Java, Node, Python, Kubernetes, Docker, CI)
wordlist_gen — Generate targeted wordlists for passwords, usernames, or subdomains
graphql_introspect — Run GraphQL introspection against an endpoint and summarize the schema with security observations (includes SSRF protection)
phpggc_generate — Generate PHP deserialization gadget chain payloads via the phpggc CLI
OOB Callback Capture (Blind SSRF/XXE/RCE)
interactsh_register — Register a new out-of-band callback URL and get a session token
interactsh_poll — Poll for captured OOB interactions for a registered session
interactsh_stop — Terminate an interactsh session and clean up resources
Includes curated sensitive file paths for Docker in its sensitive_files_list tool.
Provides tools for introspection of GraphQL APIs, returning schema summaries and security observations.
Wraps the phpggc CLI to generate PHP deserialization gadget chains for security testing.
Includes curated sensitive file paths for WordPress in its sensitive_files_list tool.
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.
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: agentscore-mcp-server
mcp_server_auditHeuristic 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 |
| high |
Filesystem write/delete |
| med–high |
Network egress |
| medium |
Code injection |
| high |
Over-broad params |
| medium |
Ambiguous/missing docstring |
| low–med |
Secret read from env |
| info |
Path traversal |
| high |
Prompt injection in docstring |
| medium |
SSRF via URL param |
| high |
Resource URI → SQL injection |
| high |
Tool shadowing (cross-tool) |
| 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_auditTakes 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_auditStatic review of a system prompt / template for injection surface. Flags untrusted placeholders, missing delimiters, trust-boundary violations, dangerous-instruction patterns.
owasp_llm_classifyMap a finding or observation to OWASP LLM Top 10 (2025) with reasoning and severity. Useful in reports and ticket creation.
http_diffAppsec-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_inspectDecode + 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).
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
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'"}
]
}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
pip install mcp-security-toolkit{
"mcpServers": {
"sec": { "command": "mcp-security-toolkit" }
}
}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.pyThe 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.
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# 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-installedSome 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.
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.
MIT.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool as 'Pure function, no I/O, no chaining,' which clearly communicates its safe, side-effect-free behavior. It also lists the types of risks it reports. Without annotations, this provides adequate transparency, though it could mention error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, bullet points for reported risks, and clear Args/Returns sections. Every sentence adds value without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description fully explains inputs, expected formats, analysis capabilities, return type, and behavior (pure function). No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'schema' as a generic object with no constraints. The description compensates by explaining that the parameter is 'A tool definition as a dict' and lists the acceptable formats (OpenAI function-calling, etc.), adding critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Statically audit a single agent tool definition for schema-level risks.' It specifies the verb (audit), resource (agent tool definition), and scope (single, static). This distinguishes it from sibling tools like 'mcp_server_audit' which likely audits an entire server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists accepted input formats (OpenAI, Anthropic, MCP, bare JSON Schema) but does not explicitly guide when to use this tool versus alternatives like 'mcp_server_audit' or 'prompt_injection_audit'. Usage context is implied but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Pure data lookup — no network, no scanning,' which is a key behavioral trait. It does not mention potential side effects or authentication needs, but for a simple lookup this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then provides input examples and a disclaimer. It is slightly verbose but each sentence adds value. It is well-structured with an 'Args' section, balancing informativeness and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers everything needed: purpose, input format, case-insensitivity, and return structure (LookupReport with matched_keys and credentials). It is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'query' is described in detail: it accepts vendor/product/service identifier, is case-insensitive, and examples are given. Since schema description coverage is 0%, the description fully compensates by adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns known default credentials for a vendor/product/service, with specific input examples (short name, full key, substring). It distinguishes from sibling tools by noting it's a pure data lookup without network or scanning, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (lookup default credentials) and implicitly advises it's safe (pure lookup, no scanning). However, it does not explicitly state when not to use it or mention alternatives among siblings, missing full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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", ...}.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No | ||
| insecure | No | ||
| allow_private | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses read-only nature, SSRF protection, redirect behavior, and residual DNS rebinding risk. It also explains error returns for blocked private addresses. This is thorough, though it could briefly mention timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, security caveats, and parameter details. Every sentence adds value, with no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the tool's purpose, security considerations, error cases, and parameter effects. It is sufficiently complete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides detailed explanations for all four parameters (url, timeout, insecure, allow_private) in the Args section, adding meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run a GraphQL introspection query against url and summarize the schema.' This clearly identifies the tool's action and distinguishes it from siblings, none of which relate to GraphQL introspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (e.g., for inspecting GraphQL schemas) and explains security restrictions (SSRF, redirects). It does not explicitly state when not to use or mention alternatives, but the context is sufficient for an agent to gauge applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| response_a | Yes | ||
| response_b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavior: it is stateless, reports on status transitions with severity classes, header diffs with security tagging, cookie attribute diffs, and body diffs. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose, input format details, and a bulleted list of report outputs. Every sentence adds value, and it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema, no annotations), the description provides comprehensive coverage: input formats, report contents, and stateless nature. It is complete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by defining the expected structure for both parameters (raw HTTP response strings or dicts with specific fields), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diffs two HTTP responses with security-relevant findings. It uses specific verbs ('diff') and resources ('HTTP responses') and distinguishes itself from sibling tools that focus on other security tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies input formats (raw strings or dicts) and outlines the report contents, providing clear context for when to use the tool. However, it lacks explicit guidance on when not to use it or direct comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read captured OOB interactions for a previously-registered token.
Args:
token: token returned by interactsh_register.
Returns: PollReport with all interactions captured so far.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior but doesn't disclose potential side effects, token validity, or error conditions. Lacks detail for an external service interaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise, with no unnecessary words. Purpose is front-loaded, and Arg/Returns format is clear and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the 'Returns' section describes the result. The tool has only one parameter, and description covers purpose and parameter. Could mention edge cases like missing interactions or invalid tokens.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the 'Args' section explains token is 'token returned by interactsh_register', adding meaningful context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Read captured OOB interactions for a previously-registered token', using a specific verb and resource. It clearly distinguishes from sibling tools interactsh_register and interactsh_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains tool should be called with a token from interactsh_register, providing clear context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new interactsh callback URL via the interactsh-client CLI.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | interact.sh | |
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details spawning, capturing, and persisting behavior, and mentions return type. However, it does not disclose side effects like resource cleanup or prerequisites (e.g., CLI installation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then bulleted args. Compact and efficient – every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what, how, and return value. Lacks error handling or prerequisite details, but is sufficient for a simple registration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains both parameters: server hostname with default, and timeout as seconds to wait. This adds significant meaning beyond the schema's defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Register a new interactsh callback URL' with specific verb and resource. Differentiates from sibling tools like interactsh_poll by mentioning it returns a token that pairs with poll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes that it spawns a detached client and persists a session for polling, giving clear context. Implicitly guides use for out-of-band detection, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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}
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| delete_log | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: terminates process, removes session descriptor, default log removal, best-effort nature, and return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two paragraphs) with no fluff. Well-structured: brief summary then detailed args/returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description includes return values. All parameters and behavior documented. Sibling tools provide context. Complete for a clean-up tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains both parameters: token usage and delete_log default/behavior, adding essential meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (stop), resource (interactsh-client session), and cleanup. It distinguishes from siblings like interactsh_register and interactsh_poll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (after registration), but lacks explicit usage vs alternative tools. However, context from sibling names makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| check_weak_secrets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it decodes, audits, and optionally checks weak secrets. It does not mention side effects (likely none), but could be more explicit about being 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, uses bullet-style listing for checks, and separates args/returns. Could be slightly more compact, but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but description mentions a structured inspection report. It lacks specific fields or format details, which may leave the agent uncertain about the return structure. The checks are clear, but completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by explaining token as JWT string and check_weak_secrets as boolean with default True, adding context beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it decodes and audits a JWT, listing specific checks like algorithm issues, expiry, missing claims, suspicious kid, and weak secret detection. It distinguishes itself from sibling security tools by focusing on JWT inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (when a JWT needs security auditing). It does not explicitly state when not to use or compare to alternatives, but the sibling tools are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| max_bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it does not execute the file, includes limitations, and notes that absence of findings is not proof of safety. This is comprehensive and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with bullet points for risk findings and clear parameter explanations. It could be slightly shorter, but every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description references an 'AuditReport' schema and mentions coverage and limitations. It is sufficient for the tool's complexity, though more detail on the report structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full context: 'path' is the absolute path to a Python file, 'max_bytes' has a default of 5 MB with rationale for DoS prevention and advice for large files. This exceeds schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Statically audit an MCP server Python source file' and enumerates specific risk findings (shell execution, filesystem writes, etc.). It distinguishes itself from siblings by being the only tool focused on static analysis of MCP servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (static audit), explains non-execution (safe), and details the max_bytes parameter for preventing DoS. It lacks explicit when-not-to-use but is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| observation | Yes | ||
| top_n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the method as 'pure rule-based: keyword and regex patterns with weights per category' and explains the return structure (top_n matches, unmatched flag). No annotations exist, so the description fully handles the burden. Lacks potential caveats like sensitivity to phrasing, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with no wasted words: purpose, method, parameter descriptions, and return value are all covered in a few sentences. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains the return value (ClassifyReport with ranked matches or unmatched flag). The tool is simple (2 parameters) and the description covers all necessary aspects for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning: 'observation' is detailed as free-form text for various security artifacts, and 'top_n' is explained as number of matches (default 3). While not exhaustive, it compensates for the schema gap effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool maps findings to OWASP LLM Top 10 categories, specifying the verb (map) and resource (OWASP LLM Top 10). It distinguishes from siblings like agent_tool_risk_audit or graphql_introspect by focusing on LLM security categorization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples of valid inputs (finding, scan result, bug report, etc.) but does not mention when not to use or offer alternative tools. Given sibling tools are mostly other security utilities, the context is clear enough, but lacking exclusions prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| command | Yes | ||
| encoding | No | base64 | |
| fast_destruct | No | ||
| extra_args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description shoulders the burden. It explains the return status when phpggc is missing and lists all parameters including fast_destruct behavior. However, it omits error handling details for invalid chains or commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary followed by an Args list and Returns section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers purpose, all parameters, and the return value (PhpggcReport). It also addresses the installation dependency. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter with examples (chain identifiers, command types, encoding options, fast_destruct flag, extra_args). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a single PHP unserialize gadget chain via phpggc' with a specific verb and resource. It is distinct from sibling tools like risk audit or creds lookup, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating PHP gadget chains but lacks explicit when-to-use versus alternatives. It provides a tip to enumerate chains locally but no clear guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states behavioral traits: 'Pure function. No LLM call, no I/O, no chaining.' This goes beyond what annotations (none) provide, giving full transparency about side effects and resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement and a bullet list of findings. It is not overly verbose, though the bulleted details could be slightly more compact. Still, each sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's findings comprehensively but provides minimal detail about the output ('Structured AuditReport') and does not explain how results are structured or what to do with them. Given no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by defining the 'prompt' parameter as 'The system prompt or template text.' This adds crucial semantic meaning beyond the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Statically analyze a system prompt / template for prompt-injection surface.' It lists specific findings (placeholders, missing delimiters, dangerous patterns, precedence inversion), distinguishing it from sibling audit tools like mcp_server_audit or agent_tool_risk_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (analyze prompts for injection vulnerabilities) but does not explicitly state when not to use or how it compares to alternatives. It lacks guidance on context (e.g., before deployment, during code review).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| stack | No | common | |
| include_common | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits. It explicitly states 'No network is performed', indicating a safe, read-only operation, and describes the return format (FilesReport with paths). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with parameter explanations and return info. Every sentence adds value, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return structure (FilesReport with paths and why). All parameters are documented, and the tool's simplicity is fully covered. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it explains that 'stack' is comma-separated with supported keys listed, and 'include_common' defaults to True and always includes the 'common' set. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns curated sensitive-path lists for a given tech stack. The verb 'Return' and resource 'sensitive-path lists' are specific, and the purpose is well-defined, distinguishing it from siblings like risk_audit or default_creds_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys use for discovering sensitive files per stack, but lacks explicit guidance on when to use this over alternatives or when not to use it. However, given the distinct purpose, it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| brand | No | ||
| names | No | ||
| keywords | No | ||
| years | No | ||
| max_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It includes 'Pure function. No network.' which discloses critical behavioral traits. No contradictions or omissions of major 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with bullet points for modes and parameter details. Every sentence adds value, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return type (GenReport with sample). All parameters and modes are covered, and the context is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description elaborates on each parameter: mode explains enum values, brand/names/keywords/years/max_size are described in context of modes. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a wordlist tailored to the target surface.' It explains three modes (passwords, usernames, subdomains) with specific patterns, distinguishing it from sibling tools that are audit/inspection-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by detailing each mode and its parameters. It doesn't explicitly state when not to use or alternatives, but the sibling list shows no similar tools, and the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.1agent_tool_risk_auditdefault_creds_lookupgraphql_introspecthttp_diffinteractsh_pollinteractsh_registerinteractsh_stopjwt_inspectmcp_server_auditowasp_llm_classifyphpggc_generateprompt_injection_auditsensitive_files_listwordlist_genEach tool has a clearly distinct purpose, covering different security tasks like auditing, credential lookup, introspection, diffing, OOB interaction, JWT inspection, and wordlist generation. There is no overlap that would cause confusion.
Naming conventions are mixed: some use verb_noun (graphql_introspect), noun_verb (agent_tool_risk_audit), or prefix-based (interactsh_register). While readable, the inconsistency can lead to agent confusion about the expected pattern.
With 14 tools, the server provides a comprehensive toolkit without being overwhelming. Each tool appears necessary for the domain, and the count is well within the typical range.
The toolset covers major security assessment areas (static analysis, dynamic testing, credential checks, OOB, JWT, wordlist generation). Minor gaps exist (e.g., lack of network scanning or CVE lookup), but it fulfills its stated purpose well.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/x0base/mcp-security-toolkit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
