Export page as PDF

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

Annotations already indicate readOnly=false, destructiveHint=true, and openWorldHint=true. Beyond those, the description adds valuable context: the artifact is private and local, files survive closing, and print layout may differ from screen layout. This gives the agent important expectations about side effects and output fidelity without contradicting the annotations.

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 sentences, each earning its place: the first states the core operation and outputs, the second notes persistence, and the third warns about layout fidelity. The most important information is front-loaded, and there is no filler.

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?

With no output schema, the description properly explains the return values: path, SHA-256, and source URL. It also covers persistence and the layout caveat. Missing details are limited to parameter defaults or behavior for format/landscape, which are partially inferable from the enum schema.

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 only 33%, with only session_id documented in the schema. The description does not mention format or landscape at all, so the agent gets no guidance on how to choose A4 vs Letter or when to set landscape. With low schema coverage, the description needed to compensate for these parameters but did not.

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 uses a specific verb ('Print') and a specific resource ('the active page ... into a private local PDF artifact'), and clearly states what is returned: path, SHA-256, and source URL. This clearly distinguishes it from sibling tools like tab_capture or tab_snapshot, which are more likely screenshots or structured captures.

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 makes the basic use case clear: export the active page to a PDF. However, it does not explicitly name alternatives or say when not to use this tool, even though siblings like tab_snapshot, tab_extract, and tab_capture exist. The guidance about print layout differing from the screen is useful but is more behavioral than usage-routing.

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