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 known. The description adds that it returns one row per angle with specific metrics, which is helpful context. However, it doesn't mention any performance implications, aggregation details, or limitations beyond the output structure. For a simple read-only stats tool this is adequate but not rich; a 3 reflects that the description adds some value but doesn't go beyond what annotations imply.

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 three sentences, each earning its place: the first states the core function, the second gives concrete usage triggers, the third details the output rows. It is front-loaded with the purpose and avoids any filler, making it efficient for an agent to parse.

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, read-only statistics tool with an output schema present, the description is complete. It explains what the tool does, when to use it, and what the output contains, without needing to cover params or return format (since output schema handles that). No gaps exist for an agent 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?

The tool has zero parameters, so the schema trivially covers 100% and there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description appropriately focuses on output semantics rather than params. No additional parameter documentation 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?

The description clearly states the tool returns per-wall-angle statistics for comparison, with a specific verb ('Return') and resource ('per-wall-angle statistics'). It also lists concrete example queries (comparing angles, hardest/most climbed, flash rate by angle) that distinguish it from sibling stats tools, so an agent can select it unambiguously.

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 specifies when to use this tool: 'Use when the user asks to compare angles, which angle they climb hardest or most at, or flash rate by angle.' This gives strong contextual triggers, though it doesn't name specific alternative tools or state exclusions. That would push it to 5, but the guidance is clear enough for typical 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 and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations, notably the ordering 'hardest first' and the inclusion of flash rates, plus the optional wall-angle filter. It does not contradict 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?

Two sentences with no filler: the first states the tool's output, the second gives usage conditions and the optional filter. The most important information is front-loaded.

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?

This is a simple read-only tool with one fully documented optional parameter and an output schema. The description covers selection, expected return content, ordering, and the optional filter, so nothing necessary 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?

