get_trip

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

With no annotations provided, the description carries the full burden and explicitly discloses a key behavioral trait: 'This tool never mutates trip state.' This directly assures the agent of no side effects. It does not cover errors, auth, or rate limits, but the primary read-only behavior is clearly stated, which is strong for a read tool.

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 consists of two short, purposeful sentences with zero fluff. It front-loads the action and resource, then adds the critical non-mutation invariant. Every word 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?

Given no annotations, no output schema, and 0% parameter descriptions, this brief description leaves key questions unresolved: the semantics of the optional version parameter, the exact response shape, and how 'available version numbers' are returned. For a simple read tool, some details can be inferred, but the version ambiguity makes it incomplete.

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 must compensate. It clarifies that trip_id is the identifier for the canonical trip, but the 'version' parameter is unexplained – likely to request a specific version, yet the description mentions 'available version numbers' as output, creating ambiguity about the parameter's role. This leaves a meaningful gap for a tool with only two parameters.

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 states a specific verb ('Read'), a precise resource ('canonical trip'), and an output aspect ('available version numbers'), and explicitly distinguishes itself from mutation siblings by asserting non-mutation. This makes it immediately clear what the tool does and how it differs from tools like apply_change_proposal or rollback_trip.

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?

There is no explicit guidance on when to use this tool versus alternatives such as list_trips, get_trip_context, or get_trip_audit. The description only implies that you use it to read the canonical trip, but offers no exclusion criteria or routing to siblings, leaving an agent to infer the appropriate context.

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