pentest-mcp-server
Server Details
Offline methodology engine for authorized penetration testing, CTF, and security research.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool targets a distinct function: analyzing responses, encoding payloads, generating payloads, providing methodology guide, looking up MITRE groups/techniques, and mapping techniques to target profiles. Descriptions are specific and minimize ambiguity.
All tools share the 'pentest_' prefix and most follow a verb_noun pattern (e.g., analyze_response, generate_payloads). However, 'pentest_encode' is just a verb and 'pentest_guide' is just a noun, breaking the pattern slightly.
Seven tools is a well-scoped set for a penetration testing assistant. Each tool serves a clear purpose without redundancy, covering analysis, generation, lookup, and planning.
The tool surface covers core penetration testing needs: response analysis, payload encoding/generation, methodology guides, and threat intelligence lookups. Minor gaps exist (e.g., no reporting tool), but the set is largely complete for planning and recon phases.
Available Tools
7 toolspentest_analyze_responsePentest Analyze ResponseARead-onlyIdempotentInspect
Analyze a server response from authorized probing for information leakage, fingerprinting signals, and exploitation opportunities scoped to the authorized engagement. Accepts raw HTTP response headers and body (paste from Burp, curl, or any HTTP client) and returns structured findings grouped by category. Each finding includes: what was detected, why it matters for an authorized tester, how a defender detects misuse, and recommended remediation. Identifies version disclosures, stack traces, debug headers, internal paths, JWT/cookie patterns, CORS misconfigurations, and other common leakage patterns. Use as the bridge between recon/probing output and the methodology and payload tools.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Freeform 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_code | No | HTTP status code (100–599). Helps classify the response type. | |
| response_body | No | 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. | |
| response_headers | No | Raw HTTP response headers (paste from Burp, curl -v, or similar). Include the status line if available. Max 20,000 characters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | One-paragraph summary of findings and recommended next steps for the authorized tester. |
| findings | Yes | Structured findings ordered by severity descending (high first). |
| fingerprints | Yes | Technology fingerprinting summary for use in target_context when calling pentest_guide or pentest_map_techniques. |
| nextToolSuggestions | Yes | Suggested next tool calls — typically pentest_guide with fingerprint-populated stack, or pentest_generate_payloads for directly exploitable findings. |
| authorized_use_reminder | Yes | Reminder that response analysis is for authorized testing only. Rendered first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint as true, and the description aligns by describing analysis without side effects. It adds behavioral context about output structure (grouped findings with detection details) and scope (authorized engagement), going beyond what annotations convey.
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 dense paragraph covering purpose, input, output, and usage guidance. It is efficient but could benefit from slight restructuring (e.g., bullet points for outputs) without adding length. The omission of parameter details keeps it focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema, security domain), the description provides sufficient context: input format, output categories, and role in workflow. The existence of an output schema reduces the need to detail return values, but the description still lists detection categories, making it 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?
Schema coverage is 100% with descriptive parameter fields. The description adds value by explaining how parameters are used together (e.g., 'context' narrows pattern matching, 'response_body' truncated to first 10k chars) and by specifying pasting from common tools, which aids correct invocation.
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 analyzes server responses for information leakage, fingerprinting, and exploitation opportunities. It lists specific detection categories (version disclosures, stack traces, etc.), making the purpose precise and distinguishable from siblings like pentest_generate_payloads and pentest_lookup_technique.
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 positions the tool as a bridge between recon/probing output and methodology/payload tools, providing clear context for use. It specifies input sources (Burp, curl) but lacks explicit exclusions or alternative tool references, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pentest_encodePentest EncodeARead-onlyIdempotentInspect
Transform a payload string through one or more encoding layers for bypass research during authorized testing. Accepts a chain of encodings applied in order (e.g., ["unicode", "url", "base64"] applies Unicode → URL-encode → base64). Returns the transformed payload with a step-by-step decoding explanation: how a WAF or server would decode each layer, and why the combined encoding might bypass a specific filter. Use to understand filter bypass mechanics in an authorized engagement and to confirm that a target's decoding pipeline matches an expected bypass path. Payloads are transformed mathematically — no live probing occurs.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Ordered 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. | |
| explain | No | Include step-by-step decode explanation. Set to false for raw transform output only. | |
| payload | Yes | Input payload string to encode. Max 10,000 characters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| encoded | Yes | Final encoded payload after all chain steps applied. |
| original | Yes | The input payload. |
| decode_path | No | Step-by-step explanation of how a decoder (WAF, server, browser) would reverse the encoding chain. Included when explain is true. |
| detection_note | Yes | How defenders detect encoded payload variants — decoding normalizers, entropy analysis, behavioral detection. Always included to maintain the dual offense/defense framing. |
| bypass_rationale | No | Why this encoding combination might bypass common filter patterns. Included when explain is true. |
| intermediate_steps | Yes | Intermediate values at each encoding step, for tracing the chain. |
| authorized_use_reminder | Yes | Reminder that encoding transforms are for authorized bypass research only. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds critical behavioral context: 'Payloads are transformed mathematically — no live probing occurs.' It also details the return value (transformed payload with step-by-step decoding explanation) and constraints (max 6 steps, 10k chars).
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 (6 sentences) and front-loaded with the primary action. Every sentence contributes uniquely, with no redundancy. The structure clearly separates purpose, usage, and behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, 10 encoding types, max 6 steps) and the presence of an output schema, the description thoroughly covers purpose, usage context, behavioral guarantees, and return structure. It leaves no critical gaps for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing an example of the chain encoding order ('e.g., ["unicode", "url", "base64"]') and explaining that the output includes a step-by-step decoding explanation, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool transforms a payload through encoding layers for bypass research, using a specific verb ('Transform') and resource ('payload string'). It is distinct from sibling tools like pentest_generate_payloads or pentest_analyze_response, which focus on generation or analysis.
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 explicitly advises when to use the tool: 'Use to understand filter bypass mechanics in an authorized engagement and to confirm that a target's decoding pipeline matches an expected bypass path.' It also clarifies that no live probing occurs, helping agents avoid misuse.
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 PayloadsARead-onlyIdempotentInspect
Generate payload templates for authorized testing against systems the tester owns or is permitted to test. Payloads are annotated templates — each includes why it works in the specified context, what vulnerability class it tests, detection signatures that WAF/IDS products might fire, and recommended mitigations. Context-awareness is core: an XSS payload for an HTML attribute differs entirely from one for a JS template literal, and both differ from a DOM-based sink. When a WAF profile is specified, bypass variants reference known public research for that WAF product. All payloads are illustrative templates for authorized testing only.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of payload variants to return (1–20, default 5). More variants cover different bypass approaches for the same context. | |
| category | Yes | Vulnerability category for payload generation. | |
| encoding | No | 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. | |
| waf_profile | No | WAF 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_context | Yes | Precise 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
| Name | Required | Description |
|---|---|---|
| category | Yes | Requested payload category. |
| payloads | Yes | Payload templates ordered by coverage breadth, each annotated with offense and defense context. |
| injection_context | Yes | Requested injection context. |
| authorized_use_reminder | Yes | Reminder that these templates are for authorized testing only. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description adds behavioral details such as payloads being annotated templates with detection signatures and mitigations. No contradiction, and description enriches understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences, front-loads the core purpose, and efficiently conveys necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, existing output schema), the description fully covers behavior, context-awareness, and typical usage, leaving no significant 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 coverage is 100%, so baseline is 3. The description adds context about how injection_context and waf_profile affect output, and notes encoding order. This extra semantic clarity raises the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates payload templates for authorized testing, with context-awareness and explanatory annotations. It is distinct from sibling tools like pentest_analyze_response or pentest_encode, which focus on different operations.
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 explicitly limits use to authorized testing and explains when to specify a WAF profile. It provides clear context but does not enumerate all alternative scenarios or directly compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pentest_guidePentest GuideARead-onlyIdempotentInspect
Return a structured attack methodology playbook for the given attack vector and optional target context, for use in authorized penetration testing, CTF, or security research. Covers reconnaissance, enumeration, exploitation, and post-exploitation phases for the vector, filtered to what is relevant given the provided stack and WAF profile. Each phase includes: what to look for, tools to use, common mistakes, detection indicators that would alert defenders, and recommended mitigations. Next-tool suggestions are pre-filled with payload generator and technique lookup calls. Covers 15 vectors via the vector enum. Authorized testing only.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | Restrict output to a specific phase. Use "all" for a complete playbook. Use a specific phase when working through a step-by-step flow. | all |
| vector | Yes | Attack vector to retrieve methodology for. Each vector has its own methodology branch covering recon through exploitation. Authorized testing only. | |
| target_context | No | Optional target profile for authorized engagement. Providing this narrows the playbook to what is most relevant for the specific environment. |
Output Schema
| Name | Required | Description |
|---|---|---|
| phases | Yes | Ordered methodology phases. Contains only the requested phase when phase input is not "all". |
| vector | Yes | The requested attack vector. |
| owasp_references | Yes | Relevant OWASP Testing Guide test case IDs (e.g., "WSTG-INPV-01"). |
| nextToolSuggestions | Yes | Suggested follow-up tool calls with arguments pre-populated from the playbook findings. |
| attack_technique_ids | Yes | Relevant ATT&CK technique IDs for cross-referencing with pentest_lookup_technique. |
| authorized_use_reminder | Yes | Reminder that this methodology applies to authorized testing only. Included in every response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, and the description adds behavioral context by detailing the phases, tools, detection indicators, and mitigations included. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that presents the main purpose first and lists contents efficiently. It could be structured with bullet points for readability, but it is appropriately sized and front-loaded.
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 complexity (15 vectors, multiple phases, optional context) and the presence of an output schema, the description covers all necessary aspects: what each phase includes, next-tool suggestions, and authorized use. It is complete for a guide tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that phase restricts to specific phases, vector covers 15 enums each with methodology, and target_context narrows the playbook, enhancing meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'structured attack methodology playbook' for a given attack vector and optional target context, distinguishing it from siblings like payload generators or technique lookups. It specifies the verb 'return' and the resource, and mentions covering recon through post-exploitation.
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 explicitly says 'for use in authorized penetration testing, CTF, or security research' and 'Authorized testing only,' providing clear context. It implies usage as a high-level guide with next-tool suggestions, but does not explicitly list when not to use or alternatives among siblings.
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 GroupARead-onlyIdempotentInspect
Look up a MITRE ATT&CK threat group (intrusion set) or software entry by name or ID for authorized penetration testing and threat intelligence. Returns the group or software record: ATT&CK ID, display name, known aliases, type (group vs. software), description, and the techniques it uses with procedure-level context from public ATT&CK reporting. Accepts exact ATT&CK IDs (G0007 for threat groups, S0002 for software) or keyword/name search (e.g., "APT28", "Mimikatz", "Lazarus Group"). Equally useful for defenders building detection coverage around specific adversary tradecraft.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ATT&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
| Name | Required | Description |
|---|---|---|
| id | Yes | ATT&CK ID (e.g., "G0007" for a group, "S0002" for software). |
| name | Yes | Primary display name (e.g., "APT28", "Mimikatz"). |
| type | Yes | "group" for intrusion sets (threat actors), "software" for malware and tools. |
| aliases | Yes | Known alternate names from ATT&CK. |
| description | Yes | ATT&CK description (truncated to 800 characters). |
| attack_version | Yes | ATT&CK dataset version used (e.g., "Enterprise v19.1"). Included so callers know the data vintage. |
| techniques_used | Yes | 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. |
| authorized_use_reminder | Yes | Reminder that threat group data is for authorized testing and research only. Rendered first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and idempotent, and the description adds behavioral details: returns specific fields, ID lookup is exact and case-insensitive, name search returns best match. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with key information. It is clear but could be slightly more concise; still, no wasted sentences.
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 parameter count (1), annotations, and output schema, the description covers most needs: return fields, search behavior, and use cases. It does not mention error handling, but this is acceptable for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is fully described in the schema (100% coverage) and the description adds semantic context (examples, search behavior, case-insensitivity), providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up MITRE ATT&CK threat groups or software entries by name or ID, with specific verb and resource. It differentiates from sibling tools like pentest_lookup_technique by specifying it handles groups and software.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies authorized use cases (penetration testing, threat intelligence) and explains how to query (by ID or name/keyword). It lacks explicit when-not-to-use or comparisons to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pentest_lookup_techniquePentest Lookup TechniqueARead-onlyIdempotentInspect
Look up a MITRE ATT&CK technique by ID or keyword for authorized penetration testing and security research. Returns the full technique record: name, associated tactics, description, detection opportunities (log sources, behavioral indicators), real-world procedure examples from public reporting, recommended mitigations, and related sub-techniques. The detection and mitigation sections make this equally useful for defenders building detection coverage. Accepts exact IDs (T1190, T1059.001) or keyword search (e.g., "sql injection", "pass the hash", "web shell upload").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ATT&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_subtechniques | No | Include sub-techniques in the result. Set to false when only the parent technique summary is needed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Technique name. |
| tactics | Yes | ATT&CK tactics this technique belongs to (e.g., "Initial Access", "Execution"). |
| detection | Yes | Detection context — directly useful for blue team detection coverage. |
| platforms | Yes | Target platforms (e.g., "Windows", "Linux", "Web Application"). |
| description | Yes | ATT&CK description of the technique. |
| mitigations | Yes | Recommended mitigations from ATT&CK. |
| technique_id | Yes | ATT&CK technique ID (e.g., "T1190"). |
| attack_version | Yes | ATT&CK dataset version used (e.g., "Enterprise v19.1"). Included so callers know the data vintage. |
| sub_techniques | Yes | Sub-techniques of this parent technique. Empty when querying a sub-technique itself, or when include_subtechniques is false. |
| procedure_examples | Yes | Real-world usage examples from ATT&CK public reporting. Useful for understanding adversary application of the technique. |
| authorized_use_reminder | Yes | Reminder that technique data is for authorized testing and research only. Rendered first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it returns full technique records, accepts exact IDs or keywords, and details the output structure, which is consistent and non-contradictory.
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, front-loaded with the main action, and every sentence adds value: purpose, return content, dual usage, and input examples. No superfluous information.
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 presence of an output schema, the description sufficiently covers input, search modes, and result components without needing to detail return values. It is complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage with descriptions for both parameters, but the description adds context by explaining the query parameter accepts IDs or keywords with examples, and implies the output includes sub-techniques by default.
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 looks up MITRE ATT&CK techniques by ID or keyword, and differentiates from siblings (analyze, encode, generate payloads, guide, map) by focusing on retrieval of full technique details including detection and mitigations.
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 specifies authorized use for penetration testing and security research, and notes the tool is also useful for defenders, but does not explicitly discuss when to use vs. alternative tools like pentest_map_techniques.
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 TechniquesARead-onlyIdempotentInspect
Given a profile of the authorized test target (technology stack, exposed services, authentication type, OS), return a ranked list of ATT&CK techniques and OWASP test cases most relevant to that profile — not a generic dump of all techniques. Ranking factors: platform match, service match, auth type exposure, technique prevalence. Each result includes why it is relevant to this specific profile, the detection opportunity, and the recommended mitigation. Use when starting an authorized engagement to prioritize the testing scope; pair with pentest_guide to get the full methodology for each top-ranked vector.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Target operating system. Narrows to OS-specific techniques. | |
| limit | No | Maximum number of techniques to return (1–50, default 15). Higher values give broader coverage; lower values focus on highest-relevance items. | |
| stack | No | Technology stack components (e.g., ["Node.js", "Express", "PostgreSQL", "Redis"]). Each element matched against technique platform and procedure examples. | |
| services | No | Exposed services and interfaces (e.g., ["REST API", "GraphQL", "file upload", "admin panel"]). Narrows technique relevance. | |
| auth_type | No | Authentication mechanism in use. Surfaces auth-specific attack techniques. |
Output Schema
| Name | Required | Description |
|---|---|---|
| attack_version | Yes | ATT&CK dataset version used for technique data. |
| profile_summary | Yes | One-sentence summary of the target profile as interpreted by the ranking algorithm. |
| owasp_test_cases | Yes | Relevant OWASP Testing Guide test cases for the profile (up to 10). |
| ranked_techniques | Yes | Techniques ordered by relevance_score descending. |
| authorized_use_reminder | Yes | Reminder that technique mapping is for authorized testing engagements only. Rendered first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds ranking factors (platform match, service match, auth type, prevalence) and explains output includes relevance, detection opportunity, and mitigation, going beyond annotation details.
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 compact (3 sentences) and front-loaded with the core purpose. Each sentence adds essential information: what it does, ranking factors, output details, and usage guidance. No redundant or unclear language.
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?
With a rich input schema (100% coverage), output schema present, and clear sibling context, the description fully covers the tool's purpose, input, and output behavior. It leaves no important question unanswered for the given complexity.
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?
Input schema has 100% coverage with descriptions for each parameter. The description adds value by explaining how parameters (stack, services, auth_type) are used in ranking logic, providing context beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'ranked list of ATT&CK techniques and OWASP test cases most relevant to that profile' and explicitly notes it is 'not a generic dump of all techniques,' distinguishing it from sibling tools like pentest_lookup_technique.
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 explicitly advises when to use ('when starting an authorized engagement to prioritize the testing scope') and suggests pairing with pentest_guide for full methodology, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!