TurboPentest MCP Server lets you launch and manage AI-powered penetration tests against verified domains directly from your AI assistant (Claude Desktop, Claude Code, Cursor, etc.).
Start a pentest (start_pentest): Launch a pentest against a verified target URL, choosing from four scan tiers (recon, standard, deep, blitz) and optionally providing a GitHub repo for white-box scanning (SAST, secrets, SCA).
Get pentest details (get_pentest): Retrieve status, progress, findings summary, executive summary, attack surface map, and STRIDE threat model for a specific pentest.
List pentests (list_pentests): View all pentests ordered newest first, filterable by status (queued, scanning, complete, failed).
Get findings (get_findings): Fetch structured vulnerability findings including severity, CVSS, CWE, proof-of-concept, remediation guidance, and retest commands — filterable by severity.
Download reports (download_report): Download completed pentest reports in markdown (AI-friendly), JSON (structured data), or PDF (formatted document) format.
Check credits (get_credits): View your credit balance and available scan tiers with pricing.
Verify attestation (verify_attestation): Publicly verify a blockchain-anchored pentest attestation by hash — no API key required.
List domains (list_domains): View verified domains and their verification status (domains must be verified before pentesting).
Built-in prompts: Use guided workflows for deep-dive findings analysis (analyze_findings), comparing pentests (compare_pentests), running full-lifecycle pentests (run_pentest), and summarizing overall security posture (security_posture).
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_..."
}
}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. |
Built-in prompts guide your AI assistant through multi-step workflows. Invoke them by name in any MCP client that supports prompts.
Prompt | 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
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/IntegSec/turbopentest-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
