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

Annotations already declare readOnlyHint and idempotentHint true, so safety is covered. The description adds valuable behavioral context: the fallback behavior when multiple employees match ('returns up to 20 candidates instead'). This is beyond the annotations and helps the agent understand an important edge case.

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 with no filler. The purpose is front-loaded, and the critical fallback behavior is stated concisely. 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?

For a read-only tool with annotations covering safety, the description is fairly complete. It covers the core output (summary and incidents) and the ambiguous-name fallback. It does not describe the exact return format or pagination, but since there is no output schema, a bit more detail might be expected. However, given the tool's simplicity, this is a minor 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 all parameters are documented in the schema. The description adds minimal semantic value beyond the schema: it reiterates the employee parameter ('Employee ID or part of a name') but does not explain grace_minutes or the date filters. Baseline of 3 is appropriate when the schema fully covers 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 ('Attendance summary and incident list') and a clear resource ('for one employee'), and lists the incident types (late, no-show, missed clock-out). It distinguishes itself from siblings by the 'one employee' scope, which is not ambiguous.

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 for a single employee's attendance but does not explicitly mention alternatives or when not to use this tool. It does not reference sibling tools like find_late_arrivals or missing_clock_events, leaving the agent to infer the scope from 'one employee'.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior beyond annotations: the individual (non-aggregated) grain and 'worst first' ordering, and implies only late entries are returned. No contradiction.

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 zero filler. The primary behavior is front-loaded, and the usage cue is immediately actionable.

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 strong annotations and a fairly complete schema, the description covers purpose and usage. It leaves 'worst first' imprecise (likely by minutes late), and does not explicitly route away from siblings, but these are minor gaps.

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 80% (4 of 5 parameters documented) with defaults and formats included. The description does not add parameter-specific semantics, so the 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?

The description states a specific verb and resource ('List individual late clock-ins') and adds an ordering qualifier ('worst first'). It implies differentiation from aggregated siblings like repeat_late_arrivals via 'individual', but does not explicitly name any sibling.

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?

'Use for "who was late on X" questions' gives a clear, concrete usage context. It does not specify exclusions or alternatives, but the cue is sufficient for basic routing.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by stating the returned fields including the date range, which goes beyond the annotations. There is no contradiction or missing behavioral 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 concise, front-loaded sentences deliver all necessary information without waste. The first sentence states the core purpose and fields; the second adds a useful output detail (date range). No filler or redundant language.

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 parameterless tool with no output schema, the description provides the essential information: the full set of data returned (every site, country, timezone, headcount, date range). This is sufficient for an agent to call and interpret the result without further clarification.

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 has zero parameters, so the schema coverage is effectively 100% and the baseline is 4. The description correctly focuses on the output, adding no parameter details because none are needed. It fully leverages the no-parameter structure.

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 ('List') and resource ('every site') with additional detail on the fields returned (country, timezone, headcount, date range). This clearly distinguishes it from siblings like location_trends or employee_attendance, which suggest different data views.

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 a clear use case—obtain a complete list of sites with their metadata—but it does not explicitly mention when to choose this tool over alternatives, provide exclusions, or reference sibling tools. The guidance is adequate but not fully explicit.

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 read-only/idempotent/non-destructive behavior; the description adds meaningful runtime behavior by disclosing that weekly rows carry partial_week=true when the date range cuts into a week. It does not fully describe output shape, but this is a strong addition beyond the annotations.

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, no filler. The core purpose is front-loaded, the use case follows, and the partial_week edge case earns its place as the final sentence.

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 conveys the return concept (late rate/no-shows per site by grouping) and a key edge-case flag. It is sufficient for an agent to invoke correctly, though it leaves minor output formatting details unspecified.

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 80%, and the schema already explains to/from/location/grace_minutes with defaults and constraints. The description adds only light context for group_by via 'grouped by weekday or by week', which is consistent with the schema enum, so a 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?

The description opens with a specific, scoped statement — 'Late rate and no-shows per site, grouped by weekday or by week' — naming the resource and aggregation. The phrase 'site-level patterns' clearly separates it from event-level siblings like find_late_arrivals and employee_attendance.

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?

