Weather That Doesn't Suck

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the description is free to add substantive behavior and does: it explains the effort-adjustment model (a runner is warmer than someone standing still at the same feels-like) and describes the output shape (short practical advice followed by the underlying weather). The opaque 'same rules as the website's outfit card' reference is the one weak spot.

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?

It is front-loaded with the core purpose and kept to three sentences with no padding. The middle 'website's outfit card' clause is the only sentence that does not clearly earn 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?

Despite 9 parameters (none required) and no output schema, the description tells the agent what comes back — practical advice plus the weather it depends on — and the schema fully documents every input including defaults and time-parsing behavior. Nothing essential to calling the tool correctly is missing, and the remaining gaps are minor.

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 every parameter — including the nested preferences object, units, and time decoding rules — is already documented in the schema. The description only restates intensity and preference examples, adding little beyond that. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource (what to wear) and scopes it to an activity, time, and place, with the outfit returned alongside the weather it rests on. It is clearly differentiated from weather siblings like get_forecast or outdoor_activity_weather because it produces clothing advice, though it never names a sibling explicitly.

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

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

Usage is implied rather than stated: the agent can infer it should be called when a wear recommendation is wanted, and it notes what is optional (intensity, preferences). There is no explicit when-to-use, when-not-to-use, or routing against the weather siblings, and the reference to 'the website's outfit card' points outside the toolset.

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, idempotent, open-world safety profile, so the description's value is in the behavior it adds: it discloses the response structure (facts labelled forecast or formula, inferences each with basis and confidence, an explicit list of unknowns) and failure behavior ('if it cannot tell what was asked it says so and gives the general picture'). That is substantive disclosure beyond the structured fields, and none of it contradicts 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 purpose is front-loaded in the opening clause and every sentence carries information about capability, output shape, or fallback. It runs long for a tool description, but the length is earned by the breadth of topics covered; there is little 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 9 optional parameters, no output schema, and full schema coverage, the description supplies the missing return-value semantics (facts vs inferences vs unknowns) and the ambiguity fallback, which an agent needs to interpret results. Minor gaps remain, such as how it resolves location vs latitude/longitude conflicts, but those are documented in 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 schema already documents every parameter including enums, units defaults, and time formats. The description only adds 'pass the question as asked, or a topic' and the topic list, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — explaining weather in plain conversation terms — and enumerates the kinds of questions it answers (feels-like, rain impact on a hike, mud, frost, pressure). This clearly separates it from data-fetching siblings like get_weather or get_forecast, which the description never names but implicitly contrasts by emphasizing reasoning over raw values.

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

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

Usage is implied rather than stated: the conversational framing ('for conversation', 'pass the question as asked, or a topic') signals when this tool fits, but there is no explicit when-to-use/when-not guidance and no named alternatives (get_weather, get_trail_weather, clothing_recommendation) that an agent should prefer for simple lookups.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds the non-obvious behavioral fact that this is a legacy compatibility shim whose real-world recommendation is to use another tool, which is exactly the kind of context annotations cannot express.

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 with zero waste; the compatibility framing is front-loaded so the agent immediately understands the tool's status before reading the mechanics.

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 one-parameter, no-output-schema tool the description covers purpose, origin of the id, and preferred alternative. It stops short of describing the returned weather payload, which is a minor gap given no output schema exists, but the annotations already cover the safety and idempotency profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single `id` parameter is fully documented in the schema, including its format example. The description merely restates that the id comes from `search`, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Returns the weather for an id from `search`') and explicitly positions itself against the sibling `get_weather`, so an agent can distinguish it without opening any schema.

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

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

It names the use case ('Compatibility tool for ChatGPT connectors') and the exclusion with the preferred alternative ('For real use prefer get_weather'), leaving nothing to inference about when to pick this tool over the sibling.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it explains that windows are stretches rather than exact hours, that equally-good start times are collapsed, that a uniform day is reported as such, and that a bad day yields a least-bad stretch with a reason. This is exactly the behavioral context an agent needs to interpret the result.

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?

Purpose and output shape are front-loaded, then usage examples, then the date input hint. It is a bit long and repeats the 'says so when the day is uniform / nothing is good' idea, but every sentence still carries usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain the return shape, and it does: best window, alternate, bad stretch, each with a short reason, plus fallback behavior on poor days. With 8 parameters all schema-documented and annotations covering safety, nothing an agent needs to call and interpret this tool 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 every parameter is already documented, including date syntax, units, and activity enums. The description largely restates the date guidance ('Give a date such as Saturday, tomorrow or 2026-10-03') rather than adding new meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Finds the best time on a day for an activity') and immediately enumerates what it returns (best window, alternate, bad stretch). This clearly separates it from forecast/weather siblings like get_forecast or outdoor_activity_weather, which report conditions rather than a recommended time window.

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?

