Skip to main content
Glama

pentest-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

Server Details

Offline methodology engine for authorized penetration testing, CTF, and security research.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 64 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
cyanheads/pentest-mcp-server
GitHub Stars
1
Server Listing
@cyanheads/pentest-mcp-server

TDQS

A4/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a distinct action+resource: analyzing responses, encoding payloads, generating payloads, retrieving guides, and looking up/mapping ATT&CK data. The payload tools (generate vs. encode) are related but clearly differentiated by generate-vs-transform verbs, and the ATT&CK tools split cleanly into group lookup, technique lookup, and profile mapping.

Naming Consistency5/5

All seven tools follow a uniform pentest_<verb>_<noun> snake_case pattern (analyze_response, encode_payload, generate_payloads, get_guide, lookup_group, lookup_technique, map_techniques). The convention is predictable and consistent throughout.

Tool Count5/5

Seven tools is well-scoped for an authorized-testing research aid, with each tool earning its place across analysis, payload work, methodology guidance, and ATT&CK intelligence. No redundant or filler tools.

Completeness4/5

The surface covers response analysis, payload generation/encoding, methodology playbooks, and ATT&CK lookup/mapping, forming a coherent advisory workflow. Minor gaps exist (e.g., no reporting/notes or CVE-vulnerability lookup), but core research and methodology needs are met.

Available Tools

7 tools
pentest_analyze_responsePentest Analyze ResponseA
Read-onlyIdempotent
Inspect

Analyze an HTTP response from authorized probing for information leakage, fingerprinting signals, and related exposure. Structured findings cover version disclosures, stack traces, debug headers, internal paths, authentication patterns, CORS configuration, detection signals, remediation, and associated methodology vectors.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextNoFreeform context about the authorized test target — e.g., "login endpoint", "GraphQL API", "file upload handler". Narrows the pattern matching to relevant categories. Max 2,000 characters.
status_codeNoHTTP status code (100–599). Helps classify the response type.
response_bodyNoRaw HTML, JSON, XML, or error response body text. Maximum 10,000 characters.
response_headersNoRaw HTTP response headers, optionally including the status line. Maximum 20,000 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
summaryNoOne-paragraph summary of findings and associated follow-up actions.
findingsNoStructured findings ordered by severity descending (high first).
fingerprintsNoDetected server, framework, language, database, cloud, and other technology signals.
nextToolSuggestionsNoSuggested tools derived from detected fingerprints and findings.
authorized_use_reminderNoReminder that response analysis is for authorized testing only. Rendered first.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already carry readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered elsewhere. The description earns credit by disclosing the authorization precondition and by enumerating the categories of structured findings produced (version disclosures, stack traces, debug headers, CORS, detection signals, remediation), which tells the agent what kind of analysis result to expect beyond the raw schema.

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

Conciseness4/5

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

Two sentences, purpose front-loaded before the findings enumeration, no filler. The second sentence is a long comma series, which is dense but still informative rather than padded; it stays within acceptable size for a tool with a rich output schema.

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

Completeness4/5

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

With an output schema present, the description need not explain return shape, and it correctly focuses on what the tool consumes (an HTTP response) and what dimensions it analyzes. The notable remaining gap is guidance on when this analysis is warranted versus the sibling guide/lookup tools, plus any indication of how truncation limits affect results.

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

Parameters3/5

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

Schema description coverage is 100%, and each of the four parameters already documents its own format, bounds, and purpose (context narrows matching, body/header size caps). The description adds nothing parameter-specific, so the baseline 3 for schema-sufficient tools applies.

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

Purpose5/5

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

States a specific verb (analyze) plus a precisely scoped resource (an HTTP response from authorized probing), and names the analysis goals: information leakage, fingerprinting signals, exposure. The sibling tools are all payload/technique generators and lookups, so this tool's resource is unmistakably distinct without needing to name an alternative.

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

Usage Guidelines3/5

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

"From authorized probing" implies the precondition and the general use case (post-request response triage), but there is no explicit when-to-use, no when-not-to-use, and no routing to or from the sibling payload tools. Usage is inferable but never stated, which lands it at the minimum-viable level.

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

pentest_encode_payloadPentest EncodeA
Read-onlyIdempotent
Inspect

Transform a payload string through an ordered encoding chain for authorized filter research. Results include the final value, intermediate values, optional decode path and rationale, and detection guidance. All transforms are local; no live probing occurs.

