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

With no annotations provided, the description carries the burden of disclosing behavior. It transparently states the order is real, payment is cash upon pickup/delivery, and that the server resolves actual products and never invents prices. It also mentions delivery conditions. However, it omits potential side effects like cancellation or order confirmation details.

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 bilingual but still brief and to the point. It packs essential information into two short paragraphs without redundancy. Every sentence adds value, covering the action, payment method, key input requirements, and delivery constraints.

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?

Given there is no output schema, the description does not explain what the tool returns (e.g., confirmation, order ID) or how errors are handled (e.g., item unavailable). While it sets expectations for the input and payment, it lacks information about the response or failure modes, leaving some incompleteness for a full user interaction.

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 provides descriptions for most parameters (86% coverage), and the tool description adds practical guidance on what values to pass (e.g., item names from ver_negocio, cash payment, delivery address requirement). The 'cantidad' parameter lacks a description in the schema, but the description doesn't clarify it either, so a minor gap exists.

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 tool's function: placing a real food/product order paid in cash, with explicit pickup or delivery options. It distinguishes itself from sibling tools like reservations or appointments by focusing on food ordering.

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 implicitly indicates when to use this tool (for food orders) and provides specific instructions such as sending item names exactly as shown in ver_negocio and the requirement for an address for delivery. However, it does not explicitly state when not to use it or contrast with alternatives.

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