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

Annotations already declare readOnly, openWorld and non-destructive, so the safety profile is covered; the description adds the real behavioral substance: the 41 CFR 301-11.20 75% M&IE rule on first/last day, cross-month and cross-fiscal-year proration, the fy-inference default, and the fact that ambiguous cities return candidate rate areas rather than an estimate. Only gap is no statement about rate resolution failures or numeric precision.

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?

Front-loads the one-line purpose, then cost components, then per-parameter rules, then the formula. Nearly every sentence earns its place, though the 'Do not add separate monthly mie_total or grand_total values' instruction is aggregation guidance aimed at the caller rather than a tool behavior and reads as a slight detour.

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?

An output schema exists so return values need no prose, yet the description still flags the one non-obvious return case (candidate rate areas instead of an estimate). With six parameters, an open-world read and no schema descriptions, the formula block and month/fiscal-year interaction rules close every remaining gap.

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 description coverage is 0%, so the description carries the full burden and does: travel_month format is pinned to a 3-letter abbreviation with its default behavior, fiscal_year gets both a definition and an inference rule, county gets a selection rationale, and num_nights is bounded 1-365. city/state are self-evident and correctly left 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?

States a specific verb and resource — estimate total per diem cost (lodging + M&IE) for a trip — and immediately scopes it against siblings by excluding airfare and ground transportation and by naming lookup_city_perdiem for rate-area selection. An agent can distinguish it from lookup_state_rates or get_mie_breakdown without opening any schema.

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?

Gives explicit conditions for each optional parameter: fiscal_year 'Pass it for a trip that already happened', travel_month omitted means max monthly lodging rate for a conservative IGCE, county for multi-county cities. It also states the failure path — no estimate when the city is ambiguous or unresolved — and names the alternative tool for county resolution.

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