nodriver-proxy-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation3/5
The tool set covers a wide range of proxy, browser, and traffic functions, but there is notable overlap between proxy-level and browser-level interception tools (e.g., add_interception_rule vs browser_intercept_request) and between extract_from_flow and extract_session_variable. Descriptions clarify the differences, but the 39-tool surface makes misselection possible.
Naming Consistency2/5Naming is inconsistent across the set: browser_* tools use a domain-prefix convention, while proxy tools mix verb_noun (manage_proxy, search_traffic) and noun_verb (proxy_status, extract_session_variable). No uniform verb_noun pattern is applied across all tools.
Tool Count2/5At 39 tools, the surface is heavy and exceeds the typical range. The broad scope of proxy, browser, and pentesting functionality somewhat justifies the size, but it still feels bloated compared to more focused servers.
Completeness4/5The tool set covers the full lifecycle of proxy management, traffic capture/inspection/replay, browser automation, and advanced testing features like fuzzing and scripting. Minor gaps exist (e.g., no direct flow deletion, no tab management beyond listing), but agents can complete workflows using the available tools.
Average 4.5/5 across 39 of 39 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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.
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
- 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 explains the core behavior and the prerequisite, but does not disclose side effects, error conditions (e.g., no history), or what happens if the session is invalid. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose and prerequisite. The Args section is somewhat redundant with the schema and misses a parameter, so it's not perfectly structured, but overall it is concise and to the point.
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?
With an output schema present, return values are likely covered. The description includes the key prerequisite and the main behavior, but the missing tab_id parameter and lack of edge-case information leave it incomplete for a tool with two optional parameters.
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?
The schema has two parameters (tab_id, session_name) with no descriptions. The description only explains session_name in the Args section and completely omits tab_id, leading to incomplete parameter guidance. Given 0% schema coverage, this is a significant 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 states a specific action ('Navigate back in browser history') with a helpful analogy ('like clicking the Back button'). It clearly distinguishes this from sibling tools like browser_go by focusing on backward navigation.
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 includes an explicit prerequisite ('browser_open and browser_go must have been called first'), which provides clear context for when this tool should be used. However, it does not mention alternatives or exclusions, so it's slightly shy of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It mentions a prerequisite and the nature of the data source, which is useful. However, it does not explicitly state whether the operation is read-only, has side effects, requires permissions, or what error conditions exist. For a read tool, this is 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded summary, a clear prerequisite, a brief rationale, and an argument list. The rationale about web apps storing tokens is useful but adds length. Overall, every sentence has purpose, and the structure is easy to scan.
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 covers purpose, prerequisite, and two of three parameters. It lacks any mention of tab_id and does not explicitly describe the return structure (though an output schema exists). Given no annotations, the description carries more weight, and these gaps prevent it from being fully complete.
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?
The description explains storage_type (local, session, both) and session_name (browser session) with defaults, which adds value since the schema itself has no descriptions. However, tab_id is entirely omitted, leaving a gap. The partial coverage compensates for the 0% schema coverage but is not complete.
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 uses a specific verb and resource: 'Dump browser localStorage and/or sessionStorage contents.' It also distinguishes this tool from siblings by emphasizing it returns data the proxy cannot see, making it clear this is for client-side storage rather than network traffic. Examples like JWT tokens and API keys further clarify its purpose.
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 clear context for when to use this tool: when you need data stored client-side that never appears in HTTP traffic. It also gives a prerequisite (browser_open and browser_go must be called first). However, it does not explicitly name alternative tools or exclude specific scenarios, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (base64 PNG), prerequisites, and optional selector behavior. However, it omits the tab_id parameter and does not mention potential failure conditions or whether the screenshot is viewport or full-page, leaving behavioral disclosure incomplete.
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 well-organized with a clear summary, a prerequisite line, bulleted use cases, and an args section. It is compact and efficient, though slightly longer than the minimal two-sentence standard, which is justified by the added context.
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 covers core usage and output, but misses `tab_id` semantics and does not clarify viewport vs. full-page capture beyond the selector note. Given the output schema exists and no annotations are present, the description leaves some gaps but is mostly adequate.
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?
With 0% schema description coverage, the description adds meaning for `selector` (CSS selector, optional, full-page if omitted) and `session_name` (default value). However, it entirely omits `tab_id`, leaving one of three parameters undocumented, so compensation for the coverage gap is partial.
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 takes a screenshot of the current page and returns a base64-encoded PNG. The verb 'Take' plus resource 'screenshot' is specific, and it distinguishes from siblings like browser_get_dom or browser_get_text by focusing on visual capture.
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 concrete use cases (verifying page state, checking for bot detection, documenting evidence) and states the prerequisite that browser_open and browser_go must have been called first. This gives clear when-to-use context, though it does not explicitly name alternative tools for non-visual needs.
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 of disclosing behavioral traits. It only says 'Remove' without stating whether removal is permanent, irreversible, or has side effects on active proxy sessions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the action, then a prerequisite, then the parameter explanation. Every sentence earns its place, with no fluff.
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 one-parameter delete tool, the description covers the essential usage: what it does, how to get the ID, and the format. However, it omits mutation implications (permanence, side effects) and error behavior. An output schema exists, so return values are covered, but the behavioral gap remains.
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 compensates by explaining the parameter's purpose, providing an example format ('r-abc12345'), and telling the user where to obtain it. This is meaningful added value beyond the raw 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 action ('Remove') and the resource ('proxy interception rule') with an explicit reference to identifying it by ID. It is distinct from sibling tools like add/list, providing a specific verb+resource construction.
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?
It provides an explicit prerequisite, telling the user to get rule_id from list_interception_rules or the add_interception_rule response. This clearly indicates the expected usage context, though it doesn't mention alternative tools or when not to use it.
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 must carry the burden of behavior disclosure. It explains the clear behavior (default true) and press_enter option, but does not mention error handling, waiting for element visibility, or how tab_id is used. This is a moderate disclosure level, leaving some behavioral traits undocumented.
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 well-structured with clear sections: intro, prerequisite, typical flow, and args. It is longer than ideal but each part serves a purpose, and the flow example is particularly useful. No wasted words.
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?
For a 6-parameter tool with no annotations, the description provides a solid overview, usage examples, and parameter details. It lacks explanation of tab_id and does not describe return values or error cases, but the output schema likely covers return information. Overall, quite complete for the tool's complexity.
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 description's Args section adds meaningful explanations for selector, text, clear, press_enter, and session_name, including examples and defaults. However, it omits tab_id, a parameter in the schema, leaving that parameter without semantic explanation. Since the schema itself has no descriptions (coverage 0%), the description covers most parameters well but not all.
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 ('Type text into an input field') and provides concrete examples (login forms, search boxes, payload injection). This distinguishes it from sibling browser tools like browser_click and browser_go.
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 includes a prerequisite (browser_open and browser_go must be called first), a typical login flow with numbered steps, and a use case for XSS testing. It also explains when to use press_enter for search forms. It lacks explicit exclusions relative to alternatives, but the context is clear and actionable.
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 discloses that it disables all interception and clears all rules, and notes the return to normal browsing. However, it does not explain potential side effects (e.g., impact on captured traffic history) or whether the action is reversible, leaving some behavioral ambiguity.
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 stating the action and when to call it, followed by a compact Args section. Every sentence earns its place, and the most important information is 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?
For a simple disable operation with a single optional parameter and an output schema, the description covers purpose, usage, and parameter semantics adequately. It explicitly states the scope ('for this browser session'), so the main context is present. Minor gap: it does not specify whether disabling all rules affects other sessions or if there are any prerequisites, but these are not critical for this tool.
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 schema for session_name has only a type and default, with 0% description coverage. The description's Args section adds the meaning 'Browser session to use' and notes the default, which is sufficient for this single, simple parameter. It could be more detailed (e.g., valid session names), but it compensates well for the schema's lack of description.
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 first sentence clearly states the action and scope: 'Disable ALL CDP Fetch interception and remove all rules for this browser session.' This distinguishes it from sibling tools like remove_interception_rule, which targets a single rule, by explicitly indicating that all rules are affected.
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 explicitly says 'Call this when you want to stop intercepting and return to normal browsing,' providing clear context for when to use the tool. It also clarifies that it clears both request and response intercept rules. However, it does not mention alternatives like remove_interception_rule for targeted removal, so it misses an explicit exclusion.
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 the full disclosure burden. It clearly explains that execution happens in the page's JS context with full access to DOM, variables, functions, and APIs, and that it returns the expression's result. It does not mention potential side effects of arbitrary JS (e.g., page navigation, state mutation) or error behavior, but the inherent nature of arbitrary execution plus the provided context gives reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (PREREQUISITE, USE CASES, Args). Every part adds value: the use cases illustrate practical applications, the prerequisite prevents misuse, and the arg descriptions clarify input semantics. It is concise yet sufficiently detailed without verbose filler.
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 prerequisites, use cases, execution context, and return behavior, making it fairly complete for a complex tool. The presence of an output schema reduces the need for return-format details. However, it does not clarify whether promise-returning expressions are awaited (the fetch example returns a promise), and the missing 'tab_id' semantics leave a minor gap.
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%, so the description must compensate. It explains 'expression' well with examples and multi-line support, and defines 'session_name' with default. However, it completely omits 'tab_id', one of the three parameters, leaving its semantics and usage unclear. This partial compensation earns a middle score.
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 opens with a specific verb and resource: 'Execute arbitrary JavaScript in the browser page context.' It clearly distinguishes this tool from siblings like browser_get_dom or browser_get_text, which only read specific parts of the page. The 'Returns the expression's result' clause further defines the tool's purpose.
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 explicitly states a prerequisite: browser_open and browser_go must have been called first. It also provides concrete use cases, which help the agent know when to invoke this tool. However, it does not explicitly mention when NOT to use it or point to alternatives such as browser_get_dom for simple DOM reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It communicates a read-only action ('List all open tabs...') and states what is returned (tab IDs and URLs), plus a prerequisite. However, it does not explicitly rule out side effects or describe error behavior (e.g., missing session), which keeps it at an adequate but not rich level.
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 front-loaded: the first sentence states the purpose, followed by a prerequisite and a brief usage note. The Args section is minimal and necessary given the schema lacks parameter descriptions. Every sentence earns its place.
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?
For a simple one-parameter list tool with an output schema present, the description is nearly complete. It covers the prerequisite, parameter semantics, and how to use the result. It could mention behavior when no session exists, but that is a minor gap given the tool's simplicity.
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 schema's session_name property has only a title and default, with no description (0% schema description coverage). The description compensates with an Args section explaining 'Browser session to query' and noting the default. This fully covers the single optional parameter and adds 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 opens with a specific verb and resource: 'List all open tabs in a browser session with their tab IDs and URLs.' This clearly distinguishes the tool from siblings like browser_list_sessions (sessions vs. tabs) and browser_open (opening vs. listing).
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 explicitly states a prerequisite: 'browser_open must have been called first.' It also explains how to use the returned tab_id with other browser_* tools, giving clear operational context. It does not explicitly mention when not to use this tool or compare it to browser_list_sessions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It clarifies that the tool generates a command rather than executes it, and the use cases imply side-effect-free operation. However, it doesn't explicitly state whether the command includes headers/cookies or if any request is actually sent, leaving some behavioral ambiguity.
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 well-structured with a clear one-sentence purpose, a prerequisite callout, bullet-style use cases, and a concise parameter note. Every line contributes useful information and no filler or repetition is present.
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?
For a single-parameter tool with an output schema, the description is adequately complete. It covers the input source and typical usage scenarios. It doesn't detail the output format, but the presence of an output schema reduces that burden, so remaining gaps are minor.
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 fully compensates. It explains that flow_id identifies the captured HTTP flow, and crucially tells the user how to obtain a valid flow_id (via get_traffic_summary or search_traffic). This adds meaningful context beyond the bare 'Flow Id' string in 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 states a specific verb, resource, and deliverable: 'Generate a copy-paste curl command that reproduces a captured HTTP flow.' It clearly distinguishes the tool from siblings like replay_flow or send_raw_request by emphasizing the generated artifact (a curl command) rather than execution.
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 gives explicit usage context, listing concrete use cases (sharing, terminal testing, Burp/Postman import) and a prerequisite (obtain flow_id via get_traffic_summary or search_traffic). However, it doesn't explicitly mention when not to use this tool or contrast it with alternative siblings.
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 available, the description carries the burden for behavioral disclosure. It reveals that clicking returns any JavaScript alert/confirm/prompt dialog messages, which is important for XSS detection, and states the prerequisite. It also cautions against providing both selector and text. However, it does not disclose behavior for missing elements, multiple matches, or page navigation after click, so it is not fully transparent.
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 well-structured with clear sections (prerequisites, parameter selection, XSS detection, Args) and front-loads the core action and return value. It is slightly repetitive because the Args section re-lists selector, text, and session_name with similar examples as the bullets above, but overall it is efficient and focused.
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 complexity, the description covers essential context: prerequisites, selector/text XOR logic, dialog return for XSS detection, and session parameter. The presence of an output schema reduces the need to explain return values. Missing pieces include tab_id, error handling for not-found elements, and behavior after a click that triggers navigation. These gaps prevent a perfect score, but the description is otherwise comprehensive.
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 description coverage is 0%, so the description must compensate. It explains selector (CSS selector with examples), text (visible text with best-match hint), and session_name (browser session, default). A notable gap is the complete omission of tab_id, one of the four schema parameters. The description also doesn't specify what happens if both selector and text are omitted. Despite this, it adds substantial semantics beyond the schema's bare properties.
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 opens with a specific verb and target: 'Click an element on the page.' It also mentions the resource (page) and differentiates from sibling tools like browser_type (typing) and browser_go (navigation) by focusing on click behavior and return of dialog messages. The XSS detection use case further clarifies a distinct purpose.
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 clear usage context: it states the prerequisite (browser_open and browser_go), explains the selector vs. text choice ('Provide EITHER selector OR text (not both)'), and gives a specific use case for XSS verification. However, it does not explicitly mention alternatives or when not to use this tool, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the actions (replace_body and block), the real-time CDP mechanism, and provides an example. However, it does not disclose that the interception rule persists until disabled or removed, nor does it mention how it interacts with browser_intercept_disable or remove_interception_rule. This lifecycle information is important for safe use.
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 well-structured with labeled sections (PREREQUISITE, USE CASES, Available actions, Args). It is longer than average but every section adds value, and the example clarifies usage without being redundant. It is somewhat verbose but not wasteful.
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?
For a tool with 5 parameters, no schema descriptions, and no annotations, this description is remarkably complete. It covers prerequisites, use cases, action semantics, parameter details, and an example. The existence of an output schema means return values don't need explanation. The only minor gap is the interception lifecycle, but overall it is fully contextualized.
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?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: url_pattern (regex), action (replace_body or block), search_pattern (required for replace_body), value (replacement text), and session_name (default 'default'). It even provides a concrete example demonstrating parameter 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 opens with 'Intercept and modify INCOMING browser responses in real-time via Chrome CDP Fetch API', which clearly states the specific verb, resource, and mechanism. It also distinguishes itself from the sibling tool browser_intercept_request by focusing on incoming responses, making the purpose unambiguous.
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?
It explicitly states the prerequisite (browser_open must be called first) and lists concrete use cases (CSP bypass, response tampering, XSS injection, removing security headers). It does not explicitly mention alternatives or when not to use, but the detailed use cases and the distinction from request interception provide clear guidance.
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 discloses important behavioral traits: the data is not visible to the proxy, console messages can include stack traces/internal URLs, and the 'clear' parameter controls buffer clearing. It also notes the prerequisite. It doesn't discuss output format or side effects beyond clear, but provides strong contextual detail.
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?
Well-structured with a bold lead sentence, a value proposition, prerequisite callout, examples of console message types, and an Args section. Each section adds information without redundancy, making it appropriately sized 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?
Covers purpose, prerequisites, parameter semantics (except tab_id), and use-case context. The presence of an output schema presumably covers return format. Missing tab_id documentation is the main gap, but overall this is a comprehensive description.
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 description explains 'level' with allowed values, 'clear' with its side effect, and 'session_name' default. However, it completely omits 'tab_id', which appears in the schema. Since schema description coverage is 0%, the description must compensate, and it does for 3 of 4 parameters with one notable 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 'Read JavaScript console output from the browser' with a specific verb and resource. It also differentiates from proxy/network tools by noting 'Returns data the PROXY CANNOT SEE,' which distinguishes it from sibling traffic-related 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?
Provides explicit preconditions (browser_open and browser_go must be called first) and frames the tool's unique value proposition (data the proxy cannot see). It implies when to use it but does not explicitly name alternative tools or 'when not to use' scenarios, so it lacks a dedicated exclusion clause.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It discloses the prerequisite, the read-only nature ('get visible text content'), and implies that only visible text is returned. However, it does not discuss edge cases like element-not-found or whether it waits for the page to load, which would be useful but is not critical for a simple getter.
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: a clear opening sentence, a prerequisite block, usage/sibling guidance, and a brief args list. Every sentence contributes value, with no fluff or redundant text.
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 tool is relatively simple, and the presence of an output schema reduces the need to explain return values. The description covers prerequisites, usage context, and an alternative tool. The main gap is the undocumented 'tab_id' parameter, which prevents full completeness. Overall, it is mostly complete but with this notable omission.
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?
The description adds meaning to 'selector' by giving examples and to 'session_name' by indicating a default, but it completely omits 'tab_id', which appears in the input schema. With schema description coverage at 0%, the description fails to fully compensate by documenting all parameters. This creates a potential gap for the AI agent in understanding the 'tab_id' parameter.
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 ('Get the visible text content of a specific DOM element') and identifies the resource ('a specific DOM element'). It also distinguishes from the sibling tool 'browser_get_dom' by noting that the latter is for 'full DOM analysis', making the purpose specific and unambiguous.
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?
The description provides explicit usage context: 'Use this to read specific parts of a page' and an explicit when-not-to-use with a named alternative: 'For full DOM analysis, use browser_get_dom instead.' It also states a clear prerequisite ('browser_open and browser_go must have been called first'), giving thorough guidance on when to invoke the 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 carries the full burden of behavioral disclosure. It discloses the key behavior: waits for an element/text, uses a timeout with a default of 10 seconds, and 'Returns error if element doesn't appear.' It also discloses the constraint 'Provide EITHER selector OR text (not both).' It does not mention what happens on success (return value), but an output schema exists, so that is not 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?
The description is well-structured with a purpose statement, prerequisite, usage context, and a clearly formatted argument list. Every sentence adds value, and the examples for selector and text are helpful. It is appropriately sized for a tool with five parameters and is easy to scan.
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 the essential context: when to use it, prerequisites, and parameter semantics. The missing `tab_id` parameter and the lack of clarification on what 'appear' means (e.g., visible vs. present in DOM) are minor gaps. Since an output schema exists, return-value details are not required, and the description is sufficient for an agent to use the tool effectively in most dynamic-content scenarios.
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 is the only source of parameter meaning. It explains four of five parameters: selector, text, timeout, and session_name, with examples and constraints. However, it omits the `tab_id` parameter that is present in the schema. This is a notable gap, but the explanation given for the other parameters is detailed and actionable.
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 function: 'Wait for a DOM element or text to appear on the page.' It uses a specific verb ('wait') and resource ('DOM element or text'), and distinguishes it from sibling tools by positioning it as a synchronization step after navigation/clicking (e.g., 'Use this AFTER browser_go or browser_click').
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 clear when-to-use guidance: 'Use for SPAs, AJAX, and dynamic content' and 'when the page loads content asynchronously.' It also states a prerequisite (browser_open and browser_go must have been called first). However, it does not explicitly mention alternatives or when NOT to use it, so it lacks the full when/when-not/alternatives structure for a 5.
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 disclosing behavior. It states that static assets and OPTIONS requests are always ignored regardless of scope, and that subdomains must be listed explicitly. These details go beyond the schema and provide useful context for the agent.
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 well-structured: a one-sentence purpose, usage context, behavioral note, and examples. It is not excessively verbose, though the reset behavior is mentioned twice (once in examples and once in Args). Minor redundancy prevents a perfect score.
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?
For a simple tool with one parameter and an output schema, the description covers essentials: when to call, what it does, parameter semantics, and behavioral quirks. It doesn't mention error behavior or what happens if called before proxy start, but the explicit 'Call AFTER' hint partially covers that. Overall, it's complete enough for typical use.
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?
Schema coverage is 0%, so the description must fully explain parameters. It does so comprehensively: 'List of domains to record. Subdomains must be listed explicitly. Empty list = record all traffic.' Examples clarify the expected format and the reset behavior, leaving no ambiguity about the single parameter.
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 function: 'Limit which domains the proxy records.' This specific verb+resource phrasing distinguishes it from sibling tools like manage_proxy or proxy_status. It also provides concrete examples showing the intended effect, making the purpose unambiguous.
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 explicitly instructs to call AFTER manage_proxy(action="start"), providing a key usage prerequisite. It explains when to use the tool ('focus on specific target domains and reduce noise') and how to reset to default behavior. However, it doesn't explicitly mention when NOT to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. It discloses the main side effect ('terminate the Chrome process') and the resource-freeing intent. It also explains the default session behavior. However, it does not address edge cases like closing a non-existent session or implications for other sessions, which would be useful for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear first sentence, a usage hint, and an Args section. Every sentence contributes value without redundancy. It is appropriately sized for a simple tool.
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?
For a simple tool with one optional parameter and an output schema present, the description covers the necessary context: what it does, when to use it, and parameter defaults. It lacks minor edge-case behaviors (e.g., error handling for non-existent sessions), but these are not critical for the primary use case. Overall, it is adequately complete.
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 description adds meaning to the sole parameter via the 'Args' section: 'Session to close (default: "default")'. This clarifies the purpose and default value, exceeding the schema which only provides a title and default. Since schema coverage is 0%, this description is essential and fulfills the parameter semantics completely.
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 function: 'Close a browser session and terminate the Chrome process.' It uses a specific verb ('Close') and resource ('browser session'), and includes the additional detail of terminating the Chrome process, which distinguishes it from session-management siblings like browser_list_sessions or browser_open.
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 an explicit usage trigger: 'Call this when you're done with a browser session to free resources.' It does not mention alternatives or exclusions, but for a simple close operation this is adequate. The default session behavior is also clarified, which serves as a practical guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists exactly what is extracted (forms, links, scripts, iframes, comments, event handlers, data-* attributes, simplified DOM tree), explains the effect of max_depth on token usage, and states the prerequisite. This gives a thorough understanding of the tool's behavior without needing to invoke it.
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 well-organized with clear sections: purpose, prerequisite, extracted items, usage, and args. It is somewhat long but every section adds value, especially the detailed list of extracted data elements. It could be more concise, but the structure enhances readability.
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 prerequisites, the exact data extracted, parameter defaults, and a use case. An output schema is present, so return values need not be described. It lacks error-handling details or edge cases (e.g., what happens if selector not found), but for a DOM extraction tool with moderate complexity, it is adequately 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?
Schema description coverage is 0%, so the description must compensate. It explains selector (root element CSS selector), max_depth (depth of traversal and token trade-off), and session_name (browser session), but omits tab_id entirely. This is a slight gap, but the provided parameter details go beyond the schema's basic type/default information.
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 extracts security-relevant DOM structure with a specific verb ('Extract') and resource ('DOM structure from the current page'). It distinguishes from sibling tools like browser_get_text or browser_js by focusing on security-relevant elements such as forms, CSRF tokens, scripts, and comments.
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 explicitly states when to use it ('initial recon after navigating to a page') and provides a prerequisite ('browser_open and browser_go must have been called first'). It also contrasts with the proxy by noting it returns data the proxy cannot see, but it does not name alternative tools 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses return values (page title, JS dialog messages) and the prerequisite, but does not cover failure modes (e.g., timeouts, invalid URLs) or side effects (e.g., browser history). It adds some useful context but is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a one-sentence purpose, a clear prerequisite callout, an SPA tip, and a concise Args list. Every sentence earns its place without verbosity.
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 all parameters, prerequisites, and a common use case (SPAs). An output schema exists, so the description need not detail return values further. It is complete for the tool's complexity, though it could mention error handling or edge 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?
Schema coverage is 0%, so the description fully compensates with an Args section that explains every parameter, including examples, defaults, and optionality. For instance, it specifies that wait_for is for SPAs and that tab_id uses the active tab if omitted, adding significant meaning beyond the bare 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's verb+resource: 'Navigate to a URL and wait for the page to load.' It distinguishes from siblings like browser_back (navigate back) and browser_open (open a session) by specifying the navigation action and return values.
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?
The description explicitly states a prerequisite ('PREREQUISITE: browser_open must have been called first') and provides guidance for when to use the wait_for parameter (SPAs that load content dynamically). This gives clear context on when and how to use the 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 carries the full burden. It discloses that 'Dead sessions are automatically cleaned up,' which is a useful behavioral trait beyond the obvious 'list' action. It also specifies the returned fields (status, PID, ports, uptime), giving transparency into the output. It doesn't explicitly state that the operation is read-only, but that is reasonably implied by the verb and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and immediately followed by a usage hint and a behavioral note. Every word earns its place; there is no fluff or repetition. This is model of conciseness.
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?
For a simple list operation with no parameters, the description covers purpose, usage timing, return fields, and a non-obvious behavior (auto-cleanup of dead sessions). An output schema exists to detail the return structure further, so the description is complete enough for an agent to select and invoke the tool correctly.
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 tool has zero parameters, so the input schema is trivially covered (100% by default). The description mentions the output fields even though an output schema exists, adding semantic value about what the returned data looks like. This aligns with the baseline of 4 for zero-parameter tools.
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 begins with 'List all active browser sessions' – a specific verb and resource – and elaborates with status, PID, ports, and uptime. This clearly distinguishes it from sibling tools like browser_list_tabs (which lists tabs within a session) and browser_close (which affects sessions). The purpose is unambiguous.
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?
It explicitly advises 'Use this to check which sessions are running before sending commands,' providing clear context for when to invoke this tool. It doesn't mention exclusions or alternatives by name, but the usage hint makes the appropriate scenario evident. Sibling differentiation is implicit rather than explicit.
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. It discloses that the tool is a scan (non-mutating), explains the default behavior of scanning the 100 most recent flows if flow_ids is omitted, and states it returns detected auth types and associated flow IDs. This is solid behavioral transparency, though it does not explicitly say 'does not modify traffic' or address potential failure modes.
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 well-structured: a one-sentence summary, a prereq callout, a bulleted list of detectable types, return info, usage guidance, and parameter details. Although slightly long, every sentence adds distinct value, and the organization aids quick comprehension.
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?
This is a simple tool with one optional parameter and an output schema present (though not shown in the prompt). The description covers all essential context: what it does, when to use it, prerequisites, default behavior, and return type. No significant gaps remain.
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 merely defines flow_ids as an optional string with no description. The description compensates fully by specifying comma-separated format, giving an example, and explaining that omission triggers automatic scanning of the 100 most recent flows. This adds crucial meaning beyond the raw 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 opens with a clear statement: 'Automatically scan captured traffic to detect authentication mechanisms.' It then lists specific auth types detected (JWT, Bearer tokens, API keys, etc.), making the tool's function unambiguous. This clearly distinguishes it from sibling tools like search_traffic or extract_from_flow, which have different objectives.
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 explicitly advises using this tool 'early in a pentest' and highlights a prerequisite (proxy running with captured traffic). It provides enough context for an agent to know when to deploy it. It does not mention alternatives or exclusions, but the 'early in a pentest' guidance and the tool's specific scope implicitly separate it from other traffic analysis tools.
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 the full burden. It discloses the prerequisite (proxy running, traffic exists), pagination behavior, and even a token-saving tip (smaller limit). It doesn't cover edge cases like empty traffic or rate limits, but for a read-only listing tool, these are 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, requirements, return fields, workflow, and parameter details. It's slightly longer than minimal due to the workflow line, but every sentence adds value and the main purpose is 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?
The description is highly complete for a list tool. It covers prerequisites, pagination, return fields, and integration with other tools. An output schema exists, so detailed return structure is not required, but the description still lists key fields. The workflow provides excellent context.
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?
Schema coverage is 0%, so the description fully compensates. It explains both limit and offset with defaults, and provides concrete pagination guidance (offset=20 gets the next page). This is more than enough for an agent to invoke correctly.
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 'Get a paginated list of all captured HTTP flows' with a specific verb and resource. It distinguishes from sibling tools like inspect_flow (which inspects a single flow) by emphasizing 'all captured flows' and pagination. The workflow snippet further clarifies its role.
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 gives clear usage context: requires a running proxy and existing traffic, and explains how to use returned flow_id values with downstream tools. It doesn't explicitly name alternatives like search_traffic or state when not to use this tool, but the context is sufficient for appropriate selection.
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?
There are no annotations, so the description carries the full transparency burden. It discloses that only metadata is returned by default to save tokens, that adding fields to the include list unlocks headers/bodies, and enumerates all available options. This goes beyond the schema and gives the agent a clear model of what to expect, though it doesn't mention potential size limits or error conditions.
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 well-structured and front-loaded: a one-line purpose, a prerequisite note, a behavioral note, and a clear Args list with bullet options and an example. Minor redundancy exists because the source of flow_id is mentioned both in the PREREQUISITE and again in the flow_id argument description.
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?
The tool has only two parameters, a clear singular purpose, and an output schema. The description provides all essential context: what it returns, how to control the response, where to get the required ID, and an example. There are no major gaps for an agent to select and invoke this tool correctly.
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 provides zero descriptions for the two parameters, so the description must fully compensate. It thoroughly explains flow_id as coming from get_traffic_summary or search_traffic, and details each valid value for include with an example. It also clarifies that metadata is the default, which overrides the schema's 'default: null' ambiguity.
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 opens with 'Get full details of a single HTTP flow (request headers, body, response headers, body).' This is a specific, action-oriented statement with a clear resource (HTTP flow) and scope. It also distinguishes itself from siblings like get_traffic_summary and search_traffic, which retrieve lists of flows, by focusing on a single flow's full details.
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 usage context via the PREREQUISITE statement: 'Get flow_id from get_traffic_summary or search_traffic first.' It also explains the default behavior and how to expand with the include parameter. However, it does not explicitly mention when not to use this tool or describe alternative tools for similar purposes (e.g., extract_from_flow).
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 are provided, so the description carries the full burden. It adds meaningful behavioral traits: variables persist until the proxy is restarted and are created by extract_session_variable. While it doesn't explicitly state that the tool is read-only, that is inherent in a list operation, so this is acceptable.
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 three short sentences, with the primary action front-loaded in the first sentence. It includes only essential information—what is listed, why it matters, and its lifecycle—with no wasted words.
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?
For a zero-parameter list tool, the description covers all essential aspects: what is listed, their purpose, how they are created, and their persistence. The output schema exists and presumably documents the return values, so no further detail is needed.
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 tool has 0 parameters and the input schema is empty. The baseline for 0 params is 4, and the description does not need to explain parameters. It makes no redundant parameter claims.
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 uses the specific verb 'list' with the resource 'saved session variables', and explains their role as {{name}} placeholders in replay_flow. This clearly distinguishes it from sibling tools like extract_session_variable, which creates them, and replay_flow, which consumes them.
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 useful context by stating that variables are created by extract_session_variable and used in replay_flow, implying when listing them is relevant. It does not explicitly say 'use this when' or name alternatives, but there is no competing list tool among siblings, so 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: httpOnly support, domain matching constraints, and default values for path and flags. However, it omits mention of the tab_id parameter and any side effects like overwriting existing cookies, which keeps it from a perfect score.
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 moderately long but well-structured with clear sections (purpose, prerequisite, use cases, args). Each sentence adds value, and the front-loaded purpose allows quick understanding. Slight verbosity in the use-case list is acceptable given its practical utility for security testing.
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?
For a tool with 8 parameters and no annotations, the description is remarkably complete. It provides prerequisites, use cases, parameter constraints, and defaults. The output schema exists, so return-value details are not required. The only minor gap is tab_id, but overall the description equips an agent to select and invoke the tool correctly in most scenarios.
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?
Despite 0% schema description coverage, the description explains every parameter except tab_id. It adds meaningful context: name examples, domain must match parent domain, path default, secure and http_only flag effects, and session_name default. The omission of tab_id is a minor gap given it appears in the schema but is undocumented in the description.
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 'Set a cookie in the browser via CDP' with a specific verb and resource. It distinguishes itself from document.cookie in JS by highlighting the ability to set httpOnly cookies, which sets it apart from sibling browser manipulation tools.
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 lists the prerequisite (browser_open and browser_go) and provides concrete use cases (IDOR testing, session fixation, httpOnly bypass). It also implicitly contrasts with JavaScript document.cookie, giving an alternative approach for the same task. This goes beyond mere context to actionable guidance.
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 the burden of behavioral disclosure. It explains that saved variables are automatically substituted in replay_flow, the regex must have exactly one capture group, and source options are enumerated. It does not mention variable overwrite behavior but covers essential 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for description, prerequisite, substitution behavior, workflow, and args. It is detailed but every sentence adds value, and the numbered workflow makes it easy to follow.
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?
For a 4-parameter tool with no annotations, the description covers purpose, prerequisites, parameter semantics, integration with replay_flow, and a complete workflow. An output schema exists, so return value details are not necessary. Missing error scenarios are the only minor gap but do not detract from completeness.
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?
Schema description coverage is 0%, so the description compensates fully. Each parameter is explained: flow_id, regex (with capture group rule and example), name (as {{name}}), and source (with four valid values and a default). This adds significant meaning beyond the raw 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 'Extract a value from a captured flow and save it as a named session variable' with a specific verb and resource. It distinguishes from siblings by explaining the auto-substitution in replay_flow, which is a unique capability.
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?
Provides a clear prerequisite (flow_id from get_traffic_summary or search_traffic) and a typical auth workflow that illustrates exactly when to use this tool in sequence with search_traffic and replay_flow. It does not explicitly name alternatives but gives strong usage context.
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 are provided, so the description carries the transparency burden. It discloses that the rules are browser-level only and points to the sibling tool for proxy-level, adding behavioral context beyond a simple 'list' statement. It does not mention error handling or side effects, but for a read-only list operation this is acceptable.
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. It opens with the main purpose, follows with an important note about scope and alternatives, and ends with a clear Args list. Every sentence earns its place with no fluff.
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's low complexity (one optional parameter), a clear output schema, and the description covering scope and alternatives, the description is complete. It provides enough context for an agent to select and invoke the tool correctly without needing additional return value documentation.
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 schema has no property descriptions (coverage 0%), but the description includes an Args section explaining session_name as 'Browser session to use (default: "default")'. This adds meaning beyond the raw schema field name and default value, effectively compensating 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 tool lists active CDP Fetch interception rules for a browser session with a specific verb and resource. It explicitly distinguishes from the sibling tool list_interception_rules, making its purpose unambiguous.
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?
Provides explicit guidance on when to use this tool: it notes that these are browser-level rules only (set via browser_intercept_request/response) and directs users to use list_interception_rules for proxy-level rules. This is a clear alternative and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 disclosing effects. It clearly states that the action 'permanently deletes all recorded flows' and adds the important caveat that 'Session variables are NOT cleared.' This gives the agent a complete picture of the destructive and non-destructive aspects.
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 a direct action statement followed by a clear usage scenario and a prominent warning. Every sentence earns its place, and there is no wasted text.
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?
For a parameterless, destructive tool, the description covers the purpose, the recommended usage time, and the key behavioral caveat about session variables. Since an output schema exists, return-value details are unnecessary, making this description complete for its complexity.
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 tool takes zero parameters and the schema is empty, so there are no parameters for the description to explain. The description correctly avoids adding irrelevant parameter details, earning the baseline score for parameterless tools.
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 uses the specific verb 'Delete' with a clear resource: 'all captured traffic from the database.' It distinguishes itself from sibling read tools like get_traffic_summary and search_traffic, making its scope unambiguous.
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 explicitly states when to use it: 'Use when you want a clean slate before a new test.' It also warns that session variables are not cleared, which implies a limitation, but it does not name an explicit alternative tool for clearing session variables.
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 are provided, so the description carries the full burden. It discloses the three extraction methods with examples and implies a read-only operation via 'extract'. However, it does not explicitly state what happens if multiple extractors are supplied or if no extractor is provided, leaving some behavioral ambiguity.
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 moderately long but organized with sections (purpose, prerequisite, extractor options, alternative, args). Every sentence adds value; the length is justified by covering three extraction methods, though it could be slightly tightened.
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's complexity, the description covers prerequisites, usage rules, parameter semantics, and alternatives. An output schema exists, so return values need not be described. The description is complete for selecting and invoking the tool correctly.
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?
Schema description coverage is 0%, but the description fully compensates by explaining flow_id, json_path, css_selector, and regex with concrete examples and constraints (e.g., 'use capture groups to extract specific parts'). It also clarifies that exactly one extractor must be chosen.
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 extracts specific data from a flow's response body using JSONPath, CSS selector, or regex. It specifies the resource ('a flow's response body') and verb ('Extract'), and distinguishes from sibling tools like extract_session_variable and inspect_flow.
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 provides a prerequisite (get flow_id from get_traffic_summary or search_traffic), instructs to choose exactly one extractor per call, and directs users to extract_session_variable when the value is needed for replay_flow. This clearly states when and how to use the tool versus 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?
With no annotations, the description carries the full burden. It discloses that only 'active' rules are returned and that these are proxy-level rules specifically added via add_interception_rule. It does not mention side effects, but 'list' implies read-only, and the scope clarification adds value 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the primary action front-loaded and a brief, relevant note about the sibling tool. Every word earns its place; no wasted text.
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?
For a zero-parameter list tool, the description fully explains what is listed and explicitly differentiates from the related browser-level tool. The output schema exists, so return-value details are not required in the description.
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 zero parameters, so the baseline is 4. The description adds no parameter-specific details because none are needed; the empty input schema is fully covered.
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 uses a specific verb ('List') and resource ('all active proxy interception rules'), and clarifies the source via 'added via add_interception_rule'. It clearly distinguishes from the sibling browser_list_intercept_rules by explicitly naming the alternative.
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?
The description explicitly states when to use this tool (for proxy-level rules) and when not to, directing the user to browser_list_intercept_rules for browser-level CDP Fetch rules. This is a clear when/when-not guidance with a named alternative.
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 the behavioral disclosure burden. It clearly explains that 'stop' kills the process, that 'ui=true' launches mitmweb on port 8081 instead of headless mitmdump, and that upstream forwards traffic. However, it doesn't mention what happens if the process is already running or whether stopping is graceful.
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 well-structured with a purpose statement, WORKFLOW section, and Args list. Every sentence adds value, and the length is justified by the need to explain four parameters and integration options.
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 workflow, parameters, and integration with Burp/mitmweb. An output schema exists, so return values need not be described. It is slightly incomplete regarding behavior when called repeatedly or error conditions, but for the scope of the tool it is highly complete.
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?
Although schema coverage is 0%, the description's 'Args' section fully explains each parameter: action values ('start'/'stop', no others), port default and requirement, ui behavior, and upstream usage. This adds far more meaning than the raw 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 opens with a specific verb+resource: 'Start or stop the mitmproxy background process.' It clearly identifies the tool's role as the proxy lifecycle manager, distinguishing it from sibling tools like proxy_status and get_traffic_summary.
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?
It explicitly states 'This is the FIRST tool you should call before any proxy/traffic operation' and provides a numbered workflow. It also covers when to use options like upstream for Burp and ui for web GUI, giving clear usage context.
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 are provided, so the description carries the full burden. It clearly implies a read-only status check and lists return fields. However, it doesn't explicitly state that it has no side effects, though this is clear from the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the purpose, and the second provides actionable guidance. Perfectly front-loaded and concise.
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?
For a zero-parameter status check, the description covers what it does, when to call it, and what follow-up action to take. An output schema exists, so no return format explanation is needed.
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 tool has 0 parameters, so the baseline is 4. The description appropriately focuses on output and usage rather than parameter details, since none exist.
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 uses a specific verb ('Check') and resource ('mitmproxy process'), and clearly states it returns status, port, and PID. This differentiates it from manage_proxy, which starts/stops the proxy.
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?
Provides explicit when-to-use guidance: 'Call this BEFORE any proxy operation if you're unsure whether the proxy is already running.' It also names the alternative tool (manage_proxy) with a concrete action to take when the proxy is not running.
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 the full burden and discloses key behavioral traits: immediate effect, browser-only scope, and what 'block' does (returns network error). It could add details on side effects like rule persistence or interaction with intercept_disable, but the provided behavior is clear and sufficient.
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 well-structured with sections for purpose, prerequisite, comparison, actions, and args. It is front-loaded and every sentence adds value, including the comparative note and examples, without redundancy.
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's moderate complexity, the description covers all essential aspects: purpose, prerequisite, differentiation from sibling, actions, args, and examples. An output schema exists, so no need to detail return values. The description is comprehensive enough for correct invocation.
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?
Schema has 0% description coverage, so the description fully compensates. All five parameters are explained, including regex pattern examples, action options, required conditions for key/value, and default for session_name. The inline examples make usage concrete.
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 intercepts and modifies outgoing browser requests in real-time via Chrome CDP Fetch API. It also distinguishes itself from the sibling add_interception_rule, making its unique purpose unambiguous.
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 provides a prerequisite (browser_open must be called), and contrasts with add_interception_rule by explaining when to use each (instant browser-only vs. proxy-level with ~5s delay). It also gives usage examples for each action, effectively guiding when and how to invoke.
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 are provided, so the description carries the full burden. It does disclose key behaviors: session variable substitution ({{varname}} replacement), regex replacements, and the follow_redirects behavior with a default and purpose. However, it does not explicitly mention that this sends live traffic which could have unintended side effects, nor does it discuss authentication requirements or rate limits. Still, the description provides meaningful behavioral context beyond a simple 'resend' action.
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 well-organized with bold section headers (PREREQUISITE, Session variable substitution, Regex replacements, TYPICAL IDOR WORKFLOW, Args). Each section serves a purpose and builds logically. While it is long, the length is justified by the tool's complexity and the need to explain the substitution and replacement mechanisms. The most critical information (what it does) is front-loaded, and the argument list is at the end.
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?
Despite having three parameters and no annotations, the description covers everything needed: purpose, prerequisites, usage context, parameter semantics, and even a concrete workflow example. Since an output schema exists, return-value details are not required. The description is complete enough for an agent to correctly select and invoke this tool without further clarification.
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 zero description coverage, so the description entirely compensates. The 'Args' section provides clear explanations for all three parameters: flow_id (the captured flow to replay), replacements (a list of objects with regex and replacement), and follow_redirects (with default and purpose). It even gives an example of the replacements format, which is crucial for correct invocation. This is excellent parameter documentation.
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 function: 'Resend a captured HTTP request with optional modifications.' The verb 'resend' is specific and the resource ('captured HTTP request') is well-defined. The analogy to Burp Repeater instantly conveys the tool's nature. It distinguishes itself from sibling tools like 'inspect_flow' (viewing only) and 'send_raw_request' (creating new requests) by focusing on replaying an already-captured flow.
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?
The description provides an explicit PREREQUISITE (get flow_id from get_traffic_summary or search_traffic), a typical IDOR workflow with exact steps, and mentions when to use the feature (token rotation via session variable substitution). This goes beyond general clarity by giving concrete before-and-after steps, effectively covering 'when to use' and referencing alternatives for acquiring the flow_id.
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 transparency burden. It discloses the prerequisite, AND logic across filters, default limit (50), and search scope (URL/request body/response body for query). While it doesn't detail edge cases like empty traces or no matches, the core behavior is well-specified for the user. The presence of an output schema further reduces the need to explain return structure.
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 longer than average but every section earns its place: a one-line summary, a prerequisite, usage differentiation, filter semantics, and concrete examples. It is front-loaded with the core purpose and structured with clear sections, making it scannable and efficient despite its length.
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?
The tool has 5 optional parameters, no annotations, and a rich schema. The description covers all essential contextual info: prerequisites, filter behavior, combination logic, parameter semantics, and examples. It also distinguishes from a sibling tool. Since an output schema exists, the description need not explain return values. This is fully complete for a search 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?
Schema description coverage is 0%, but the description's Args section adds substantial meaning to each parameter: query (searches URL and bodies), domain (exact match), method (HTTP verbs), status_code (exact code), and limit (max results with default). Examples illustrate parameter usage, far exceeding the bare schema. This fully compensates for the schema's lack of 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 starts with a specific verb+resource pair: 'Search captured traffic' with the dimensions keyword, domain, HTTP method, or status code. It explicitly distinguishes itself from get_traffic_summary by stating 'Use this instead of get_traffic_summary when you need to find specific requests.' This meets the highest bar for purpose clarity.
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?
The description provides explicit when-to-use guidance, naming the alternative (get_traffic_summary) and stating the prerequisite that the proxy must be running and have captured traffic. It also clarifies that filters are optional and combine with AND logic, providing concrete examples. This fully addresses usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses that rules affect all traffic, are cached for ~5 seconds, and explains default resource_type behavior. Also details the semantics of each action (inject_header, replace_body, block) including required parameters.
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?
Despite its length, the description is exceptionally well-structured with clear sections (purpose, prerequisites, actions, args) and examples. Every sentence adds value; no redundancy or filler—a model of how to document a complex tool.
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?
Covers purpose, usage, parameters, examples, and alternatives comprehensively. With an output schema present, the description need not explain return values. Fully complete for a 7-parameter tool with multiple action variants.
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?
Schema description coverage is 0%, but the description compensates comprehensively by explaining all seven parameters, their required conditions, defaults, and examples. Goes far beyond what the schema provides.
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's function: adding a rule to modify HTTP traffic in real-time through mitmproxy. Distinguishes from sibling tools like browser_intercept_request/response by noting its broader applicability to all traffic.
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?
Provides explicit prerequisite (proxy must be running), scope (applies to ALL traffic), and alternatives (browser_intercept_request/response for instant browser-only). Includes examples for each action, making usage guidelines highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and succeeds: it discloses that each session is an independent Chrome instance, that multiple sessions can run simultaneously, that nodriver bypasses bot detection, and that traffic can be routed through a proxy port. This goes well beyond the schema.
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 well-structured with a bold opening sentence, a numbered startup sequence, and an Args section. Every sentence provides actionable information—no filler or redundancy—making it appropriately sized and easy to scan.
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's complexity (session management, proxy dependency, headless mode), the description covers all essential aspects: prerequisites, sequencing, multi-session use, anti-bot behavior, and parameter effects. The presence of an output schema means return-value details are not the description's job.
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?
Although schema description coverage is 0%, the description thoroughly explains each parameter: session_name for unique names, proxy_port must match manage_proxy and 0 disables routing, headless default true and false for visual debugging. This adds critical meaning the schema lacks.
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 uses a specific verb ('Launch') and clearly identifies the resource ('a new Chrome browser session with anti-bot bypass'). It distinguishes this tool from siblings by explicitly stating it must be called before any other browser_* tool and explaining its session-launching 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?
Provides explicit usage context: 'Call this BEFORE any other browser_* tool' and a numbered startup sequence with manage_proxy and browser_go. It also explains when multiple sessions are useful for multi-user testing, giving the agent clear guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 disclosure and does so thoroughly. It reveals the isolated sandbox nature, resource limits (256MB, 60s CPU, 32KB output), the require for human approval, proxy bypass behavior, and automatic dependency installation. These details go well beyond what any annotation would provide.
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 long but every section earns its place: an introductory summary, explicit use cases, a code example, resource limits, and parameter explanations. It is well-structured with clear headers and code blocks, making it highly scannable despite its length.
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?
This is a complex, powerful tool with 5 parameters and a required human approval gate. The description covers usage scenarios, SDK integration, resource constraints, and safety requirements. Since an output schema exists, the lack of return value explanation is not a gap. The description is complete for agent decision-making and safe invocation.
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?
Although the input schema has 0% description coverage, the description compensates fully by explaining each parameter inline: script_content (Python code using NdpSDK), dependencies (pip packages), timeout (default 300), approved (must be true only after human approval), and bypass_proxy (skips proxy). This adds meaning far beyond the bare schema titles 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 purpose: 'Execute a Python script in an isolated sandbox with full access to all other tools via NdpSDK.' It uses a specific verb (execute), identifies the resource (Python script), and distinguishes itself from sibling tools by positioning it as the programmatic orchestration layer for all 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'WHEN TO USE THIS (instead of individual tools)' section listing concrete scenarios like race conditions, blind SQL injection, and multi-step exploit chains. It also states the prerequisite that approved must be true, giving clear guidance on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers it: it discloses high-volume concurrent request sending, baseline measurement, anomaly detection criteria, and the mandatory approval requirement. It also explains the replacement workflow and concurrency aggressiveness, giving the agent a clear model of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-organized into labeled sections (REQUIRES, PREREQUISITE, HOW IT WORKS, SETUP, Args), with a front-loaded summary. Every sentence adds useful setup, workflow, or parameter information that is not present in the schema, so the length is justified.
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?
For a complex tool with five parameters, the description provides a complete workflow from prerequisite capture to final anomaly detection, plus setup examples and approval requirements. It appropriately references sibling tools like replay_flow and browser_go, and since an output schema exists, not detailing return values is acceptable.
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 zero description coverage, so the description must compensate—and it does. Each of the five parameters is explained with defaults, usage expectations, and examples, including the crucial approved flag semantics and the requirement that flow_id contain target_pattern.
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 opens with 'Fuzz a captured HTTP request by injecting payloads and detecting anomalies,' giving a specific verb and resource that clearly distinguishes it from siblings like replay_flow and inspect_flow. The 'HOW IT WORKS' section further clarifies the replacement and anomaly-detection mechanism, reinforcing the tool's unique 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?
The description provides explicit prerequisites, including approved=true and the need for a flow_id containing the target_pattern. It offers concrete setup guidance for URL versus body fuzzing, explicitly referencing replay_flow for body insertion, and clearly states the human-approval gate—making when and how to use the tool unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behavior: requires approved=true, SSRF protection blocks localhost/private IPs, TLS defaults, redirect following, and host override behavior. This goes far beyond the schema and sets clear expectations for safety and operation.
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 well-structured with sections for usage, security, example, and args. Every sentence adds value, and the example is concise yet illustrative. It is appropriately sized for a complex tool without unnecessary filler.
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's complexity, 6 parameters, and absence of annotations, the description covers purpose, usage, alternatives, security, and parameter semantics thoroughly. The presence of an output schema handles return value details, and the description provides all necessary context for correct invocation.
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?
Schema description coverage is 0%, but the description explains every parameter: raw is the complete request text, host overrides routing, port defaults, tls for HTTPS, follow_redirects, and approved must be set only after explicit human approval. This fully compensates for the missing 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 states a specific action ('Send a hand-crafted raw HTTP request'), identifies the resource (raw HTTP), and distinguishes itself from replay_flow. The analogy to Burp Repeater and the explicit use cases make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when you need full control over request formatting' and a direct alternative 'For replaying captured traffic, use replay_flow instead.' Also clarifies the no-proxy requirement and the mandatory human approval, giving clear conditions for use.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/BobongKu/nodriver-proxy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server