ParametersJSON Schema
NameRequiredDescriptionDefault
chainYesOrdered list of encodings to apply (1–6 steps). Applied left to right. E.g., ["unicode", "url"] applies Unicode escape first, then URL-encodes the result.
explainNoWhether to include the decode path and bypass rationale.
payloadYesInput payload string to encode. Max 10,000 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
encodedNoFinal encoded payload after all chain steps applied.
originalNoThe input payload.
decode_pathNoStep-by-step explanation of how a decoder (WAF, server, browser) would reverse the encoding chain. Included when explain is true.
detection_noteNoDetection methods for encoded variants, including normalization and behavior signals.
bypass_rationaleNoWhy this encoding combination might bypass common filter patterns. Included when explain is true.
intermediate_stepsNoIntermediate values at each encoding step, for tracing the chain.
authorized_use_reminderNoReminder that encoding transforms are for authorized bypass research only.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds real value beyond that: it discloses the return shape (final value, intermediate values, optional decode path and rationale, detection guidance) and explicitly states all transforms are local with no live probing, which an agent could not infer from annotations alone.

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

Conciseness5/5

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

Three sentences, front-loaded with the core action and scope, then output contents, then the safety caveat. No filler sentences and nothing repeated from the schema.

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

Completeness5/5

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

An output schema exists, so the description need not enumerate return fields in detail, and it still summarizes them at the right level. Combined with annotations covering the safety profile and a fully documented input schema, an agent has everything needed to call this correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the payload, chain (with left-to-right ordering, max 6 steps and an example) and the explain flag. The description mentions the ordered chain and optional decode path but adds no syntax or format information beyond what the schema provides, so the baseline of 3 applies.

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

Purpose4/5

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

The description names a specific verb ('Transform/encode') and resource ('a payload string') plus the mechanism ('ordered encoding chain'), which is clearly distinct from siblings like pentest_generate_payloads or pentest_analyze_response. It does not explicitly name a sibling to differentiate against, so it stops short of a 5.

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

Usage Guidelines3/5

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

The phrase 'for authorized filter research' implies the intended context, but there is no explicit when-to-use vs when-not, no prerequisites, and no routing to alternatives such as generate_payloads when no payload exists yet. Usage is only implied.

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

pentest_generate_payloadsPentest Generate PayloadsA
Read-onlyIdempotent
Inspect

Generate context-specific payload templates for authorized systems. Each template includes its vulnerability category, context rationale, WAF/IDS detection signature, mitigation, optional WAF research note, and optional encoded variant.

ParametersJSON Schema
NameRequiredDescriptionDefault
countNoNumber of payload variants to return (1–20, default 5). More variants cover different bypass approaches for the same context.
categoryYesVulnerability category for payload generation.
encodingNoOptional encoding chain applied left to right to each returned template.
waf_profileNoWAF or filter in front of the authorized test target. When a specific WAF is named, bypass variants referencing known public research are included.none
injection_contextYesPrecise injection context. Critical for XSS: an HTML attribute payload differs from a JS string payload. Provide the most specific context for the best results.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
categoryNoRequested payload category.
payloadsNoPayload templates ordered by coverage breadth, each annotated with offense and defense context.
injection_contextNoRequested injection context.
authorized_use_reminderNoReminder that these templates are for authorized testing only.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and deterministic output. The description adds valuable detail about what each template includes (category, rationale, detection signature, mitigation, optional research note and encoded variant), which is beyond annotations and helps agents understand output structure.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the primary action and scope, then briefly enumerates output contents. Every clause earns its place with no redundancy or filler.

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

Completeness4/5

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

Given the tool's complexity (5 parameters, enums, output schema present), the description provides enough context about the returned templates and ties to the 'context rationale' element. It does not explicitly mention parameters like count or encoding, but those are fully documented in the schema, and the output schema is present, so nothing critical is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the description does not need to elaborate on parameters. It adds no parameter-specific details beyond the schema, and the baseline of 3 is appropriate when schema carries the full load.

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

Purpose5/5

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

The description clearly states the tool's verb ('Generate') and resource ('context-specific payload templates'), with a scope qualifier ('for authorized systems'). It is easily distinguished from siblings like pentest_analyze_response (analysis) or pentest_encode (encoding), so an agent knows exactly what this tool does without opening the schema.

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

