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

Annotations establish readOnlyHint/idempotentHint/openWorldHint=false, but the description adds behavior the annotations cannot carry: an empty account yields a first-run welcome, otherwise the next item in the user's own order with what governs it; the session token must be echoed on later calls; and the stark instruction not to invent a next step because that substitutes the agent's priority for the user's. That is genuine behavioral disclosure, not restatement.

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?

It is a single dense paragraph, but it is front-loaded with the purpose before the routing rules and each clause carries a distinct instruction. The main cost is some overlap between the body text and the `venture` schema description, which repeats the 'never pick for them' rule almost verbatim.

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?

There is no output schema, and the description compensates by describing what comes back (facts from saved work to reflect in one's own words, a plain statement when nothing is queued, the first-run welcome on an empty account). Combined with zero required parameters and full annotation coverage, nothing an agent needs to call this correctly 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 100%, so the 3 baseline applies automatically, but the description goes further by explaining the intent behind `venture` (only what the human named verbatim, with worked examples) and the reason it must never be chosen for them. It also states 'there is no workspace argument' and that the session token is passed back on later calls, adding operational meaning beyond the field docs.

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 opening sentence states a concrete verb+resource: recalling where the person left off from their own saved work, naming the three things returned (what they were working on, what they decided, what is next). It explicitly distinguishes itself from the sibling ask_unl, which 'serves their decisions on any turn by itself', so the agent can route without opening either 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 explicit trigger conditions ('call this when they ask where they left off, what they were working on or already decided, or to carry on with their project') and an explicit non-trigger ('Unl is already on without this call'). It also maps the colloquial phrase 'connect to unl' onto this tool, which is exactly the kind of routing guidance an agent needs.

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