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, and it delivers richly. It discloses cross-platform behavioral differences (Android full CDP vs iOS WebKit dialect), the failure mode for Chrome-only domains on iOS (-32601), and the subtle trap that `*.enable` on iOS reports success without proving domain existence. It also states the scope boundary (browser only, not device/native apps). This goes far beyond what any annotation would typically 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?

The description is dense but well-organized: it opens with the core action, then scope, then usage guidance, then a clearly flagged iOS-specific warning. Every sentence carries substantive information. It is longer than average, but the length is justified by the genuinely complex cross-platform behavior that agents must know. The only slight deduction is that the iOS warning could be tightened, but the structure (with 'IMPORTANT, iOS:' as a clear signal) is effective.

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 raw-protocol escape-hatch tool with no output schema and no annotations, the description is remarkably complete. It covers what the tool does, when to use it, the scope boundary, platform differences, failure modes, and parameter semantics. The only thing not detailed is the exact reply format, but for a raw CDP command that is inherently dynamic and would be impossible to fully specify. The description gives an agent everything needed to invoke it correctly and avoid the documented pitfalls.

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 baseline is 3. The description adds meaningful semantics beyond the schema: it explains the `method` format with a concrete example ('Emulation.setGeolocationOverride'), clarifies that `params` is the command's parameter object, and notes that `params` can be omitted for commands that take none. It also explains the `udid` auto-detection of iOS vs Android. The only minor gap is that `pageId` and `socket` are not elaborated in the description, but the schema already covers them and the description's focus on the two most important parameters is reasonable.

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 ('Send a raw DevTools-protocol command'), a precise resource ('browser page on a device'), and the return behavior ('return its reply'). It explicitly frames itself as the escape hatch for capabilities no dedicated tool wraps, which distinguishes it from the many sibling tools that wrap specific DevTools features (e.g., android_devtools_evaluate, ios_safari_evaluate, webpage_screenshot). The scope boundary ('reaches web content only, never the device or native apps') further sharpens the purpose.

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 gives explicit when-to-use guidance: use it when no dedicated tool exists, and explicitly says 'Prefer a dedicated tool when one exists' with the reason (dedicated tools handle setup ordering, lifecycle, teardown). It also provides platform-specific usage warnings (iOS vs Android protocol differences) and a concrete error signature (-32601) to help agents recognize failure modes. This is exemplary routing guidance.

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