Breathe HR MCP by usefulapi

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, so the safety profile is known. The description adds real value beyond that: the request becomes an absence, the allowance is deducted, and the action is attributed to the 'API Employee' — concrete consequences of the destruction hint.

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 dense sentence front-loaded with the WRITE marker, followed by the endpoint. Every clause (effect, allowance deduction, attribution, path) earns its place with no padding.

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 single-parameter mutation with no output schema, the description covers purpose, side effects, and speaker attribution. It omits permission requirements and any reversibility note (e.g. can the approval be undone), which would complete the picture for a non-idempotent destructive write.

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% and the single parameter already documents its integer type and origin (from breathehr_list_leave_requests). The description only repeats the path placeholder, adding nothing beyond the schema. Baseline 3 applies.

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?

States a specific verb (approve) and resource (pending leave request), and goes further to describe the resulting state change: it converts to an absence deducted from the allowance. This clearly distinguishes it from siblings like reject_leave_request or get_leave_request.

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 word 'pending' implies a precondition, so an agent can infer this applies only to unapproved requests. However, it never explicitly names reject_leave_request as the alternative or states when not to use this tool, leaving routing to inference.

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

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

Annotations already declare non-idempotent, destructive, open-world writes, and the description reinforces this with "Each call creates a new request" plus genuinely new context: the request enters the account's approval workflow and the employee's approver is notified. It stops short of saying what happens on overlapping/duplicate leave or whether the write can be undone.

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?

Short, front-loaded with the WRITE marker and the core action, then four tight clauses covering default type, approval flow, notification, and non-idempotency, ending with the endpoint. 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 9-parameter mutation with no output schema and rich annotations, the description covers the workflow consequences well (pending request, approval rules, approver notification, non-idempotency). It does not say what the call returns (e.g. a request id) or how failures surface, which leaves a small gap for an agent chaining calls.

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 all nine parameters are already documented (types, defaults, date patterns, half-day flags). The description only restates the default type (Holiday) and adds nothing about date format, half-day interaction, or the notes field, so the baseline of 3 applies.

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 opens with an explicit verb+resource ("request leave for an employee") and a WRITE marker, and the note that it "is created as a request, then follows the account's approval rules" cleanly separates it from sibling operations like breathehr_approve_leave_request and breathehr_reject_leave_request. An agent can tell what this does without opening the schema.

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?

Usage is implied rather than stated: the description makes clear this creates a pending request (as opposed to approving/rejecting), but never names the alternative tools or states when to prefer listing/getting a request instead. No exclusions or prerequisites (e.g. valid employee, available allowance) are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: the account is resolved from the API key itself ('this API key belongs to'), so the caller learns no account identifier is required. It stops short of covering error/rate-limit behavior.

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?

A single front-loaded sentence naming the resource and its returned fields, with the endpoint appended. No filler and nothing buried.

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?

With no output schema, the description usefully enumerates the return fields (id, name, domain, enabled modules), which is exactly what an agent needs from this read-only call. Minor gap: 'enabled modules' is not described in any detail.

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?

The tool takes zero parameters, so the baseline is 4; the effective 'input' is the authenticated API key, which the description does explain. Nothing further about parameters is needed.

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?

Specific resource (the Breathe HR account/company tied to the API key) with an explicit list of the returned fields (id, name, domain, enabled modules). It is naturally distinct from the sibling tools, which all operate on employees, leave, expenses, etc., though it does not explicitly name or contrast 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?

There is no guidance about when to call this versus alternatives, nor any prerequisites (e.g. use this to resolve the account/company context before other calls). The usage is only implied by the resource name and the trailing 'GET /account'.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds genuinely valuable behavioral context beyond that: bank details and NI number are never returned, and it names the underlying GET /employees/{id} endpoint, which helps an agent understand the data boundary.

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 tight sentence with the return-content detail and exclusion front-loaded, followed by the endpoint. Zero filler; every clause carries 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?

