Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose side effects and safety. It mentions the analysis techniques but not that the tool renders a page, may write files via outputDir, or whether it's read-only. Missing information about navigation or resource consumption.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is reasonably concise and front-loads the main purpose. It includes a few extra words like 'for coding agents' but is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 19 parameters and no output schema, the description is too brief. It doesn't explain the output format, return value, or workflow, leaving the agent with insufficient context for a complex tool. The parameter schema helps but doesn't fill the output gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning about parameters, and only indirectly hints at sampling and diffs without referencing specific parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes page motion, specifying the methods (keyframes, CSS animations, pixel diffs, contact sheet). This is a specific verb+resource combination, but it doesn't explicitly distinguish from the sibling capture_motion, so not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 vs alternatives. It doesn't mention use cases, exclusions, or refer to sibling tools like capture_motion or capture_page. The only context is implied by the parameter names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full disclosure burden. It mentions Playwright video and motion evidence, but does not describe output behavior, file-saving side effects, default duration/video embedding, or safety implications. It is not misleading, but it is sparse for a non-trivial capture tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One tightly written sentence front-loads the action, object, and use condition. No filler, no redundancy, and it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool has 15 parameters and no output schema, the schema itself is rich (100% coverage) and includes output hints such as includeVideo embedding WebM in the MCP response. The description establishes the use case succinctly; together with the schema, this is sufficient for an agent to select and invoke the tool, though the prose alone would be incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 no parameter-specific semantics beyond conceptual triggers like 'animations' and 'scrolling,' which lightly echo scrollDuringCapture and related fields. The schema already documents all parameters thoroughly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb ('Record') and a clear resource ('short rendered page motion evidence with Playwright video'), with explicit scope ('when animations, transitions, scrolling, or dynamic media matter'). This distinguishes it from static tools like capture_page and other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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: 'when animations, transitions, scrolling, or dynamic media matter.' It stops short of naming alternatives or stating when not to use it, so it misses the full 5 criterion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 mentions Playwright but does not disclose side effects like file saving, network requests, or that it renders JavaScript. The tool's full behavioral profile (output format, potential state changes) is left unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action and key context. It is concise with no redundant information, making optimal use of its limited length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter count (14), no output schema, and no annotations, the description is too thin to be contextually complete. It omits return format, output location, and behavioral side effects, and does not adequately differentiate from sibling tools like read_url or capture_motion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of the 14 parameters with descriptions, so the baseline is 3. The description adds no parameter-specific semantics beyond the schema, but no compensation is needed given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Capture') and resource ('rendered page evidence') and notes a use case ('when visual layout, screenshots, or browser state matter'), which reasonably distinguishes it from siblings like read_url. However, it could more explicitly mention screenshots as the primary output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'when visual layout, screenshots, or browser state matter' provides clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the context is sufficient for a single-sentence description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full responsibility for disclosing behavioral traits. It only states the target is a 'public website' and that use should be legitimate, but it does not disclose that the tool actively downloads assets, generates numerous network requests, or may strain the target server. It also does not mention rate limits, robots.txt considerations, or the fact that the tool may produce a large local artifact bundle.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary purpose, and includes a concise list of deliverable types. The second sentence adds an important usage restriction without fluff. Every word contributes to defining the tool's scope and boundary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 20 parameters and no output schema, yet the description only provides a high-level summary of outputs. It does not state what the return format is (e.g., paths to saved files, an index, a summary) or mention side-effect behaviors such as asset downloading and network load. Because the schema covers parameters well, the description is adequate but not fully complete for an operation of this scale.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 20 parameters have individual descriptions in the schema with defaults and ranges, so schema coverage is 100%. The description adds no parameter-specific details, but the schema already provides complete guidance. This meets the baseline for high coverage and does not need further compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action 'Generate a clone-ready evidence bundle for a public website' and enumerates concrete artifact categories (screenshots, design tokens, assets, page topology, behaviors, component specs). This clearly distinguishes it from sibling tools like read_url or capture_page, which focus on simpler retrieval. The verb and resource are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear acceptable-use boundary: 'Use only for legitimate site migration, learning, or authorized rebuilds.' This gives a when-to-use context but does not compare against any sibling tools or mention when a simpler alternative (e.g., capture_page) would be more appropriate. It lacks explicit exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description must disclose behavior. It lists check areas but fails to describe output format, side effects, or prerequisites, leaving behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficiently communicates the tool's purpose with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sparse description for a tool that checks multiple subsystems; no output details or guidance on interpreting results, especially without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema fully documents the checkBrowserLaunch parameter with description. The tool description doesn't add additional semantics beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it checks local runtime, security policy, remote readers, and Playwright availability. Distinguishes from sibling web tools by focusing on environment diagnostics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to run this diagnostic tool versus the web task siblings. Absence of explicit context leaves the agent to infer appropriate timing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of behavioral disclosure. It adds useful context by mentioning direct fetch first and optional remote readers only when configured, but it does not cover error handling, redirects, or the default private-network blocking (though the schema covers the latter).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single succinct sentence that front-loads the core purpose and key behavior. Every word earns its place, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, output format (normalized text), and fallback behavior. It lacks explicit guidance on choosing among sibling tools and does not discuss error outcomes, but given the simple scope and full schema coverage, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters are described in the schema (100% coverage), so the description correctly avoids repeating parameter details. It adds no extra semantic value beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a public http(s) URL as normalized text, which is a specific verb+resource+output. It distinguishes from sibling tools like capture_page by emphasizing text extraction rather than visual capture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 siblings such as capture_page or clone_website. It only mentions the fetch approach, with no explicit alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not explain whether the tool performs any web access, returns a recommendation, has side effects, or what 'cheapest' means (cost, latency, resources). This is a significant gap for a non-trivial routing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no fluff. Every word contributes to the purpose ('choose', 'cheapest', 'reliable', 'before reading/browsing/screenshots'), 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a router tool with no output schema and no annotations, the description is incomplete. It fails to explain what 'route' means, what the tool returns, or how it selects the cheapest reliable route. The minimal description leaves the agent guessing about the tool's behavior and return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 both parameters. The description adds no extra meaning about how 'task' and 'url' influence the routing decision, leaving it at the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Choose') and resource ('cheapest reliable web perception route'), clearly distinguishing this as a router from sibling tools that perform actual perception actions. It also gives context ('before reading, browsing, or using screenshots') and aligns with the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'before reading, browsing, or using screenshots.' This provides clear context for its position in the workflow, though it does not mention exclusions or alternative tools to use instead. No 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.