This server lets you launch and manage AI-powered penetration tests, review vulnerabilities, and generate reports with blockchain attestation.
Launch pentests against verified domains across four tiers (recon, standard, deep, blitz), optionally with a GitHub repo for white-box scanning (SAST, secret detection, SCA).
Check scan status, progress, findings summary, executive summary, attack surface map, and STRIDE threat model for a pentest.
List past pentests with status and finding counts, filterable by status.
Retrieve structured findings with severity, CVSS, CWE, PoC, remediation, and retest commands, filterable by severity.
Download reports in markdown, JSON, or PDF format.
Check your credit balance and available scan tiers with pricing.
Verify blockchain-anchored attestations by hash (public, no API key required).
List your verified domains and their verification status.
Access guided workflows as tools (e.g., run_pentest, analyze_findings, compare_pentests, security_posture) for clients that don't support MCP prompts.
Allows for white-box scanning by integrating GitHub repositories into penetration test workflows for source code analysis.
MCP server for TurboPentest — launch AI-powered penetration tests, review vulnerability findings, and generate security reports, all without leaving your coding assistant.
Ask your AI assistant to run a pentest, check progress, and walk you through remediation — the server handles all the API calls. Every completed scan is anchored to the blockchain, giving you a tamper-proof attestation you can share with customers or auditors.
Related MCP server: redteam-mcp
Sign up and create an API key at turbopentest.com/settings/api-keys.
Before scanning, verify that you own the target domain at turbopentest.com/domains.
Claude Code (.mcp.json in your project root):
{
"mcpServers": {
"turbopentest": {
"command": "npx",
"args": ["@turbopentest/mcp-server"],
"env": {
"TURBOPENTEST_API_KEY": "tp_live_..."
}
}
}
}Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"turbopentest": {
"command": "npx",
"args": ["@turbopentest/mcp-server"],
"env": {
"TURBOPENTEST_API_KEY": "tp_live_..."
}
}
}
}Cursor (Settings > MCP Servers > Add):
{
"command": "npx",
"args": ["@turbopentest/mcp-server"],
"env": {
"TURBOPENTEST_API_KEY": "tp_live_..."
}
}OpenAI Codex CLI (~/.codex/config.toml, or run codex mcp add turbopentest -- npx @turbopentest/mcp-server and set the env var when prompted):
[mcp_servers.turbopentest]
command = "npx"
args = ["@turbopentest/mcp-server"]
[mcp_servers.turbopentest.env]
TURBOPENTEST_API_KEY = "tp_live_..."Then run /mcp inside Codex to confirm turbopentest is listed. Codex's MCP
client doesn't support the "prompts" primitive, so the four guided workflows
are also exposed as plain tools (turbopentest_workflow_*, see below) and
described in this repo's AGENTS.md, which Codex reads automatically.
You: "Run a standard pentest on staging.example.com"
Claude: Checks domain is verified, confirms credit balance,
calls start_pentest → "Started tp_abc123, 4 agents, ~1 hour"
You: "Any findings yet?"
Claude: Calls get_pentest → "62% complete — 3 findings (1 high, 2 medium)"
You: "Show me the high severity ones"
Claude: Calls get_findings(severity: "high") →
[1] HIGH: SQL Injection in /api/search
CVSS: 8.6 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-89
PoC: POST /api/search?q=' OR 1=1--
Remediation: Use parameterized queries...
Retest: sqlmap -u "https://staging.example.com/api/search" ...
You: "Give me a prioritized remediation plan"
Claude: Uses the analyze_findings prompt → produces a full markdown
remediation plan grouped by severity and effortPass a GitHub repository URL to start_pentest to enable white-box mode. In addition to black-box testing, the scan will include:
SAST — static code analysis for common vulnerability patterns
Secret detection — leaked API keys, credentials, and tokens in source
SCA — dependency audit for known CVEs
You: "Pentest staging.example.com, the repo is github.com/myorg/myapp"Tool | Description |
| Launch a pentest against a verified domain. Supports four tiers and optional GitHub repo for white-box scanning. |
| Get scan status, progress, findings summary, executive summary, attack surface map, and STRIDE threat model. |
| List all pentests with status and finding counts. Filterable by status. |
| Retrieve structured findings with severity, CVSS, CWE, OWASP category, PoC, remediation steps, and retest commands. Filterable by severity. |
| Download a report in markdown (best for AI), JSON, or PDF format. |
| Check your credit balance and available scan tiers with pricing. |
| Verify a blockchain-anchored attestation by SHA-256 hash. No API key required — public endpoint. |
| List your verified domains and their verification status. |
| Returns the |
| Returns the |
| Returns the |
| Returns the |
Security note: turbopentest_start_pentest checks domain verification
itself before calling the API — it will refuse (isError: true) to launch
against a target whose domain isn't verified on your account, rather than
relying solely on the agent to check first.
Built-in prompts guide your AI assistant through multi-step workflows. Invoke them by name in any MCP client that supports prompts (Claude Code, Claude Desktop, Cursor). In clients that only support tools (Codex), use the matching turbopentest_workflow_* tool above instead — the text is identical.
Prompt | Equivalent tool | Description |
|
| Full-lifecycle pentest: domain check → credit verification → launch → progress monitoring → findings summary → report download |
|
| Deep-dive analysis of a single pentest's findings, producing a prioritized remediation plan with effort estimates and retest commands |
|
| Diff two pentests on the same target — shows what's new, what's been fixed, and what's still unresolved |
|
| Executive briefing across your 5 most recent pentests: risk trends, highest-risk targets, and top 3 recommended actions |
Tier | Agents | Duration | Price |
Recon | 1 | ~30 min | $49 |
Standard | 4 | ~1 hour | $99 |
Deep | 10 | ~2 hours | $299 |
Blitz | 20 | ~4 hours | $699 |
Default tier is standard. Use recon for a quick surface sweep or blitz for maximum coverage on critical assets.
Every completed pentest is anchored on-chain as a tamper-proof attestation. The SHA-256 hash is included in the report and can be independently verified — by you, your customers, or auditors — with no API key required:
You: "Verify attestation abc123def456..."turbopentest_verify_attestation returns the scan metadata (tier, agents, duration, risk score, findings summary) alongside the blockchain proof (chain ID, transaction hash, block number, merkle root).
Variable | Required | Default | Description |
| Yes | — | API key from turbopentest.com/settings/api-keys |
| No |
| Override the API base URL (for testing) |
Node.js 18+
A TurboPentest account with at least one verified domain
See docs/CODEX.md for the full Codex guide — configuration,
the tool list, the authorization model, and why the guided workflows are
exposed as turbopentest_workflow_* tools instead of MCP prompts.
Privacy policy: https://turbopentest.com/privacy
Subprocessors: https://turbopentest.com/subprocessors
Support: open a case at https://turbopentest.com/support (typically answered within a few hours on business days) or join the Discord
Bugs in this MCP server: https://github.com/integsec/turbopentest-mcp/issues
Your API key is sent only to turbopentest.com/api as a bearer token over
HTTPS. It is never logged and never transmitted anywhere else. Customer pentest
content is not used to train public AI models.
MIT
Download a pentest report. Use format=markdown for AI-readable content, format=json for structured data, or format=pdf for the full formatted report. The scan must be complete.
| Name | Required | Description | Default |
|---|---|---|---|
| pentest_id | Yes | The pentest ID (UUID) | |
| format | Yes | Report format: markdown (best for AI reading), json (structured data), pdf (formatted document) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite condition ('The scan must be complete'), which is valuable context. However, it doesn't describe other behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the scan isn't complete, leaving gaps in transparency.
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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the tool's purpose, parameter usage, and prerequisite condition. Every sentence adds value with no wasted words, making it easy for an AI agent to parse quickly.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and prerequisite well, but lacks details on behavioral aspects (e.g., error handling, output structure) that would be helpful for an agent, especially without annotations or an output schema.
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 100%, so the schema already documents both parameters thoroughly. The description adds some semantic context by explaining the purpose of each format option (e.g., 'markdown for AI-readable content'), but this is largely redundant with the schema's enum descriptions. Baseline 3 is appropriate when the schema does most of the work.
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 specific action ('Download a pentest report') and resource ('pentest report'), distinguishing it from siblings like 'get_pentest' (likely metadata) or 'get_findings' (specific findings). It provides a clear verb+resource combination that is distinct from other tools in the list.
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 clear context for when to use this tool ('The scan must be complete'), which is essential guidance. However, it doesn't explicitly mention when NOT to use it or name alternatives among siblings (e.g., 'get_pentest' for non-report data), so it falls short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your credit balance and available scan tiers with pricing. Credits are required to launch pentests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('check') and mentions the purpose of credits for launching pentests, adding useful context. However, it doesn't disclose details like authentication needs, rate limits, or error handling, which are important for a tool that interacts with billing or resource systems.
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 appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's function and its relevance to pentests. Every sentence earns its place by adding clear information without redundancy or unnecessary details.
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 low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. It explains what the tool does and why it matters, though it could benefit from more behavioral details (e.g., response format or error cases) to fully compensate for the lack of structured data.
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 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the semantic output ('credit balance and available scan tiers with pricing'), which compensates for the lack of an output schema. This goes beyond the schema, providing meaningful context for what the tool returns.
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 with specific verbs ('check', 'launch') and resources ('credit balance', 'available scan tiers with pricing', 'pentests'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_pentests' or 'get_pentest', which might also relate to pentest operations but focus on different aspects.
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 by stating 'Credits are required to launch pentests,' suggesting this tool should be used before starting a pentest to check resource availability. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no comparison to sibling tools) or any exclusions, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get structured vulnerability findings for a pentest. Each finding includes severity, CVSS, CWE, description, PoC, remediation, and retest command. Use the severity filter to narrow results.
| Name | Required | Description | Default |
|---|---|---|---|
| pentest_id | Yes | The pentest ID (UUID) | |
| severity | No | Filter findings by severity level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool retrieves 'structured vulnerability findings' and includes a severity filter, but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, pagination, or what happens if no findings exist. For a tool with no annotations, this leaves significant gaps in understanding its 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 concise and front-loaded: the first sentence defines the core purpose and key attributes, and the second sentence provides usage guidance. Both sentences earn their place by adding value. It could be slightly more structured (e.g., bullet points for attributes), but it's efficient with zero waste.
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 annotations and no output schema, the description is moderately complete for a read operation. It covers the purpose and basic usage but lacks details on behavioral aspects (e.g., response format, error handling) and doesn't fully compensate for the missing output schema. It's adequate but has clear gaps for a tool retrieving structured data.
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 100%, with clear descriptions for both parameters (pentest_id as UUID, severity as enum filter). The description adds minimal value beyond the schema: it mentions 'severity filter' but doesn't explain parameter interactions or semantics further. Baseline 3 is appropriate since the schema does the heavy lifting.
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: 'Get structured vulnerability findings for a pentest' with specific attributes listed (severity, CVSS, CWE, etc.). It distinguishes from siblings like 'download_report' or 'get_pentest' by focusing on vulnerability findings rather than reports or pentest metadata. However, it doesn't explicitly contrast with all siblings (e.g., 'list_domains'), keeping it at 4 rather than 5.
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 some usage context: 'Use the severity filter to narrow results' implies this tool is for retrieving findings, possibly with filtering. However, it lacks explicit guidance on when to use this vs. alternatives like 'download_report' (which might include findings) or prerequisites (e.g., requires a pentest_id). The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a pentest including status, progress, findings summary, executive summary, attack surface map, and STRIDE threat model.
| Name | Required | Description | Default |
|---|---|---|---|
| pentest_id | Yes | The pentest ID (UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what details are returned but doesn't disclose behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, error conditions, or pagination. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 single, efficient sentence that front-loads the purpose and lists included details. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse quickly.
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 annotations and no output schema, the description is incomplete. It lists return details but doesn't explain the structure, format, or potential errors. For a tool that returns complex data (e.g., executive summary, threat model), more context is needed to help the agent use it effectively.
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 100%, with the parameter 'pentest_id' clearly documented as a UUID in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain where to get the pentest_id from or format nuances). Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb 'Get' and resource 'pentest' with specific details included (status, progress, findings summary, etc.). It distinguishes from siblings like 'list_pentests' (which likely lists multiple pentests) and 'get_findings' (which likely focuses only on findings). However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 no guidance on when to use this tool versus alternatives like 'list_pentests' or 'get_findings'. It doesn't mention prerequisites (e.g., needing a pentest ID) or context for usage. The agent must infer usage from the tool name and parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your verified domains and their verification status. Domains must be verified before you can run pentests against them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 implies a read-only operation ('List') and adds useful context about verification status and prerequisites for pentests, but lacks details on permissions, rate limits, or response 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?
Two sentences that are front-loaded with the core purpose and follow with essential context. Every sentence earns its place without redundancy or waste.
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?
For a simple list tool with no parameters, no output schema, and no annotations, the description is reasonably complete—it explains what it does and why it matters. However, it could benefit from mentioning return format or pagination to be fully comprehensive.
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 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter-specific information, which is acceptable since there are no parameters to document.
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 specific action ('List') and resource ('your verified domains and their verification status'), distinguishing it from siblings like 'list_pentests' or 'get_findings' by focusing on domain verification rather than pentests or findings.
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?
It provides clear context for when to use this tool ('Domains must be verified before you can run pentests against them'), linking it to the pentest workflow. However, it does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your pentests with status and finding counts. Results are ordered newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| status | No | Filter by scan status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions ordering ('newest first') and what data is returned ('status and finding counts'), but doesn't cover important aspects like pagination behavior (only mentions 'limit' parameter), authentication requirements, rate limits, error conditions, or whether this is a read-only operation. For a listing tool with no annotation coverage, this leaves significant gaps.
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 single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes only essential additional details about ordering and data included. Every element earns its place.
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?
For a listing tool with 2 parameters (fully documented in schema) and no output schema, the description provides basic but incomplete context. It covers what data is returned and ordering, but lacks information about response format, pagination beyond the 'limit' parameter, error handling, and authentication requirements. Given the complexity level and absence of annotations/output schema, this is minimally adequate but has clear 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 100%, so the schema fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (no syntax hints, format details, or usage examples). This meets the baseline of 3 when the schema does the heavy lifting.
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 verb ('List') and resource ('all your pentests') with additional details about what information is included ('status and finding counts'). It distinguishes from some siblings like 'get_pentest' (singular) and 'start_pentest' (creation), but doesn't explicitly differentiate from 'list_domains' which is a similar listing operation for a different resource.
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 by mentioning ordering ('newest first'), but provides no explicit guidance on when to use this tool versus alternatives like 'get_pentest' (for a specific pentest) or 'get_findings' (for detailed findings). No prerequisites, exclusions, or comparative context with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch an AI-powered penetration test against a target URL. The domain must be verified first (see list_domains). Requires an available credit matching the selected tier.
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | The target URL to scan (must be a verified domain) | |
| repo_url | No | GitHub repository URL for white-box scanning (SAST, secrets, SCA) | |
| tier | No | Scan tier: recon (1 agent, 30min), standard (4 agents, 1hr), deep (10 agents, 2hr), blitz (20 agents, 4hr) | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: it's a launch/mutation operation (implied by 'Launch'), requires verification and credits, and mentions scanning tiers. However, it lacks details on rate limits, response format, or 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?
Two sentences are front-loaded with essential information (action, target, prerequisites), with zero wasted words. Each sentence earns its place by covering critical usage constraints.
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?
For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers prerequisites and tier context, but lacks details on what happens after launch (e.g., async process, report generation) or error scenarios, leaving gaps in operational understanding.
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 100%, so the schema already documents all parameters well. The description adds minimal value beyond the schema, only implying target_url must be verified and tier affects credit usage, but no additional syntax or format details.
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 specific action ('Launch an AI-powered penetration test') and target resource ('against a target URL'), distinguishing it from siblings like list_domains or get_pentest by focusing on initiating a scan rather than querying existing data.
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?
It provides explicit prerequisites (domain must be verified via list_domains, requires available credit) and context (matching the selected tier), but does not specify when to use alternatives like get_findings or list_pentests for post-scan actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a blockchain-anchored pentest attestation by its hash. This is a public endpoint — no API key required. Use this to confirm that a pentest was actually performed and its results are authentic.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The attestation hash to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond basic functionality: it specifies this is a 'public endpoint — no API key required', which informs authentication needs, and implies read-only verification without destructive effects, though it doesn't detail rate limits or exact response 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?
The description is front-loaded with the core purpose, followed by key behavioral details, all in two efficient sentences with zero wasted words. Each sentence earns its place by adding distinct 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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage context, and key behavioral traits like public access. However, without an output schema, it doesn't explain return values (e.g., verification status or error details), leaving a minor 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?
The schema description coverage is 100%, so the parameter 'hash' is already documented in the schema. The description adds marginal meaning by linking the hash to verification of pentest authenticity, but doesn't provide additional syntax or format details beyond what the schema states.
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 specific action ('verify'), resource ('blockchain-anchored pentest attestation'), and mechanism ('by its hash'). It distinguishes this from sibling tools like 'download_report' or 'get_pentest' by focusing on verification rather than retrieval or listing.
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 clear context for when to use this tool ('to confirm that a pentest was actually performed and its results are authentic'), but does not explicitly mention when not to use it or name specific alternatives among the sibling tools (e.g., 'get_pentest' for retrieving details).
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.
v0.1.5download_reportget_creditsget_findingsget_pentestlist_domainslist_pentestsstart_pentestverify_attestationScored across 8 tools
Each tool has a distinct purpose with clear boundaries: download_report retrieves reports, get_credits checks balances, get_findings provides vulnerability details, get_pentest gives full test details, list_domains shows domain status, list_pentests lists tests, start_pentest launches tests, and verify_attestation verifies authenticity. No overlap or confusion exists between these functions.
All tools follow a consistent verb_noun pattern using snake_case: download_report, get_credits, get_findings, get_pentest, list_domains, list_pentests, start_pentest, and verify_attestation. This uniformity makes the toolset predictable and easy to navigate.
With 8 tools, the count is well-scoped for a pentesting server, covering essential operations like launching tests, retrieving results, managing domains, and verifying attestations. Each tool earns its place without redundancy or bloat.
The toolset provides complete coverage for the pentesting domain: it supports the full lifecycle from domain verification and test initiation to retrieving findings, reports, and attestation verification. No obvious gaps exist; agents can perform all core workflows seamlessly.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
