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

With no annotations, the description carries the full behavioral load and does so: 75%/100% M&IE split, daily rate selection across seasonal and fiscal-year changes, lodging capped at the GSA nightly limit with excess reported as 'overage' and excluded from the payable total, and null totals when lodging cost is omitted. It also discloses that responses carry a calculation version and source fingerprint for auditing.

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-loaded with a one-line purpose, then organized into trip description, calculation rules, and notes — an agent can skim the headings. There is some duplication with the schema (ZIP/destination ID guidance, boundary-date rule), but nearly every bullet carries operational information.

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?

No output schema exists, so the description must describe return values, and it does: daily breakdown, trip totals, overage, null-total condition, and audit metadata. For a 3-parameter calculator this leaves nothing an agent needs before calling it.

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 100%, so the baseline is 3, but the description adds interpretive weight: it explains that a stop's location is the TDY locality rather than the hotel, clarifies who owns a shared boundary date, and states the downstream consequence of omitting lodging_cost_per_night. Only verification_url goes unmentioned.

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 first line states a specific verb and resource — 'Calculate a GSA CONUS trip per diem entitlement' — and the following paragraph scopes it to multi-stop CONUS trips that return a daily breakdown plus trip totals. That verb-plus-trip-scope framing distinguishes it from the many rate-lookup siblings (get_gsa_perdiem_by_zipcode, get_mie_breakdowns) without needing to name them.

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?

Extensive rules on how to structure input: stops in travel order, inclusive dates, TDY locality vs hotel location, transition-date ownership, and the FTR 301-11.21 precondition for meal deductions. It never explicitly says when to prefer this over rate-lookup siblings, but the trip-level intent is clear context.

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