boond_expenses_get

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get an expense report' implies a read-only operation but adds nothing beyond what the tool name already signals — no response format, not-found behavior, or related expense-report endpoints are mentioned.

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?

One short sentence with zero filler; the verb, object, and identification method are all front-loaded. Every word earns its place, and the meaning cannot be conveyed more efficiently.

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?

For a one-parameter get-by-ID tool this is close to adequate for invocation. However, with no output schema and no annotations, the agent cannot anticipate the response shape or error behavior, and no guidance is given on where the ID originates. It is minimally viable but not complete.

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 should compensate for the undocumented `id` parameter. The phrase 'by ID' merely restates the parameter's role and adds no format, source, or relationship information (e.g., that the ID comes from boond_expenses_search). No meaning beyond the schema is contributed.

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 uses a specific verb ('get'), names the resource ('expense report'), and specifies the lookup key ('by ID'). Among the many siblings (boond_expenses_search, boond_expenses_create, boond_expenses_update), this unambiguously identifies the retrieve-by-identifier variant.

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 'by ID' clause implies the tool is used when an identifier is already known, and the sibling naming convention suggests boond_expenses_search for finding IDs. However, the description never explicitly contrasts the two or states when not to use this tool, leaving the routing decision to inference.

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