Control Google Chrome

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

Annotations already indicate readOnlyHint=false (mutating) and destructiveHint=false (not destructive). The description adds value by mentioning that actions target the 'focused Chrome window' and that this is part of a reliable browsing workflow. However, it does not disclose edge cases (e.g., behavior when windowHandle is invalid, tab limits, or permission requirements) beyond what annotations provide.

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?

Two sentences with no filler: the first clearly states purpose, the second provides actionable usage advice. Every word earns its place, and important information is front-loaded.

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 tool with 4 parameters, no output schema, and no parameter descriptions, the description is too sparse. It omits return values, error handling, prerequisites (e.g., 'Chrome must be running'), and behavior for unsupported actions. While the workflow hint helps, it does not cover the full complexity of browser control.

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 0%, placing full burden on the description to explain parameters. The description only mentions 'URL' and 'navigation/tab shortcuts' in passing, failing to document 'profile', 'windowHandle', or the specific 'action' enum values. This leaves the agent with only parameter names and types, which is insufficient for correct invocation.

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 opens URLs or sends navigation/tab shortcuts to the focused Chrome window. It distinguishes from sibling tools like 'open_url' (likely generic) and 'list_windows'/'window_control' (setup steps) by focusing on Chrome control. The specific verb+resource combination ('Open a URL or send navigation/tab shortcuts to the focused Chrome window') leaves no ambiguity.

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 explicit workflow guidance: 'For reliable GUI browsing, list windows, focus Chrome, act, then capture a screenshot.' This tells the agent when and how to use the tool in sequence. However, it does not explicitly state when NOT to use it (e.g., if Chrome is not running) or compare to alternatives like 'open_url' for non-focused scenarios.

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