Usage Guidelines4/5

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

The description implicitly frames usage as part of an authorized pentest workflow, but does not explicitly state when to prefer this tool over alternatives such as pentest_guide or pentest_map_techniques. The context is clear, yet exclusions or alternative routing are left to inference.

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

pentest_get_guidePentest GuideA
Read-onlyIdempotent
Inspect

Return an authorized-testing methodology for a selected vector and optional target context. The playbook covers reconnaissance, enumeration, exploitation, and post-exploitation phases with objectives, techniques, detection signals, mitigations, common pitfalls, references, and context-derived tool suggestions across 15 vectors.

ParametersJSON Schema
NameRequiredDescriptionDefault
phaseNoMethodology phase selector. "all" returns the complete playbook; a named phase returns only that phase.all
vectorYesAttack vector to retrieve methodology for. Each vector has its own methodology branch covering recon through exploitation. Authorized testing only.
target_contextNoOptional target profile for authorized engagement. Providing this narrows the playbook to what is most relevant for the specific environment.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
phasesNoOrdered methodology phases. Contains only the requested phase when phase input is not "all".
vectorNoThe requested attack vector.
owasp_referencesNoRelevant OWASP Testing Guide test case IDs (e.g., "WSTG-INPV-01").
nextToolSuggestionsNoSuggested tools and arguments derived from the playbook.
attack_technique_idsNoRelevant ATT&CK technique IDs for cross-referencing with pentest_lookup_technique.
authorized_use_reminderNoReminder that this methodology applies to authorized testing only. Included in every response.

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. Beyond that the description usefully enumerates what the returned playbook contains (objectives, techniques, detection signals, mitigations, pitfalls, references) and that target_context narrows results — meaningful content disclosure that annotations cannot convey.

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

Conciseness5/5

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

Two sentences, front-loaded with the core action and scope, then the playbook contents. No filler, no restatement of the title, and the optional-vs-required distinction is signaled immediately.

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

Completeness4/5

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

For a read-only retrieval tool with an output schema and full parameter documentation, the definition is nearly self-sufficient: it conveys scope, phases, and the role of target_context. The only gap is the absence of routing guidance against the six sibling tools, which matters given the high tool count.

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

Parameters3/5

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

Schema description coverage is 100%, so vector, phase, and the nested target_context fields (waf, stack, recon_notes) are already fully documented with examples. The description only restates 'selected vector and optional target context' and adds the vector count; it contributes little syntax or format detail beyond the schema.

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

Purpose5/5

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

States a specific verb and resource — 'Return an authorized-testing methodology for a selected vector' — and scopes the output to a named set of 15 attack vectors. It is clearly distinguishable from siblings like pentest_generate_payloads or pentest_lookup_technique, which produce payloads or lookups rather than a multi-phase playbook.

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

Usage Guidelines3/5

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

Usage is implied through the phase/vector scope and the 'authorized testing only' framing, but the description never states when to prefer this over pentest_lookup_technique or pentest_generate_payloads, despite the playbook apparently producing 'context-derived tool suggestions'. No explicit alternatives or exclusions are named.

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

pentest_lookup_groupPentest Lookup GroupA
Read-onlyIdempotent
Inspect

Look up a MITRE ATT&CK threat group or software entry by ID, name, or keyword. Results include ATT&CK identity, aliases, type, description, and associated techniques with procedure-level context from public ATT&CK reporting.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesATT&CK threat group ID (e.g., "G0007"), software ID (e.g., "S0002"), or name/keyword (e.g., "APT28", "Mimikatz", "Lazarus Group"). ID lookup is exact and case-insensitive; name/keyword search returns the best match.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idNoATT&CK ID (e.g., "G0007" for a group, "S0002" for software).
nameNoPrimary display name (e.g., "APT28", "Mimikatz").
typeNo"group" for intrusion sets (threat actors), "software" for malware and tools.
errorNoPresent when the call failed. Absent on success.
aliasesNoKnown alternate names from ATT&CK.
descriptionNoATT&CK description (truncated to 800 characters).
attack_versionNoATT&CK dataset version used (e.g., "Enterprise v19.1").
techniques_usedNoUp to 20 techniques associated with the group or software, including procedure-level context and technique IDs.
authorized_use_reminderNoReminder that threat group data is for authorized testing and research only. Rendered first.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds value by specifying what the result contains (identity, aliases, type, description, techniques with procedure-level context), and it notes the query fallback from exact ID to best-match on name/keyword. There is no contradiction with annotations, and the added behavioral detail is useful beyond the annotations.

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