'Use to spot site-level patterns such as a bad day of the week' gives an explicit use case. It does not mention when not to use it or name alternatives, so it falls short of a 5 but is clearly contextualized.

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 mark the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds behavioral context by defining what counts as a no-show ('scheduled shift, no clock-in') and a missed clock-out ('clocked in, never clocked out'), which is not in the schema or annotations. It does not mention pagination or output shape, but the core detection behavior is transparent.

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 sentence with parenthetical definitions, and every word earns its place. It is front-loaded with the verb and object, making the purpose immediately clear.

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 has no output schema, so an agent still does not know the exact shape of returned records. The description also gives no guidance on choosing between this tool and repeat_missing_clock_events. However, annotations cover safety, and the parameter schema handles defaults and bounds, making it adequate for simple invocation.

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 schema documents from, to, and location, while the description supplies meaning for the type enum values (no_show, missed_clock_out) by defining them in plain language. It does not discuss the limit parameter or type=all behavior, though those are partly self-evident from schema constraints and defaults. Overall, it adds some semantic value beyond the 60% schema coverage but does not fully compensate for the undocumented 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 opens with a specific verb, 'List', and identifies the exact resource: no-shows and missed clock-outs, with parenthetical definitions for each. It is clearly not tautological and it clarifies the core subject matter. It does not explicitly differentiate from siblings such as repeat_missing_clock_events, so it falls just short of full 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?

No sentence explains when to prefer this tool over repeat_missing_clock_events, find_late_arrivals, or employee_attendance. The intended use is implied by the title and description, but no exclusions or alternatives are named. An agent has to infer context from the sibling list.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool ranks employees and returns metrics, which is some behavioral context. However, it does not disclose output format, sorting order, or any side effects (though none expected). Given the annotations, the description adds modest value but not rich detail.

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 two sentences, front-loaded with the core purpose and output metrics, followed by a concise usage hint. No wasted words; it is efficient and well-structured for quick comprehension.

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 has 6 parameters, no output schema, and moderate complexity. The description covers the purpose and output metrics but omits details about the 'min_times_late' threshold (which defines 'repeatedly') and the 'limit' parameter. It also does not describe the response format. These gaps mean an agent may not fully understand how to configure the call or interpret results without additional inference.

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 67% (4 of 6 parameters have descriptions). The descriptions for 'to', 'from', 'location', and 'grace_minutes' are provided in the schema, but 'limit' and 'min_times_late' lack descriptions. The tool description does not clarify these parameters, nor does it explain how 'min_times_late' relates to 'repeatedly'. The description adds no parameter semantics beyond the schema, so it fails to compensate for the undocumented fields.

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 tool ranks employees who were late repeatedly, and specifies the metrics (late count, late rate, average minutes late). It also includes a usage phrase ('who is regularly late') that helps distinguish it from siblings like find_late_arrivals. This is a specific verb+resource+output combination.

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 includes an explicit usage context: "Use for 'who is regularly late' questions." This gives clear when-to-use guidance. However, it does not mention alternatives or exclusions, even though siblings like repeat_missing_clock_events exist. The guidance is sufficient for the primary scenario but lacks explicit comparison.

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 read-only, idempotent, and non-destructive behavior. The description adds behavioral context by indicating that the tool aggregates and ranks employees rather than returning raw event records, and that output includes counts and rates.

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 concise, front-loaded sentences. The first states the core behavior, and the second provides practical usage examples. No filler or redundant restatement of the tool 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?

For a tool with no output schema and five optional parameters, the description communicates the result shape reasonably well through 'counts and rates' and 'Rank employees.' It could more explicitly contrast with missing_clock_events or define the repeat threshold, but the name, title, and min_times parameter cover most of 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 80%, with from, to, location, and min_times already described. The description adds general framing about ranking and rates but does not add meaningful parameter-level detail beyond the schema, so the baseline score of 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?

The description names a specific action and resource: 'Rank employees by no-shows and missed clock-outs, with counts and rates.' This clearly conveys what the tool does and distinguishes it from the sibling missing_clock_events through the 'repeat' framing and ranking behavior.

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 explicitly provides usage context with natural-language question examples: 'who keeps not turning up' and 'who forgets to clock out.' It does not list exclusions or alternative tools, but the guidance is clear enough for selection in most cases.

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