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

Beyond the readOnly/openWorld annotations, the description discloses the output shape (one row per board), the key metrics included, and the important nuance that hardest_boardsesh_grade and median_boardsesh_grade are normalised across boards for fair comparison. This gives the agent a clear picture of behavior without needing to infer it.

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 with the core purpose, then gives trigger examples, then lists output details. Each sentence adds distinct value and nothing is redundant 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 tool with an output schema, the description covers the purpose, trigger conditions, output granularity, and the crucial normalisation caveat. There is no missing context that would prevent an agent from invoking 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 there is no parameter semantics to clarify. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on output semantics instead of input 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?

The description states a clear, specific action: comparing the user's climbing across all logged boards. It also gives concrete example questions, which distinguishes it from sibling tools like boardsesh_get_summary that focus on a single board or aggregate summary.

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 when to use the tool: when the user asks which board they are strongest on, how boards compare, or where they climb most. It does not mention when not to use it or name alternatives, so it stops just short of full routing 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 and openWorldHint=true, covering the safety profile. The description adds non-obvious behavioral context beyond annotations: similarity is hold overlap on a 0-1 scale, 0.5 feels genuinely related, and climb_uuid should come from an earlier tool result. No contradiction exists.

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-load the purpose, then the when-to-use context, then the key similarity semantics and input source. Every sentence earns its place with no filler or repetition.

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 four-parameter read-only lookup with an output schema and clear annotations, the description covers purpose, invocation context, similarity semantics, and the source of the required parameter. Anything further, such as return values or parameter defaults, is already expressed in the schema and 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that climb_uuid is an opaque identifier from another tool's output and by giving the similarity threshold that helps interpret results, lifting it above the schema-only 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?

The description opens with a specific verb and resource: 'Find climbs that use a similar set of holds to a given climb.' It further distinguishes the tool from generic search or recommendation siblings by making the similarity criterion explicit (hold overlap) and naming concrete use cases.

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 invocation triggers: user asks for climbs like one they enjoyed, one they are projecting, or wants to train a specific movement again. It stops short of the top tier because it does not explicitly name sibling alternatives or state when not to use this tool.

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 it read-only, and the description adds behavioral context: entries are returned newest first, across all boards, and each entry represents one climb at one angle with attempt count. This goes beyond the structured annotations and clarifies the tool's output granularity.

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 four sentences with a clear structure: purpose, when-to-use, data shape, filters. It is front-loaded and every sentence contributes, though the data-shape sentence could be inferred from 'ascents'; still, it's not bloated.

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 6-parameter read-only tool with an output schema, this description covers purpose, typical use cases, ordering, scope, and filter list. No critical selection information is missing; the only small gap is explicit sibling differentiation, but use cases already imply 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%, and the description's filter list (limit, board, angle, status, start_date/end_date) is purely a summary of the schema, adding no new semantic meaning beyond what the properties already convey. 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?

The first sentence states a specific verb ('Return') and resource ('logbook entries') with a clear scope ('across every board') and ordering ('newest first'). This differentiates from sibling tools like boardsesh_get_sessions or boardsesh_get_summary, which operate on different resources.

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 concrete use cases ('recent climbs, sends, flashes, attempts, what they did on a date, or wants raw history') which distinguish from aggregated sibling tools. However, it does not name alternative tools or state when not to use this tool, so it stops short of explicit exclusion.

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 nature. The description adds useful context beyond that: output ordering ('hardest first'), inclusion of flash rates, and the domain fact that grades differ between boards, which helps interpret results.

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, purposeful sentences with the core result front-loaded. No wasted words; each sentence earns its place by covering what, when, and how to handle the optional filter.

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 purpose, trigger conditions, and board-filter guidance. With only one optional parameter and an output schema present, nothing critical is missing for an agent to 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?