Gives concrete trigger phrases ('when should I go?', 'what's the best time Saturday?') and the acceptable date forms, which tells the agent exactly when this tool is the right pick. It stops short of naming an alternative sibling or stating when not to use it, so it does not reach 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 cover safety (readOnly, idempotent, non-destructive, openWorld), and the description still adds real behavioral context: the ~7-day horizon, that the tool admits rather than guesses beyond it, and that a bare hour without AM/PM is refused instead of inferred. This is exactly the kind of guardrail behavior an agent needs.

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?

Front-loads the purpose with illustrative phrasing, then moves to parameters, return shape, and the horizon limit. The example phrases cost a little space but earn it by clarifying accepted time formats; overall tight and well-ordered.

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?

No output schema exists, so the description carries the burden of describing returns and it does so (one-line summary, temperature range, rain, wind, actionable conditions, hourly and daily rows). Combined with the horizon caveat and time-format guidance, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds value by specifying the intended invocation pattern (start_time required in practice, end_time or duration_hours as optional alternatives). It complements rather than repeats the rich per-parameter schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (forecast over a time period) and illustrates scope with concrete query examples ('this weekend', 'between 6 PM and midnight'). It implies a distinction from the current-conditions sibling get_weather via the time-range framing, but never names an alternative explicitly.

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

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

Gives clear context for invocation ('What's Saturday looking like?', 'this weekend') and tells the agent the canonical call shape: give start_time, optionally end_time or duration_hours. It stops short of naming when to prefer sibling tools like find_best_weather_window or get_trail_weather.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful context: it returns a two-hourly timeline plus a bottom line, and it flags that it does not know terrain/shade/exposure and says so. It does not discuss rate limits, auth, or cost.

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?

Front-loads the purpose in the first clause, then enumerates outputs and inputs. The long output enumeration is dense but earns its place given there is no output schema; the only mild cost is a slightly run-on feel.

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 19-parameter, no-output-schema tool, the description covers input modes, temporal coverage, timeline granularity, and caveats well. Return-format explanation is necessarily present since no output schema exists, and the coverage is adequate though it does not discuss missing-data or error behavior.

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 19 parameters in detail. The description adds only marginal framing, restating the trail_id-or-route choice and the pace-or-duration choice that the schema already spells out. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("weather for a trail over time") and immediately distinguishes the sampling model from a point forecast ("sampled along the trail rather than at one point"). It is clear what the tool produces, though it never names the very similar sibling route_weather, so the agent must infer that distinction.

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

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

Gives concrete entry conditions: supply trail_id (routing to list_trails) or a route, plus start_time and either a pace or total_duration_hours. It also states a limitation (no terrain/shade/exposure knowledge). It stops short of explicit when-not guidance or naming an alternative tool for point forecasts.

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/openWorld/non-destructive, so the description is free to add the harder context and does: `data.current` distinguishes station observation, model estimate, and forecast hour, `data.alerts.status` distinguishes a verified "no alerts" from an unchecked one, and results carry sources, data age, and cache status. These are trust-critical traits no annotation conveys.

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?

Front-loaded with the core purpose and scoped tightly, with no filler paragraphs. It runs long across several clauses and quote-heavy examples, but each sentence carries distinct routing or behavioral information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining the meaning of key response fields (`data.current`, `data.alerts.status`) and the provenance/age/cache behavior of answers. An agent knows what to expect back and how much to trust it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents hours, units, location, latitude, and longitude. The description adds no parameter-level detail beyond that, which matches the baseline 3 when structured fields do 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 gives a specific verb+resource (plain-language weather for a place) and enumerates exactly what the answer contains: one sentence, current conditions, 24 hours, 7 days, alerts. It also distinguishes itself from the nearest sibling by naming outdoor_activity_weather and contrasting "what is it?" with "should I?".

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 supplies trigger phrases ("what's the weather", "do I need a jacket", "is it going to rain") and an explicit exclusion with a named alternative for outdoor-decision queries. This is exactly the when/when-not/alternative structure the rubric rewards.

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, openWorld, so the safety profile is covered. The description adds meaningful behavioral context by naming the exact fields returned and the 'known trails' scope, which is what makes the empty-result fallback necessary.

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: purpose and return fields first, then the downstream id usage, then the fallback. No filler and the most decision-relevant information leads.

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?

No output schema exists, yet the description compensates by naming the returned fields (name, length, bounds, exposure coverage) and explaining what to do when a trail is missing. Complete for a zero-parameter discovery tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case. The description still adds value by establishing the id/trail_id naming contract consumed by downstream tools, linking this call's output to other tools' inputs.

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 ('Lists the trails WTDS knows by name') and immediately enumerates the returned attributes (length, bounds, exposure data). This distinguishes it from the sibling search/fetch tools that return arbitrary web results.

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 routes the agent onward: use a trail's id as trail_id in get_trail_weather or route_weather, and if a trail is absent, send the route itself. Both the when-to-use and the fallback are named, leaving nothing 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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it separates forecast from advice, discloses what it infers (mud, ice, fog) versus what it cannot know (trail surface), and states that an official weather warning overrides everything. It also effectively documents the return shape in the absence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the output contract before the input guidance, and almost every clause carries information. The opening 'Our flagship tool' is marketing filler that does not help selection, and the middle run-on sentence about inference versus unknowables is dense, but overall the length is justified by the tool's complexity.

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?

No output schema exists, so the description carries the burden by enumerating the verdict values and the returned fields. Combined with the input guidance and the explicit warning-override rule, an agent has everything needed to call this correctly and interpret the result.

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, but the description adds genuine semantics on top: naming a whole day makes the tool find and judge the best window inside it, and the relationship between start_time and duration_hours as an alternative to a natural-language phrase. The activity enum is restated from the schema rather than extended, which caps this at 4.

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 transformation of a specific resource: weather turned into a go/no_go verdict for a named outdoor activity, and enumerates the returned fields (reason, temp/feels-like, rain, wind, sunset, what to wear, concerns). An agent can distinguish it from get_forecast or get_weather without opening a schema.

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

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

Explicitly routes the WHEN-to-go case to a named sibling: 'To find WHEN to go, use find_best_weather_window.' It also explains the accepted forms of the temporal input (start_time + duration_hours, or a phrase, or a whole day which triggers best-window selection), so the calling conditions are fully specified.

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/openWorld, so the safety profile is covered; the description goes further with real behavior: progress position is never stored or logged, start_time is ignored when progress is given, a bare hour is refused rather than guessed, GPX input is capped near 450 KB, and units default by region. These are non-obvious traits an agent cannot infer from structured fields.

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?

Front-loaded with the core purpose and the routing decision before any parameter talk, and the return summary and sibling pointer come last. The quoted 'Not "the weather on the trail" but...' sentence is rhetorically useful but slightly padded against an otherwise dense, well-ordered description.

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 an 18-parameter, zero-required, nested-input tool with no output schema, the description covers the input modes, the two execution modes, timing semantics, and even the return shape (checkpoints with arrival time, place, weather and light, the changes, and a bottom line). Nothing essential 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: it enumerates the mutually exclusive route-input families (trail_id, GPX, GeoJSON, polyline, coordinates, place names) and states that trail_id is used OR one of the route formats. It also explains the pace-vs-total_duration_hours relationship and how break/rest inputs stretch arrival times.

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 — weather encountered along a route at each checkpoint's arrival time — and sharpens it with the contrast between 'the weather on the trail' and 'what will I encounter, where, and when'. It also names the sibling get_trail_weather and the condition that selects it, so an agent can route between them without opening a schema.

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

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

Explicitly covers two usage modes: a planned trip (start_time + pace) and a person already on the route (progress, answering for the remainder from now). It routes to get_trail_weather for an hour-by-hour timeline. It doesn't distinguish itself from other siblings like find_best_weather_window or outdoor_activity_weather, so it stops short of full when-not 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful pipeline context: it returns ids that must be passed to fetch, which the annotations do not convey.

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 compatibility role and the correct alternative, 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?

For a single-parameter lookup with no output schema, the description supplies the missing return-value behavior (ids for fetch) plus routing guidance. Nothing an agent needs to call or avoid it is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single query parameter is fully documented in the schema with an example. The description reframes it as a place-matching query but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (finds) and resource (places matching a query), and immediately distinguishes itself from fetch by noting it returns ids to pass along. The role as a compatibility shim is unambiguous, so an agent can tell it apart from the direct-answer weather 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?

Explicitly says this is a compatibility tool and instructs the agent to prefer get_weather, outdoor_activity_weather and others for real use. Both the when-to-use (compatibility path) and when-not-to-use conditions are named.

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