browser_broadcast

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

With no annotations, the description must carry the full behavioral burden, and it does disclose useful traits: parallel execution, automatic per-tab tabId injection, per-tab results keyed by tab id, and that timeout is per-tab. It says nothing about partial failure handling, concurrency limits, or whether mutating commands are safe to broadcast, so the safety profile remains unspecified.

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?

Three short sections, front-loaded with the core behavior before the argument list. Every sentence earns its place, and the arg notes are justified by the 0% schema coverage rather than 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?

For a tool with a nested free-form command object, no output schema, and no annotations, the description covers the essentials: what runs in parallel, how tabId is injected, and the shape of the result. The remaining hole is failure/partial-success semantics, which for a broadcast tool is the one thing an agent would most want to know.

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%, so the description has to compensate, and it largely does: tab_ids are identified as the target tabs, timeout as per-tab seconds, and the free-form command object is illustrated with concrete examples ({"action": "pageInfo"}). This adds meaning the schema cannot, since command is an untyped object with additionalProperties and no examples of its own.

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?

States a specific verb and resource: fire the same command at every listed tab in parallel. An agent can tell generally what it does, but the description never distinguishes it from overlapping siblings like browser_parallel or browser_batch, so the routing decision is left ambiguous.

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?

Usage is only implied by the purpose sentence: use it when you want the same command applied across many tabs. There is no explicit when-not guidance and no mention of the closest alternatives (browser_parallel, browser_batch), which is a real gap in a sibling set this dense.

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