Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct Burp feature or action: collaborator generation vs. polling, dedup management (load, list, get, search, send to repeater), JS file handling (load, list, get, search), history browsing (list, search, inspect), repeater/intruder creation from history or template, direct request sending, and sitemap building. Overlaps like multiple tools that send to repeater are differentiated by source (history entry vs. template vs. dedup entry).
Naming Consistency5/5Tool names follow a consistent verb_noun pattern (e.g., collaborator_check, dedup_get, list_history, send_request) with occasional prepositions for specificity (e.g., dedup_to_repeater, repeater_from_history). The naming is predictable and readable across the entire set.
Tool Count5/5With 20 tools, the server covers multiple distinct aspects of Burp interaction (history, repeater, intruder, collaborator, dedup, JS files) without being overbearing. Each tool serves a clear purpose, and the count is well-scoped for a comprehensive Burp automation interface.
Completeness4/5The tool set provides a solid coverage of core Burp workflow needs: history inspection, mutation and forwarding to repeater/intruder, collaborator interaction, dedup management, and JS file analysis. Minor gaps exist—such as no direct way to manage scope or proxy settings—but the surface is sufficient for typical automated testing scenarios.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
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.jsonto 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.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Load a _manifest.csv'. It does not mention side effects, whether it modifies state, requires authentication, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks necessary detail. It is not well-structured to convey the core functionality effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and two parameters, the description is severely incomplete. It fails to explain what the tool does with the manifest, expected output, or parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the description adds no meaning to the parameters (manifest_path, name). The agent gets no clues about what these parameters represent or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a _manifest.csv file, which is a specific resource and action. However, it does not differentiate from sibling tools like js_read or js_list, leaving ambiguity about what 'load' entails versus 'read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any prerequisites, context, or scenarios where js_load is appropriate.
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, so description must carry full burden. It discloses basic behavior (list, filter) but omits details like read-only nature, authentication needs, or what 'source' means. The description adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. Concise but sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations, the description is insufficient. It does not explain 'name' or 'limit', nor differentiate from sibling list tools. An output schema exists, so return values are covered, but input semantics are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description only hints at host_filter purpose. The required parameter 'name' and optional 'limit' are not explained at all, leaving the agent to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists JS files in a source with optional host regex filtering. However, it does not distinguish from sibling tool 'js_list', which could be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., js_list, js_search). No exclusions or prerequisites 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?
The description details the behavior of payload_markers (order, duplicate handling) but omits other behavioral traits such as whether the original history entry is modified, authentication requirements, or rate limits. Since no annotations are provided, this is a moderate effort.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, then details payload_markers. It uses two concise sentences without superfluous words, though it could benefit from listing other parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description is very incomplete. It covers only one parameter and lacks context on the rest, making it difficult for an agent to use the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains payload_markers, leaving eight other parameters (tab_name, method, path, set_headers, remove_headers, body, page_size, history_id) completely undescribed. This is insufficient for a 9-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Send a request to Burp Intruder, built from a history baseline'), but does not differentiate it from sibling tools like repeater_from_history, which have similar names and operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., repeater_from_history). The description does not mention context, prerequisites, or scenarios where this tool is preferred.
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 fully disclose behavior. It only states 'List all registered JS sources' without mentioning side effects, permissions, or whether it is read-only. The description lacks crucial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no unnecessary words. It is concise but could benefit from additional structure or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, existing output schema), the description is largely adequate. It explains the core functionality, and the output schema can provide return value details. However, it could be more complete by noting that the list includes all sources without filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema description coverage is trivially 100%. The description adds no parameter-specific information, but none is needed. A baseline of 3 is appropriate, raised slightly due to the absence of required elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'registered JS sources'. It is specific and distinguishes from siblings like 'js_search' or 'js_files', though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'js_search' for filtering. There are no use case examples or exclusions.
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, the description carries the full burden for behavioral disclosure. It explains the ref parameter flexibility but omits critical details like what the output contains (e.g., file content, metadata), error behavior (e.g., file not found), and side effects. The max_bytes parameter is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. The first states the purpose, the second explains the ref parameter. Information is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete. It fails to describe what the tool returns (e.g., file content), does not explain the name and max_bytes parameters, and omits error handling or size limit behavior, making it insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It does for ref, detailing multiple formats (integer index, full URL, path, saved_as path, basename) and that the first match wins. However, it does not explain the 'name' parameter or 'max_bytes', leaving those unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read one JS file from a source,' specifying the verb (read) and resource (JS file). This distinguishes it from sibling tools like js_list (list files), js_search (search), and js_load (load bulk), which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and purpose.
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 full burden. It explains that the dedup entry provides baseline cookies/UA, overrides can be applied, and the wrapper uses Burp's API. However, it does not disclose side effects, permissions needed, or error conditions, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that are front-loaded with purpose, then provide behavioral detail. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no per-param docs) and presence of an output schema, the description provides sufficient high-level context but lacks detail on prerequisites (e.g., must have dedup entries loaded) and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional structured overrides' but does not individually explain any of the 8 parameters (name, index, tab_name, etc.), leaving agents to infer meanings from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'a dedup entry to Burp Repeater', and adds context about optional overrides and baseline inheritance, which distinguishes it from sibling tools like repeater_from_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as repeater_from_history or intruder_from_history. The description does not provide when-not-to-use or selection criteria.
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?
Describes the tool's behavior (reading proxy history, grouping, counting) and output format. However, with no annotations, it fails to disclose potential side effects, auth needs, or limits. It implies a read operation but does not explicitly state non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Fairly concise and front-loaded with the action. The output format is well described, but some minor redundancy or missing details slightly reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has two parameters, the description provides some context but lacks explanation for page_size and usage scenarios. It covers the structure but misses completeness for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains host_filter as a regex for scoping, adding meaning beyond the schema (which has 0% coverage). However, page_size is not mentioned at all, leaving its purpose unclear. Description covers only one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds a sitemap from Burp proxy history, groups entries, counts occurrences, and returns a specific tree-style JSON. This distinctly describes its function and differentiates it from sibling tools like dedup_* or search_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some context by noting there is no upstream Target tool, implying it's the sole sitemap builder. It mentions using host_filter for scoping, but does not specify when to use this tool versus alternatives or provide explicit when-not scenarios.
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 states it searches and returns results. No disclosure of read-only nature, side effects, rate limits, or other behavioral traits. For a search tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines action and output, second gives usage instructions. Perfectly front-loaded with no filler. Every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a search tool with output schema (present, so return value details covered). Lacks parameter descriptions and pagination guidance, but covers the key integration point (history_index). Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%; description only mentions regex (implied) and history_index (returned, not parameter). No explanation of count (pagination size) or offset (page offset). Adds minimal value beyond the schema's field names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Search', resource 'Burp proxy history', and method 'with a regex'. Differentiates from siblings like list_history and inspect_history_entry by specifying regex search and returning compact list with history_index. Also explains how history_index feeds into other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for regex-based searches and hints at integration with other tools via history_index. However, no explicit exclusions or when-not-to-use guidance compared to alternatives like inspect_history_entry or list_history.
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 cover behavior. It only states 'load' without explaining side effects, permissions, or what happens on load (e.g., parsing, storage). The presence of an output schema is not leveraged to describe output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and parameter definitions, front-loaded with the core action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains parameters but omits behavioral details like error handling or output format. Given the output schema exists, the description could be more complete about the loading process, making it adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaningful detail: path is filesystem path (absolute or ~-expandable), name is an identifier defaulting to parent directory name. This goes beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a 'deduped_requests.txt' file from a specific Burp extension, using a specific verb and resource. This distinguishes it from sibling tools like dedup_get and dedup_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for loading files from the named extension, but it does not explicitly state when to use this tool versus alternatives (e.g., dedup_get for already-loaded data). Some context is provided but no direct comparison.
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 carry burden. It reveals output format and token thriftiness but does not explicitly state it's read-only or mention permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of purpose. No extraneous information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 params and no schema descriptions, the description is thin. Output format is noted, but missing details on pattern syntax, source definition, and parameter constraints. Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fails to explain any parameters. The agent must rely on parameter names and defaults, which is insufficient for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a grep across on-disk JS files, specifying the verb and resource. It also distinguishes itself from sibling tool js_read for fetching full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (searching JS files) and suggests alternative js_read for full content. However, it does not explicitly exclude cases like non-JS files or other siblings.
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 disclose behavioral traits. However, it only states the operation without mentioning side effects, permissions, or that it is a safe read operation, leaving ambiguity about 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information, perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and includes an output schema, the description sufficiently conveys the purpose. It does not need to explain return values as the schema covers that, and for a simple list-all function, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage trivially), and the description does not need to add parameter meaning. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all registered dedup sources' uses a specific verb ('list') and clearly identifies the resource ('registered dedup sources'), distinguishing it from siblings like dedup_get and dedup_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all possible sources, but provides no explicit guidance on when to use this tool versus alternatives (e.g., dedup_search for filtered queries, dedup_get for individual source details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states that by default it returns metadata plus truncated previews, and setting full=True gives complete raw data. This provides a solid behavioral contract, though it avoids discussing error behavior or index bounds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description: first sentence states purpose, second explains default behavior and option. No extraneous text, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values do not need detailed explanation. Description covers default vs full modes adequately. Could mention that entries are from a dedup store or index validity, but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description clarifies that index is 1-based and full is a boolean for full vs truncated output. However, the 'name' parameter is not explained, leaving its purpose ambiguous. The description adds value but not complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch a dedup entry by its 1-based index', identifying the action and resource. It distinguishes from siblings like dedup_list (lists all) and dedup_search (searches) by specifying indexed retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like dedup_list or dedup_search. The context of '1-based index' implies usage when the index is known, but no when-not-to or alternative references are provided.
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 full responsibility. It discloses the token-thrifty nature (short snippet) and regex search behavior, but lacks details on error handling, case sensitivity, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet complete, using a list for field values and separate lines for clarity. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and siblings, the description adequately explains the tool's purpose, parameters, and return format. It could mention how to discover valid 'name' values (via dedup_list), but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description partially compensates by explaining the 'field' parameter options and implying 'pattern' is a regex. However, 'name' and 'limit' are not elaborated, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Regex-search') and resource ('registered dedup source'), enumerates field options, and states the return format (index, url, status, snippet). It distinguishes itself from the sibling tool dedup_get, which fetches full data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on field values and explicitly directs to use dedup_get for full request/response, offering an alternative. However, it does not include explicit when-to-use or when-not-to-use context relative to other siblings like dedup_list.
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 disclose behaviors. It doesn't mention ordering (e.g., reverse chronological), pagination details beyond the parameters, or any limits. It adds 'recent' but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides usage guidance. No redundancy, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination parameters and an output schema (not shown), the description is mostly adequate but lacks details on ordering (e.g., recent by time) and pagination usage. Given sibling tools, it could mention that history entries are from the current project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and description does not explain count or offset parameters. While names are self-explanatory, description should clarify their role (e.g., pagination) to add value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists Burp proxy history entries with history_index, distinguishing it from search_history (regex search) and repeater_from_history (which sends one entry to repeater).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this when regex search isn't precise enough, and mentions feeding entries into repeater/intruder tools, providing clear context for when 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the polling action, return value (underlying function), and filtering mechanism with substring match. Missing details on potential latency or error handling, but sufficient for a simple read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences with no unnecessary words. Information is front-loaded and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one optional parameter and an output schema presumably documenting return values, the description covers core functionality. Minor gap: does not mention that it is typically used after collaborator_generate, but it remains complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parametric descriptions, but the description fully compensates by explaining the single parameter 'payload' as a substring filter with 'best-effort substring match'. This adds valuable meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls Burp Collaborator for received interactions, using a specific verb and resource. It distinguishes from sibling tools like collaborator_generate, which generates payloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While context signals list sibling tools, the description does not explain prerequisites or context (e.g., after generating a payload with collaborator_generate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the baseline contributes Host, cookies, auth, UA, etc., and overrides modify only specified fields. It also explains the page_size parameter for scanning history. However, it does not discuss behavior on missing id, conflicting overrides, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines) and well-structured: a clear one-sentence purpose, a brief explanation of the baseline concept, and a bulleted list of arguments. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters well and acknowledges an output schema exists. However, it omits prerequisites (e.g., having a history entry), possible errors, or the fact that it opens a new Repeater tab. Still, it is fairly complete for a tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the tool description's Args section provides essential meaning. Each parameter (history_id, tab_name, method, etc.) is briefly explained. While not exhaustive, the descriptions are sufficient to interpret parameter purposes and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Send a request to Burp Repeater, built from a history baseline plus optional structured overrides.' It specifies the resource (Burp Repeater using history) and distinguishes from siblings like 'repeater_from_template' by emphasizing the baseline and overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context but does not explicitly instruct when to use this tool versus alternatives (e.g., repeater_from_template, intruder_from_history). It mentions scanning history entries to find the id, which hints at a use case, but lacks direct guidance on when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains key behavioral traits: inheritance mechanism (inherit_from_history_id copies headers, then headers arg overrides), automatic re-derivation of Host/Content-Length. However, it does not mention error handling, rate limits, or output behavior. Since no annotations are provided, the description shoulders the burden well but has minor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-paragraph overview followed by a bulleted list of arguments. Every sentence adds value, and the structure is clear. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameter semantics are well-covered, the context is incomplete: no explanation of return values (though output schema exists, it's not referenced), no mention of prerequisites, error cases, or success cues. For a tool with 7 parameters and no annotations, more contextual completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning for all parameters: URL includes an example, method default is stated, headers override inherited, body, tab_name, and inheritance mechanics are explained. This compensates fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'Burp Repeater', and specifies it's built from scratch with URL and structured fields. It distinguishes from siblings like 'repeater_from_history' by emphasizing 'from scratch' and optional inheritance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for constructing a new request from scratch with optional inheritance, but does not explicitly state when to use this tool versus alternatives like 'send_request' or 'intruder_from_history'. No clear 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states the tool issues an HTTP/1.1 request, does not open a Repeater tab, and returns the response. It also explains the mutation mode modifies a history entry. It does not cover potential side effects like rate limiting or authentication details, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two usage modes clearly listed. Every sentence adds value without redundancy. It is appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete given the existence of an output schema (which explains return values). It covers parameters, modes, and behavior. However, it lacks examples or error handling info, and the page_size parameter is undocumented. For a complex tool with 10 parameters, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 9 of 10 parameters (history_id, url, method, path, set_headers, remove_headers, headers, body, inherit_from_history_id) but does not mention 'page_size', which has a default of 200 and likely controls response pagination. This is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Issue an HTTP/1.1 request via Burp (no Repeater tab) and return the response.' It specifies the exact function (sending a request) and distinguishes it from siblings like 'repeater_from_history' by noting it does not open a Repeater tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on two usage modes (mutate history entry or build from scratch) and when to use each. It mentions optional parameter inheritance. However, it does not explicitly state when not to use this tool or suggest alternatives like Repeater or inspect_history_entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 explains the positional addressing limitation ('Burp's MCP doesn't expose stable IDs; addressing is positional') and that the tool fetches from proxy history. It does not mention return format, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short paragraphs. The first sentence immediately states the purpose. Inline code clarifies the parameter semantics. The usage guidance adds context without unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (documenting return values), the description covers all essential aspects: purpose, parameter semantics, behavioral quirk (positional addressing), and usage context. An agent has enough information to select and correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fully explains both parameters: history_id is a 0-based index into the most recent page_size entries, and page_size determines the window. This adds significant meaning beyond the schema's bare titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch and pretty-print') and the resource ('Burp proxy history entry by index'), making the purpose immediately clear. It distinguishes from sibling tools like list_history and search_history by specifying inspection of a single entry by positional index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage scenario: 'Use this to inspect cookies/headers before crafting a mutated request.' This helps an agent decide when to invoke this tool. However, it does not explicitly list alternatives or when not to use it, which would have made it stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the OOB testing nature and the need to save payloads for later checking. However, it could mention that generated payloads are unique and time-limited, though not strictly required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short paragraphs, front-loaded with the action and purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter (count) and presence of output schema, the description fully covers what the agent needs: what the tool does, how to use it, and next steps. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), but description compensates by implying 'count' through 'one or more'. It adds value by explaining how to use the parameter (generate multiple). Could explicitly mention 'count' default, but still strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate), resource (Burp Collaborator payloads), and purpose (out-of-band injection canaries). It distinguishes from siblings like collaborator_check by specifying a different role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: for SSRF, blind XSS, OOB SQLi, etc. It also provides the workflow: generate, save, plant, then poll collaborator_check, which guides the agent on the correct sequence.
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.
Latest Blog Posts
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/titaniumtushar/burp-mcp-plus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server