Export Session

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

With no annotations, the description fully carries the burden and does so well: it discloses the destructive side effect on the user's browser (importing REPLACES existing toom.de cookies, including basket/market choice), the security profile (anonymous token, no login, keep private), and the no-op-without-confirm behavior. This is exactly the behavioral context annotations would otherwise provide.

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?

Purpose is front-loaded in the first sentence, followed by security and confirmation guidance. It is slightly verbose with parenthetical asides (cookie-manager example, 'no login, but still a token'), but every sentence carries actionable information rather than 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?

Output schema exists, so return values need no explanation. The description covers the mutation's side effects, privacy constraints, and the confirmation gate, which is everything an agent needs to invoke this safely. Nothing material is missing.

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 coverage is 0%, so the description must compensate. It explains 'confirm' thoroughly (default false = nothing written; must be true after user agreement), but 'market' is only implied by 'a market's basket' and never explicitly described as selecting which market's session. Strong on one parameter, partial on the other.

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?

States a specific verb (write/export) applied to a specific resource (the session cookies of a market's basket) and gives the intent ('to look at that basket in your own browser'), which implicitly separates it from view_basket. An agent can tell what this does without opening the schema.

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 gives an explicit precondition ('Ask the user first') and a precise two-step workflow: without confirm=True nothing is written, call again with confirm=True only after explicit agreement. It does not name alternative siblings (e.g. view_basket) for in-server inspection, so it stops short of a full when/when-not routing.

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