set_cookie

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. The verb 'Set' implies a state-mutating write operation, and 'on the current page' adds a scoping constraint. However, it fails to disclose whether existing cookies with the same name are overwritten, whether the cookie is session-only or persistent, or whether any domain/host restrictions apply.

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?

A single front-loaded sentence with zero filler words; every word contributes meaning. It is somewhat under-sized relative to the information burden it carries, but as pure conciseness it 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?

The tool has 4 parameters, no annotations, no output schema, and no parameter descriptions, yet the description provides only one contextual detail: that the cookie applies to the current page. It omits overwrite behavior, persistence semantics, domain handling, and any relationship with sibling cookie tools. This is minimally more than a tautology.

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 for the undocumented parameters. It mentions none of name, value, path, or domain — no clarification of required fields, defaults beyond the schema's bare 'default: /', or encoding concerns for the value. No meaning is added beyond the schema's raw type declarations.

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 ('Set') and resource ('a cookie') with a location scoping ('on the current page'). It distinguishes cleanly from sibling tools: delete_cookie/get_cookies differ by verb, and set_local_storage/set_session_storage differ by resource type.

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?

No guidance is given about when to use this tool versus alternatives. It does not mention that get_cookies or delete_cookie are companions for inspecting/removing cookies, nor any exclusions or preconditions such as needing a page to be loaded first. The agent receives zero routing help.

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