check_leave_balance

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description indicates a read operation (returns balance), which implies a non-mutating behavior distinct from siblings like apply/approve/reject/cancel. However, it doesn't disclose details like whether employees with no leave type assigned return zero or are omitted, what happens for invalid employee IDs, or whether the response includes all leave types or only those with remaining balance.

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 is a single, efficient sentence with zero wasted words. It front-loads the verb ('Return') and clearly states the object and scope. Every word contributes meaning.

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?

The tool is simple: one obvious parameter, no output schema, no nested objects, and no annotations. The description adequately captures the core function. However, with no annotations and no output schema, the description could benefit from mentioning the return format (e.g., leave type to remaining days mapping) or edge cases. The simplicity of the tool keeps the gap moderate.

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 with a single parameter the description does not compensate. However, there's only one parameter (employee_id) whose meaning is fairly self-evident from its name—it identifies which employee's balance to check. The parameter semantics are inherent in the schema field name, and a single obvious parameter reduces the need for elaboration. Baseline 3 is appropriate since there's minimal ambiguity.

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 clearly states the verb+resource: 'Return the remaining balance for each leave type for an employee.' It's a read-only query tool distinct from siblings like apply_for_leave, approve_leave, reject_leave, cancel_leave (which are all mutations) and list_pending_requests (which lists requests rather than balances). The purpose is unambiguous and differentiates well from siblings.

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 implies usage context—it's a leave balance query—but doesn't explicitly state when to use it vs alternatives or any exclusions. It doesn't mention that it requires an employee_id, nor does it suggest this is for checking before applying for leave. Some context is implicit given the sibling names, but no explicit guidance on choosing between tools is provided.

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