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.6/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of penetration testing: response analysis, encoding, payload generation, methodology guidance, technique lookup, and technique mapping. There is no overlap in functionality, and descriptions clearly differentiate them.
All tools follow the 'pentest_verb_noun' pattern consistently (e.g., analyze_response, generate_payloads, map_techniques). The minor exception of 'pentest_guide' still follows the verb-first convention and is clear in context.
With 6 tools, the server covers essential pentest helper functionalities without being bloated. Each tool serves a clear purpose, and the count is well-scoped for the domain.
The tool set covers major phases: analysis, encoding, payload generation, methodology, technique lookup, and target mapping. It provides a comprehensive foundation for authorized testing, though a tool for direct scanning or live interaction could be considered a slight gap depending on the intended use.
Available Tools
6 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 already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral details: payloads are 'annotated templates' with explanations, detection signatures, mitigations, and context-awareness. 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 relatively concise (3 sentences) and front-loaded with the main purpose. It could be slightly more structured, but every sentence adds substantive 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 complexity (5 parameters, 2 required, 3 enums, output schema exists), the description fully covers tool capabilities, context-awareness, and output nature. No gaps remain for an agent to understand correct usage.
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 descriptions for all parameters. The description adds value by explaining context-awareness (e.g., XSS differs by injection context) and that WAF profiles trigger known bypass research, beyond what the schema provides.
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 uses specific verbs ('generate payload templates') and clearly identifies the resource ('for authorized testing'). It distinguishes from siblings like pentest_encode by noting 'context-awareness is core' and mentioning encoding can be done via pentest_encode.
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 states the tool is for 'authorized testing against systems the tester owns or is permitted to test,' providing clear context of use. It references pentest_encode for more control over encoding, but does not exhaustively list when not to use this tool versus all 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_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!