grubhub_timepicker

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

No annotations are present, so the description carries the full burden. It usefully discloses behavioral traits: it returns slots up to 7 days out, groups slots by date, uses full timestamps with the restaurant's real UTC offset so callers don't need to handle DST, and notes the upstream computes only one location_mode per call. It does not cover errors or pagination, but it provides far more behavioral context than most similar tools.

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?

Although the description is fairly long, every sentence earns its place: the core verb/resource, the return value scope, the sibling contrast, the timezone/DST behavior, and the location_mode semantics. It is front-loaded with purpose and is organized logically. No filler or repetition is present.

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 five parameters, no annotations, and no output schema, the description is quite complete. It describes the return content (future delivery or pickup slots, grouped by date, full timestamps with UTC offset) and the calling constraint (one mode per call). Minor gaps such as pagination, error behavior, or what happens when no slots are available prevent a perfect score, but an agent can reasonably call the tool and understand its result.

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 already 100%, so the baseline is 3. The description adds real value beyond the schema by spelling out the exact meaning of location_mode ('DELIVERY returns delivery slots only; PICKUP returns pickup slots only') and by restating the days range with the default of 7. This extra parameter-level guidance is meaningful, though restaurant_id and coordinates are not further clarified because they are self-evident.

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 opens with a specific verb-and-resource statement: 'Get one Grubhub restaurant's future orderable time-slot calendar.' It also explicitly contrasts this tool with grubhub_availability, making it clear that this returns the full future slot calendar while grubhub_availability only gives current availability plus one next time. That sibling differentiation makes the purpose unmistakable.

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 explicit when-to-use guidance: a caller needs this when they must build a date-and-time picker from a full future slot calendar. It names the alternative (grubhub_availability) and explains its narrower scope, and it further specifies the location_mode difference. No inference is required to choose between siblings.

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