camoufox-reverse-mcp

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct aspect of browser automation and reverse engineering. Overlapping concepts like hooking and tracing are clearly separated by different mechanisms (function hooks, presets, source instrumentation, engine-level tracing) with explicit descriptions.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern in snake_case. A few unified tools like 'cookies' and 'scripts' use nouns, but their descriptions clarify they encapsulate multiple actions. This minor deviation is acceptable.
Tool Count4/5
35 tools is above the typical 3-15 range, but each tool has a clear purpose and many replace older separate tools. The count is justified by the complexity of the reverse engineering domain and does not feel bloated.
Completeness5/5
The tool surface covers the full lifecycle of reverse engineering: browser launch, navigation, network capture/interception, hooking, JSVMP instrumentation, engine-level tracing, cookie/storage management, script inspection, state management, and offline verification. No obvious gaps for the stated purpose.
Average 3.9/5 across 35 of 35 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 9 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits: waits, scrolling, error handling, return value, or side effects. The agent cannot infer if the tool blocks, throws on missing elements, or modifies page state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but lacking structure. No front-loading of critical info. It is acceptable for a simple tool but could be improved with bullet points or warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely sparse. It does not cover prerequisites (page loaded, element exists), behavioral context (will it scroll to element?), or return values. For a destructive action like click, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter 'selector' with no description (0% schema coverage). The tool description does not explain what format the selector expects (CSS, XPath, etc.). No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Click on a page element.'). The action is evident, but does not explicitly distinguish from siblings (e.g., type_text, navigate). The description is straightforward but could be more specific (e.g., 'by CSS selector').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like type_text or evaluate_js. The description lacks context for choosing click over other interaction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions return format but no safety traits (e.g., read-only, requires permissions) or side effects. Lacks basic behavioral disclosure for a file 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, front-loaded with purpose in first sentence. No redundant words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing explanation of the 'limit' parameter and context about file location, ordering, or performance. Without output schema, the return format info is helpful but incomplete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. Fails to explain its purpose or effect, leaving the agent to infer from the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list' and resource 'trace files on disk', with context 'for post-hoc analysis'. Distinguishes from sibling 'query_trace_file' by emphasizing listing all files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like query_trace_file. Implied usage from 'post-hoc analysis' but no explicit recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden of behavioral disclosure. It fails to mention error behavior (e.g., invalid selector, page not loaded), output format (e.g., base64, file path), or effects on browser state. Only parameter effects are described minimally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with purpose first, then parameter list. No unnecessary words, but could be slightly more structured (e.g., bullet points) for clarity. Still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks critical context such as return value format (e.g., image data, file path), error handling, and how it differs from sibling 'take_snapshot'. Incomplete for an AI agent to reliably invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 'full_page' captures entire scrollable page and 'selector' targets a specific element, adding meaning beyond the schema's type and title. However, it does not clarify behavior when both are specified or format requirements for selector.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool takes a screenshot of the current page or a specific element, covering basic purpose. However, it does not differentiate from sibling 'take_snapshot' which may have similar functionality, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'take_snapshot'. No mention of prerequisites, scenarios where it should not be used, or when each parameter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'realistic keystroke delays' but omits details like whether it simulates focus/blur events, whether it overwrites or appends text, or whether it works with different input types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action. However, it could be expanded to include key parameter details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not mention return values, error conditions (e.g., element not found), or behavior details (e.g., does it clear the field? does it send keyboard events?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description should illuminate parameters. It only implicitly mentions 'delay' via 'realistic keystroke delays'. It does not explain that 'selector' is a CSS selector or XPath, or that 'text' is the string to type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Type text into an input field with realistic keystroke delays.' It uses a specific verb (type) and resource (input field), effectively distinguishing it from siblings like click, navigate, or evaluate_js.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., evaluate_js to directly set value). There is no mention of prerequisites, when not to use, or comparison to other typing methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'token-efficient' but does not disclose whether the tool is read-only, has side effects, or what the output contains. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose. The 'token-efficient' note adds value but is extra; still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters, the description fails to explain what the accessibility tree contains or how to interpret the result, and no output schema compensates. Incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter information, which is acceptable. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the accessibility tree, which is a specific resource. However, it does not differentiate from siblings like 'take_screenshot' nor explain the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'take_screenshot' or 'get_page_info'. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only lists what is returned, but does not state whether the tool requires an active page, has side effects, or is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the purpose. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is minimally adequate but lacks contextual details such as safety guarantees (read-only), required state (active page), or relation to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage). According to guidelines, baseline is 3 when schema description coverage is high. The description does not add parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current page URL, title, and viewport size'. It is specific and distinguishes the tool from siblings like navigate, click, or take_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies read-only operation with 'post-hoc analysis' but does not explicitly state that it never modifies state, lacks disclosure on performance or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by a parameter list. It could be more concise by reducing redundancy, but the front-loaded purpose aids quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description lacks information about return values or behavior of each mode. It references 'Same as trace_property_access' but does not explain what each mode returns for a trace file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds significant value by explaining each parameter's purpose (e.g., 'Filter by object name', 'Bucketed timeline mode'). It 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a specific historical trace file for post-hoc analysis. It distinguishes from siblings like trace_property_access (which accesses current trace properties) and list_trace_files (listing files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'Same as trace_property_access' but does not provide usage context or exclusions.
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?
Description mentions preserving init scripts, which provides some behavioral context. However, with no annotations, it lacks disclosure of other effects (e.g., state reset, cookie clearing). The info is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. However, it omits essential parameter guidance, which could be added briefly without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reload action with one optional parameter and no output schema, the description is nearly complete but misses parameter explanation. It adequately covers the primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (wait_until) with default but no description. The description does not mention the parameter at all, failing to compensate for 0% schema coverage. The agent cannot infer valid values or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (reload) and resource (current page), and adds distinguishing detail about preserving init scripts. This differentiates it from siblings like navigate or close_browser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., navigate, close_browser). No mention of prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It fails to disclose timeout behavior (e.g., error on timeout), blocking nature, or return values. Only states what is waited for, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, output schema, or schema descriptions, the description is too minimal. It lacks return value, error handling, prerequisites (e.g., browser open), and details on behavior differences between element and network wait.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds meaning by linking selector to element and url_pattern to network request, but does not explain timeout default/units or clarify that parameters are alternatives. Incomplete beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for an element to appear or a network request matching a URL pattern. It uses specific verb 'wait' and resources, distinguishing it from siblings like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (waiting for condition before proceeding) but lacks explicit guidance on when to use versus alternatives. No exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains each action (log, block, modify, mock, stop) and associated parameters for modify and mock. However, it omits details like whether interception persists across navigation, how to remove interceptions, or any side effects on the browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently covers all parameters and their roles. It uses a list-like format with lines starting with parameter names, which aids readability. However, it could be slightly more structured (e.g., bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks important context: it does not describe the return value, how to see intercepted requests, how to remove interceptions, or the lifecycle of the interception. The tool deals with mutable state, but these aspects are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so effectively, explaining url_pattern with a glob example, listing all five action values, and clarifying the conditional use of modify_headers, modify_body, and mock_response. This fully covers the purpose and usage of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Intercept network requests matching a pattern.' It uses a specific verb and resource, and the actions (log, block, modify, etc.) further clarify its function. However, it does not explicitly differentiate this tool from siblings like network_capture or list_network_requests, which also deal with network requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the possible actions but provides no guidance on when to use this tool versus alternative network tools such as network_capture or list_network_requests. There is no mention of prerequisites, exclusions, or context for choosing interception over other methods.
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?
The description reveals that a new context is created, but lacks details on side effects (e.g., what happens to existing contexts, whether the import overrides any existing state). No annotations are provided, so the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and covers the essential information: purpose, argument, and return value. It could be slightly more concise, but it is well-structured with clear sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides adequate information to understand basic usage. However, it lacks details on error handling, expected behavior when the file is invalid, or interaction with the current browser state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description, but the description adds context: state_path is a path to a JSON file exported by export_state. This adds meaning beyond the schema type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: importing browser state from a JSON file by creating a new context. It distinguishes itself from sibling tools like export_state and reset_browser_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after export_state to restore state, but does not provide explicit guidance on when to use this tool versus alternatives like reset_browser_state, nor does it mention any prerequisites or context state requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It mentions optional features and return values but omits prerequisites (e.g., browser must be launched) and fails to clarify side effects like state changes, which are expected for navigation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, covering all necessary details without unnecessary verbosity. It front-loads the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description provides a thorough list of return fields and parameter explanations. However, it lacks details on error conditions and prerequisites, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter (e.g., 'url: Target URL') beyond the schema's basic title, adding useful context for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool navigates to a URL with optional hook injection and redirect tracing. The verb 'navigate' and resource 'URL' are specific, and the tool is easily distinguished from siblings like 'reload' or 'take_snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'reload', 'click', or 'wait_for'. The description lacks explicit context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'release all resources,' hinting at cleanup, but does not disclose irreversible side effects such as loss of browser state or inability to reuse the browser session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and to the point. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately explains the core action. However, it could briefly mention the irreversible nature or that the browser must be open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter description is needed. Schema coverage is 100% (vacuously). Baseline 4 applies as schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Close the Camoufox browser and release all resources.' It uses a verb-resource structure that distinguishes it from sibling tools like 'launch_browser' or 'navigate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., browser must be open), consequences (e.g., loses unsaved state), or contrast with other tools like 'reset_browser_state'.
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?
Without annotations, the description carries full burden. It conveys a read operation ('Get') and specifies the return format as a dict of key-value pairs, but omits details like error handling, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences with no waste. The purpose is front-loaded, and the parameter and return are clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 0 required parameters and no output schema, the description covers the core behavior and return format. Minor gaps (e.g., error states) but acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the single parameter 'storage_type' with its allowed values ('local' for localStorage, 'session' for sessionStorage), adding significant meaning beyond the schema's bare type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'contents of localStorage or sessionStorage', distinguishing it from sibling tools that handle other aspects like page info or console logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., get_page_info for DOM data). The context of siblings is not leveraged to set exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions it exports state and returns a dict. It does not disclose whether it is a read-only operation, permissions needed, file overwrite behavior, or side effects, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes both purpose and parameter explanation, but could be better structured with a separate returns section and less informal formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and siblings like import_state, the description is mostly complete. It mentions what is exported and what it returns, but lacks details on behavior like overwriting files or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the single parameter save_path by indicating it is a local file path for saving state JSON, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'complete browser state', and specifies it includes cookies and storage. It differentiates well from sibling tools like import_state (import) and reset_browser_state (reset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving browser state but does not explicitly state when to use it versus alternatives like import_state or reset_browser_state, nor does it provide context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is read-only (captured request details) and describes parameters, but does not specify behavior on invalid request_id, rate limits, or performance implications. Decent coverage but lacks edge-case details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (3 sentences and a param list) and front-loaded with the purpose. Each part adds value, though the returns section could be more detailed. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return as 'dict with request and response details' but lacks specifics on structure. For 4 params, it covers param semantics well but omits error handling and response format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so description must compensate. It explains request_id source, default values for booleans, and the special value -1 for max_body_size. This adds significant meaning beyond schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'get full details of a specific captured network request', specifying verb and resource. It distinguishes from sibling 'list_network_requests' (which lists requests) and 'get_request_initiator' (which gets the initiator).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'from list_network_requests' but does not explicitly state when to use this tool over alternatives, nor does it provide when-not-to-use guidance. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does mention which parameters are destructive (clear_cookies, clear_storage) and that others remove state like hooks and network capture. However, it does not describe side effects like losing ongoing captures, reversibility, or potential impact on the browser session. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear, concise opening sentence explaining the tool's core function. The parameter details are presented as a bulleted list, which is easy to parse. It is not overly verbose, though the bullet list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters. However, it lacks information about return values or success/failure output (no output schema exists). It also does not mention error conditions, prerequisites, or whether the tool can be safely called multiple times. For a reset tool, these details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose: removing persistent hooks, clearing network capture, clearing routes, and also clarifying that clear_cookies and clear_storage are destructive and default to False. This adds significant meaning beyond the bare boolean names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reset' and the resource 'MCP-side browser residual state', and distinguishes from 'without closing the browser', which differentiates it from siblings like close_browser. It also lists specific state components (hooks, network capture, routes, cookies, storage) for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to clear state but keep the browser open, contrasting with close_browser. However, it does not provide explicit guidance on when to use this tool versus alternatives like remove_hooks or network_capture for granular operations. No when-not-to-use or prerequisite information is given.
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?
Despite no annotations, the description details behavior: automatic fallback to evaluate_handle on serialization error, aggressive cleaning of return values (BOM, lone surrogates, whitespace, JSON auto-parse), and structured return dict with keys. This provides good transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, version note, behavior details, argument list, and return format. It is front-loaded but slightly lengthy; each sentence adds value, though minor redundancy exists (e.g., version note in both description and returns).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary JS execution), lack of output schema, and no annotations, the description is remarkably complete. It covers edge cases (fallback, cleaning), return structure, and hints for errors, providing an agent with sufficient context to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains both parameters: expression must be a single expression (not declarations) with IIFE workaround, and await_promise defaults to true. This adds critical meaning beyond the schema's simple type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary JavaScript expressions in the page context, using specific verb+resource. It distinguishes itself from siblings like 'scripts' and 'hook_function' by focusing on arbitrary evaluation, not script management or hooking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it provides constraints (single expression, no declarations, IIFE if needed) and notes on await_promise, it does not offer guidance on when to use this tool over siblings like 'scripts' or 'hook_function'. No explicit when-to-use or alternatives are mentioned.
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 covers key behaviors: it returns a list of filtered logs and clears the buffer if the clear parameter is True. It could mention that it only reads existing logs without affecting the page, but it's adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences for purpose, then list of parameters and return type. No unnecessary words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, behavioral effect of clear, and return structure. With an output schema present, the return description is sufficient. The tool is straightforward and well-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0%, the description fully documents all three parameters (level, keyword, clear) to clarify their meaning and effect, compensating completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets console output from the page, with a specific verb and resource, and distinguishes from sibling tools like get_storage or take_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only explains what the tool does, not context for choosing it over other tools.
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 explains actions and outputs, but omits potential side effects such as whether 'save' overwrites files or if there are any destructive behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, but the opening line could be more concise. Overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers all actions and parameters. However, it could mention error handling or default behavior for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the 0% schema coverage by explaining each action's parameter requirements, including the 'inline:<index>' format for URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for script inspection with three actions: list, get, save. It explicitly replaces three older tools and distinguishes itself from sibling browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for each action and parameter requirements, but does not explicitly state when not to use this tool or mention 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 the tool's read-like behavior (checking, no side effects implied) and details the return value sections (mcp, deps, browser, overall_ok, recommendations). It also notes version changes (session checks removed). However, it does not explicitly state that it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a structured list of return sections. It front-loads the purpose and includes relevant version history. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description provides sufficient context: what is checked, the return structure, and a version note. It is complete for the agent to understand 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). Per guidelines, the baseline is 4. The description adds value by explaining the output structure but cannot add parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('check') and resource ('MCP environment, dependencies, and browser state'). It lists specific components checked (MCP version, dependencies like esprima and playwright, browser state) and distinguishes it from sibling tools like 'compare_env' by focusing on a self-check rather than comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for initial diagnostics but provides no explicit guidance on when to use it versus alternatives like 'reset_browser_state' or 'compare_env'. The context is implicit, lacking when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions persistence and return format, but does not disclose potential side effects, error handling, or impact on the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with a clear header, bulleted preset list, and separate sections for args and returns. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return value. Lacks error details but is sufficient for a simple tool with 2 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so description fully explains parameters: preset names and options, and persistent's behavior (survives navigation). Adds significant meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool injects a pre-built hook template for common reverse engineering tasks, listing specific presets. This distinguishes it from siblings like hook_function, which injects custom hooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the listed presets for common tasks, but lacks explicit guidance on when to use this tool versus alternatives like hook_function 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly indicates a read-only listing operation and specifies return fields. It could mention if listing is limited or if filters combine with AND/OR, but the basic behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single introductory sentence followed by a bullet-style parameter list and a return line. Every line adds value, and the structure is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (implied by 'has output schema: true'), the description adequately covers return fields. It lacks details on filter combination logic and the scope of 'captured network requests', but overall is sufficient for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaningful details: 'substring filter', 'convenience domain filter', and examples for method/resource_type. This goes beyond parameter names and provides concrete guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List captured network requests with optional filters', specifying the verb (list), resource (captured network requests), and qualifier (optional filters). It distinguishes from siblings like get_network_request (single request) and network_capture (capture control).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like get_network_request or network_capture. Usage is implied by the name and sibling tools, but the description lacks any direct comparison or when-not-to-use instructions.
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 return types for each action and notes that 'delete' with no filter clears all cookies—a destructive behavior. However, it does not cover potential side effects (e.g., impact on browser state) or error conditions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line title, a line about replacement, clearly labeled Args section, and a Returns section. Every sentence earns its place, and the most important info (action options) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and multiple actions, the description covers the primary use cases and return values. The presence of an output schema reduces the need to detail return format. However, it lacks details on error handling, cookie dict format for set, and constraints (e.g., domain format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: 'action' with its three values and effects, 'domain' for filtering, 'cookies_list' for set, and 'name' for delete. This adds significant meaning beyond the schema, though the structure of 'cookies_list' items is only vaguely described as 'cookie dicts'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'Cookie management' and explicitly lists three actions (get, set, delete) with distinct behaviors. It also notes that it replaces older tools (get_cookies, set_cookies, delete_cookies), establishing a clear scope distinct from sibling browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each action via the 'action' parameter and provides context for domain and name filters. It mentions replacing older tools but does not explicitly contrast with alternatives like 'get_storage' or state when not to use this tool. The guidance is clear but not exhaustive.
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 full burden. It describes each action's effect (e.g., 'begin capturing', 'stop capturing (buffer retained)', 'clear the capture buffer', 'return current capture state') and notes that url_pattern defaults to capturing all and capture_body is for start only. It also specifies the return format. It lacks details on memory/performance impacts but is otherwise 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief sentence, then Args and Returns sections. It is efficient and front-loaded. The version number 'v0.9.0' adds minor clutter but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description adequately covers the tool's purpose, parameters, actions, and return value. It is complete for controlling network capture, though it does not mention integration with sibling tools for reading captured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does 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 fully explains each parameter: action values (start, stop, clear, status) with their meanings, url_pattern as a glob pattern for start, and capture_body as a boolean for start only. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is 'Unified network capture control' and lists specific actions (start, stop, clear, status), making the tool's purpose clear. It also distinguishes itself from sibling tools like start_network_capture and stop_network_capture by noting it replaces 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it replaces start_network_capture and stop_network_capture, giving context on when to use this tool over separate ones. However, it does not explicitly mention when not to use it or suggest alternative tools for reading captured data, leaving some workflow ambiguity.
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 handles behavioral disclosure well. It details that intercept mode injects custom JS with context variables, trace mode logs non-invasively, and mentions persistence and non-overridability. It could mention potential resource usage or removal mechanisms, but overall it is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-liner and bulleted arguments. While informative, it is somewhat verbose; for example, the context variable explanations could be condensed. Still, it remains clear and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is remarkably complete. It explains every parameter, the return value format, and gives usage patterns like examples for function_path. It covers both modes thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides extensive parameter semantics beyond the schema: explains function_path format, mode options, hook_code context variables, position values, and trace-related parameters. This adds significant meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Hook or trace a function (v0.9.0 unified).' It clearly states the tool's purpose and distinguishes it as a unified replacement for older hook and trace functions. Sibling tools like hook_jsvmp_interpreter and trace_property_access are different, so this description effectively differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes ('intercept' and 'trace') with their requirements and behavior, e.g., 'Requires hook_code' for intercept. It provides context for when each mode is appropriate. However, it does not explicitly compare with siblings like hook_jsvmp_interpreter or trace_property_access, which would improve 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?
No annotations exist, so the description fully bears responsibility. It discloses behavioral traits: attach mode cannot inject host/os font-fallback shim, close_browser() only disconnects in attach mode, and that enable_trace requires a custom browser build. It does not detail side effects like resource consumption or authentication needs, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with 'Args:' and 'Returns:' sections, and each parameter is documented concisely. It is somewhat lengthy but every sentence adds value. Minor redundancy (e.g., repeating 'attach' mode behavior) could be tightened, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 optional parameters, no output schema), the description is complete: it covers both modes, parameter dependencies, return type (dict with status/config/page list), and mentions related tools (close_browser, trace_property_access). An agent can confidently invoke this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all 10 parameters. It does so thoroughly: headless, os_type, locale, proxy, humanize, geoip, block_images, block_webrtc, enable_trace, and ws_endpoint each have clear descriptions of purpose, defaults, and special notes (e.g., geoip auto-infers from proxy, ws_endpoint overrides others). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Launch the Camoufox anti-detection browser, or attach to a running one.' It uses a specific verb ('launch'/'attach') and resource ('Camoufox browser'), distinguishing it from sibling tools like navigate or take_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use launch vs attach mode via the ws_endpoint parameter, noting that attach ignores other launch args. It mentions server startup command and fingerprint considerations. However, it lacks explicit exclusions or alternatives to using this tool versus other browsers/setup methods.
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?
Describes execution context (runs signer_code in current page context), comparison logic (pass_rate, first_divergence), and iterative workflow. With no annotations, this is good transparency; could mention if it modifies browser state but likely doesn't.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with numbered workflow and argument list. Not overly verbose, but a couple of sentences could be merged. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects for an offline verification tool: workflow, parameter expectations, return values (total_samples, passed, etc.). No output schema, but return dict explained. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully explains each parameter: signer_code (JS function), samples (list with id, input, expected), compare_params (optional list of keys). Adds structure and examples beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'offline verify a signing function against user-provided samples.' The verb 'verify' and resource 'signing function' are specific, and the offline context distinguishes it from real-time debugging tools like hook_function or intercept_request among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a typical workflow (capture requests, extract samples, write code, call this tool, iterate) which implies when to use it. Missing explicit when-not-to-use or alternatives, but the workflow gives strong contextual 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?
No annotations are provided, so the description carries the full burden. It explains the tool collects fingerprint data and returns categorized environment data, and mentions the optional 'properties' parameter with defaults. It does not contradict any annotations (none present). It adds context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short paragraphs. The first sentence immediately states the purpose. Every sentence provides value, and there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and no output schema, the description is complete. It explains the argument, default behavior, and return type (dict). Sibling tools are diverse and this description is sufficient for an AI agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'properties' with only type info. The description adds significant meaning: it explains the parameter is optional, lists default property categories (navigator, screen, canvas, WebGL, audio, timing). This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool collects browser environment fingerprint data for comparison with Node.js/jsdom. It uses a specific verb ('Collect') and resource ('browser environment fingerprint data'), and distinguishes itself from siblings like 'check_environment' which might check individual properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the use case: comparison with Node.js/jsdom. It implies when to use the tool but does not provide explicit alternatives or when-not-to-use scenarios. Sibling tools like 'check_environment' could be related, but no exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool modifies state in-place and returns a dict with status, restored_objects, and cleared counts. It does not mention failure conditions or prerequisites, but the information provided is sufficient for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for the main action, followed by a bullet list of arguments and returns. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 1-parameter schema and no output schema or annotations, the description covers the tool's purpose, the parameter's effect, and the return structure completely. No additional information is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'keep_persistent' is described in detail: 'If True, keep persistent init_scripts registered.' This adds meaning beyond the schema's title 'Keep Persistent' and default value, explaining the effect of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and the resource 'installed hooks', with the specific action of restoring original objects in-place. This distinctly differentiates it from sibling tools like 'hook_function' which installs hooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after hooks have been installed, as it says 'remove installed hooks' and 'restore original objects'. However, it does not explicitly state when to use vs alternatives or provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly explains engine-level operation, undetectability, and collect_values behavior. Could mention performance impact but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with title, body, Args, and Returns sections. Every sentence is informative with no redundancy. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is remarkably complete. Covers all modes, return structures, edge cases, and interaction with other tools (evaluate_js).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description thoroughly explains each parameter with examples and special cases (e.g., duration=0 for existing trace, bucket_ms for timeline). Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it traces DOM property access at the engine level, invisible to JS, and distinguishes itself from sibling tools like compare_env and evaluate_js by noting fallback behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions prerequisite (custom browser with enable_trace=True) and fallback to compare_env. Provides context for when to use different modes but no explicit when-not-to-use.
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 fully discloses behavioral traits: need for hooks, limitations with interceptors and Firefox, and workarounds like reload_with_hooks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold section headers, concise sentences, and front-loaded main purpose. Every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, single parameter, and no output schema, the description covers prerequisites, limitations, return value structure, and workarounds completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter request_id, with brief description 'The ID of the request'. Schema coverage is 0%, so description should add more context (e.g., source of request_id). Adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the JS call stack that initiated a network request', which is a specific verb and resource. Distinguishes from sibling tools like get_network_request and list_network_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes golden path, prerequisite (inject_hook_preset), and known limitations with workarounds, guiding when to use and when not.
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 details each action's behavior (registering routes, rewriting scripts, fetching logs) and important constraints (timing, tags). It does not explicitly mention side effects or destructive nature, but the context (instrumentation, rewrites) implies mutation. Slightly more explicit behavioral statements could push it to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with clear sections (Args, Returns, IMPORTANT) and uses bullet points for actions and parameters. Every sentence serves a purpose, including migration guidance (was: old_name). It front-loads the core purpose and parameter table, then adds critical timing notes. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all actions, describes every parameter in detail, provides default values, explains when to use filters, and even includes a full workflow example. The only omission is a detailed return value structure, but 'dict with action-specific results' is acceptable given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides exhaustive parameter explanations, including default values, valid options (e.g., for action, mode, wait_until), and specific use cases (e.g., filter_property_names for reducing overhead). This fully compensates 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for JSVMP source-level instrumentation and unifies multiple actions (install, log, stop, reload, status). It distinguishes from sibling tools by focusing on a specific instrumentation domain, with a clear verb (instrumentation) and resource (JSVMP scripts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, including a timing pattern requiring installation before navigate, with a step-by-step example. Explains each action's purpose and when to use alternatives (e.g., using reload after navigate). This is best-in-class for usage clarity.
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?
No annotations provided, so description carries full burden. It details behavioral traits: detectability of proxy mode, the need to install hooks before navigation, persistence, and the wrapping of Reflect.get/apply and Proxy installation on globals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, limitations, important notes, and Args section. Slightly lengthy but every sentence adds value. Could be tightened slightly, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 required and optional params, no output schema, and no annotations, the description provides complete coverage: explains return value, usage patterns, edge cases, and limitations. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description thoroughly explains each of the 8 parameters, including default values, constraints (e.g., track params only for proxy mode), and purpose (e.g., script_url for filtering, max_entries for buffer cap).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs a JSVMP runtime probe and explains multi-path instrumentation. It is distinctly different from sibling tools like hook_function or inject_hook_preset, which target other intercept mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, including a step-by-step sequence for sync-loaded SDKs. It also warns against using 'proxy' mode for RS/AK-style anti-bot and directs to alternatives like instrumentation or mode='transparent'.
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 behavioral traits: case-sensitive substring matching, dual modes (line/char) based on minification detection, and return structure. It transparently explains all relevant behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence and an Args section. It is slightly verbose due to detailed explanations, but every sentence adds value. Could be slightly more concise, but front-loading is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return format (dict with matches, total_matches, mode). All 5 parameters are fully explained, and the behavior is comprehensively described for a search tool. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry full parameter meaning. It does so thoroughly: keyword (case-sensitive substring), script_url (None vs specific, inline support), context_chars and context_lines with defaults and mode relevance, max_results with default. No parameter is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for a keyword in loaded scripts, and explicitly mentions it replaces two older tools, making its purpose unambiguous and distinct from sibling tools which are all browser automation or scripting actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use script_url=None (all scripts) versus a specific script_url (single script), and details auto-detection of minified files for mode selection. It also references the two replaced tools, providing clear context for usage without needing sibling comparison.
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:

[![camoufox-reverse-mcp MCP server](https://glama.ai/mcp/servers/WhiteNightShadow/camoufox-reverse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/WhiteNightShadow/camoufox-reverse-mcp)

Score Badge

Copy to your README.md:

[![camoufox-reverse-mcp MCP server](https://glama.ai/mcp/servers/WhiteNightShadow/camoufox-reverse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/WhiteNightShadow/camoufox-reverse-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WhiteNightShadow/camoufox-reverse-mcp'

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