Send Raw CDP command

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. It explicitly discloses two behavioral traits: there is no method allowlist (any CDP method can be sent) and no response sanitization (raw responses returned). It also clarifies a prerequisite: targetSessionId references a child target previously attached within this Raw CDP session. This goes beyond the schema and gives important transparency for an unrestricted command 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 two sentences, immediately stating the core function and the one non-obvious parameter usage. There is no filler, and every word adds value. It is front-loaded with the primary purpose, making it easy for an agent to quickly understand the tool.

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 is largely complete for a raw low-level CDP tool. It explains the unrestricted nature, the child-target parameter, and the session context. There is no output schema, so the description does not detail return values, but 'no response sanitization' implies the raw CDP response is returned. Given the complexity and the sibling tools (e.g., browser_cdp_attach), the description provides enough context for an agent to invoke it correctly, though it could briefly mention the source of sessionId.

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 must compensate. It adds meaning for targetSessionId ('use for a child target previously attached') and implies params is JSON via 'JSON params'. However, sessionId and method are not explained beyond their names and the tool title. The description does not fully elucidate all four parameters, so it only partially compensates for the lack of schema 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's function: 'Send any CDP method and JSON params'. It specifies the verb (send) and resource (CDP command), and explicitly differentiates itself from sibling tools by noting there is 'no method allowlist or response sanitization', marking it as the raw/low-level option in the browser_* family.

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 about when to use the tool: for raw CDP commands that bypass normal restrictions, and specifically instructs to use targetSessionId for child targets attached within the current Raw CDP session. It does not explicitly list alternatives or say when not to use it, but the 'without a method allowlist or response sanitization' phrasing implies it is for cases outside the curated sibling tools.

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