The schema already covers the board parameter thoroughly (list of board types and 'Omit for all boards'). The description adds extra meaning with the decision rule 'prefer filtering to one board when the user names one,' which goes beyond the schema and aids parameter selection.

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's function: 'Return the user's send pyramid: sends per grade, hardest first, with flash rates.' This specific verb-resource pairing distinguishes it from siblings like boardsesh_get_grades and boardsesh_get_summary.

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 trigger cases ('pyramid, grade distribution, flash rate per grade, or how solid they are at a level') and advises preferring a board filter when the user names a board. It does not name alternative tools or explicit when-not-to-use cases, so it stops 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 establish readOnlyHint=true and openWorldHint=true, so no safety contradiction exists. The description adds behavior beyond the annotations by clarifying that grade scales are board-specific and that the result is a mapping—context that helps the agent trust and interpret the tool's output.

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 concise and front-loaded: the first line states exactly what the tool returns, and the second gives usage guidance. Every sentence earns its place, with no redundant or vague 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 tool with a single optional parameter, existing output schema, and annotations covering safety, the description is complete. It covers purpose, usage, and a key behavioral caveat (board-specific scales). An agent can invoke this tool correctly with the information provided.

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?

With schema coverage at 100%, the parameter 'board' is already documented as 'Board type, e.g. kilter, tension, moonboard.' The description adds value by explaining why the board parameter matters ('Boards do not share one scale') and gives a concrete use case (passing min_grade_id), which enriches the parameter's meaning 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 ('Return'), a concrete resource ('a board's grade scale'), and the exact mapping ('difficulty_id to grade label'). It also distinguishes this tool from siblings by noting that boards do not share one scale, making its role clear among the many boardsesh getters.

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 tells the agent when to use the tool: 'Use when you need a difficulty_id for a grade the user named...' and when to reuse it for explaining grade IDs. It also warns that boards do not share one scale, which indirectly tells the agent not to assume a global grade system and to pass the correct board parameter.

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 known. The description adds value by disclosing the exact output semantics: per-hold counts by hand/foot/start/finish usage and average difficulty. It also offers behavioral guidance that hold ids are wall positions and that the agent should reason about patterns and grade ranges rather than individual ids.

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 with the core purpose, followed by usage conditions, output summary, and a practical example. Every sentence earns its place: no filler, no restating of the tool name, and the most important scoping guidance appears 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 read-only analytical tool with an output schema present, the description covers the essential context: what the tool returns, when to use it, how to combine it with grade parameters, and how to interpret hold ids. Since the output schema handles return-value details and the input schema handles parameters, an agent has 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 description coverage is 100%, so all six optional parameters already have individual descriptions. The description adds a useful hint about combining a grade range with the heatmap, but it does not substantially enrich parameter meaning beyond what the schema already provides. Per calibration, 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 verb and resource: 'Return which holds the wall's climbs use,' and immediately gives the analytical purpose of spotting strengths and weaknesses. This clearly distinguishes it from sibling tools like get_summary, get_grade_pyramid, and get_progression, which focus on different aggregations.

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 states when to use the tool: 'Use when the user asks about weaknesses, hold types they avoid or overuse, or what to train.' It also gives a concrete pattern for combining it with a grade range. It does not name alternatives or explicitly say when not to use it, but the trigger conditions are clear 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond annotations: chronological ordering ('oldest period first') and the concrete set of per-period statistics, which helps set expectations for the response structure.

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 with no filler. The core behavior is front-loaded, followed by usage guidance and output expectations. Every sentence earns its place and keeps the description scannable.

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 tool has only two optional parameters, complete schema descriptions, full annotations, and an output schema, the description covers the remaining gaps: when to use the tool, what ordering to expect, and what fields appear in each period. Nothing needed 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%, so both parameters are already fully documented with allowed values and defaults. The description only reinforces the month/week concept rather than adding parameter-specific semantics beyond the schema. 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: 'Return climbing progression over time', and adds a meaningful behavioral detail ('oldest period first'). It also clarifies what each period contains, which helps distinguish this from sibling summary or session 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 explicitly says when to use it: 'when the user asks whether they are improving, about trends, or for a month-by-month or week-by-week view.' It does not name alternatives or provide explicit when-not-to-use exclusions, but the context is 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?

