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

With no annotations, the description carries the burden, and it is largely transparent: it discloses that the cookie is non-HttpOnly, limited to the current document origin, defaults to path=/ and 365-day expiry, and returns { set, name, cookie }. It does not spell out overwrite behavior or failure states, but it covers the main behavioral constraints and side effects.

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 and front-loaded: purpose first, then use case, then limitation, then defaults and return. It is a single paragraph with no filler, though it repeats some defaults already present in the schema.

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?

Given no output schema and no annotations, the description is complete: it covers purpose, use case, key limitations, defaults, and the return shape. It also mentions browser auto-detection and the unavailable CDP route, so an agent has enough context to call it safely and correctly.

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?

The schema already provides 100% parameter descriptions, so the baseline is 3. The description adds useful context beyond those descriptions: the cookie is applied to the current page origin via document.cookie, cannot be HttpOnly/Secure-only, and the browser is auto-detected. This clarifies how name/value/path and days behave in practice.

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 action — 'Set a cookie on the CURRENT page origin in the device browser' — along with the mechanism (document.cookie) and a concrete use case (seed auth/session state). The current-origin limitation and explicit browser targets differentiate it from cookie-reading/clearing siblings such as webpage_clear_cookies, ios_safari_cookies, and android_devtools_cookies.

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?

It explicitly says when to use it ('Use to seed auth/session state before a flow') and explains when it is not appropriate: it cannot set HttpOnly/Secure-only or cross-domain cookies, and notes that the alternative CDP Network domain is not exposed on iOS. This gives an agent enough conditional guidance to choose or reject the tool.

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