Schema description coverage is 100%: the only parameter, 'angle', is fully documented with examples and the default behavior ('Omit for all angles'). The description merely restates 'Optional wall-angle filter', adding little beyond the schema, 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 ('Return') and resource ('the user's send pyramid') with concrete output details: sends per grade, hardest first, and flash rates. This clearly distinguishes it from sibling tools like kilter_get_sends or kilter_get_summary by naming the exact grade-level distribution concept.

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 gives explicit when-to-use guidance: 'Use when the user asks about their grade pyramid, distribution of grades, flash rate per grade, or how solid they are at a level.' It does not list when-not-to-use or name alternative tools, but the trigger conditions are clear enough for an agent to route correctly.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral detail beyond those: results are unique per climb and angle, sorted hardest first, with an optional wall-angle filter. This gives the agent meaningful expectations about the tool's behavior without contradicting 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?

The description is two concise, front-loaded sentences: the first states exactly what the tool returns, and the second gives usage triggers and parameter guidance. There is minimal redundancy, and the key differentiating behavior is presented first.

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 tool with two optional parameters and an existing output schema, the description is complete. It covers purpose, usage triggers, deduplication behavior, ordering, and the optional angle filter, and the annotations cover safety, making it sufficient for correct 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?

Schema description coverage is 100%, so the baseline is 3; the schema already documents angle and limit, including defaults. The description mentions the optional wall-angle filter and the default limit, but this largely duplicates the schema rather than adding new semantic meaning.

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 action ('Return') and a precise resource: the user's hardest sent climbs, with uniqueness per climb and angle, ordered hardest first. This clearly separates it from siblings like kilter_get_sends or kilter_get_grade_pyramid by focusing on 'hardest sends, best climbs, max grade, or personal bests.'

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 says 'Use when the user asks about their hardest sends, best climbs, max grade, or personal bests,' providing clear context for when this tool should be selected. It does not mention when not to use it or name an alternative, but the use-case guidance is specific enough to route an agent correctly.

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 indicate a safe read-only operation, and the description adds meaningful behavioral context: ordering ('newest first'), entry granularity, inclusive date filtering, and the meaning of the 'topped' filter. This goes beyond the structured annotations without contradicting them.

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 tight sentences: purpose, usage context, and filter summary. Every sentence earns its place, and the most important information is front-loaded.

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 an output schema and five optional, well-described parameters, this description is complete. It explains when to use it, what it returns at a unit level, and how every filter behaves, so an agent can invoke it correctly 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 coverage is 100%, so the baseline is 3. The description adds extra value by stating the limit maximum of 500 (not present in the schema), clarifying angle units in degrees, and compactly summarizing all filter semantics including inclusive date ranges.

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: 'Return the user's Kilter logbook entries, newest first.' It also clarifies the unit of data ('one climb at one wall angle on one date with the number of tries'), which distinguishes it from send lists, projects, summaries, and statistics tools.

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 gives clear trigger conditions: 'Use when the user asks about recent Kilter climbs, attempts, what they climbed on a date, or wants raw history.' It does not explicitly name alternative tools or state when not to use it, but the context is specific enough for an agent to route correctly.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds meaningful behavior: results are ordered 'oldest period first,' each period contains specific aggregates, and angle filtering is optional. This gives the agent a useful preview of response semantics without contradicting 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?

The description is tightly written and well-structured: purpose first, then when-to-use, then parameter clarification, then output contents. Every sentence earns its place with no redundancy.

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 only two optional parameters, a full input schema, and an output schema. The description covers purpose, usage triggers, period semantics, output fields, and the optional angle filter. Nothing essential is missing for an agent to select and invoke 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 coverage is 100%, so the schema already documents both parameters. The description adds marginal value by restating period's default ('month') and calling angle an optional filter, but it does not introduce new semantic 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?

The description states a specific verb and resource: 'Return climbing progression over time, oldest period first.' This clearly identifies the tool's function. It does not explicitly name and distinguish sibling tools, but the time-based progression focus sets it apart from the summary, logs, sends, and pyramid siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use when the user asks how they have progressed, trends, whether they are improving, or for a month-by-month/week-by-week view.' This is explicit about when to use the tool, though it does not mention when not to use it or name alternatives.

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, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context: the definition of a project per (climb, angle), the sorting order ('most recently tried, then most attempts'), and the optional angle filter. This goes beyond what annotations provide.

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: the first states purpose, the second gives usage, the third adds behavioral nuance and sorting. Everything is front-loaded and every sentence earns its place. No filler or redundancy.

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 description covers the tool's definition, usage triggers, sorting behavior, angle scoping, and filter option. With an output schema present and annotations covering safety, nothing essential is missing for an agent to select and 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% and already explains the angle and limit parameters, including defaults and semantics. The description adds little beyond restating 'Optional angle filter,' which is redundant. The (climb, angle) definition provides indirect context but does not add parameter-level detail not already in 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?

The description states a specific verb ('Return') and resource ('user's projects') and defines what a project is ('climbs attempted but never topped at that wall angle'), which clearly differentiates it from sibling tools like sends or logs. It also explains the (climb, angle) granularity, removing ambiguity about what constitutes a project.

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 lists the use cases ('what they are working on, unfinished climbs, or what to try next'), which tells the agent when to invoke this tool. It does not explicitly name alternative tools or exclusions, but the context is clear enough that an agent can route correctly among the siblings.

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 covered. The description adds meaningful behavioral context beyond the annotations: it explains the 'flash' status semantics ('topped on the first try'), the ordering ('newest first'), and the date/angle/limit filters. This is useful for an agent deciding whether the tool matches the user's intent.

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 compact and front-loaded: the core purpose is in the first sentence, the usage context in the second, and the filter summary in the third. Every sentence earns its place, and there is no redundant or filler content.

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 an output schema, so return values need not be described. The description covers the main behavioral aspects (ordering, flash semantics, filters) and the annotations cover safety. The only minor gap is that it does not explicitly mention pagination or the meaning of 'openWorldHint', but for a read-only list tool with a rich schema, this is 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 the schema already documents all four parameters. The description adds a small amount of extra meaning by restating the limit default and range and the date format, but it does not go beyond what the schema already provides. Baseline 3 is appropriate because the schema carries 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?

The description states a specific verb ('Return climbs the user has topped (sent)'), a clear resource (sends), and an ordering constraint (newest first). It also distinguishes itself from siblings by explicitly mentioning 'sends, ticks, completed climbs or flashes', which maps to the tool's domain and differentiates it from kilter_get_logs, kilter_get_projects, and kilter_get_hardest_sends.

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 gives clear context for when to use the tool ('when the user asks about their sends, ticks, completed climbs or flashes') and includes a useful clarification about flash status. It does not explicitly name alternative tools or state when not to use it, but the sibling list and the domain-specific phrasing make the intended usage clear enough.

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 this as read-only and non-destructive. The description adds useful behavioral detail beyond annotations: sessions are grouped by calendar day, sorted newest first, and include angles, sends, flashes, attempts, hardest send, and all climbs logged that day.

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 deliver the core behavior, use cases, return contents, and default limit without wasted words. The information is front-loaded and easy to parse.

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?

Given the output schema is present, annotations cover safety, and the only parameter is optional with a documented default, the description provides everything needed to select and invoke the tool 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 coverage is 100%, so the schema already documents the lone limit parameter with its default. The description restates the default but adds little semantic value beyond the structured 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?

The description clearly states the tool returns recent climbing sessions grouped by calendar day, newest first. It provides concrete use cases that distinguish it from sibling tools focused on summaries, logs, sends, and projects, though it does not explicitly name an 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 description explicitly says when to use it: when the user asks how their last session went, what they climbed yesterday, or wants to compare sessions. It lacks an explicit 'when not to use' or direct sibling comparison, but the guidance is clear.

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. The description adds useful behavioral context beyond that by defining the result as a compact aggregate of the whole Kilter history and enumerating the totals included, such as sends, flashes, attempts, and hardest send/flash.

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 the core action and resource front-loaded. The second sentence efficiently adds when to use it and what totals it covers, with relevant example queries that earn their 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?

Given zero parameters, annotations confirming a safe read operation, and the presence of an output schema, the description is complete. It tells an agent when to invoke the tool and what kind of information it will receive.

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 accepts zero parameters and schema description coverage is 100%, so parameter semantics require no additional explanation. Baseline for 0 parameters is 4; the description does not need to compensate for missing parameter docs.

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?

Description names the action ('Return'), the resource ('compact overview of the user's whole Kilter history'), and the scope ('whole Kilter history'). It is clearly distinct from sibling tools that return granular lists or specific statistics.

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 says 'Use first' and gives concrete triggers: broad questions like 'how is my climbing going?' and needs for totals. It does not explicitly name sibling alternatives or state when not to use it, so it misses the top tier but provides clear context.

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