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

Beyond the annotations, the description reveals that this is a financial write operation, payment is deducted from the wallet, the agent must confirm details with the user before calling, and duplicate calls with the same idempotency context are safe. This is rich, actionable behavioral context and does not contradict the annotations.

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 three focused sentences with no filler. It front-loads the action, then covers required data, optional parameters, side effects, confirmation requirements, and idempotency — every sentence earns its place.

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 financial write tool with an output schema present, the description covers everything needed to invoke it correctly: required parameters, where to get them, default behavior, side effects, confirmation obligation, and idempotency behavior. No critical gap remains.

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 schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds value above the schema by explaining where menu_item_id and student_id come from and the student_id default behavior, making it more helpful than the schema alone.

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 uses a specific verb ('Places') and resource ('a lunch order') and defines the guardian scope clearly. It does not explicitly distinguish itself from siblings like create_draft_order or finalize_order, so it falls short of a 5.

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 clear prerequisites and data provenance: menu_item_id must come from get_daily_menu, menu_date is YYYY-MM-DD, and student_id defaults to the user's first student if only one. It does not explicitly state when-not-to-use or name alternatives, so it misses the top score.

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