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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the output format (Markdown), size (about 2,000 words, capped at 12,000 chars), and exact content composition. This gives an agent a strong mental model of what to expect from the call.

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?

Two sentences deliver a complete picture: the first packs a dense but organized list of contents pigeonholed into a single read call, the second adds role and timing guidance. No filler words; every clause adds value.

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 a single parametercan No output schema, the description fully covers what an agent needs: the tool's scope, return format, content detail, and size limits. There are no ambiguous gaps for a tool of this complexity.

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 input schema already documents project_id as a UUID with 100% coverageandarameter semantics baseline is therefore 3. The description mentions 'project' generically but adds no new parameter-specific meaning beyond what the schema provides.

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 verb and resource: 'gives a chat client ... a whole TaScan project', followed by a precise list of included content (task lists, open decisions, last 5 cycles, receipts, total spend). This clearly distinguishes the tool from sibling read tools like tascan_get_project or tascan_list_tasks, which cover only subsets.

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?

The phrase 'Use it before asking a human to paste anything' provides a clear, practical when-to-use instruction. It implies this is the go-to tool for obtaining a full project digest, though it does not explicitly name alternatives or conditions for when a narrower tool would be preferred.

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