emulate

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

Annotations include readOnlyHint: false, which implies this tool may have side effects, but the description doesn't elaborate on the nature of those effects (e.g., whether emulation is temporary, whether it affects the page state persistently, or if it requires specific permissions). The parameter descriptions hint at persistence (e.g., extraHttpHeaders persist across navigations), but the tool-level description doesn't summarize behavior beyond 'emulates'. It's not contradictory, but it doesn't add significant behavioral context beyond what parameters already state.

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 concise but very generic. It's not verbose or wasteful, but it's also not front-loaded with the most important info. It's acceptable, but could be more structured by listing the emulation categories (e.g., viewport, user agent, color scheme, etc.).

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 has 8 parameters, a required pageId, and no output schema. The description doesn't explain return values or side effects beyond what parameters imply. Given the number of parameters, a more comprehensive overview of what emulation types are supported and how they interact would be helpful. The schema is rich, but the tool description alone doesn't give an agent a complete picture of how to use these parameters together. There's no mention of clearing overrides or default behavior beyond parameter hints.

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 each parameter is described. The description of the tool itself adds little beyond what's in the schema. The parameter descriptions are quite detailed (e.g., viewport format, enums for network conditions), so the schema does most of the heavy lifting. The tool description doesn't add extra meaning beyond 'these are the emulation options', so a baseline 3 is appropriate.

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 says 'Emulates various features on the target page', which is a clear verb+resource but lacks specificity about which features. It doesn't differentiate from siblings like resize_page (which is more specific) or navigate_page. However, the parameter list makes it clear it covers multiple emulation types (viewport, user agent, color scheme, etc.), so the purpose is reasonably clear, but could be more explicit about the range of emulation features.

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. For example, it doesn't mention that resize_page might be more appropriate for simple viewport changes, or that evaluate_script could be used for setting user agents. It only says 'emulates various features' without context on selection. There is no when/when-not guidance.

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