Annotations already indicate a safe read-only operation. The description adds meaningful behavioral detail beyond that: the per-(board, climb, angle) project definition and the sort order by most recently tried, then most tries. This gives the agent useful expectations about what the call returns and how it behaves.

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 core definition and use case, followed by a concise sorting and edge-case note. Every sentence earns its place and there is 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-optional-parameter read-only tool with an output schema, the description is complete. It defines the domain concept, gives usage guidance, clarifies a subtle behavioral rule, and states ordering—all an agent needs 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 description coverage is 100%, so the schema already fully documents the board and limit parameters. The description does not add parameter-level meaning, but it does not need to; the baseline score 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 uses a specific verb ('Return'), identifies the resource ('the user's projects'), and defines 'projects' precisely as climbs attempted but never sent at that angle. This definition distinguishes it from sibling tools like boardsesh_get_ascents, so an agent can tell them apart.

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?

Explicitly states when to use the tool: 'when the user asks what they are working on, unfinished climbs, or what to try again.' It provides clear context but does not explicitly name alternatives or give a when-not-to-use directive, which leaves a small gap in 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 establish this as read-only and non-destructive. The description adds useful behavioral detail beyond that: newest-first ordering, grouping by calendar day, and the specific data included per session. No annotation contradiction exists.

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 with no filler: purpose and ordering first, usage triggers second, output contents third. Each sentence earns its place and the key action 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 two optional, fully documented parameters and an output schema, the description covers when to use it and what the result structure contains. It could more explicitly contrast with sibling tools, but nothing critical 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 input schema has 100% description coverage, with clear explanations for board filtering and limit. The description does not add parameter-level semantics beyond that, so the baseline 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 opens with a specific verb and resource: 'Return recent climbing sessions (entries grouped by calendar day), newest first.' It also enumerates the session-level contents (boards, sends, flashes, hardest send, climbs), which separates it from sibling tools like get_summary or get_ascents.

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 'Use when...' clause gives three concrete triggers: asking about a last session, what was climbed on a day, or comparing sessions. It does not name explicit alternatives or state when not to use it, so it stops short of full routing 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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by defining the output as a compact cross-board aggregate and enumerating the totals included, which goes beyond what annotations reveal.

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, front-loading the core purpose before the usage examples. The long second sentence is a single scannable list that earns its place by conveying both query intents and returned totals.

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 summary tool with an output schema, this description is complete: it states scope, when to use it, and what data the summary contains. Nothing an agent needs to invoke it correctly 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 has zero parameters and schema coverage is 100%, so there is no parameter information for the description to add. The baseline of 4 applies because the interface is fully represented by the empty input 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?

States a specific verb and resource: 'Return a compact overview of the user's whole Boardsesh history, across all boards.' This clearly distinguishes it from sibling tools that focus on individual ascents, sessions, projects, grades, etc. The overall scope is explicit.

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 explicit guidance: 'Use first for broad questions' with concrete example queries, plus the list of totals the tool covers. It does not explicitly name sibling alternatives for when more granular data is needed, so it stops short of a full when/when-not description.

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 readOnly/openWorld annotations, the description reveals that at_level derives from the user's send history, excludes already-sent climbs, and falls back to a saved board configuration. This gives useful behavioral context 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?

Three short sentences front-load the purpose, then add usage triggers and the one key behavioral prerequisite. There is no filler or repetition.

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 an output schema and safe read-only annotations, the description covers the main triggers, the at_level behavior, and the prerequisite that a saved board is used. It could add one line about how other kind values treat send history, but this is not essential 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 coverage is already complete, so the baseline is 3, and the description adds extra meaning for at_level by explaining it uses send history and excludes sent climbs, plus the saved-board dependency. It does not over-explain the other parameters, which the schema already documents.

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 action and resource: suggest climbs the user has not sent yet from Boardsesh recommendations. It distinguishes this from sibling search/project tools by emphasizing recommendations and unsent climbs.

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 explicit trigger contexts such as asking what to try next, wanting new climbs, projects at their level, or something fresh. It also states the board-configuration prerequisite, though it does not name alternative siblings or say when not to use this tool.

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 useful context about filtering behavior but does not go deeper into return characteristics or potential quirks; with annotations present this is adequate.

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 core action and filter scope, the second gives concrete use cases and routes to the recommended alternative. Every sentence 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 search tool with 9 optional parameters, the description plus a 100%-covered schema and output schema provide enough context. It clearly separates search from recommendation and leaves parameter details 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%, so the baseline is 3. The description adds semantic groupings like 'grade range' and 'popularity' that map to min/max_grade_id and min_ascents, but this is a small addition over 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: 'Search the board's climb catalogue with filters.' It also names the sibling it is not, boardsesh_recommend_climbs, making the tool's role clear among a large sibling set.

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 explicitly says to use this tool when the user wants to find specific climbs by name, grade, benchmarks, popularity, or sent status, and directs recommendation-style requests to boardsesh_recommend_climbs. This is strong when-to-use guidance with an alternative.

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