Bug Bounty MCP Server

by R-s0n

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose. Methodology tools are differentiated as general vs. specific (rs0n's). Wordlist tools cover recommendation, content retrieval, listing, and searching. Knowledge base tools (browse, read, search) are separate operations. No overlapping responsibilities.
Naming Consistency5/5
All tools follow a consistent verb_object pattern with snake_case. Predominantly use 'get_' for data retrieval, with other verbs like 'assess', 'browse', 'list', 'read', 'search'. No mixing of conventions.
Tool Count5/5
14 tools is well-scoped for a bug bounty assistance server. It covers methodology, payloads, wordlists, knowledge base access, and report assessment without being overwhelming or too sparse.
Completeness5/5
The tool set provides comprehensive support for bug bounty testing: methodology (general and specific), payloads, WAF bypass, cloud security, wordlist management, report quality assessment, and real-world reports. There are no obvious missing features.
Average 3.7/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under GPL 3.0.
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?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention any side effects, authentication needs, rate limits, or response characteristics, leaving the agent with insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 21 words, efficient and front-loaded. However, it could be slightly more structured (e.g., listing platforms) to improve scanability without losing conciseness.
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 has 2 parameters (one required) and no output schema, the description provides a high-level overview but lacks details on return format or result types. It is adequate for a simple retrieval tool but could be more complete for cloud security context.
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%, providing clear explanations for both 'provider' (enum list) and 'topic' (example values). The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
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 'Get' and the resource 'cloud-specific security testing information', and lists cloud platforms (AWS, Azure, GCP, etc.), effectively distinguishing from sibling tools like get_bounty_reports or get_methodology.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description only states the tool's purpose without context for selection.
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?
With no annotations provided, the description fully relies on itself to disclose behavioral traits. It only says it 'returns' a wordlist but does not specify format (e.g., file content, path, or lines), whether it is a safe read, or any side effects. This leaves important behavioral 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, no wasted words, and directly communicates the tool's purpose. It is well-structured for quick consumption.
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 detailed input schema (enum with 20 values, optional head param) and no output schema, the description is adequate but does not clarify what 'returns' means (e.g., content vs. reference). It covers the core action but lacks completeness regarding the output format.
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 baseline is 3. The description does not add meaningful information beyond the schema; it only restates the purpose of the 'task' parameter implicitly. The 'head' parameter is not mentioned in the description.
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 action ('Get a recommended wordlist'), the resource ('wordlist'), and the context ('for a specific testing task'). It also mentions returning the best SecLists wordlist based on common bug bounty use cases, which differentiates it from sibling tools like 'search_wordlists' or 'list_wordlists'.
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 guidance on when to use this tool versus alternatives like 'search_wordlists' or 'get_wordlist'. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer from the 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 provided; description only says 'Get' which implies read-only, but does not disclose any behavioral traits like rate limits or side effects.
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?
Single sentence, front-loaded with key information, no wasted words.
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 simple retrieval tool with one parameter and no output schema, the description provides sufficient context. Could mention the return format but not critical.
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%, and the description does not add meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves WAF bypass techniques for vulnerability types. The verb 'Get' and resource 'WAF bypass techniques' are specific, but it does not explicitly distinguish from siblings like get_payloads.
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?
Description implies usage when needing WAF bypass for a specific vulnerability type, but lacks guidance on when not to use or alternatives.
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 carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, what it returns (e.g., list of directories/files), or any side effects. Only a basic action is described.
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 purpose, and contains no unnecessary words or repetition.
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?
For a simple browsing tool with one parameter and no output schema, the description explains the purpose and usage. However, it lacks details about the return value format (e.g., list of items), which could be helpful for the agent.
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% for the single parameter 'path', with a clear description and default. The tool description does not add additional meaning beyond the schema, meeting the baseline of 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 the verb 'browse' and the resource 'directory structure of the bug bounty knowledge base', and explains the purpose 'to discover what topics and categories are available'. It distinguishes from siblings like 'read_knowledge_file' and 'search_techniques'.
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 use for discovering structure but does not explicitly state when not to use or mention alternatives. No guidance on when to prefer browsing over searching or reading files.
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 burden. It discloses the tool returns payload lists, bypass techniques, and exploitation methods from known sources, but lacks details on output format, size limits, or potential errors. Basic behavior is clear but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and efficient, but could be front-loaded with the key verb and resource for quicker scanning. No wasted words.
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?
Missing output schema means the description should explain return format or structure. It only says 'returns relevant payload lists, bypass techniques, and exploitation methods' without details like whether it's raw text, JSON, or links. Incomplete for a data-fetching 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 coverage is 100%, so the description doesn't need to add much. It reiterates the category as a vulnerability category and specific_topic as a narrow-down, but provides no additional meaning beyond the schema's enum and descriptions.
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 gets payloads and attack vectors for a specific vulnerability category, naming sources PayloadsAllTheThings and HackTricks. It distinguishes from siblings like get_wordlist and browse_knowledge_base.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose, but no explicit guidance is given on when to use this tool versus alternatives like search_techniques or get_waf_bypass. No when-not-to-use or exclusions mentioned.
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 carries full burden. It mentions the tool is based on historical patterns but does not disclose behavioral traits such as whether the assessment is deterministic, if any data is stored, or if there are rate limits. It lacks depth for a predictive 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 long and front-loaded with the core purpose. Every word earns its place, and there is no extraneous information.
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?
Despite being a relatively simple tool with 5 parameters, the description does not specify the output format (e.g., a score, classification, or textual assessment). Without this, an AI agent cannot fully understand how to use the result, making it 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 covers 100% of parameters with descriptions. The description adds only a generic instruction to provide vulnerability details, which does not improve understanding beyond the schema. 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 evaluates a bug bounty finding's likelihood of acceptance or rejection, specifying the action 'evaluate' and resource 'potential bug bounty finding'. This distinguishes it from sibling tools like browse_knowledge_base and get_bounty_reports which are retrieval-oriented.
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 by saying 'Provide vulnerability details to get an assessment' but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. It offers no guidance on prerequisites or context.
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 exist, so the description must bear the burden. It indicates a read operation returning step-by-step approaches but does not disclose output format, limitations, or side effects. More detail on what 'returns' entails would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that efficiently communicates purpose and scope. It is front-loaded and free of fluff, but could be slightly more structured (e.g., separating what it does vs. what it returns).
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 simple tool with one parameter and no output schema, the description covers the main use case adequately. It states return type (methodology and checklists) and scope (specific types or general). Minor gaps: does not specify if output is per target type or list, nor the format (e.g., markdown).
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 single parameter target_type has 100% schema coverage with enum and description. The description reinforces the parameter's purpose but adds no new semantic detail beyond what the schema already provides. Baseline 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 returns structured bug bounty testing methodology and checklists for specific vulnerability types or general web app testing. The name aligns, and it is distinct from siblings like get_bounty_reports or get_cloud_security.
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 for testing methodology needs but does not explicitly contrast with siblings or provide when-not-to-use guidance. It lacks exclusion criteria or alternative recommendations.
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 carries full burden. It describes the content (four pillars) but does not disclose the behavior (e.g., return format, whether it's a summary or full text, any side effects). For a read-only retrieval of static content, this is adequate 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?
Two sentences: first introduces the specific resource, second emphasizes its importance and lists content. Every sentence is useful, no fluff.
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 simple retrieval tool but misses details about the output format and does not cover all possible input values (missing overview and skills). Given the absence of an output schema, this is a gap.
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 with a description for the 'pillar' parameter. The tool description adds context by listing four pillars, but omits two enum values (overview, skills) and does not explain their meanings. The parameter is simple, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific methodology from a named source (rs0n's DEFCON 32 workshop) and lists the pillars. It distinguishes itself as the 'PRIMARY methodology' for testing, but does not explicitly differentiate from the sibling 'get_methodology' tool.
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 explicitly says this should be the primary methodology guiding all testing, implying it should be used first. However, it does not mention when to use alternatives or when not to use this tool.
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 carries full burden. It only mentions 'Get' implying a read operation, but lacks details on return format, pagination, authentication, or side effects. For a read tool, basic behavioral traits are missing.
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 with three short sentences, front-loading the main action and immediately providing usage context. No unnecessary words or redundancy.
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 simple two-parameter tool with no output schema, the description covers the core functionality and offers clear usage scenarios. It lacks details on return type, but the name and context make it adequate.
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 baseline is 3. The description does not add extra meaning beyond the schema's field descriptions; it merely restates the purpose of the two types without enriching parameter semantics.
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 retrieves real-world bug bounty reports, distinguishing between accepted and rejected types. The verb 'Get' is specific to the resource, and the context differentiates it from sibling tools like assess_report_quality or get_payloads.
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 explicitly guides when to use each type: accepted for methodology examples, rejected for understanding what not to submit. However, it does not mention when to avoid the tool or consider alternatives.
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 exist, so the description is solely responsible. It states 'Returns directory listings' but does not disclose details like recursion depth, size limits, authentication, or output format. Behavior is straightforward but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and resource, second lists use cases. Front-loaded and efficient with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description explains the tool's action (browsing categories, returning directory listings) and use cases. It lacks details on return structure, but for a browsing tool it is reasonably complete.
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% and both parameters have descriptions (enum for category, optional for subdirectory). The description adds use-case context but no extra parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses SecLists wordlists by category and lists use cases like directory brute-forcing, subdomain enumeration, etc., making the purpose specific and distinct from sibling tools such as 'search_wordlists' and 'get_wordlist'.
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 for exploring categories but does not explicitly state when to use this tool versus alternatives like 'search_wordlists' or 'get_wordlist'. No when-not-to-use or alternative naming is provided.
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 carries the full burden. It does not disclose any behavioral traits such as rate limits, pagination, authentication requirements, or output structure. It only states the search scope without additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the action and scope, the second explains usage. It is front-loaded with essential information and contains no wasted words.
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 presence of sibling tools and high schema coverage, the description adequately covers purpose and usage. However, it lacks information about the output format or result structure, which would be helpful since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing example queries (e.g., 'XSS WAF bypass') and contextualizing the query parameter with terms like 'techniques, payloads, and methodologies'. However, it does not add detail for the source or maxResults parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a bug bounty knowledge base for techniques, payloads, and methodologies, with specific examples. It distinguishes from sibling tools by focusing on general search across the entire knowledge base, as opposed to more specific tools like get_payloads or search_wordlists.
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 tells the agent to use this tool to find information about vulnerability types and attack techniques, providing clear context. Although it does not explicitly mention when not to use it, the use case is well-defined and implicitly differentiates from siblings.
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 implies a read-only operation but lacks details on idempotency, side effects, rate limits, or size limitations. The description is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundancy. Every sentence adds value.
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 simple retrieval tool with two parameters, the description covers purpose and usage well. No output schema is provided, so a brief note on return format (e.g., 'returns the wordlist as text') would improve completeness, but it is still adequate.
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 the description does not add significant value beyond the schema. The 'path' parameter example is helpful but the schema already includes descriptions. No additional meaning is provided.
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 retrieves the contents of a specific SecLists wordlist file for tasks like directory brute-forcing, fuzzing, and subdomain enumeration. It distinguishes well from siblings like 'list_wordlists' and 'search_wordlists' by specifying the action and resource.
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 usage context for testing tasks, but does not explicitly mention when not to use this tool or point to alternatives like 'list_wordlists' for listing or 'search_wordlists' for finding specific wordlists.
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 provided, so description must cover behavioral traits. It describes a read operation with no side effects, but lacks details on error handling, permissions, or what happens if the path is invalid. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded. No unnecessary words. Every sentence adds value.
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?
The description is complete for a simple read tool with one parameter. It could mention the return format but that is implicit. No output schema exists, so description need not cover it.
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 single parameter 'path' is described with an example in the schema. The description adds no additional meaning beyond the schema, which already has 100% coverage. Baseline 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?
Clearly states the action (read a file) and the resource (bug bounty knowledge base). The additional phrase 'Use this after searching' provides context that distinguishes it from sibling tools like browse_knowledge_base.
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?
Explicitly suggests using after searching, implying it's for reading full content of already-identified files. No direct alternatives mentioned, but the context is clear enough.
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 carries the full burden. It implies a read-only search operation but does not disclose details such as the return format, whether multiple results are returned, or any side effects. It adds some context by mentioning 'SecLists' and 'filename or keyword' but lacks behavioral traits like pagination or rate limits.
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 no filler. It is front-loaded with the action ('Search for wordlists') and directly states the use case. Every word adds value.
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 has no output schema, so the description could clarify what the tool returns (e.g., list of filenames, paths). It does not mention whether results are ordered, limited, or paginated. Given the context of sibling tools like 'get_recommended_wordlist', users might expect more detail about output format.
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 input schema covers 100% of parameters with descriptions, but the tool description adds concrete examples for both parameters: 'e.g., 'common', 'api', 'subdomain', 'sqli', 'traversal' for query and 'like 'Discovery', 'Fuzzing', 'Passwords' for category. This enriches the semantics beyond the schema alone.
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: search for wordlists by filename or keyword. It distinguishes itself from sibling tools like 'list_wordlists' (which likely lists all) and 'get_wordlist' (which retrieves a specific one) by specifying that it's for finding the right wordlist for a specific testing task.
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 guidance on when to use the tool: 'Use this to find the right wordlist for a specific testing task.' It implies a search context but does not explicitly state when not to use it or compare with alternatives like 'list_wordlists' or 'get_recommended_wordlist'.
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:

[![rs0n-bug-bounty-mcp-server MCP server](https://glama.ai/mcp/servers/R-s0n/rs0n-bug-bounty-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/R-s0n/rs0n-bug-bounty-mcp-server)

Score Badge

Copy to your README.md:

[![rs0n-bug-bounty-mcp-server MCP server](https://glama.ai/mcp/servers/R-s0n/rs0n-bug-bounty-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/R-s0n/rs0n-bug-bounty-mcp-server)

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/R-s0n/rs0n-bug-bounty-mcp-server'

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