Get leave requests

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

With no annotations provided, the description carries the full behavioral burden, and it delivers substantial detail: automatic paging, combined results, a 60-day range limit validated before calling Keka, default date behavior, and preservation of the numeric status field without guessed labels. It does not cover auth, rate limits, or errors, but it is far more transparent than a minimal fetch description.

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?

Three sentences, each earning its place: the first states the core purpose, the second covers paging behavior, and the third explains date constraints and status handling. The description is front-loaded and contains no filler.

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 read-oriented list tool with four optional parameters and full schema coverage, the description provides the key call-time context: paging, range validation, defaults, and status semantics. The lack of an output schema is not fully compensated because the agent does not learn what fields each leave request contains, but the operational details needed to invoke it correctly are present.

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 coverage is 100%, so the baseline is 3, but the description adds meaningful extra semantics by disclosing the 60-day maximum range and the automatic paging behavior that affects how from/to and pageSize are used. It does not add much for employeeIds, but the schema already documents those parameters fully.

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 ('Fetch') plus a clear resource ('leave requests across the organization from Keka for a date range'). This immediately distinguishes it from sibling tools like get_timesheet_entries, get_employees, and get_holidays, and it does not merely restate the title.

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 clearly implies this is the tool for org-wide leave requests over a date range, but it never explicitly states when to prefer it over alternatives or when not to use it. There is no explicit alternative routing or exclusion guidance, so usage is mostly inferred from the resource name.

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