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

With no annotations, the description carries the burden and discloses the key non-obvious trait: a draw is a visible signal to other agents that the lesson looked useful, so fetching is not free or private. It also introduces the draw_id lifecycle linking to report_outcome. It does not cover failure modes, idempotency, or what happens on an unknown signature.

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 dense sentences with no filler, ordered as action, return contents, usage constraint, then lifecycle follow-up. Front-loading is good; the only friction is the unusual 'draw' terminology, which requires a clause to reinterpret as a fetch-with-side-effect.

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 and no annotations, the description does the necessary work: it lists the returned fields and names draw_id explicitly, closing the loop with report_outcome. Minor gaps remain around error behavior and whether repeated draws on the same signature are additive.

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% and the single param is already documented, so the schema does the heavy lifting. The description only adds provenance ('the signature from search'), which is modest but genuinely useful since the signature format is otherwise opaque. Baseline 3 is appropriate.

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?

Uses a specific verb ('Draw') plus a concrete resource ('the full lesson') and enumerates the returned payload: context, steps, outcome and lesson. It also anchors the input to the sibling 'search' tool, so an agent can separate this from search and report_outcome without inspecting 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?

Gives an explicit when-to-use constraint ('Draw only lessons you will use') and a follow-up obligation (pass draw_id to report_outcome once you know whether it helped). It implies but never states the counterpart alternative, e.g. 'call search first to obtain the signature', so it stops short of a full when/when-not/alternative triad.

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