gobuster-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool maps to a distinct gobuster mode (dir, dns, vhost, fuzz, s3, tftp) or management function (status, stop, list scans, wordlists), so there is no overlap or ambiguity. Agents can easily select the right tool for the target.
Naming Consistency4/5
All tools share the 'gobuster_' prefix, but the suffix mixes mode nouns (dir, dns, vhost) with action verbs (stop, list_scans). This is predictable and readable, but not a pure verb_noun pattern throughout.
Tool Count5/5
With 10 tools, the server is well-scoped for a single-purpose gobuster interface. Each enumeration mode earns its place, and management/utility tools are minimal but sufficient.
Completeness4/5
The tool set covers all standard gobuster enumeration modes and the scan lifecycle (status, stop, list). A minor gap is the lack of an explicit 'get results' tool, but status likely returns findings, so agents can work around it.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only adds that execution happens 'on remote Kali host via SSH', which is useful, but it fails to disclose whether the operation is read-only, potential network impact, rate limiting, or expected side effects. For an enumeration tool, this is a significant gap.
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 extremely concise: two sentences with no filler. The first sentence front-loads the purpose, and the second adds critical execution context. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what results look like and any prerequisites. It does not mention return values, interpretation of results, or the need for pre-configured SSH access. For a tool with 6 parameters and no output schema, this is under-specified.
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?
The input schema already provides 100% coverage for all 6 parameters with clear descriptions. The tool description adds no extra parameter-specific meaning beyond stating the general purpose, so the baseline score of 3 is appropriate.
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 'TFTP file enumeration mode - discovers files on TFTP servers' which clearly identifies the verb (discovers), resource (files on TFTP servers), and distinguishes it from sibling gobuster modes like gobuster_dir or gobuster_dns. The name and description align perfectly.
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 guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what the tool does, leaving the agent to infer usage from the 'mode' label without naming alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool brute-forces Host headers and executes on a remote Kali host via SSH, which is useful context. However, it does not describe output format, potential side effects, or any safety/authorization considerations, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with front-loaded purpose and no fluff. It efficiently states what the tool does and adds the operational detail of remote SSH execution without unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no output schema, yet the description only covers high-level behavior. It omits expected return values, error handling, and operational considerations like how results are reported, making it incomplete for a complex enumeration tool.
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 structured schema already documents all 13 parameters. The description adds no additional meaning to the parameters, such as how they interact or typical values, so the baseline score of 3 is appropriate.
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 performs virtual host enumeration by brute-forcing Host header values, which is a specific verb and resource. It also implicitly distinguishes itself from sibling modes like gobuster_dir and gobuster_dns by focusing on virtual hosts.
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 does not provide any guidance on when to use this tool versus alternatives such as gobuster_dir or gobuster_dns. It lacks explicit context about prerequisites, target scenarios, or when not to use it, so the usage is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only adds the word 'asynchronous' and 'status', but does not describe the return format, possible status values, error behavior for invalid scan_id, or whether the call is blocking/non-blocking. This lack of detail is a significant gap for a status-polling tool.
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, direct sentence with no filler or redundant phrasing. It stays on point and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description leaves out what a returned status looks like and how to interpret it. While it covers the basic purpose and parameter, it is just barely complete for an AI agent that needs to know what to expect from the call.
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?
The schema already fully describes the single parameter (scan_id) with a clear explanation ('The scan ID returned from an async scan'). The description adds no additional semantic value beyond reinforcing the async context, so baseline 3 is appropriate.
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 a specific action ('Check the status') applied to a specific resource ('an asynchronous gobuster scan'). It is unambiguously differentiated from sibling tools like gobuster_stop (which terminates scans) and gobuster_list_scans (which enumerates scans).
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 description implies usage when a scan_id from an asynchronous scan is available, but it does not explicitly state when to use this tool over alternatives like gobuster_list_scans or gobuster_stop. There is no mention of exclusions or contextual triggers beyond the basic scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action but does not mention consequences like irreversibility, impact on partial results, or response/confirmation behavior. This is a significant gap for a mutation tool.
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 sentence with no superfluous content. It is front-loaded with the verb and resource, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the core action. However, with no annotations and minimal guidance, it is not fully complete—missing usage context and behavioral details, though it remains adequate for a basic stop operation.
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?
The input schema has 100% coverage with a clear description for scan_id ('The scan ID to stop'). The description text itself adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Stop') and resource ('running asynchronous gobuster scan'), clearly distinguishing it from sibling tools like gobuster_status (which checks status) and gobuster_list_scans (which lists scans).
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 intended usage is implied: use this when you need to stop a scan. However, it does not explicitly state alternatives or exclusions, such as noting that this only applies to asynchronous scans or that you should obtain the scan ID from gobuster_list_scans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It reveals that the tool executes on a remote Kali host via SSH and uses wordlist-based brute forcing, which are meaningful traits. However, it omits side effects, async scan behavior, result output, and potential rate-limit impact, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the essential purpose. Every word earns its place, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters) and lack of output schema, the description is too sparse. It fails to mention return values, async/sync behavior, scan lifecycle (e.g., using gobuster_status), or how to interpret results. These are critical for an agent to correctly invoke the tool and use its output.
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 coverage is 100%, so every parameter has a description. The tool description adds minimal semantics beyond the schema, only framing the operation as 'wordlist-based brute forcing'. It does not elaborate on how parameters interact or provide usage examples, fitting the baseline 3.
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 it is the 'DNS subdomain enumeration mode' and specifies the verb 'discovers' with the resource 'subdomains for a target domain'. This unambiguously differentiates it from sibling tools like gobuster_dir (directory brute-forcing) and gobuster_vhost (virtual host discovery).
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 phrase 'DNS subdomain enumeration mode' implies the tool is for discovering DNS subdomains, which guides selection among the gobuster family. It also notes remote execution via SSH, giving context. However, it does not explicitly state when NOT to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses a read-only listing operation but does not elaborate on what kinds of wordlists are included, whether it scans local directories, or any environment dependencies. For a simple list tool, this is acceptable but not rich.
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, clear sentence with no unnecessary words or repetition. It is perfectly concise and front-loaded.
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 tool with one optional parameter, no output schema, and a simple listing function, the description conveys the essential purpose. However, it does not specify the output format (e.g., file paths vs. names) or mention the category filter in the description, so it is slightly incomplete.
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?
The input schema fully documents the single optional 'category' parameter with enum values and a default of 'all', giving 100% coverage. The description adds no additional parameter information, so the baseline of 3 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?
The description clearly states the verb 'List' and the resource 'available wordlists', with a specific scope 'on the Kali host'. This distinguishes it from sibling tools like gobuster_dir or gobuster_list_scans, which serve different functions.
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 description does not explicitly state when to use this tool versus alternatives, but the purpose implies it is the utility for discovering wordlists before running gobuster scans. There are no explicit exclusions or alternative references, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses some behavioral traits such as executing remotely via SSH and using wordlist-based brute forcing. However, it omits details about active scanning consequences, rate limits, or how results are returned, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose. It is concise, free of redundancy, and quickly conveys what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters) and lack of an output schema, the description covers the core purpose and remote execution but does not explain expected output, interpretation of results, or typical usage nuances. This leaves the tool under-specified for an agent unfamiliar with gobuster's behavior.
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?
The input schema provides 100% coverage for all 16 parameters, so the baseline is met. The description adds minimal extra meaning beyond mentioning wordlist-based brute forcing, which loosely relates to the wordlist parameter but doesn't enhance understanding of any specific parameter.
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 function as 'Directory/file enumeration mode' with the objective to discover hidden directories and files on web servers. It distinguishes itself from sibling tools like gobuster_dns and gobuster_vhost by focusing on path brute-forcing.
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 provides clear context by specifying this mode is for directory/file enumeration via wordlist-based brute forcing, implying when to use it. However, it doesn't explicitly exclude alternatives or mention when not to use it, stopping short of full prescriptive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (FUZZ replacement) and importantly notes that it 'Executes on remote Kali host via SSH.' However, it does not mention potential side effects (e.g., generating significant network traffic), the meaning of async, or result format, leaving some uncertainty for a complex scanning tool.
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 concise sentences with no redundancy. The most critical information (FUZZ replacement) is front-loaded, followed by use case and execution context. Every sentence earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with 13 well-documented parameters, but it lacks information about output format or workflow (e.g., how results are returned, when to use async). Since there is no output schema, some guidance on return values would improve completeness. The description is not deficient enough to score 2, but it leaves practical gaps.
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?
The schema has 100% coverage, so every parameter is already well-documented (e.g., url, headers, post_data). The description adds little beyond what the schema provides, merely summarizing that FUZZ can appear in URLs, headers, or POST data, which is already evident from parameter descriptions. Thus, baseline 3 is appropriate.
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 function: 'Fuzzing mode - replaces the FUZZ keyword in URLs, headers, or POST data with wordlist entries.' This specific verb+resource (replaces in fuzz mode) distinguishes it from sibling tools like gobuster_dir or gobuster_dns, making its purpose unmistakable.
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?
It gives a clear use case: 'Useful for parameter discovery and testing.' While it doesn't explicitly name alternatives or say 'use this instead of X', the stated purpose effectively guides when to choose fuzzing over directory or DNS brute-forcing. The mention of remote Kali execution adds context for deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs wordlist-based brute forcing and executes on a remote Kali host via SSH. However, it does not mention whether the scan is read-only, potential rate limits, authentication needs, or any side effects. While 'discovers open S3 buckets' suggests non-destructive reconnaissance, more operational transparency would be expected for a network scanning tool.
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 sentences, front-loaded with the core purpose and execution context. Every word earns its place, with no redundant or marketing language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema), the description covers the main purpose and execution environment but omits details about expected output/return values, potential impact of the scan, and how to handle results. The schema covers parameters, but the description alone would not fully prepare an agent for what happens after invocation.
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?
The schema description coverage is 100%, so the baseline is 3. The description adds context around the wordlist parameter by mentioning 'wordlist-based brute forcing', but it doesn't clarify parameter syntax, formats, or relationships beyond what the schema already provides. No additional parameter semantics are introduced.
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 function: 'Amazon S3 bucket enumeration mode - discovers open S3 buckets using wordlist-based brute forcing.' It identifies both the resource (S3 buckets) and the action (enumeration), and the 'mode' phrasing distinguishes it from sibling gobuster tools.
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 provides clear context for when to use this tool: it is for discovering open S3 buckets via wordlist brute forcing. Though it doesn't name alternative tools explicitly, the 'mode' label implies it is one of several gobuster modes, and the S3-specific terminology sets it apart. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'List' implies a read-only operation, and there are no side effects mentioned, which is appropriate for a simple list tool. However, it does not explicitly state whether authentication is required or what constitutes 'recent', leaving some ambiguity about the tool's behavior.
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 sentence that directly states the tool's function without any filler words. It is front-loaded with the verb 'List' and the resource, making it immediately clear and concise.
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 zero-parameter tool with no output schema, the description adequately states what the tool does. It includes the key qualifiers 'active and recent' to set expectations. However, it does not describe the output format or fields, which could be valuable given the lack of an output schema.
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?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, 0 parameters gives a baseline of 4, and the description correctly implies that no parameters are needed. There is no additional parameter meaning to convey.
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 purpose: 'List all active and recent gobuster scans' – a specific verb ('List') and resource ('gobuster scans') with a clear scope ('active and recent'). This distinguishes it from sibling tools like gobuster_status (which checks a specific scan) and gobuster_stop (which stops scans).
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 description implies when to use this tool (to get an overview of active and recent scans) but provides no explicit guidance on when to use it versus alternatives like gobuster_status or gobuster_stop. It is left to the agent to infer the tool's role from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sec-gobuster-mcp MCP server](https://glama.ai/mcp/servers/schwarztim/sec-gobuster-mcp/badges/card.svg)](https://glama.ai/mcp/servers/schwarztim/sec-gobuster-mcp)

Score Badge

Copy to your README.md:

[![sec-gobuster-mcp MCP server](https://glama.ai/mcp/servers/schwarztim/sec-gobuster-mcp/badges/score.svg)](https://glama.ai/mcp/servers/schwarztim/sec-gobuster-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-gobuster-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server