ClimbCast

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context: the data is 'stored' (precomputed, not derived live), 'public' (no auth-gated content), and includes truth-lineage and sufficiency metadata that tells the agent how much to trust the numbers.

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, front-loaded with the verb and resource, and the 'Informational only' caveat placed last where it reads as a qualifier. No filler, though the enumerated payload list is slightly dense.

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 must describe the return shape, and it does name the key fields (truth lineage, data sufficiency, eligibility). For a single-parameter read tool whose annotations cover safety, this is sufficient; only the exact response structure and any pagination/absence behavior remain unstated.

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 schema already documents region_id with an example ('pnw-olympics'), so the description carries no additional parameter burden. Baseline 3 applies; the description neither adds syntax nor omits anything 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?

States a specific verb ('Returns') and a precise resource ('stored public regional forecast accuracy'), and enumerates the payload components (truth lineage, data sufficiency, eligibility). It is clearly distinct from the conditions/objectives siblings, 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?

The phrase 'Informational only' gives a meaningful usage cue — the result is not an authoritative or actionable signal — but there is no explicit when-to-use, when-not-to-use, or named alternative among get_objective_conditions, get_route_conditions, or search_objectives.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds useful framing ('public' data, informational-only, provenance included) but says nothing about auth, rate limits, or what happens with an unknown slug.

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 the resource and payload front-loaded and no filler. The format restatement is mildly redundant with the schema, keeping it just short of a 5.

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 what comes back (summit weather, provenance, timestamps), covering the return-value gap. It is nearly complete for a simple two-parameter read tool, missing only the sibling routing guidance.

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 documents slug provenance and the json/markdown format with a default. The description's mention of 'JSON or markdown' simply restates the schema, adding no new syntax or constraint details. 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 (returns conditions for a covered objective) and enumerates the payload: summit weather, source provenance, timestamps. This distinguishes it reasonably from search_objectives, but it does not explicitly contrast with get_route_conditions, the closest 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?

'Informational only' signals this is a read for reference rather than an action, and the required slug ties it to lookup flow. However, it never states when to choose this over get_route_conditions or get_forecast_accuracy, leaving alternative selection 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 cover safety (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context beyond them: the fixed seven-day window, that values are anchored to the route high point and aspect, that source provenance and timestamps accompany the data, and the 'informational only' caveat that warns against treating it as authoritative.

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 is returned and the scope, with no filler. Every clause carries information the agent can use.

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 return-value burden and does reasonably well: it names the seven-day range, the anchoring geometry, and the inclusion of provenance and timestamps. It does not mention the format parameter's effect on the response or any limits/errors, leaving a small 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 slug, route_id, and format are fully documented in the schema itself. The description adds no additional meaning about parameter values, formats, or interactions, 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?

States a specific verb (Returns) and resource (public route conditions) with scope: seven days, anchored to the route high point and aspect, plus provenance and timestamps. It is clearly distinguishable from get_objective_conditions by resource, though it does not explicitly name the sibling to route the agent.

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: 'Informational only' signals this is a read-only informational lookup rather than a decision tool, but there is no explicit statement of when to use this versus get_objective_conditions or get_forecast_accuracy, nor any prerequisite 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, idempotentHint, non-destructive, and closed-world behavior. The description adds scope context ('current public scope') and that results are informational only, which is useful beyond the annotations, though auth and rate-limit behavior are not covered.

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 concise sentences, front-loaded with the core search action and scope. Every sentence adds some useful context with 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 rich annotations, a fully documented schema, and no output schema, the description is largely complete. It states the catalog scope and informational nature, though it does not discuss pagination behavior beyond the limit parameter.

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 query, limit, region, and activity. The description repeats name/alias matching and region enum values but adds no syntax or format details 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?

States a specific verb ('Searches'), resource ('public coverage catalog'), and matching scope ('by name or alias'), with optional filters. This clearly distinguishes it from sibling get_* condition/forecast 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 phrase 'Informational only' gives a useful usage caveat, and optional filters are noted. However, there is no explicit guidance on when to prefer this over sibling tools or when not to use it.

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