Conciseness5/5

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

The description is two concise sentences, front-loaded with the core action and resource, then clarifying the accepted input formats and the nature of results. Every sentence earns its place, and there is no redundant repetition of the tool name or schema details.

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

Completeness5/5

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

For a single-parameter lookup tool with no nested objects and an output schema present (as per context signals), the description covers the purpose, input formats, and return content. The agent has everything needed to decide when to invoke it and what to expect, and the annotations cover side effects. Nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100% for the single 'query' parameter, so the schema already documents the parameter fully. The description adds extra semantic nuance: ID lookup is exact and case-insensitive, while name/keyword search returns the best match. This exceeds the baseline for high schema coverage and helps the agent understand query behavior without opening the schema.

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

Purpose5/5

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

The description states a specific action ('Look up') with a clear resource ('MITRE ATT&CK threat group or software entry') and the input modes ('ID, name, or keyword'). It differentiates from the sibling pentest_lookup_technique by focusing on groups/software rather than techniques, and it enumerates the returned fields, so an agent can tell exactly what the tool does.

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

Usage Guidelines4/5

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

The description clearly implies when to use this tool: when looking up threat groups or software entries from ATT&CK. It implicitly distinguishes from pentest_lookup_technique by the resource type, but it does not explicitly state 'use this for groups/software, not techniques' or mention any exclusions. Given the sibling names, the context is clear enough without explicit exclusion.

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

pentest_lookup_techniquePentest Lookup TechniqueA
Read-onlyIdempotent
Inspect

Look up a MITRE ATT&CK technique by exact ID or keyword. Results include tactics, platforms, description, detection data, public procedure examples, mitigations, related sub-techniques, and dataset version.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesATT&CK technique ID (e.g., "T1190", "T1059.001") or keyword describing the technique (e.g., "sql injection", "pass the hash", "web shell upload"). ID lookup is exact; keyword lookup returns the best match plus related techniques.
include_subtechniquesNoInclude sub-techniques in the result. Set to false when only the parent technique summary is needed.

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameNoTechnique name.
errorNoPresent when the call failed. Absent on success.
tacticsNoATT&CK tactics this technique belongs to (e.g., "Initial Access", "Execution").
detectionNoATT&CK detection context for the technique.
platformsNoTarget platforms (e.g., "Windows", "Linux", "Web Application").
descriptionNoATT&CK description of the technique.
mitigationsNoRecommended mitigations from ATT&CK.
technique_idNoATT&CK technique ID (e.g., "T1190").
attack_versionNoATT&CK dataset version used (e.g., "Enterprise v19.1").
sub_techniquesNoSub-techniques of this parent technique. Empty when querying a sub-technique itself, or when include_subtechniques is false.
procedure_examplesNoReal-world usage examples from ATT&CK public reporting.
authorized_use_reminderNoReminder that technique data is for authorized testing and research only. Rendered first.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already establish read-only and idempotent behavior. The description adds a brief summary of the result contents (tactics, platforms, detection data, etc.), but since an output schema exists, this enumeration adds only moderate value beyond the structured annotations.

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

Conciseness4/5

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

The description is a single front-loaded sentence that hits the action first and then lists the result fields. The enumeration is somewhat long, but each item is meaningful and contributes to a complete overview.

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

Completeness5/5

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

Given the tool's simplicity, fully documented schema, existing output schema, and read-only idempotent annotations, the definition is complete for an agent to invoke it correctly. Nothing essential for making the call is missing.

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

Parameters3/5

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

Schema description coverage is 100%, with rich detail on the query parameter (examples, exact vs. best-match behavior) and include_subtechniques (default and when to disable). The description itself adds no parameter-level meaning beyond what the schema already provides.

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

Purpose5/5

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

States a specific verb ('look up'), a distinct resource ('MITRE ATT&CK technique'), and the two accepted input modes ('exact ID or keyword'). This clearly distinguishes it from the sibling pentest_lookup_group without requiring the agent to open either schema.

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

Usage Guidelines2/5

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

The description provides no explicit when-to-use or when-not-to-use guidance, nor does it reference any sibling tool. The only usage hint appears inside the include_subtechniques parameter schema, not in the description itself.

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

