chrometools-mcp

by docentovich

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v3.6.0
Disambiguation3/5
Several tools have overlapping purposes, such as executeModelAction vs click/type/selectOption, and analyzePage vs smartFindElement vs getElementDetails. However, detailed descriptions help distinguish many of them, though the volume creates ambiguity.
Naming Consistency4/5
All tools use camelCase with a mostly verb-first pattern (get, list, search, click, type, etc.). A few names like smartFindElement and executeModelAction break the pattern slightly, but overall naming is consistent.
Tool Count2/5
With 59 tools, the server is excessively large. While it covers multiple domains (browser automation, Figma, scenarios, API models), many tools could be consolidated, making the surface overwhelming.
Completeness4/5
The server covers browser automation, iframe handling, network, console, Figma design, scenario recording, and API model generation comprehensively. Minor gaps exist (e.g., cookie management, file upload), but the core workflows are well covered.
Average 3.8/5 across 59 of 59 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose whether deletion is permanent, requires permissions, or what side effects occur (e.g., deleting secrets). The mention of 'secrets' is vague and adds ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It communicates the core purpose efficiently, though it lacks additional useful context.
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?
For a mutation tool with no annotations or output schema, the description is too thin. It does not explain permanence, confirmation, or the nature of 'secrets', leaving the agent uncertain about the operation's effects and safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole parameter 'name' with 'Scenario name', achieving 100% coverage. The description does not add extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('scenario and secrets'), which distinguishes it from other scenario-related tools like listScenarios or exportScenarioAsCode. It lacks explicit distinction from potential delete-like siblings, but no such siblings exist.
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 usage context, prerequisites, or alternatives are mentioned. The tool is simple enough that usage is implied (when you want to delete a scenario), but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only mentions requirements. It does not explain the return format (e.g., base64 PNG data, URL), failure modes, or side effects. The statement about token requirement is also ambiguous given the schema marks it optional.
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, brief sentence states purpose and requirements without waste. Very economical and easy to parse.
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?
For a tool without output schema and annotations, the description omits essential return value information and usage context. It is not complete enough for an agent to understand what the tool returns or when to prefer it over other Figma tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description adds little beyond the schema, except noting the requirement for token and IDs, which may conflict with the optional figmaToken parameter. It does not provide additional semantic detail for scale or format.
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 exports a Figma frame as PNG, using a specific verb and resource. However, it mentions PNG only while the schema supports jpg and svg, slightly narrowing the actual functionality. It distinguishes from sibling tools like getFigmaSpecs.
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 alternative Figma tools like getFigmaSpecs or listFrames. The only context is the requirement for an API token and file/node IDs, which is more of a prerequisite than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions search by text or tags but does not disclose default project filtering behavior (searching current project only), read-only nature, or what happens with no criteria. This is a gap for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple search tool, though it could have been slightly more informative without sacrificing brevity.
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 read-only search with full schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it does not mention return format or provide usage context, leaving the agent without a complete picture of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description adds that 'text' and 'tags' are search criteria, which matches the schema, but it does not clarify how they combine (AND/OR) or the role of 'allProjects' beyond the schema's own description.
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 verb 'search' and resource 'scenarios', with specific scope 'by text or tags'. This distinguishes it from listScenarios which likely lists without filtering, but the description does not explicitly name the sibling tool or contrast behavior.
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 like listScenarios or other search tools. The description merely states what it does without context, exclusions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Pixel-perfect validation' without explaining whether the tool performs a read-only comparison, requires a live page, makes network calls to Figma API, or what happens on mismatch. No side effects, auth prerequisites, or failure behavior are disclosed.
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 two concise sentences with no filler. The main verb and object are front-loaded in the first sentence, and the second sentence adds context ('Pixel-perfect validation'). It is appropriately sized for a tool with clear purpose, though slightly vague tone costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, yet the description is minimal. It fails to explain what the tool returns (e.g., a diff percentage or pass/fail), preconditions (e.g., element must exist and be visible), or how threshold and figmaScale affect the comparison. This is a substantial gap for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters (fileKey, nodeId, selector, threshold, figmaScale, figmaToken) with meaningful descriptions. The tool description adds no semantic value beyond the schema, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare Figma design with browser element' — a specific verb and both resources. 'Pixel-perfect validation' adds scope. This clearly distinguishes it from sibling tools like getFigmaFrame (retrieves frame) or screenshot (captures browser), as none perform comparison.
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 implies a validation use case but provides no explicit guidance on when to use this tool vs alternatives like getFigmaFrame, screenshot, or getComputedCss. There are no exclusions or prerequisites stated, leaving the agent to infer context from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only lists the data types extracted and does not mention authentication requirements (the figmaToken parameter is optional but not explained in context), network calls, return format, or potential side effects. This is minimal and leaves the agent guessing about the tool's 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?
The description is a single sentence, tightly worded, and front-loads the purpose. Every word contributes, and the list of spec types adds useful detail without bloat. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple extraction tool with fully documented schema, the description is minimally adequate. However, without an output schema, the agent is left to infer the return structure, and the absence of usage guidance or behavioral details (e.g., whether this replaces or complements sibling tools) leaves gaps. It is enough to understand the basic purpose but not fully complete for robust selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for each parameter (nodeId, fileKey, figmaToken). The description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Extract' and clearly identifies the resource ('design specs from Figma') while enumerating the categories (colors, fonts, dimensions, spacing). This provides a clear sense of the tool's function, though it does not explicitly differentiate itself from overlapping siblings like getFigmaStyles or getFigmaColorPalette, which might also extract similar data.
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?
There is no guidance on when to use this tool versus the many Figma-related siblings (e.g., getFigmaStyles, getFigmaFrame, getFigmaColorPalette). The description simply states the action without indicating whether this is the comprehensive extractor or if specialized tools should be preferred for specific spec types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It says 'Check connection' but does not mention whether the tool has side effects, what it returns, or what happens if the connection is missing. The name 'enableRecorder' also hints at a state change that the description does not confirm or deny.
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 two sentences long and front-loads the core purpose. The second sentence adds a practical usage note. It is appropriately sized, though some wording could be more precise; it does not over-explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential behavioral context for a simple diagnostic tool: no expected return value, no failure behavior, and no mention of prerequisites. The ambiguity between 'enable' and 'check' further reduces completeness, and with no output schema or annotations, the description should provide more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. No additional parameter details are needed, and the description does not introduce any parameter-related confusion.
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 a specific action ('Check ChromeTools Extension connection') and context ('for scenario recording'), which differentiates it from tools like startRecording or stopRecording. However, the name 'enableRecorder' suggests an enabling action, while the description only says 'check', creating slight ambiguity about the tool's actual effect.
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 should be used to verify the extension connection before recording, and provides an alternative ('Use Chrome Extension popup (CT icon) for recording'). It does not explicitly state when to avoid using this tool or compare it to sibling tools, so the guidance is mostly implicit.
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 for behavioral disclosure. It mentions the action but does not describe the return format, authentication behavior beyond the optional token, potential large payloads, or any side effects. Minimal behavioral context beyond the verb.
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 short and front-loaded with the main action. The second clause ('For extracting design system') is slightly redundant with the parenthetical '(Design System)' but still adds intent clarification. Overall, it is concise with minor redundancy.
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?
There is no output schema and no annotations, so the description should explain what the tool returns and any important operational context. It does not; the output format is ambiguous, and the tool is not contextualized within the Figma sibling family. The description is adequate only for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with useful descriptions ('File key or URL' and 'API token (optional)'). The description adds no additional parameter guidance, so it meets the baseline of 3 for high schema 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 identifies the action ('Get all components') and the target ('from file'), with a parenthetical hint about design systems and a purpose clause. It distinguishes itself from sibling tools like getFigmaStyles by focusing specifically on components.
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 provides a general purpose ('For extracting design system') but does not explicitly state when to use this tool versus alternatives such as getFigmaStyles or getFigmaColorPalette, nor does it mention exclusions. The guidance is implied rather than explicit.
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?
There are no annotations, so the description carries the burden of explaining behavior. 'List' implies a read-only operation and 'with metadata' suggests the return content, but it does not explicitly state non-destructiveness, default project scope, pagination, or output shape. It adds minimal behavioral 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 a single, direct sentence with no filler. It front-loads the action and object, making it immediately scannable and appropriately sized for the tool's simplicity.
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 one-parameter list tool without an output schema, the description is minimally adequate but lacks explicit mention of what metadata is returned and the default project-scoping behavior. The allProjects default must be inferred from the schema, and the phrase 'all scenarios' is slightly ambiguous without qualification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter (allProjects) has its own clear description. The tool description contributes no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and resource ('scenarios with metadata'), so the core purpose is identifiable. However, it does not explicitly differentiate from related tools like searchScenarios or getScenarioInfo; 'all' implies breadth but no sibling comparison is given.
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 searchScenarios, getScenarioInfo, or deleteScenario. The allProjects parameter hints at project scoping but the description does not state use cases, exclusions, or why one would choose this tool over similar ones.
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 present, so the description must disclose behavior. It mentions dependency resolution as a behavioral trait, but it does not disclose potential side effects of executing a scenario, whether it modifies browser state, or error/failure behaviors. This is a significant gap for a tool that causes actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no redundant content. The first sentence delivers the core purpose, and the second adds a valuable usage tip. It is front-loaded and 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?
For a complex execution tool with no output schema and no annotations, the description omits critical operational context: return values, side effects, error handling, and how execution fits into broader workflows. The schema covers parameters, but the behavioral and outcome context is severely under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already thoroughly describes all four parameters, including projectId's disambiguation role. The description only restates the projectId tip without adding new parameter-level meaning, so it stays at the baseline for high schema 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 executes a scenario by name and includes dependency resolution, using a specific verb and identifying the resource. This distinguishes it from sibling tools like deleteScenario or saveScenario. The disambiguation tip adds precision.
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 provides a parameter-specific guideline for projectId but does not explicitly state when to choose this tool over alternatives like executeScript or deleteScenario. Usage context is implied by the name and core action, but no exclusions or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The verb 'Get' implies a read-only operation, and the description lists the categories of data returned. However, it does not disclose error behavior, return format, or any side-effect potential, which is a gap but not a contradiction.
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, concise sentence that is front-loaded with the primary action and resource, followed by a colon-separated list of the included properties. There is no redundant wording, making it highly efficient.
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 single-parameter tool with no output schema, the description adequately conveys the return categories (dimensions, positioning, margins, padding, borders). It could be more explicit about the return structure (e.g., units or coordinate system), but overall it is sufficiently complete for an agent to understand the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (selector described as 'CSS selector'), so the baseline is 3. The description adds no additional meaning beyond the schema, but it does imply that the selector refers to an element from which the box model is obtained.
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 with a specific verb ('Get') and resource ('element box model'), and enumerates the contained data (dimensions, positioning, margins, padding, borders). This is more specific than a generic 'get element info' and differentiates from siblings like getComputedCss, though it does not explicitly mention alternatives.
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 like getComputedCss or getElementDetails. There are no stated scenarios, exclusions, or prerequisites, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the key trait that it reuses the browser instance, but omits important behaviors such as what happens if no browser is open, whether it uses the current tab, or possible error conditions. The description is too sparse to fully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero filler. It is front-loaded with the primary action and includes only the most essential extra context (browser reuse). 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?
While the tool is simple (2 params, no output schema), the description lacks key behavioral and usage context. It does not explain what happens if no browser exists, whether a browser must be opened first, or how the waitUntil parameter affects behavior. Given the absence of annotations, the description is noticeably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter details beyond what the schema already provides; it does not mention the waitUntil parameter or its default value. No extra value is added.
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 ('Navigate') and resource ('URL'), and the phrase 'Reuses browser instance' distinguishes it from sibling tools like openBrowser, which would create a new browser instance. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Reuses browser instance' implies that this tool is for navigating within an existing browser session rather than opening a new one, providing some contextual guidance. However, it does not explicitly state when to use it over alternatives like openBrowser, nor does it mention prerequisites such as having an open browser.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Window persists for further interactions' is a useful behavioral detail beyond the tool's name, indicating the window remains available. However, it doesn't disclose potential side effects, whether it reuses an existing window, or any blocking behavior, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core action and adds a key persistence detail 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 one-parameter tool with a clear schema and a simple behavior, the description is mostly adequate. It explains the core action and a critical behavioral trait (persistence) but omits clarification about whether a new window is always created and how that relates to existing tabs, which is relevant given sibling tools. Still, given the simplicity, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the 'url' parameter with a description ('URL to navigate to'), giving 100% coverage. The tool description adds no additional semantics about URL format or restrictions, so it sticks to the baseline for well-schemaed parameters.
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 action ('Open browser and navigate to URL') and identifies the resource. The mention that the window persists adds a distinguishing behavioral trait, but it doesn't explicitly contrast with sibling tools like navigateTo, so it lacks direct sibling differentiation.
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 doesn't state prerequisites, exclusions, or recommended contexts. The persistence note is implied but not framed as a decision criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only says 'Returns matching requests with full details,' which suggests a read operation. However, it omits the destructive 'clear' behavior (from the schema), the default types (Fetch, XHR), and any side effects. The tool could clear the network log if clear=true, which is a significant undisclosed behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and return value without any fluff or redundant information. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filter tool with 3 parameters and full schema coverage, the description is adequate but lacks key context. It does not mention that the tool can also filter by request types, nor does it disclose the clear side effect or default types. Without an output schema, the return format is vague ('full details'), but the tool's simplicity keeps completeness at a moderate level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters with 100% coverage, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema. It mentions URL pattern but doesn't elaborate on the 'types' or 'clear' parameters, which are already explained 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 'Filter' and the resource 'network requests' with the specific criterion 'by URL pattern.' This distinguishes it from sibling tools like 'listNetworkRequests' (which lists all) and 'getNetworkRequest' (which retrieves one). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 filtering network requests, but it does not explicitly state when to use it over alternatives like 'listNetworkRequests' or provide any exclusions. The usage context is only implied via the tool name and description, with no mention of the 'types' parameter or clear flag that would affect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Get browser console messages' and gives a purpose, but does not mention that the 'clear' parameter can delete messages after reading, nor does it describe any return format or side effects. The description is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler: 'Get browser console messages. For debugging JS errors and tracking behavior.' Every word serves a purpose.
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 output schema, the description should clarify return values, but it does not. It also omits behavioral nuances such as the clearing side effect. For a simple tool with two optional parameters, the description is too sparse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters ('clear' and 'types') having descriptions. The tool description itself adds no parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'browser console messages', followed by a stated purpose 'For debugging JS errors and tracking behavior.' This unambiguously distinguishes it from sibling tools like listNetworkRequests or listTabs.
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 a clear usage context: 'For debugging JS errors and tracking behavior.' This tells the agent when to use the tool, though it doesn't explicitly mention alternatives or exclusions relative to other debugging 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?
With no annotations provided, the description carries the full burden. It fails to explicitly state that this is a read-only operation without side effects, nor does it mention authentication requirements or error behavior. It only describes the output, leaving safety and side-effect assumptions to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, and every word adds value. It is appropriately sized for a simple tool with no unnecessary repetition.
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 extraction tool with a sparse schema and no output schema, the description adequately covers what the tool does and what it returns. It could clarify whether the palette is for the whole file or a selection, but it is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters (fileKey and figmaToken) with clear descriptions, so the description does not need to add extra parameter semantics. It adds no new parameter-level information, but the schema is sufficient.
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 ('Extract color palette') and describes the output (unique colors with hex, rgba, usage count). This distinguishes it from sibling tools like getFigmaStyles or getFigmaFrame, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description—use this when needing color palette data from a Figma file—but no explicit guidance is given about when to prefer this over alternatives, nor are any exclusions or preconditions 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?
With no annotations, the description carries the full burden. It discloses that the tool fetches node structure and rendered image and returns simplified design data with AI instructions, which is transparent about its internal process. However, it lacks explicit statements about side effects, error conditions, or prerequisites like authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences lead with the core purpose, followed by the process and focus area. Each sentence adds distinct value with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description outlines the high-level workflow but does not detail the exact structure of the returned 'simplified design data' or possible limitations. With no output schema, this leaves some ambiguity about the response format, though it covers the tool's main function adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all five parameters, so the schema fully documents them. The description adds no parameter-specific details beyond what the schema already states, so it merits the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it converts Figma designs to React/Tailwind code, with a specific verb, resource, and outcome. The process description (fetches node structure and rendered image, returns design data with AI instructions) distinguishes it from sibling tools like getFigmaFrame or getFigmaSpecs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for converting Figma designs to React/Tailwind code and mentions its focus on React/Tailwind styling, offering some context. However, it does not explicitly state when to use this tool over related Figma tools, nor does it provide exclusions or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses analysis, element extraction, grouping, and helper generation, but leaves ambiguous whether the tool writes files, returns code to the UI, or requires a prior analyzePage call. The lack of side-effect or prerequisite disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose. Each sentence adds distinct value: generation of POM, the analysis/extraction/grouping behavior, and supported frameworks. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with four parameters and no output schema. The description explains what the generated code does at a high level but omits how the code is returned/stored and whether a prior analysis step is mandatory. This incomplete output/usage contract lowers completeness.
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?
All four parameters have schema descriptions (100% coverage), so baseline is 3. The description adds minor context (grouping to sections, framework support) but doesn't clarify parameter values or interactions beyond what the schema already provides.
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 opens with a specific verb-resource pair: 'Generate Page Object Model (POM) class from current page analysis.' It goes on to detail the analysis and generation behaviors (extracting elements, grouping by sections, framework-specific code), which clearly distinguishes it from sibling tools like generateApiModels or convertFigmaToCode.
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 phrase 'from current page analysis' implies a workflow dependency but does not explicitly state when to use this tool versus alternatives like analyzePage or other generators. It lists supported frameworks but gives no exclusions, alternatives, or prerequisites, so usage context is only implied.
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 should carry the full burden. While 'Get' implies a read operation, the description does not explicitly confirm it is non-mutating, nor does it disclose any potential side effects, performance considerations, or return format. It restates the tool's function without adding behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and followed by the primary use case. No extraneous 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?
With no output schema and no annotations, the description should explain return values and edge cases. It does not describe the response structure or any limitations. Given the tool's simplicity and full parameter documentation, this is an acceptable but not complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents all four parameters clearly. The description adds no additional parameter guidance beyond the schema, so it meets the baseline for full schema 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 'Get computed CSS styles for element', using a specific verb and resource. It distinguishes itself from sibling tools like getBoxModel and getFigmaStyles by specifying 'computed CSS styles'.
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 adds 'For layout debugging and responsive design', providing clear usage context. However, it does not explicitly mention when not to use it or point to alternative 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 are provided, so the description carries the full burden of behavioral disclosure. It does not mention authentication requirements, rate limits, pagination, or any side effects. Although 'get' implies a read-only action, the description lacks explicit safety context and does not go beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately state the action and the purpose. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with two parameters and no output schema, so the description should ideally convey what the return value looks like or any caveats. It explains the scope (color, text, effect, grid) and purpose, but does not mention return format or file-level limitations. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (fileKey and figmaToken). The description adds no additional parameter-level meaning beyond what the schema states, so it appropriately relies on the schema. Baseline 3 is warranted.
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 all styles (color, text, effect, grid) and explicitly ties it to extracting design tokens. The verb 'get' plus the resource 'styles' is specific and distinguishes it from sibling tools like getFigmaColorPalette or getFigmaComponents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For extracting design tokens' provides a clear context for when to use this tool. It does not explicitly exclude alternatives or name when-not-to-use, but the stated purpose is enough to guide an agent toward selecting it for design token extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and use cases, but does not mention potential side effects (e.g., triggering JavaScript events, network requests), whether it performs a real mouse move, or behavior on failure/visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and target, followed by use cases. No wasted words or redundant qualifiers.
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 two-parameter tool with full schema coverage, the description provides adequate purpose and usage context. However, with no annotations or output schema, it lacks return value/error behavior and any safety profile, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters fully described. The description repeats 'by APOM ID or CSS selector' but does not add semantic detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Hover over element') and clearly identifies the resource ('element by APOM ID or CSS selector'). It distinguishes hover from sibling tools like click and type by naming the action and use cases.
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 explicitly states when to use the tool: 'For hover effects, tooltips, :hover states.' However, it does not mention alternatives or when not to use it, so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral disclosure burden. It states the extraction output (fileKey, nodeId) but omits error handling behavior, input validation, or the fact that the schema also accepts a bare fileKey rather than a full URL, which could be surprising to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler words; front-loads the action and outputs. Every word earns its place.
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 one-parameter utility, the description is adequate but leaves out the tool's role in the broader workflow (e.g., feeding fileKey to other Figma tools). Since there is no output schema, a brief note about the returned shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the single parameter with 100% coverage, including the fact that it accepts 'Figma URL or fileKey'. The description adds no additional format details, so the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Parse' with a clear resource 'Figma URL' and names the output variables 'fileKey and nodeId', making its purpose distinct from sibling tools that operate on frames or styles.
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's use case but provides no explicit guidance on when to choose it over alternatives, such as when needing to convert a URL before calling frame-related tools. Sibling tools like getFigmaFrame might use this internally, but the description doesn't mention 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 provided, the description carries the burden of disclosure. It adds useful behavioral details: case-insensitive matching and scope across all pages. However, it does not describe the return format, whether partial matches are supported, pagination behavior, or authentication requirements (noting figmaToken is optional in schema). These gaps limit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb and resource, and contains zero filler. Every word adds value (case-insensitive, across all pages).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must be self-sufficient. It covers core purpose and two behavioral traits, but leaves out important context such as what the return value looks like, whether the search is partial or exact, and how results are ordered. For a simple search tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter (fileKey, figmaToken, searchQuery). The description does not add additional parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') on a specific resource ('frames/components') with a clear scope ('by name') and an added constraint ('Case-insensitive across all pages'). This clearly distinguishes it from sibling tools like listFrames (which lists all) and getFigmaComponents (which likely lists components separately).
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: use this when you need to find frames/components by name. However, it does not explicitly mention when not to use it or suggest alternatives like listFrames for browsing all frames or getFigmaFrame for fetching by ID. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the selection mechanism (value/text/index) but adds minimal behavioral context beyond the schema. It does not mention side effects, prerequisites like element visibility, error behavior, or whether the operation modifies the page state. This is a significant gap for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the main action. It avoids unnecessary detail and every sentence carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core purpose and selection alternatives. However, it omits behavioral details like what happens when multiple selection criteria conflict, whether the select must be visible, or any prerequisites. With no annotations or output schema, a bit more context would be helpful, but it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's phrase 'Specify value, text, or index' echoes the schema but adds no new semantic meaning. The priority ordering is already in the schema descriptions, so the description does not enhance parameter understanding.
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 'Select dropdown option' and specifies the two ways to identify the element ('by APOM ID or CSS selector'). This distinguishes it from sibling tools like click or type, and is a specific verb+resource combination.
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 indicates the intended use by telling how to select (by APOM ID or CSS selector, specifying value/text/index). It provides clear context but does not explicitly mention when not to use this tool or compare with similar alternatives like selectFromGroup, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states the high-level action without mentioning side effects, impact on the current page, or how deviceScaleFactor affects behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action, and every word earns its place. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and schema provides parameter limits, but the description falls short on behavioral context (e.g., whether the viewport change applies to the current page or persists). It is minimally complete but leaves gaps due to missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions for width, height, and deviceScaleFactor. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Change viewport dimensions') and adds a clear use case ('Test responsive layouts'), effectively distinguishing it from sibling tools like getViewport.
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 by stating the intended scenario (responsive layout testing) but does not explicitly mention alternatives or exclusion cases. This is a clear context without exclusions, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'Returns ranked candidates' but omits the tool's optional action execution (e.g., click, type) and the minConfidence threshold behavior that could auto-execute actions. This is a significant gap for a tool that might perform side-effectful operations.
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 exceptionally concise with exactly two sentences. 'Find elements with natural language' states the core purpose, 'Returns ranked candidates' describes output, and 'Prefer analyzePage for better performance' gives useful guidance. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is partially complete: it explains the find and return behavior but omits the optional action automation and confidence-based skipping which are key aspects of the tool's functionality. The schema covers these details, but the description alone would not give a full picture. Without an output schema, it does mention 'ranked candidates' which is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all parameters, including detailed explanations of 'description', 'action', 'maxResults', and 'minConfidence'. The description adds no extra parameter-level meaning beyond what the schema already gives, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find elements with natural language' and that it 'Returns ranked candidates.' This is a specific verb+resource combination that distinguishes it from sibling tools like findElementsByText and click. The mention of analyzePage as an alternative further differentiates it.
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 gives explicit guidance to 'Prefer analyzePage for better performance,' which is a clear alternative recommendation. However, it doesn't outline specific when-to-use or when-not-to-use scenarios beyond performance, so it's not fully exhaustive but still provides useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only says 'wait for element to appear' without explaining what happens on timeout, whether it checks visibility (despite the 'visible' parameter), or whether it returns a result. This is a significant gap for a wait tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core action. Every word earns its place, and there is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters, but with no annotations and no output schema, the description should explain timeout behavior and return semantics. It provides usage context but lacks these behavioral details, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's own parameter descriptions; it merely restates the general purpose. It neither improves nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Wait for element to appear.' It also distinguishes itself from sibling tools by targeting dynamic content and lazy-loaded elements, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'For dynamic content and lazy-loaded elements.' This implies usage scenarios but does not explicitly exclude alternatives or name them, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool targets new files and describes POM integration behaviors, which adds context. However, it doesn't state whether the tool writes a file, returns code, or what happens if the file already exists, leaving side effects unclear.
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 two sentences, front-loaded with the core purpose, and includes necessary differentiation and mode explanations without excess. It could be slightly better organized, but it is appropriately concise.
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 8 parameters and no output schema, the description covers core purpose and main mode options but omits important behavior like return value, file creation details, or handling of optional parameters. It is adequate for a basic understanding but not fully complete for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats some enum semantics already present in the schema (e.g., pageObjectMode explanations) and adds the 'NEW file' context, but it doesn't significantly enhance understanding of parameters like cleanSelectors or includeComments beyond what the schema provides.
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 exports a scenario as test code for a NEW file, which is a specific action on a specific resource. It explicitly distinguishes from appendScenarioToFile, making the purpose unambiguous and differentiating it from sibling 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 directly says 'Use appendScenarioToFile for existing files,' providing a clear alternative for the append case. It also explains the different pageObjectMode options, giving context on when to choose each mode. However, it doesn't explicitly mention when not to use this tool for other scenarios, but the key alternative is named.
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 the description alone must disclose behavioral traits. It only states that it retrieves details, implying read-only, but does not mention error behavior, secret handling defaults, or whether it requires any permissions. This is a significant gap for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the purpose and lists the data returned. No filler or repetition.
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 read-only getter with two well-documented parameters, the description covers the main purpose and return content (actions, parameters, dependencies). However, lack of output schema and annotations means the description should also clarify error handling and secret inclusion behavior, which it partially inherits from the schema but doesn't explicitly state. Still, it's adequately complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters fully: 'name' as scenario name and 'includeSecrets' with default. The description adds no additional meaning to either parameter, merely using the word 'parameters' generically, which could confuse with scenario parameters vs tool parameters.
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?
Clear verb+resource: 'Get scenario details' specifies the action. The additional list 'actions, parameters, dependencies' clarifies the scope of details, distinguishing from siblings like listScenarios or searchScenarios which focus on listing/searching rather than fetching full details of a specific scenario.
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 use when you need full scenario details by name, but it doesn't explicitly state alternatives or exclusions. There are siblings like listScenarios and searchScenarios, but the description's mention of 'details' suggests the use case. Still, no explicit guidance on when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this directly modifies the DOM style attribute, whether changes are temporary or persistent, or potential side effects like overriding existing styles – a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences: the first states the action, the second states the intended use. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully documented parameters and no output schema, the description covers the core action and use case adequately. However, it omits behavioral considerations like persistence or side effects, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (selector and styles). The description adds no extra parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it applies inline CSS to an element, which is a specific verb and resource. It distinguishes itself from sibling read-oriented tools like getComputedCss, and adds a clear use-case ('For live editing and prototyping').
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?
Indicates intended use with 'For live editing and prototyping', giving clear context. It does not explicitly mention alternatives or when not to use, so it misses a full exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not explain how the drag is performed (e.g., mousedown/mousemove/mouseup sequence), what happens on failure, or effects of distance/duration. The only behavioral hint is the mode selection, which is already in 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 four short, front-loaded sentences. No filler words; each sentence adds actionable information (purpose, use cases, mode guidance, alternative tool). Excellent structure for quick comprehension.
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 drag tool with no output schema and no annotations, the description provides essential usage context but lacks depth on behavioral nuances (e.g., coordinate origins, supported element types, error cases). It is adequate but leaves gaps that a more detailed description could fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining when to use 'synthetic' mode (JS libraries) and mentions scrollHorizontal as an alternative for scrollbars, enriching the understanding of parameters like mode and direction.
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 'Drag element in any direction' with specific use cases (maps, charts, SVG, canvas, sliders), distinguishing it from sibling tools like scrollHorizontal and click. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage guidance: use mode='synthetic' for JS libraries and use scrollHorizontal for scrollbars. This clarifies when to use this tool versus alternatives, though it doesn't explicitly list all exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the intended effect (trigger lazy loading, assist visibility testing) but does not cover details like default scroll behavior, failure handling, or return value. This is adequate for a simple action but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description provides adequate context for selection and basic invocation. However, it lacks usage guidance relative to siblings and behavioral details, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema, but it also does not need to; the schema already documents selector and behavior clearly.
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 ('Scroll to element') and adds context ('For lazy loading and visibility testing'), distinguishing it from sibling tools like scrollHorizontal and waitForElement. The verb+resource phrasing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For lazy loading and visibility testing' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one meaningful behavior ('Follows active tab automatically') and implies a continuous session with 'Use stopRecording to finish.' However, it does not mention prerequisites (e.g., whether enableRecorder must be run first), behavior if already recording, or any state changes beyond starting. This is a minimal but not empty disclosure.
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 three short, focused sentences: purpose, a behavioral trait, and a pairing instruction. Every sentence earns its place with no redundancy or filler, making it highly concise and well-structured.
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 start-recording tool, the description covers the core action and workflow. However, it lacks context about prerequisites (e.g., enableRecorder), error conditions (e.g., already recording), and what the tool returns. With no annotations and no output schema, these gaps make it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three optional parameters, and the schema already provides clear descriptions for name, tags, and description. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Start recording user actions,' a specific verb+resource that clearly states the tool's function. It distinguishes from sibling tools like stopRecording by referencing 'Use stopRecording to finish,' and the 'Follows active tab automatically' adds scope. This is strong clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: start recording, it follows the active tab, and you finish with stopRecording. This gives a basic workflow but does not explicitly exclude alternatives like enableRecorder or state prerequisites. It is clear but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the Strategy Pattern mechanism and the prerequisite of calling analyzePage(), which is useful context. However, it does not disclose return format, error behavior, or potential side effects, despite examples showing mutating actions like type and check.
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-organized with a clear intro, prerequisite callout, model list, and examples. Each section adds useful information without wasting words. It is slightly longer than necessary but remains focused and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's model-driven complexity and the absence of an output schema, the description should explain return values and error behavior. It adequately covers the discovery workflow (analyzePage) and usage patterns, but leaves out critical execution outcomes (e.g., success/failure, return data), making it incomplete for an agent to use confidently.
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 already covers all four parameters, but the description adds valuable concrete examples mapping actions to params (e.g., type→text, SetDate→date, selectOption→value, check→no params). This goes beyond the schema's descriptions and clarifies 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's purpose: 'Universal tool to execute any model-specific action on element.' It distinguishes itself from specific sibling tools like click/type by being a generic action executor tied to element models. Examples further clarify the resource and action scope.
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 explicit guidance to use analyzePage() first to discover available actions in the 'models' map. It also illustrates usage with multiple examples across different model types. However, it doesn't explicitly state when not to use this tool versus the specialized sibling tools, though that is implied by its universal nature.
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 present, so the description carries the burden. It discloses that the tool can 'optionally perform actions directly', implying non-read-only behavior, but does not elaborate on side effects (e.g., clicking may navigate) or state that the default is read-only. This is a partial disclosure.
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 four sentences, front-loads the core purpose, and provides useful guidance. Minor redundancy exists between 'get their selectors' and 'Returns working selectors', but no fluff is present and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested action object and no output schema. The description covers the main use case and the alternative to executeScript, but it does not explain the return format (e.g., array of selectors) or that actions apply to the first match (only mentioned in the schema). Some operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by specifying 'visible text content' for the text parameter, but it does not clarify exact, caseSensitive, or action semantics beyond the schema's brief 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 uses a specific verb ('Find') and resource ('elements by visible text content'), and states the output ('get their selectors'). It explicitly distinguishes from executeScript by saying 'Use this INSTEAD of executeScript', which clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'when you need to find elements', and names an alternative: 'INSTEAD of executeScript'. It also states that returned selectors work with click/type tools, giving downstream usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses what the tool returns (bounds, CSS selector, position, attributes, computed styles) and mentions the optional children tree analysis. However, it doesn't explicitly state that the operation is read-only or non-destructive, nor does it mention caching behavior (relevant to the 'refresh' parameter) or any side effects. The 'Get' verb implies read-only, but without annotations, more explicit disclosure would be ideal.
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, consisting of three sentences that front-load the core purpose, then describe the output, and finally state when to use it. Every sentence adds value, with no redundancy or fluff. It is well-structured and easy to scan.
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 four parameters, the description does a solid job of covering the essential context: what it does, what it returns, and when to use it. The schema handles parameter details fully. It could be more complete by noting error behavior or preconditions, but for a read-only retrieval tool, it adequately covers invocation and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description adds some context by explaining the APOM ID usage and the children analysis feature, which aligns with the 'id' and 'analyzeChildren' parameters, but it doesn't add significant new semantic information beyond the schema. The description's mention of analyzePage output simplified context helps clarify the 'id' source, earning a 3 rather than a lower score.
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: 'Get detailed information about element by its APOM ID.' It specifies the resource (element) and the action (get details), and differentiates itself from siblings by mentioning it returns full details including bounds, CSS, position, attributes, and computed styles, plus optional children tree analysis. This distinguishes it from more specialized tools like getBoxModel or getComputedCss.
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 tells when to use the tool: 'Use this when analyzePage output was simplified and you need complete information about specific element or analyze specific sections in detail.' This provides clear context and references a sibling tool (analyzePage). However, it doesn't explicitly mention when not to use it or name alternative tools for specific scenarios, so it misses the full 'when-not/alternatives' rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool returns file structure with all pages and frames, but does not mention output format, pagination, errors, or any other behavioral specifics. This is adequate but not rich, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and scope, and contains no unnecessary words. Every word earns its place, making it very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and no output schema, this description is largely complete. It offers clear purpose and usage guidance. A minor gap is the lack of detail about the structure of the returned data, but the phrase 'all pages and frames' gives a reasonable hint. Overall, it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (fileKey and figmaToken), so the schema already provides full meaning. The description adds no additional parameter context beyond what the schema defines, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('file structure'), specifying it covers 'all pages and frames'. It distinguishes from sibling tools like listFrames and getFigmaFrame by positioning as an initial discovery tool for file contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use first to discover file contents' provides clear contextual guidance for when to use this tool, implying it is the initial step before exploring specific frames or components. However, it does not explicitly name alternatives or state when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It states the return scope (method, URL, status) and pagination behavior, but does not mention potential side effects such as the 'clear' parameter which can clear data after reading. Since the schema documents this parameter, the omission is not severe, but the description alone does not fully disclose behavior for all options.
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, consisting of three short sentences that each add value: what is listed, a pointer to details, and pagination. Information is front-loaded and there is no redundant wording.
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 schema covers all parameters and the description indicates the output fields and pagination, the tool is well-specified for its simplicity. There is no output schema, but the description partially compensates by stating what is returned. It lacks mentions of default filters or interaction with other sibling tools, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description adds little beyond mentioning pagination (which relates to limit/offset), but it does not explain parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('network requests') and even specifies the fields returned (method, URL, status). It also explicitly differentiates from the sibling tool getNetworkRequest by pointing to it for details, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use getNetworkRequest for details,' which provides a clear alternative and implies using this tool for listing/overviews. It also mentions pagination support, which is relevant when handling large sets. However, it does not mention when not to use this tool (e.g., when needing detailed request info) beyond that single alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the core behavior (press key on focused element or page) but does not disclose nuances like the need to focus an element first if an id/selector is provided, or the behavior when no focus is specified. It also doesn't mention side effects or limitations. For a keyboard press tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a list of use cases. It is front-loaded with the purpose and contains no filler. Every sentence provides useful guidance.
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?
This is a simple tool with a well-documented schema and no output schema. The description covers main use cases and explains the focus behavior (on focused element or page). The schema covers parameter details. Together they give an agent sufficient context to invoke the tool correctly.
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 describes all four parameters with 100% coverage. The description mentions examples like Ctrl+A, which hints at how modifiers and key combine, but it does not add substantive meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses a keyboard key on a focused element or page, and provides concrete use cases (Enter for form submission, Escape for dialogs, Tab/Arrow for navigation, Ctrl+A for shortcuts). This specific verb+resource distinguishes it from sibling tools like click (mouse) and type (text input).
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 lists scenarios where the tool is appropriate: form submission, closing dialogs, navigation, and shortcuts. This provides clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the examples make the intended use clear.
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 discloses that the tool 'persist[s] the scenario to disk,' indicating a write side effect, and implies a dependency on stopRecording. However, it does not mention error conditions (e.g., duplicate names, write permissions), return value, or whether saving overwrites existing scenarios, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the core purpose, and the second adds necessary workflow context. It is front-loaded and earns every word.
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 absence of an output schema and the presence of sibling tools that form a recorder workflow, the description is adequately complete. It provides the purpose, the correct timing ('after stopRecording'), and the persistence behavior. It could mention return format or error behavior, but the essential context for correct use is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds little beyond the schema; it references 'recorded actions' and 'after stopRecording,' but the schema already describes actions and secrets as 'from stopRecording.' No additional parameter meaning is provided beyond what the schema covers.
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 and resource: 'Save recorded actions as a scenario.' This distinguishes it from sibling tools like deleteScenario, listScenarios, and getScenarioInfo. It also adds the key detail of persisting to disk, which clarifies the tool's specific role in the workflow.
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 explicit when-to-use guidance: 'Call this after stopRecording.' This tells the agent the correct sequence in the recording workflow. It does not explicitly name alternatives or exclusions, but the 'after stopRecording' instruction is strong and clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the two usage modes (by pixels or to end) and names common use cases, which adds useful context. However, it does not disclose potential failure modes (e.g., element not scrollable) or return behavior, leaving some behavioral traits implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It leads with the action, specifies the modes, and ends with use cases. This is an example of efficient, front-loaded writing.
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 scroll tool with 100% schema coverage and no output schema, the description covers the core purpose, modes, and target elements. It does not mention return values or error handling, but these are less critical for a scroll operation. Overall, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's phrase 'by pixels or to end' mirrors the schema's explanation of 'amount' ('Pixels to scroll or full for end'), adding little new meaning. It does not elaborate on 'selector' or 'direction' beyond what the schema already states, so the added value is 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?
The description clearly states the tool's action ('Scroll element horizontally') and its modes ('by pixels or to end'). It also gives specific use cases ('tables, carousels, scrollable containers'), distinguishing it from the sibling tool 'scrollTo' which likely handles vertical or general scrolling. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('For tables, carousels, scrollable containers') and implies horizontal scrolling scenarios. However, it does not explicitly mention alternatives (e.g., 'use scrollTo for vertical scrolling') or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds a valuable behavior—'Updates React/Vue/Angular state automatically'—which implies proper event dispatch for frameworks. However, it omits other default behaviors such as clearFirst=true and keystroke delay simulation, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starting with a clear action and resource. Each sentence adds a distinct value: the targeting mechanism and the framework state update. 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?
The tool has moderate complexity (5 params, no output schema, no annotations). The description covers the primary action, input identification, and a key behavioral guarantee, which is sufficient for basic usage. It does not mention default clear/delay behaviors, but those are already in the schema, so the description is fairly complete.
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 already describes all parameters with 100% coverage, so the bar is lowered. The description adds the 'preferred' qualifier for id over selector, which is not present in the schema and guides the agent on parameter precedence. It does not add format or syntax details, but the schema already provides those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Type text into input' and clearly states the two targeting mechanisms (APOM ID preferred or CSS selector), which distinguishes it from sibling input tools like click, pressKey, and selectOption.
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 gives a clear preference for APOM ID over CSS selector, but it does not explicitly say when to use this tool instead of alternatives like pressKey or selectOption. The intended usage is implied by the verb 'type' and the framework update note, but no exclusions or alternative tool names 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 carries the full burden. It discloses the return format (APOM tree), compact vs full format, internal selector registration, cache refresh requirement, token efficiency, and clickTarget legend. It doesn't discuss potential errors or side effects, but as a read tool this is reasonably 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 dense but well-structured, front-loading the core purpose. Every sentence provides useful information (format, IDs, refresh, efficiency, legend). It's longer than typical, but the content earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description explains the return structure, element ID usage, refresh semantics, and format options. It gives enough context for an agent to use it effectively. Minor gaps exist around error behavior and full debug format details, but overall it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some context beyond the schema (e.g., refresh after clicks, compact format), but doesn't need to re-explain parameters since the schema already documents them effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'PRIMARY tool for reading page state' with a specific verb and resource, and distinguishes it from sibling tools like screenshot and getElementDetails. It clearly conveys the tool's role and scope.
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 clear context on when to use (primary read tool), and includes actionable guidance like 'Use refresh:true after clicks' and using element IDs with click/type tools. It does not explicitly name alternatives or when-not-to-use, but the 'PRIMARY' positioning and efficiency note imply the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds two meaningful behaviors: 'Handles React/Vue/Angular events' and 'waits for navigation.' However, it omits other significant behaviors like waitForSelector, autoAnalyzeAfter, and waitForRouteChange, which are explained only in the schema. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action and identification methods; the second covers two key behaviors. Both sentences earn their place, and the content is front-loaded with the core action. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and no annotations or output schema, so the description must compensate for complexity. While the schema is 100% covered, the main description does not summarize advanced features like waitForSelector or autoAnalyzeAfter, which are essential for dropdowns/popups. The description is sufficient for basic clicks but incomplete for the tool's full capability.
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 100%, so the baseline is 3. The description adds value by specifying 'APOM ID (preferred)' over CSS selector, which is not explicit in the schema. It also implies the id/selector trade-off through framework event handling, adding semantic meaning beyond the raw parameter list.
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: 'Click element by APOM ID (preferred) or CSS selector.' It identifies the verb ('Click'), the resource ('element'), and the identification methods. It also distinguishes from sibling tools like type, hover, and pressKey by focusing on clicking and framework event handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: clicking elements with APOM ID preferred over CSS selector, and it handles framework events and waits for navigation. It does not explicitly mention alternatives or exclusions, but the tool's name and sibling list make the use case obvious (e.g., use click for mouse clicks, not for typing). This earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It goes beyond a generic statement by enumerating technical behaviors: $ref resolution, enums, allOf/oneOf, and nested objects. It also discloses the side effect of generating model files, but stops short of mentioning overwrite behavior or output location.
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 three sentences, each earning its place. It front-loads the core purpose, then adds capabilities and usage timing. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema or annotations. The description covers the core functionality and dependency on loadSwagger, but leaves out output specifics (e.g., where files are written, return value, error behavior). It is adequate but not fully complete for a tool of this complexity.
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?
All 8 parameters have schema descriptions (100% coverage), so the baseline is 3. The description does not add additional context for any specific parameter beyond what the schema provides; it only references languages and styles in a general way, which the schema already caps.
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 opens with a specific verb+resource: 'Generate typed data models from OpenAPI/Swagger spec.' It names target output types (TypeScript interfaces/types, Python dataclasses/pydantic/TypedDict) and source schemas, clearly distinguishing it from sibling tools like loadSwagger.
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 final sentence 'Use after loadSwagger to generate model files' provides clear context for when to invoke this tool, directly referencing a sibling as a prerequisite. It does not explicitly state exclusions or alternatives, but the relationship to loadSwagger is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return fields (headers, payload, response) and the dependency on requestId from listNetworkRequests. However, it does not mention error behavior, whether network recording must be active, or that the operation is read-only (though implied by 'Get'). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and details. Every word earns its place, with no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description sufficiently covers purpose, parameter source, and partial return shape. It lacks explicit error handling or edge-case behavior, but the low complexity and simple getter nature make this an acceptable level of completeness.
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 fully documents requestId with 'Request ID' (100% coverage), so the baseline is 3. The description adds contextual value by specifying 'Use requestId from listNetworkRequests,' telling the agent where to obtain a valid ID, which enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get network request details (headers, payload, response).' It specifies a concrete verb and resource and distinguishes itself from sibling tools like listNetworkRequests by focusing on single-request details and referencing the list tool for obtaining IDs.
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 gives a clear workflow hint: 'Use requestId from listNetworkRequests.' This tells the agent when to use this tool (after listing) and where to get the required parameter. It doesn't explicitly mention alternatives, but the context is sufficiently clear for a read operation.
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 for behavioral disclosure. It states the tool returns state fields, and 'Get' implies a read-only operation, but it doesn't clarify preconditions like whether the recorder must be enabled/started, or what happens if it isn't.
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, well-structured sentence that front-loads the purpose and lists the return fields. Every word contributes meaning, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is nearly complete: it enumerates all expected return fields. However, terms like 'action count' and 'current tab' are slightly ambiguous without further type or format details, though this is a minor gap.
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 the schema is trivially complete (100% coverage). The description doesn't need to explain parameters, earning the baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('current recorder state'), then enumerates the exact returned fields: isRecording, isPaused, action count, current tab. This clearly distinguishes it from sibling recording-control tools like startRecording and stopRecording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get current recorder state' clearly communicates the tool's purpose and implies when to use it, but it doesn't explicitly mention exclusions or alternative tools. No direct sibling tool competes for this functionality, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, and the description specifies the two outputs (size and pixel ratio). However, it does not explicitly state that there are no side effects, nor does it describe the exact return format, which would be valuable for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that front-load the action and purpose. Every word earns its place, with no filler or redundant content.
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 low complexity (no parameters, no output schema), the description adequately covers the essentials: what it does and a key use case. It lacks details about return formatting or edge cases, but for a simple getter tool, this is largely sufficient. The absence of an output schema slightly raises the bar, but the description's explicit mention of the returned values helps bridge that gap.
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 the baseline per rubric is 4. The description adds semantic value by telling the user what information the tool returns (viewport size and pixel ratio), which goes beyond the empty input schema and compensates for the lack of an output 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's function: to get viewport size and pixel ratio. It uses a specific verb ('Get') and resource ('viewport'), and distinguishes it from sibling tools like setViewport, which performs the opposite action. The mention of 'pixel ratio' adds precision about what is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For responsive design testing' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions, such as contrasting with setViewport for changing the viewport. This is clear but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's core behaviors: loading from URL or local file, supporting OpenAPI 2.0/3.x and JSON/YAML, and returning a structured summary. However, it does not mention error handling or whether network requests are made, but these are reasonable inferences from the description.
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 three sentences, front-loaded with the primary action, then details supported inputs and usage context. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's input, supported formats/versions, output summary, and primary use case. Since there is no output schema, the description's enumeration of the returned fields (endpoints, schemas, auth types, base URL) is valuable. It is complete for a straightforward loader, though it does not provide a precise return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for both parameters (source and format) with 100% coverage. The description reinforces that source is a URL or local file and mentions JSON/YAML, but adds no new semantic detail beyond what the schema already states. Therefore, baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Load and parse OpenAPI/Swagger spec from URL or local file.' It also specifies the output ('Returns structured summary: endpoints, schemas, auth types, base URL') and distinguishes it from sibling code-generation tools by noting it is a first step before generating models or client code.
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 gives explicit contextual guidance: 'Use this first to understand an API before generating models or client code.' This clearly signals when to use it (before code generation) and implies it is not the final generation step. It does not explicitly name sibling tools or list exclusions, but the timing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses auto-scaling and compression behavior, and how to achieve original quality, but does not mention file overwrite behavior, return value details, or error conditions. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every phrase adds value. It is concise and well-structured with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers the core purpose, key behavioral traits, and a practical usage tip. It does not detail return values or error handling, but given the schema richness and the straightforward nature of the tool, it is reasonably complete.
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 100%, so the baseline is 3. The description adds valuable semantic guidance beyond the schema by explaining the interplay of maxWidth and format for original quality, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a screenshot to a file and does not return it in context. This distinguishes it from the likely sibling tool 'screenshot' which presumably returns the image, so the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without returning in context' suggests this tool is appropriate when a file output is desired rather than an in-context return. It also provides a concrete usage tip for original quality (maxWidth: null, format: 'png'), but does not explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses token consumption (5-10k tokens) and the element/viewport distinction, which is useful. However, it does not mention other behavioral aspects like whether it is read-only, the return format, or potential failure modes. The token cost adds value but leaves some transparency 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?
Two sentences with no fluff: the first fronts the verb and resource, second gives an alternative. Every sentence earns its place, and the token cost is a concise addition.
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 7 params, no output schema, and no annotations, the description provides clear purpose, usage guidance, and token estimates. It does not describe the return format, but the token count implies an encoded image and the schema covers parameters. The tool is simple enough that this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the element-vs-viewport behavior, but this is already partly documented in the schema for id/selector ('Omit both for viewport screenshot'). No additional parameter meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Capture element image') and the alternative scenario ('full viewport when no id/selector is given'). It distinguishes itself from sibling tool analyzePage, which is specified for form data/validation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Capture element image, or full viewport when no id/selector is given') and provides a direct alternative: 'Use analyzePage for form data/validation.' This is a clear when-to-use vs. alternative guidance, similar to the top-calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately discloses that the tool sets a stateful context affecting subsequent commands, resets with no arguments, and auto-resets on navigateTo. This adds meaningful context beyond the input 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 two sentences and front-loaded. The first sentence defines the tool's purpose and affected operations; the second covers reset and auto-reset behavior. Every sentence carries high-value information 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?
The description covers key behavioral aspects (statefulness, affected commands, cross-origin use case, reset, and auto-reset) and is sufficient for an agent to select and invoke the tool correctly. It does not mention listFrames for discovery, but that is not essential given the schema and no output schema.
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?
Input schema coverage is 100% with detailed descriptions for both parameters (substring matching, mutual exclusivity). The description adds no additional parameter semantics beyond the schema, but 'Call with no args' reinforces that both parameters are optional, matching 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 uses a specific verb ('Set the active frame') and clearly identifies the resource (active frame) and scope (affects click/type/hover/analyzePage/find/executeScript/waitForElement). It distinguishes itself from sibling tool listFrames by focusing on setting rather than listing frames.
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 states when to use the tool ('required to automate cross-origin iframes') and provides reset behavior ('Call with no args to reset to the main frame') and auto-reset on navigateTo. It does not name alternative tools explicitly, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself discloses a key behavioral trait: after switching, subsequent commands target the new active tab. This goes beyond the basic definition and helps an agent understand the stateful impact. It also implies a precondition (listTabs) but does not specify error behavior for invalid indices or unmatched patterns, so it is informative but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. The action is stated first, followed by the behavioral consequence and a helpful prerequisite, making every sentence valuable and easy to parse.
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 single-parameter tool with no output schema, the description covers purpose, prerequisite, and statefulness. It lacks error-handling details, but given the low complexity and presence of a concrete usage hint, it is contextually sufficient. The absence of an output schema means return values are not specified, but that is not a significant gap for an action-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete information: the 'tab' parameter accepts either a 0-based index or a URL pattern with partial match. The description merely says 'by index or URL pattern' without adding details like partial matching, so it does not add meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Switch active browser tab by index or URL pattern.' This clearly distinguishes it from sibling tools like listTabs (listing) and navigateTo (navigating to a URL), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use listTabs first to see available tabs' provides an explicit prerequisite, and 'all subsequent commands will target the new active tab' clarifies the operational context. While it names no alternative tools, the context is clear and sufficient for an agent to know when to invoke it vs. others.
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 key risk: may break React/Vue/Angular synthetic events. It also sets expectations as a destructive/advanced tool by labeling it LAST RESORT. However, it does not mention other possible side effects (e.g., page navigation, state mutation beyond the script's scope) or return value behavior, which would be useful for a raw script execution 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 compact, front-loaded with the critical warning, and every sentence provides actionable guidance. It uses bullets-like structure with 'NEVER use for' list, making it easy to parse. No wasted words; it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the script execution returns (e.g., the script's result value, whether the result is serialized, or how errors are surfaced). Given the tool's power and fallback nature, this omission is a gap. The usage context is well-covered, but the execution result and post-conditions are left ambiguous, so completeness is below the ideal for a high-risk tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter-level semantics beyond what the schema already provides (script code, timeout, waitAfter, screenshot). It does not compensate with extra detail, but the schema is sufficient, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'executeScript' and description clearly indicate this tool executes JavaScript. It explicitly positions itself as a LAST RESORT fallback and distinguishes itself from specialized sibling tools by listing what it should NOT be used for (clicking, typing, etc.). The verb+resource+scope is clear and differentiates from alternatives.
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 provides explicit guidance: use ONLY when ALL specialized tools failed, and lists specific alternatives for common actions (click, type, scrollTo, analyzePage, etc.). It also advises against using it with React/Vue/Angular due to synthetic event breakage. This is a model of clear when-to-use and when-not-to-use guidance.
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 carries the burden of behavioral disclosure. It clearly states the output ('pong') and the optional inclusion of a message, leaving no ambiguity about side effects or return behavior. The behavior is fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information without unnecessary words. It is front-loaded with the core function and quickly states the output and optional behavior.
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?
For a trivial ping tool with one optional parameter and no output schema, the description is fully complete. It covers the purpose, behavior, and parameter semantics without needing additional context. The low complexity of the tool means no further details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'message' parameter with 100% coverage, including its optionality and purpose. The description adds no additional semantic value beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states this is a ping-pong tool for testing that returns 'pong' with an optional message. The verb 'returns' and resource 'pong' make the purpose crystal clear, and it is easily distinguishable from the browser automation and scenario-related sibling tools.
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 mentions 'for testing' which implies the tool is used for verification or sanity checks. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the tool appends to existing files and describes two Page Object modes, but omits the 'generate' mode behavior (separate POM creation) and does not detail failure conditions or side effects beyond appending. This is adequate but has clear 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?
Two concise, front-loaded sentences that immediately state the primary purpose and then provide key usage distinctions. 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?
With 12 parameters and full schema coverage, the description captures the core workflow (append to existing, use export for new) and key mode differences. It doesn't explain all modes, but the schema fills in details. No output schema is needed for an append operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds meaningful context for targetFile (must exist) and clarifies pageObjectMode values like 'generate-integrated' and 'use-existing', going beyond the schema's simple 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 appends scenario code to an existing file, using a specific verb and resource. It also distinguishes from the sibling tool by explicitly directing users to exportScenarioAsCode for new files.
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 alternative guidance: 'Use exportScenarioAsCode for new files' and implies this tool is for existing files. Also explains Page Object integration modes, giving clear context for when to use different configurations.
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 takes on the full burden of behavioral disclosure. It explicitly differentiates radio (single-select) from checkbox (multi-select with modes), and references analyzePage for option availability. It does not cover error handling or return values, but the core interactive behavior is clearly explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and contains no fluff. Every sentence adds meaningful context: group selection behavior, mode support, and reference to analyzePage for options.
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 has 7 parameters, 2 enums, and no output schema, the description covers the main behavior, group types, selection modes, and points to analyzePage for available options. It does not detail error handling or return values, but it is sufficient for an agent to invoke the tool in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly mentioning 'name', 'value', and 'text' parameters and links to analyzePage for where options come from. This helps the agent understand source data for parameters without reading the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'select' and the resource 'radio or checkbox group' with a specific scope of 'by name attribute'. It distinguishes itself from sibling tools like selectOption by explicitly naming the group type, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for radio/checkbox groups, explains radio vs. checkbox behavior, and directs users to analyzePage output for available options, implying a prerequisite. However, it does not explicitly name alternatives or state when not to use it, though the group type implicitly excludes dropdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output fields (url/name/isMain and active frame) and the purpose of discovering cross-origin iframes, but it does not explicitly state that the operation is read-only or describe potential side effects (e.g., whether it modifies the page or returns an empty list). The verb 'list' implies a safe read, but more explicit behavioral disclosure would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly concise and front-loaded. The first sentence states the core functionality and output fields; the second gives usage context and a pointer to a sibling tool. Every sentence earns its place 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?
For a zero-parameter, no-output-schema tool, the description is complete: it specifies what is returned (frames with url/name/isMain, plus active frame), the use case (discovering cross-origin iframes), and a transition to the relevant sibling tool (switchFrame). No significant gaps remain for an agent to know when and how to invoke this tool.
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 the baseline is 4. The description adds no parameter-specific detail because none exist, and the schema is empty, leaving no ambiguity. It fully covers the minimal parameter semantics 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 tool lists all frames (main and iframes) on the current page with specific fields (url/name/isMain) and includes the active frame. The verb 'List' and resource 'frames' are specific, and the mention of 'then switchFrame into one' distinguishes it from the sibling tool switchFrame.
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 provides an explicit use case: 'Use to discover cross-origin iframes (e.g. app.example.com), then switchFrame into one.' It also implicitly names the alternative (switchFrame) and the scenario where this tool is appropriate, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the returned data (URLs, titles, active status) and the tab index for use with switchTab. It also disambiguates that programmatically opened tabs are included, which is useful context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and followed by relevant usage context and a note on the return value. Every sentence earns its place with no filler.
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?
For a simple read-only listing tool with no parameters and no output schema, the description is complete. It states what is listed, the data fields included, and how the result relates to another tool (switchTab). No critical information is missing for the agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific information, but none is needed. The baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all open browser tabs with their URLs, titles, and active status.' It uses a specific verb ('list') and resource ('browser tabs'), and it distinguishes itself by noting it includes tabs opened via window.open/target='_blank', which sets it apart from any sibling that might only handle manually opened tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Use this to see all tabs opened manually or via window.open/target='_blank'.' It gives an explicit intended use case, but it does not mention alternative tools (like switchTab) or exclude scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses that the tool returns recorded actions and that it does not save the scenario, which is important behavioral context. It could further explain whether the recording buffer is cleared, but the core behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the action, and provides a clear usage hint without unnecessary words.
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?
For a tool with no parameters and no output schema, the description sufficiently covers purpose, behavior, and relationship to saveScenario, making it complete.
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 there is a baseline score of 4. The description doesn't need to elaborate on parameter details, and the empty schema confirms this.
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 stops recording and returns recorded actions, which is a specific verb+resource combination that distinguishes it from sibling tools like startRecording and saveScenario.
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?
It explicitly advises using this to review actions before saving with saveScenario, and clarifies it does not save the scenario, giving clear alternatives and exclusions.
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:

[![chrometools-mcp MCP server](https://glama.ai/mcp/servers/docentovich/chrometools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/docentovich/chrometools-mcp)

Score Badge

Copy to your README.md:

[![chrometools-mcp MCP server](https://glama.ai/mcp/servers/docentovich/chrometools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/docentovich/chrometools-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/docentovich/chrometools-mcp'

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