There is no output schema, so the description usefully compensates by sketching the returned fields and explicitly excluding sensitive ones (bank details, NI number). It is close to complete for a simple single-record read, though it omits error behavior for invalid/unknown ids.

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% and there is only one parameter, so the schema already documents employee_id. The description restates 'by id' but adds no format, range, or lookup guidance beyond what the schema provides, making 3 the correct baseline.

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?

States a specific verb+resource: fetch one employee's record by id. It enumerates the returned content (personal/job details, contacts, manager, working pattern) and the id-based scope, which cleanly distinguishes it from breathehr_list_employees.

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?

'by id' implies the single-record use case versus the sibling list tool, and the never-returned fields give a hint about appropriate use. However, it never explicitly says when to choose this over breathehr_list_employees or breathehr_list_employee_jobs, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value the annotations cannot: it documents the shape of the response (allowance, taken, booked, remaining) in the absence of an output schema. It omits any note on pagination or volume of years returned.

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?

Two tight sentences: the returned content first, the filtering rule second, then the raw endpoint as a trailing identifier. Every clause carries information and nothing is padded.

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?

With no output schema, the description usefully enumerates the returned balance fields, and the param count is small and fully documented. What is missing is a statement of whether multiple years are returned by default and any auth/permission prerequisites, but for a simple read getter this is close to 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 100%, and the schema already explains for_date as 'Only the holiday year that includes this date (yyyy-mm-dd)' plus employee_id as the Breathe employee id. The description's for_date sentence essentially restates the schema, adding no format or edge-case detail beyond it.

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 names a specific resource (an employee's holiday years) and enumerates the fields returned (start/end, allowance, taken, booked, remaining), so an agent knows exactly what it gets. It doesn't differentiate itself from the conceptually adjacent sibling breathehr_list_holiday_allowances, leaving some selection ambiguity.

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?

It gives one concrete usage rule — pass for_date to narrow to the single year containing that date — which implies the no-param case returns all years. However, there is no guidance on when to use this versus list_holiday_allowances or how employee_id is obtained, so usage is only partially implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered and the description needn't restate it. The description adds only the "with its status" hint and the GET endpoint; it says nothing about behavior for a missing or deleted id (e.g. 404 vs empty) or whether soft-deleted requests are returned.

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?

Two tight sentences with zero filler, and the core identity (single leave request by id) is front-loaded before the endpoint detail. Nothing needs trimming.

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?

With no output schema, the description carries the burden of describing the return shape, and "with its status" is a thin sketch of what is presumably a richer leave-request object (dates, type, employee, approver). For a single-param read tool this is minimally adequate but leaves the agent guessing about response fields.

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% and the single parameter (leave_request_id, positive integer) is fully documented in the schema, so baseline 3 applies. The description contributes nothing beyond the schema — no id format, source of the id, or validity constraints.

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?

States a specific verb and resource ("One leave request by id") plus the underlying REST endpoint, so the agent immediately knows this is a single-resource retrieval. It does not name the sibling breathehr_list_leave_requests to draw the singular/plural contrast, but "by id" makes the distinction reasonably inferable.

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?

Usage is only implied: the agent can infer it should be used when it already has a leave_request_id and wants one record rather than a list. There is no explicit when-to-use statement, no mention of checking against list_leave_requests first, and no mention of what to do when the id is unknown.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is carried by structured data. The description adds useful surface detail (returned fields, approved-only scope, the GET /absences endpoint), but says nothing about pagination or the next_page contract implied by the page parameter. Adequate but not rich.

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 compact sentences: what is returned, how to filter, then the endpoint. Front-loaded with the value proposition and zero filler. Nothing to trim.

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 no-required-param read tool with a rich schema and annotations covering safety, the description is close to sufficient: scope, returned fields, and filters are all present. It stops short of the routing guidance (vs. leave_requests/sicknesses) and pagination behaviour that would make it fully self-contained.

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 each of the nine parameters is already documented in the schema. The description restates the same filter set (employee, department, type, reason, dates, cancelled) without adding format or interaction detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ('List approved absences') and enumerates the returned fields (employee, dates, half days, days deducted, cancelled flag). The 'approved absences (holiday and other leave)' scoping distinguishes it from the sibling breathehr_list_leave_requests, which covers the request workflow rather than recorded absences.

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 lists filter dimensions but never says when to reach for this tool versus breathehr_list_leave_requests or breathehr_list_sicknesses. No exclusions or prerequisites are stated, leaving the agent to infer the boundary itself.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the endpoint mapping and the return fields (type, value, start/end), but says nothing about pagination behavior or result ordering beyond what the schema implies.

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?

Two sentences, zero waste: the first front-loads the resource, return fields and scope options; the second maps scopes to endpoints. Nothing is redundant.

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?

With annotations covering safety and the schema covering all four parameters, the description supplies the remaining essentials: what is returned and how scoping selects the endpoint. Only minor gaps remain (no pagination narrative), acceptable for a read-only list tool with no output schema.

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 page, per_page, employee_id and department_id are all documented in the schema. The description's scope sentence reinforces which identifier selects which endpoint variant, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

Names a specific verb and resource ('List employee benefits') and states the three scopes it can serve (company, employee, department), plus the corresponding endpoints. This is clearly distinguishable from siblings like list_salaries or list_bonuses, though it does not explicitly contrast itself against those alternatives.

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?

Usage is implied by the scope enumeration – pass employee_id or department_id to narrow, or neither for the whole company. However, there is no explicit statement of when to prefer this tool over a sibling or any precondition/exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the underlying GET endpoints, but says nothing about pagination behaviour, ordering, or empty-result handling. Useful but modest added context.

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?

Two tight sentences: scope and return fields are front-loaded, and the endpoint list is placed last as supporting detail. Nothing is redundant or padded.

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?

With no output schema, the description usefully names the returned fields, and the annotations plus fully documented parameters cover the rest. Only minor gaps remain (result ordering, empty-set behaviour), so it is close to complete for a read-only paginated list tool.

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 all four parameters are already documented in the schema; the baseline is 3. The description's scoping sentence corroborates employee_id/department_id semantics but adds no syntax, format, or interaction detail beyond what the schema states.

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?

Specific verb (list) plus resource (bonus records) and the exact fields returned (amount, date, description). It also states the three scoping modes (company / employee / department), which maps cleanly onto the three underlying endpoints and separates it from siblings like list_salaries or list_benefits.

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 effectively tells the agent which call shape matches which scenario: no filter for the whole company, employee_id for one employee, department_id for one department. It lacks explicit when-not guidance (e.g., that the employee_id and department_id filters should not be combined), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description still adds genuine behavioral context beyond the annotations: bank and NI requested values are redacted (a data-visibility constraint an agent must know about), plus the exact REST endpoints used. It omits pagination mechanics, but those live in the schema.

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?

Two tight sentences, front-loaded with what the resource is and what it contains before the scoping and redaction caveats. No filler and nothing repeated from the schema.

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?

With no output schema, the description carries the burden of conveying the return shape, and it does so by naming the returned fields and the redaction exception. Pagination semantics are delegated to the schema, which is reasonable, but a brief note on ordering or result volume would have made it fully self-sufficient.

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 page, per_page, and employee_id are fully documented in the schema; baseline is 3. The description reinforces the employee scoping but adds no syntax or format detail beyond what the schema already provides.

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?

States a specific verb (List) plus the resource (employee self-service change requests) and enumerates the payload fields (field, requested value, approval state), then clarifies the two scopes (all employees or one). An agent can distinguish this from siblings like breathehr_list_leave_requests or breathehr_list_absences without opening any schema.

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 phrase 'for all employees or one employee' implies the usage split controlled by employee_id, and the endpoint mapping hints at the underlying routing. However, there is no explicit when-to-use-vs-alternatives guidance (e.g. how this differs from list_employees or the leave-request tools), so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds that this returns id and name fields and follows GET /departments, which is useful context. However it doesn't mention pagination behavior, which is relevant given page/per_page params.

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?

Two compact sentences and the endpoint. Front-loaded with the list action, then the practical usage. Zero waste.

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 simple paginated read with full schema coverage and annotations, the description is nearly sufficient. Mentioning pagination or that next_page drives iteration would round it out, but output schema is absent so field names (id, name) helpfully fill that gap.

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 both page and per_page are already documented with defaults and the next_page chaining hint. The description adds no parameter detail, so baseline 3 applies.

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?

States a specific verb (List) and resource (departments), and even names the fields returned (id, name). It distinguishes itself from siblings like list_divisions and list_locations by being the department reference.

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?

Explains the downstream purpose: use the ids to filter absences, leave, sickness and pay. This gives clear context for why an agent would call it. It doesn't explicitly say when NOT to use it vs list_divisions, but the usage context is well articulated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are unpaginated ("All of them are returned in one reply") and the payload shape is id/name, plus the underlying endpoint.

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 short, front-loaded sentences with no filler; the resource is named first, then the return behavior. The trailing "GET /divisions" is mildly redundant with the tool name but costs almost nothing.

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 zero-parameter, read-only list tool with no output schema, the description supplies the essentials an agent needs: full-result semantics and the returned fields (id, name). It is complete enough to call correctly, with only the sibling-distinction gap remaining.

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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. It adds no misleading parameter claims and the schema/description are consistent.

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?

States a specific verb and resource ("List the company's divisions") and names the returned fields. However, it offers no differentiation from the very similar sibling breathehr_list_departments (or breathehr_list_locations), so an agent must guess which hierarchy level it needs.

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?

Usage is only implied: it is an enumeration tool that returns the complete set, so no filtering or pagination choice is needed. There is no explicit when-to-use or when-not-to-use guidance versus list_departments/list_locations, leaving the sibling choice to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the record contents and endpoint but says nothing beyond that about pagination behavior or response shape.

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?

Two tight sentences that front-load the resource and field list, with no filler. Efficient, though the trailing "GET /employee_jobs" adds little for an agent.

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-only list tool with full schema coverage, annotations covering safety, and no output schema, the description is largely complete. Only richer return/pagination context would improve 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 all three parameters (page, per_page, employee_id) are already documented in the schema. The description only echoes the employee_id scoping via "one employee", adding no syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb (List) and resource (job history records), and enumerates the returned fields (job title, start/end dates, department, location). This clearly separates it from siblings like list_employees or list_salaries, though it names no sibling explicitly.

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?

"For all employees or one employee" implies the conditional usage of employee_id, giving implicit guidance. It does not state when to prefer this over alternatives or any exclusions, so guidance remains only implied.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower, yet the description adds genuinely useful behavior: it discloses that bank details and National Insurance numbers are never returned, a privacy/response-shape constraint not present in the structured fields. It omits rate limits or pagination behavior, but the sensitive-field exclusion is a meaningful addition.

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?

Two sentences plus an endpoint marker, front-loaded with the returned fields and followed by the sensitive-data exclusion. Every clause earns its place; 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?

With no output schema, the description carries the burden of describing returns and does so by enumerating the field set and excluding sensitive fields. Combined with fully documented parameters, an agent has enough to call it correctly; only pagination flow detail is left entirely to the schema.

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% — page, filter, and per_page each carry their own descriptions, including enum meanings and the next_page chaining hint. The description adds nothing about parameters, so the baseline 3 applies.

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?

States a specific verb+resource ('List employees') and enumerates the returned fields (job title, department, division, location, line manager, etc.), so the purpose is unambiguous. It does not explicitly contrast itself with siblings such as breathehr_get_employee or breathehr_list_employee_jobs, so it stops short of full sibling differentiation.

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 when-to-use guidance: nothing says when to prefer this over breathehr_get_employee for a single record or breathehr_list_employee_jobs for job data. Usage is only implied by the verb 'List', and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the filter capability, but says nothing about pagination behavior, result caps, or auth needs beyond what the schema shows.

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?

Two short sentences, front-loaded with the resource and returned fields. No wasted words, and the endpoint reference is a compact addition.

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 simple read-only list tool, the description is minimally adequate: returned fields and filter dimensions are stated. But with no output schema and a sibling named breathehr_list_expenses, more disambiguation context is warranted.

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 schema fully documents page, per_page, state, and employee_id. The description only restates that filtering is by employee and state, adding no syntax or format detail beyond the schema's baseline.

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?

States a specific verb (List) and resource (expense claims), plus the fields returned and the API endpoint. However, it does not differentiate from the sibling breathehr_list_expenses, which an agent could easily confuse with this tool.

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?

No guidance on when to use this versus the closely-named sibling breathehr_list_expenses. The filtering behavior is mentioned but there is no context for choosing between alternatives or stating prerequisites.

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

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

Annotations already cover the read-only, non-destructive safety profile, so the bar is lower. The description adds real behavioral context beyond structured data: the default filter to unclaimed items and the toggle to include claimed ones. It omits pagination behavior, but that is already documented in the schema.

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?

Two sentences plus the endpoint path, front-loaded with the resource and the default filtering rule. No filler, though the trailing 'GET /employee_expenses' is low-value trivia rather than guidance.

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?

There is no output schema, and the description compensates by naming the returned fields (date, description, type, amount, VAT, project). Combined with the default-filter explanation and full schema coverage of inputs, an agent has enough to call it correctly.

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 page, per_page, employee_id and include_claimed are all documented structurally. The description adds only the include_claimed default semantics, largely restating the schema, so baseline 3 is appropriate.

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?

States a specific verb (List) and resource (individual expense items) and enumerates the returned fields. The phrase 'individual expense items' and 'already part of a claim' implicitly separates it from list_expense_claims, but it never names that sibling, so an agent must infer the distinction.

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?

Provides a usable default rule ('by default only unclaimed items; set include_claimed to see all'), which tells the agent how to widen the result set. However, it gives no explicit when-to-use-this-vs-alternatives guidance, notably against the sibling breathehr_list_expense_claims, whose relationship is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the field set that comes back and the fact that no pagination or filtering applies ('All of them are returned in one reply'), plus the underlying GET endpoint.

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?

A single dense sentence that front-loads the verb and resource, then lists fields, then states the return scope. Nothing is padded, though the trailing 'GET /holiday_allowances' restates the resource already implied by the name.

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?

With no output schema and zero parameters, the description carries the burden of describing what comes back, and it does so field by field and confirms there is no pagination. What remains missing is only routing guidance relative to the many sibling list tools.

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?

There are zero input parameters, so the baseline is 4 with nothing to document. The enumerated fields describe the response payload rather than inputs, which is helpful but not a substitute for parameter semantics.

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?

States a specific verb (List) and resource (holiday allowance schemes), then enumerates the returned fields (id, default flag, year_1..year_10, created_at, updated_at), which pins down exactly what the resource is. No sibling tool covers holiday allowance schemes, so the agent can distinguish it without opening a schema.

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 never says when to call this tool versus related siblings such as breathehr_get_holiday_years or breathehr_list_working_patterns, nor does it state any prerequisite or exclusion. It only implies usage through the resource name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral content by disclosing the status set returned (notably that cancelling requests appear) and the underlying GET /leave_requests endpoint, but says nothing about auth, rate limits, or result volume.

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?

Two compact sentences: the resource and returned fields first, then the filters, with the endpoint appended. Every clause carries information; the trailing 'GET /leave_requests.' is marginally redundant but harmless for an API-backed tool.

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?

With no output schema, the description does the work of naming the returned fields (employee, dates, half days, type, status, notes), and pagination is covered by the schema's page/per_page descriptions. It is close to complete for a filtered read tool, with only auth/permission context missing.

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 all seven parameters are already documented in the schema, including pagination and date semantics. The description restates the main filter dimensions without adding format or interaction detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (list leave requests) and enumerates the statuses covered (pending, approved, rejected, cancelling), which is more precise than the title alone. It does not explicitly contrast itself with the singular sibling get_leave_request, though the List/Get split makes the distinction reasonably clear.

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 names the filter dimensions (employee, department, start-date range), which implies when this tool is appropriate, but it gives no explicit when-to-use guidance or exclusions versus siblings such as get_leave_request or list_absences. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: there is no pagination or partial result set, everything comes back in one reply, and it discloses the underlying endpoint GET /locations.

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 compact sentences, front-loaded with the verb+resource, then scope of return, then endpoint. Nothing is redundant and no sentence is wasted.

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 zero-parameter, read-only list with no output schema, the description supplies exactly what an agent needs: what is listed, that results are unfiltered/complete, and the return fields. Nothing required for correct invocation is missing.

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?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain inputs, and it usefully notes the response shape (id, name) even though that is technically output-side information.

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?

States a clear verb+resource ('List the company's work locations') and even names the returned fields (id, name). It is distinguishable from siblings like list_departments and list_divisions by resource alone, but it never explicitly contrasts itself with those 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?

No explicit when-to-use or when-not-to-use guidance is given. However, with zero parameters there is little room for misuse, and 'All of them are returned in one reply' implicitly tells the agent no filtering or paging options exist, so usage is adequately implied rather than stated.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the full set is returned in a single reply, meaning no pagination or cursor handling is needed, plus the underlying GET endpoint for traceability.

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 short sentences, each earning its place: purpose and scope first, then how to consume the output, then the transport detail. No redundancy or 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 zero-parameter, read-only lookup this covers purpose, return cardinality, and downstream use. A slight gap remains in not sketching what each returned record contains (id plus label), which matters somewhat since there is no output schema, but the 'use the ids' phrasing implies 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?

The tool takes zero parameters, so the baseline of 4 applies; the description correctly implies no filtering input is accepted by stating all results come back at once. Nothing about parameter semantics is missing.

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?

States a specific verb and resource ('List the reasons for non-holiday leave') and immediately scopes it with examples ('compassionate, jury service'), which distinguishes it from sibling leave tools like breathehr_list_leave_requests and breathehr_list_holiday_allowances. An agent can tell this is a reference-data lookup, not a filtered absence query.

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?

It gives downstream usage ('Use the ids to filter absences'), which implies a two-step workflow, but never names an alternative tool or states when this should be skipped. The usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that reads are GET-based and scoped, but says nothing about pagination behavior, rate limits, or auth requirements. With annotations carrying the safety burden, this is adequate but thin.

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?

Two front-loaded sentences: the return fields and scoping come first, the endpoint mapping second. Slightly redundant with the schema's parameter descriptions, but compact and free of 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?

There is no output schema, and the description usefully names the returned fields (amount, basis, payment schedule, start date), which compensates for that gap. Pagination is covered by the schema and annotations cover safety, so an agent has nearly everything needed to call it correctly.

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 page, per_page, employee_id and department_id are already fully documented with defaults and ranges. The description restates the scope-to-parameter mapping (whole company / one employee / one department) but adds no syntax or format detail beyond the schema, matching the baseline for high coverage.

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?

States a specific verb (List) and resource (salary records), enumerates the returned fields, and defines the three scopes (whole company, one employee, one department) with the corresponding endpoints. An agent can distinguish this from siblings like list_bonuses or list_benefits without opening the schema.

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 scope options implicitly tell the agent when to use it (company-wide vs. per-employee vs. per-department), but there is no explicit when-not guidance or named alternative tools. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful framing by labelling the payload as health data and listing status values (open, returned, closed…), but says nothing about pagination behaviour, permissions, or sensitivity handling beyond the parenthetical.

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?

Two sentences plus the endpoint, with the resource and return shape front-loaded and filters after. It is efficient, though the field enumeration is slightly list-like rather than purposefully structured and the trailing 'GET /sicknesses' is redundant for an MCP tool.

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?

There is no output schema, and the description compensates by enumerating the returned fields and status values, which is exactly what an agent needs to interpret results. Combined with the fully documented input schema, this is close to complete; only the sibling boundary and pagination guidance are missing.

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 all six parameters are already documented in the schema, with page/per_page and the yyyy-mm-dd date patterns explained there. The description restates the employee/department/date-range filters without adding syntax or semantics the schema lacks, so the baseline 3 applies.

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?

States a specific verb and resource ('List sickness absence records') and enumerates the returned fields (employee, sickness type, dates, half days, days deducted, status, reason), which meaningfully separates it from the nearby breathehr_list_absences sibling. It does not explicitly name that sibling or state the boundary, so it falls short of a 5.

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 names the available filters (employee, department, start-date range), which implies usage but never says when to choose this tool over breathehr_list_absences or other leave-related siblings. No exclusions or prerequisites are given, leaving the agent to infer the boundary.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by listing the record fields returned (useful since there is no output schema) and citing the endpoint, but it says nothing about pagination behavior or result ordering.

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?

Two short sentences with the scope and field list front-loaded and no filler. The trailing 'GET /employee_training_courses' is mildly redundant but harmless.

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?

With no output schema, the field enumeration compensates reasonably well for the missing return-value documentation, and the optional employee_id scoping is stated. Pagination is left to the schema, which covers it adequately.

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 page, per_page and employee_id are fully documented in the schema; baseline is 3. The description's 'all employees or one employee' phrasing reinforces employee_id's optionality but adds no format or constraint detail beyond the schema.

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?

Specific verb (List) plus resource (employee training records) and an enumeration of the returned fields (course name, type, status, dates, cost). It clearly separates itself from sibling list_* tools by naming its distinct resource, though it does not explicitly contrast with any named alternative.

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 phrase 'for all employees or one employee' implies the scoping choice, but there is no explicit when-to-use guidance, no exclusions, and no mention of pagination workflow beyond what the schema already says.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the operation is unfiltered and complete in a single reply (no pagination or partial-result concern), which an agent would otherwise have to guess.

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 short sentences, front-loaded with the resource and the returned shape, with no filler. The trailing 'GET /working_patterns' is mildly redundant but harmless and brief.

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?

With no output schema, the description compensates by naming the fields returned (weekday hours, weekly total, default flag), which is exactly the information an agent needs. It could still say whether the list can be empty or how ordering works, but for a simple parameterless list tool this is close to 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies there is nothing to supply, and the GET path corroborates a parameterless call.

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?

States a specific verb (List) and resource (working patterns) and even enumerates the returned fields (hours per weekday, weekly total, default flag). The resource is clearly distinct from sibling list tools like list_departments or list_locations, though it never explicitly contrasts itself with 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. 'All of them are returned in one reply' hints that no filtering or pagination is needed, but this is inference rather than stated guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description goes beyond that by disclosing two non-obvious traits: the reason text is visible to the employee, and the action is attributed to the 'API Employee' actor in the audit trail. It stops short of saying whether rejection is reversible or what happens on an already-decided request.

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 short sentences, front-loaded with the operation class and verb, with every clause carrying information: mutability, precondition, employee-visible side effect, audit attribution, and endpoint. 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 two-parameter write tool whose annotations already flag destructiveness and non-idempotency and that has no output schema, the description covers the essentials plus audit and visibility context. It is only marginally incomplete on state-transition behavior (e.g., rejecting an already-approved request).

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 schema already explains both parameters, including that rejection_reason is shown to the employee and where the id comes from. The description's phrase 'a reason the employee will see' simply restates the schema, adding little beyond the baseline.

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?

States a specific verb and resource ('reject a pending leave request') with the scope qualifier 'pending', and is trivially distinguishable from its sibling breathehr_approve_leave_request. The 'WRITE:' prefix plus the POST path make the operation's nature unambiguous.

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 word 'pending' implies a precondition that the request must still be awaiting decision, which is genuinely useful selection context. However, it never names the alternative (breathehr_approve_leave_request) or states what to do when a request is not pending, so the when-to-use guidance is only implied.

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