pentest_map_techniquesPentest Map TechniquesA
Read-onlyIdempotent
Inspect

Rank ATT&CK techniques and OWASP test cases against an authorized target profile of technology stack, exposed services, authentication type, and operating system. Results include profile-specific relevance, detection opportunities, mitigations, and associated methodology vectors.

ParametersJSON Schema
NameRequiredDescriptionDefault
osNoTarget operating system. Narrows to OS-specific techniques.
limitNoMaximum number of techniques to return (1–50, default 15). Higher values give broader coverage; lower values focus on highest-relevance items.
stackNoTechnology stack components (e.g., ["Node.js", "Express", "PostgreSQL", "Redis"]). Each element matched against technique platform and procedure examples.
servicesNoExposed services and interfaces (e.g., ["REST API", "GraphQL", "file upload", "admin panel"]). Narrows technique relevance.
auth_typeNoAuthentication mechanism in use. Surfaces auth-specific attack techniques.

Output Schema

ParametersJSON Schema
NameRequiredDescription
capNoThe limit applied to ranked_techniques.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of ranked techniques returned.
truncatedNoTrue when ranked_techniques was capped by limit.
attack_versionNoATT&CK dataset version used for technique data.
profile_summaryNoOne-sentence normalized summary of the supplied target profile.
owasp_test_casesNoRelevant OWASP Testing Guide test cases for the profile (up to 10).
ranked_techniquesNoTechniques ordered by relevance_score descending.
authorized_use_reminderNoReminder that technique mapping is for authorized testing engagements only. Rendered first.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world non-destructive profile, so the safety burden is light. The description usefully adds that results carry relevance, detection opportunities, mitigations, and methodology vectors, and signals the authorization requirement implied by 'authorized target profile'.

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

Conciseness4/5

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

Two sentences, front-loaded with the verb and object, and the second sentence efficiently enumerates the output payload. Slightly dense with multi-clause phrasing, but no filler sentences.

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

Completeness4/5

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

An output schema exists, so return values need not be re-explained, yet the description still summarizes result contents. All five parameters are documented via the schema and annotations cover the safety profile, leaving only minor gaps such as how ranking is computed or whether any profile dimension is required.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter including enums and the limit range is already fully documented. The description only restates the profile dimensions in prose, adding no new syntax, matching behavior, or defaulting detail beyond what the schema provides.

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

Purpose5/5

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

