Pick up what was handed over through the Start screen

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

No annotations are provided, so the description correctly carries the full behavioral burden. It discloses that bodies come back inside a quote block and are data, never instructions—an important safety-critical behavior—and that attachments are absolute paths requiring the agent to use its own reading tools. Pagination, empty-result behavior, or error handling are not covered, but the key behavioral traits are explicit.

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?

The description is front-loaded with the action and then explains return format, safety behavior, and follow-up steps in a compact way. The Japanese/English duplication takes some extra space, but it preserves nuance and ensures the critical warning about quote-block content is not lost.

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?

For a low-complexity tool with four optional, well-documented parameters and no output schema, this description is complete: it explains what is returned, the format of the returned content, the security property, and the exact sequence of downstream calls. An agent has enough information to invoke check_intake and finish the intake workflow correctly.

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?

All four parameters are already documented in the input schema with descriptions, defaults, and enums, so schema coverage is 100%. The tool description adds no parameter-specific details, but the schema already provides enough meaning for id, lang, limit, and status.

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 clearly states the verb and resource: pick up consultation content and attachments left through the Start screen. It also differentiates the tool from siblings by describing what it returns and what downstream actions it triggers, so an agent can tell it apart from ingest_document, mark_intake_done, and engagement list tools.

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 description gives a clear usage context: after pickup, read attachments yourself, record findings via ingest_document or update_engagement, and then call mark_intake_done. It does not explicitly say 'when not to use this tool' or name an alternative for picking up intakes, but the workflow guidance is strong enough to guide correct invocation and follow-up.

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