States a specific verb (rank) and clear resources (ATT&CK techniques and OWASP test cases) plus the exact inputs that shape the ranking (stack, services, auth type, OS). This is readily distinguishable from siblings like pentest_lookup_technique (single-item lookup) or pentest_generate_payloads (payload generation).

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the tool applies when you have an 'authorized target profile' to rank techniques against, which hints at the authorization prerequisite. However, there is no explicit when-to-use guidance and no mention of alternatives such as pentest_lookup_technique for single-technique detail, so the agent must infer the boundary.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • Changedpentest_analyze_response2 fields changed
      • changedOutput schema / properties / findings / items / properties / suggested_vector / description
        Previous value: -"Pentest_guide vector name for follow-up when this finding maps to an attack vector. Absent when no direct vector mapping exists."New value: +"Pentest_get_guide vector name for follow-up when this finding maps to an attack vector. Absent when no direct vector mapping exists."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description
        Previous value: -"Suggested tool name (e.g., \"pentest_guide\")."New value: +"Suggested tool name (e.g., \"pentest_get_guide\")."
    • Removedpentest_encode
    • Addedpentest_encode_payload
    • Addedpentest_get_guide
    • Removedpentest_guide
    • Changedpentest_map_techniques1 field changed
      • changedOutput schema / properties / ranked_techniques / items / properties / pentest_guide_vector / description
        Previous value: -"Associated pentest_guide methodology vector. Absent when no direct mapping exists."New value: +"Associated pentest_get_guide methodology vector. Absent when no direct mapping exists."
  2. 7 tool updates
    • Changedpentest_analyze_response16 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / response_body / description
        Previous value: -"Response body text. Paste raw HTML, JSON, XML, or error text. Truncate to the first 10,000 characters for very large responses — the first portion carries most leakage signals."New value: +"Raw HTML, JSON, XML, or error response body text. Maximum 10,000 characters."
      • changedInput schema / properties / response_headers / description
        Previous value: -"Raw HTTP response headers (paste from Burp, curl -v, or similar). Include the status line if available. Max 20,000 characters."New value: +"Raw HTTP response headers, optionally including the status line. Maximum 20,000 characters."
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "findings",
+      "fingerprints",
+      "summary",
+      "nextToolSuggestions"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_input`: Neither response_headers nor response_body was provided. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_input"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / findings / items / properties / detection / description
        Previous value: -"How a defender or SIEM would detect exploitation of this finding."New value: +"Observable signals associated with exploitation of this finding."
      • changedOutput schema / properties / fingerprints / description
        Previous value: -"Technology fingerprinting summary for use in target_context when calling pentest_guide or pentest_map_techniques."New value: +"Detected server, framework, language, database, cloud, and other technology signals."
      • changedOutput schema / properties / nextToolSuggestions / description
        Previous value: -"Suggested next tool calls — typically pentest_guide with fingerprint-populated stack, or pentest_generate_payloads for directly exploitable findings."New value: +"Suggested tools derived from detected fingerprints and findings."
      • changedOutput schema / properties / nextToolSuggestions / items / description
        Previous value: -"A suggested follow-up tool call with pre-filled arguments."New value: +"A suggested tool with arguments derived from the analysis."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / args / description
        Previous value: -"Pre-filled arguments derived from detected fingerprints and findings. Pass directly to the suggested tool."New value: +"Arguments derived from detected fingerprints and findings."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / reason / description
        Previous value: -"Why this tool is the logical next step given the analysis findings."New value: +"Relationship between the analysis findings and the suggested tool."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description
        Previous value: -"Tool name to call next (e.g., \"pentest_guide\")."New value: +"Suggested tool name (e.g., \"pentest_guide\")."
      • changedOutput schema / properties / summary / description
        Previous value: -"One-paragraph summary of findings and recommended next steps for the authorized tester."New value: +"One-paragraph summary of findings and associated follow-up actions."
      • removedOutput schema / required
        Removed value: -[
-  "authorized_use_reminder",
-  "findings",
-  "fingerprints",
-  "summary",
-  "nextToolSuggestions"
-]
    • Changedpentest_encode8 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / explain / description
        Previous value: -"Include step-by-step decode explanation. Set to false for raw transform output only."New value: +"Whether to include the decode path and bypass rationale."
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "original",
+      "encoded",
+      "intermediate_steps",
+      "detection_note"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • changedOutput schema / properties / detection_note / description
        Previous value: -"How defenders detect encoded payload variants — decoding normalizers, entropy analysis, behavioral detection. Always included to maintain the dual offense/defense framing."New value: +"Detection methods for encoded variants, including normalization and behavior signals."
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `encoding_error`: An encoding step produced invalid output (e.g., base64 on invalid input). Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "encoding_error"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • removedOutput schema / required
        Removed value: -[
-  "authorized_use_reminder",
-  "original",
-  "encoded",
-  "intermediate_steps",
-  "detection_note"
-]
    • Changedpentest_generate_payloads9 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / encoding / description
        Previous value: -"Apply an encoding chain to payloads at generation time. Applied in order (left to right). Use pentest_encode for more control over per-payload encoding."New value: +"Optional encoding chain applied left to right to each returned template."
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "category",
+      "injection_context",
+      "authorized_use_reminder",
+      "payloads"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode.",
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / payloads / items / properties / detection_signature / description
        Previous value: -"Signature a WAF or IDS might match (e.g., specific keywords, patterns). Useful for blue team rule-writing."New value: +"Signature a WAF or IDS might match, such as keywords or patterns."
      • changedOutput schema / properties / payloads / items / properties / mitigation / description
        Previous value: -"How the target application should validate or encode input to prevent this class of payload."New value: +"Input validation or encoding control that prevents this payload class."
      • removedOutput schema / required
        Removed value: -[
-  "category",
-  "injection_context",
-  "authorized_use_reminder",
-  "payloads"
-]
    • Changedpentest_guide16 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / phase / description
        Previous value: -"Restrict output to a specific phase. Use \"all\" for a complete playbook. Use a specific phase when working through a step-by-step flow."New value: +"Methodology phase selector. \"all\" returns the complete playbook; a named phase returns only that phase."
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "vector",
+      "authorized_use_reminder",
+      "phases",
+      "owasp_references",
+      "attack_technique_ids",
+      "nextToolSuggestions"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode.",
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / nextToolSuggestions / description
        Previous value: -"Suggested follow-up tool calls with arguments pre-populated from the playbook findings."New value: +"Suggested tools and arguments derived from the playbook."
      • changedOutput schema / properties / nextToolSuggestions / items / description
        Previous value: -"A follow-up tool call with pre-filled arguments derived from the playbook."New value: +"A suggested tool with arguments derived from the playbook."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / args / description
        Previous value: -"Pre-filled arguments from the methodology context. Pass directly to the tool."New value: +"Arguments derived from the methodology context."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / reason / description
        Previous value: -"Why this tool is the logical next step."New value: +"Relationship between the playbook and the suggested tool."
      • changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description
        Previous value: -"Tool name to call next (e.g., \"pentest_generate_payloads\")."New value: +"Suggested tool name (e.g., \"pentest_generate_payloads\")."
      • changedOutput schema / properties / phases / items / properties / objectives / description
        Previous value: -"What the tester is trying to discover or accomplish in this phase."New value: +"Discovery or execution objectives for this phase."
      • changedOutput schema / properties / phases / items / properties / techniques / items / properties / detection / description
        Previous value: -"How defenders detect this technique (log sources, signatures, anomalies)."New value: +"Observable logs, signatures, and anomalies for this technique."
      • changedOutput schema / properties / phases / items / properties / techniques / items / properties / mitigation / description
        Previous value: -"How the target system should be configured to prevent or reduce impact."New value: +"Configuration or control that prevents or reduces impact."
      • changedOutput schema / properties / phases / items / properties / tools_commonly_used / description
        Previous value: -"Commonly used tools for this phase (tool names, not instructions to install or use without authorization)."New value: +"Named tools commonly associated with this phase."
      • removedOutput schema / required
        Removed value: -[
-  "vector",
-  "authorized_use_reminder",
-  "phases",
-  "owasp_references",
-  "attack_technique_ids",
-  "nextToolSuggestions"
-]
    • Changedpentest_lookup_group8 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "id",
+      "name",
+      "aliases",
+      "type",
+      "description",
+      "techniques_used",
+      "attack_version"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • changedOutput schema / properties / attack_version / description
        Previous value: -"ATT&CK dataset version used (e.g., \"Enterprise v19.1\"). Included so callers know the data vintage."New value: +"ATT&CK dataset version used (e.g., \"Enterprise v19.1\")."
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_match`: No group or software entry matched the query. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_match"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / techniques_used / description
        Previous value: -"Techniques this group or software is known to use, with procedure-level context from public ATT&CK reporting (up to 20 entries). Use pentest_lookup_technique with each technique_id for full technique details including detection and mitigations."New value: +"Up to 20 techniques associated with the group or software, including procedure-level context and technique IDs."
      • removedOutput schema / required
        Removed value: -[
-  "authorized_use_reminder",
-  "id",
-  "name",
-  "aliases",
-  "type",
-  "description",
-  "techniques_used",
-  "attack_version"
-]
    • Changedpentest_lookup_technique10 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "technique_id",
+      "name",
+      "tactics",
+      "description",
+      "platforms",
+      "detection",
+      "mitigations",
+      "procedure_examples",
+      "sub_techniques",
+      "attack_version"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • changedOutput schema / properties / attack_version / description
        Previous value: -"ATT&CK dataset version used (e.g., \"Enterprise v19.1\"). Included so callers know the data vintage."New value: +"ATT&CK dataset version used (e.g., \"Enterprise v19.1\")."
      • changedOutput schema / properties / detection / description
        Previous value: -"Detection context — directly useful for blue team detection coverage."New value: +"ATT&CK detection context for the technique."
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_match`: No technique matched the query. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_match"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / procedure_examples / description
        Previous value: -"Real-world usage examples from ATT&CK public reporting. Useful for understanding adversary application of the technique."New value: +"Real-world usage examples from ATT&CK public reporting."
      • changedOutput schema / properties / sub_techniques / items / description
        Previous value: -"A sub-technique summary. Use pentest_lookup_technique with the sub-technique ID for full details."New value: +"A sub-technique ID, name, and brief description."
      • removedOutput schema / required
        Removed value: -[
-  "authorized_use_reminder",
-  "technique_id",
-  "name",
-  "tactics",
-  "description",
-  "platforms",
-  "detection",
-  "mitigations",
-  "procedure_examples",
-  "sub_techniques",
-  "attack_version"
-]
    • Changedpentest_map_techniques13 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • addedOutput schema / anyOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "authorized_use_reminder",
+      "ranked_techniques",
+      "owasp_test_cases",
+      "profile_summary",
+      "attack_version",
+      "truncated",
+      "shown",
+      "cap"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • addedOutput schema / properties / cap
        Added value: +{
+  "description": "The limit applied to ranked_techniques.",
+  "type": "number"
+}
      • addedOutput schema / properties / error
        Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_profile`: No profile fields were provided. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_profile"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / profile_summary / description
        Previous value: -"One-sentence summary of the target profile as interpreted by the ranking algorithm."New value: +"One-sentence normalized summary of the supplied target profile."
      • changedOutput schema / properties / ranked_techniques / items / properties / detection_opportunity / description
        Previous value: -"Primary detection opportunity for defenders (truncated to 200 chars)."New value: +"Primary observable detection opportunity (truncated to 200 characters)."
      • changedOutput schema / properties / ranked_techniques / items / properties / pentest_guide_vector / description
        Previous value: -"Pentest_guide vector name for follow-up methodology. Absent when no direct mapping exists."New value: +"Associated pentest_guide methodology vector. Absent when no direct mapping exists."
      • changedOutput schema / properties / ranked_techniques / items / properties / relevance_score / description
        Previous value: -"Relevance score based on profile match factors: 1 point per matching platform, 2 per matching service, 2 for auth type match. Higher = more applicable to this profile."New value: +"Relative relevance to the supplied target profile; higher scores indicate stronger matches."
      • addedOutput schema / properties / shown
        Added value: +{
+  "description": "Number of ranked techniques returned.",
+  "type": "number"
+}
      • addedOutput schema / properties / truncated
        Added value: +{
+  "description": "True when ranked_techniques was capped by limit.",
+  "type": "boolean"
+}
      • removedOutput schema / required
        Removed value: -[
-  "authorized_use_reminder",
-  "ranked_techniques",
-  "owasp_test_cases",
-  "profile_summary",
-  "attack_version"
-]
  3. 2 tool updates
    • Changedpentest_generate_payloads1 field changed
      • changedInput schema / properties / waf_profile / enum
        Previous value: -[
-  "cloudflare",
-  "aws_waf",
-  "modsecurity_crs",
-  "imperva",
-  "akamai",
-  "none",
-  "unknown"
-]New value: +[
+  "cloudflare",
+  "aws_waf",
+  "modsecurity_crs",
+  "imperva",
+  "akamai",
+  "f5_bigip_asm",
+  "nginx_modsecurity",
+  "fortinet_fortiwaf",
+  "none",
+  "unknown"
+]
    • Addedpentest_lookup_group
  4. 6 tool updates
    • First observedpentest_analyze_response
    • First observedpentest_encode
    • First observedpentest_generate_payloads
    • First observedpentest_guide
    • First observedpentest_lookup_technique
    • First observedpentest_map_techniques

Related MCP Connectors

Related MCP Servers

  • Pentest MCP

    WillemKarahan
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables professional penetration testers to run reconnaissance, exploitation, brute-force, traffic capture, and reporting workflows through MCP-compatible stdio, HTTP, and SSE transports with integrated tools such as nmap, gobuster, nikto, John the Ripper, hashcat, and wordlist generation.
    98 npm
    GPL 3.0

  • Pentest MCP

    christine40143
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables professional penetration testers to orchestrate reconnaissance, web scanning, brute-force testing, exploitation, traffic capture, hash cracking, wordlist building, privilege escalation audits, and client report generation via STDIO/HTTP/SSE transports with optional bearer/OIDC authentication.
    98 npm
    GPL 3.0

  • Pentest MCP

    RicardoChauhan80
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables professional penetration testers to run reconnaissance and exploitation tooling—nmap, gobuster, nikto, John the Ripper, hashcat, subfinder, httpx, ffuf, nuclei, hydra, and SQLi extraction sweeps—alongside wordlist generation, engagement-record capture, and client report creation. Supports stdio, Streamable HTTP, and legacy SSE transports with bearer-token/OIDC authentication.
    98 npm
    GPL 3.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources