Weatherbit MCP by usefulapi

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's added value is the quota cost, the paid-tier prerequisite, and the forecast horizon — exactly the operational context an agent needs. Return format beyond the named field groups is not covered, but the annotation floor makes that acceptable.

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, no filler. The capability statement leads and the constraint/cost caveat follows, which is the right ordering for an agent scanning for eligibility.

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 naming the included field groups (soil, evapotranspiration) partially compensates by signaling what comes back. Missing only a note on response shape or the fixed 8-day horizon length per entry, but the essentials for a correct call are present.

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% with ranges and a units enum fully documented, so the schema carries parameter meaning entirely. The description adds no coordinate or units semantics of its own; 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 (read) and resource (8-day agriculture forecast) and names the distinguishing payload (soil and evapotranspiration fields). This clearly separates it from weatherbit_agriculture_history and the general daily/hourly forecast 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?

Gives concrete usage conditions — it consumes Weatherbit quota and requires agriculture API access (Business/Enterprise) — which tells an agent when it is even callable. It stops short of explicitly naming alternatives (e.g. use daily_forecast if agriculture access is unavailable).

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 as read-only and open-world, and the description adds meaningful behavioral context beyond that: quota consumption, agriculture API access requirement, and the end-date-exclusive date range. It does not cover return format or rate-limit specifics, but the added constraints are substantial.

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-load the operation, limits, and prerequisites with no wasted words. The most important constraints appear immediately.

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 historical weather retrieval tool with no output schema, the description covers scope, date-range limits, quota, and access prerequisites. It does not describe the returned fields, but the core invocation constraints are adequately covered.

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 high at 83%, so the schema already explains most parameters. The description still adds value by clarifying the hourly maximum of 7 days (not present in the schema) and reinforcing the 31-day limit and exclusive end date.

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: read agriculture weather history, with daily or hourly granularity. It is clear what the tool does, but it does not explicitly distinguish the resource from siblings like weatherbit_daily_history or weatherbit_energy_history.

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 useful usage conditions: historical API quota is consumed and agriculture API access is required. However, it does not say when to choose this tool over sibling history 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.

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

Annotations already cover read-only and open-world behavior, but the description adds non-obvious operational context: quota consumption and a subscription-tier gate that would otherwise surface only as a runtime error. It stops short of noting rate limits or response shape, which is acceptable coverage.

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, no waste, and the capability statement is front-loaded ahead of the cost/access caveats.

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?

Covers output nature (hourly AQI and pollutant values), horizon, cost, and access requirements with no output schema to lean on. Minor gaps remain: default value for 'hours' and whether location is resolved by coordinates only.

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 67% with lat/lon documented but 'hours' carrying only min/max bounds. The phrase 'up to 72 hourly' effectively defines what 'hours' means (number of hourly forecast steps), compensating for the schema gap.

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 ('Read'), resource ('hourly AQI and pollutant forecasts'), and scope ('up to 72'). The forecast framing implicitly separates it from weatherbit_current_air_quality, though no sibling is named 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 a prerequisite (air-quality API access on Business/Enterprise) and a cost note (consumes quota), which helps decide whether to call it. It does not say when to prefer this over weatherbit_current_air_quality or how to choose a horizon, leaving 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?

The description adds two behavioral facts the annotations do not carry: the call consumes Weatherbit quota and requires Business/Enterprise air-quality API access. That is exactly the kind of cost/prerequisite context that matters for a read-only external API call. It stops short of describing rate limits or response shape, keeping it at a 4.

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

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

Two short sentences with zero filler; the capability statement is front-loaded and the cost/prerequisite constraint follows immediately. Every clause 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 two-parameter read tool with no output schema, the description covers what is returned (AQI plus pollutants), the quota cost, and the plan requirement. Only minor gaps remain, such as units or a hint about the response envelope, which the annotation set does not otherwise supply.

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% with both lat and lon fully documented including bounds, so the schema carries parameter meaning. The description adds nothing about coordinates (e.g., precision or whether a city name is accepted), which is acceptable at the baseline for full coverage.

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 — 'Read current AQI and pollutant concentrations' — which clearly separates it from forecast and history siblings by the word 'current'. It doesn't explicitly name an alternative tool, but the resource and temporal scope are unambiguous.

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 word 'current' signals the now-cast case and the access note implies a prerequisite check. There is no explicit 'use this instead of weatherbit_air_quality_forecast when...' routing guidance and no exclusions.

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 and openWorldHint, so the safety profile is covered; the description adds genuinely non-obvious operational facts — it consumes Weatherbit quota and requires a commercial-use subscription. It stops short of describing the response payload, which matters since there is no 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?

Two short sentences, zero filler, with the core action front-loaded and the cost/eligibility caveat second. Nothing is repeated from the title or schema.

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 three-parameter read with full schema coverage, the description supplies purpose, cost, and licensing caveats. The only gap is return-value shape, which the absent output schema leaves undescribed, but the tool's simplicity limits the risk.

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%, with lat/lon bounds and the M/I/S unit enum fully documented in the schema. The description only restates that a coordinate is required, adding no format or defaulting nuance beyond structured fields, so 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 ("Get the latest weather conditions for a coordinate"), which separates it from forecast and history siblings by the word "latest"/"current". It does not explicitly name the nearest lookalike, weatherbit_current_air_quality, but the resource wording is clear enough that an agent can distinguish the two.

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: the coordinate scoping suggests point queries, and the quota/subscription note is an eligibility constraint rather than guidance on when to pick this over daily_forecast or hourly_forecast. No exclusions or explicit alternative routing are given.

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

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

Annotations already cover read-only and open-world behavior, and the description adds two things they don't: the call consumes Weatherbit quota, and the usable horizon is plan-dependent. It doesn't mention rate limits or what happens when days exceeds the plan horizon (error vs truncation), which keeps it from a 5.

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

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

Two short sentences, zero filler, with the capability stated first and the cost/plan caveat second. Every clause carries information an agent needs.

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 lists the returned field categories, and it flags the quota cost and plan-dependent horizon. The main residual gap is behavior at the horizon boundary and the default value of days.

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 75%; lat, lon, and units are documented in the schema, while 'days' has no schema description. The phrase 'up to 16 daily forecasts' does convey the practical ceiling for days, but nothing is said about default day count or how days interacts with plan horizon.

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 ('Get up to 16 daily forecasts') and enumerates the returned fields (temperature, precipitation, wind, conditions). The word 'daily' implicitly separates it from hourly/minutely/current siblings, but no sibling is named 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?

There is no guidance on when to choose daily over weatherbit_hourly_forecast, weatherbit_current_weather, or the agriculture/energy variants, and no exclusions or prerequisites. The only contextual note is a quota/plan caveat, which is about cost, not selection.

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 safety (readOnlyHint, openWorldHint) and the description adds real behavioral context beyond them: an entitlement prerequisite (historical-data subscription) and a metering caveat (quota can count multiple requests for the range). These are exactly the failure modes an agent needs warned about before calling. It stops short of saying what happens if the range exceeds 31 days.

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

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

Two short sentences, front-loaded with the core operation and its hard limit before the quota and entitlement caveats. No filler or restated title.

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, but all parameters are documented at full coverage and the description supplies range limits, entitlement, and quota behavior for a non-destructive read. Only the error/behavior when the 31-day or subscription constraint is violated is left 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%, so all five parameters are self-documenting, including the enum for units and the exclusive-end_date rule. The description's restatement of the 31-day and exclusive-end constraints duplicating the schema means it adds no new parameter-level meaning; 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 (read) and a specific resource (daily historical weather) with a scope constraint (at most 31 days). The word 'historical' implicitly separates it from the forecast siblings, but no sibling is named, so an agent must infer the routing.

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 hard constraints (31-day cap, end date exclusive, subscription requirement) so the agent knows when the call is valid, but never says when to prefer this over weatherbit_agriculture_history or weatherbit_energy_history, which likely return overlapping daily history for their domains. Usage is implied rather than routed.

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. The description adds useful context beyond that: it consumes Weatherbit quota and requires energy API access at the Business/Enterprise tier. It does not explain errors, rate limits, or response behavior, but it meaningfully covers cost and access.

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 purpose, then cost/access constraints, then a parameter default. Every sentence adds distinct value with no 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 read-only forecast tool with no output schema, the description covers purpose, quota, access tier, and threshold defaults. It remains incomplete on the tp parameter semantics and forecast horizon, which matter 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 60%, with lat, lon, and units documented in the schema. The description adds the important threshold default of 18 C, compensating for one undocumented parameter, but it does not explain the tp enum values 'daily' and 'hourly' beyond their names.

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 and resource: 'Read degree-day and irradiance forecasts.' This clearly distinguishes it from general weather forecast siblings and from weatherbit_energy_history, but it does not explicitly name alternatives or clarify forecast scope such as daily vs. hourly.

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 notes quota consumption and Business/Enterprise access requirements, which implies this is a metered, premium forecast tool. However, it gives no explicit guidance on when to use this instead of weatherbit_energy_history, weatherbit_daily_forecast, or other 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 cover safety (readOnlyHint, openWorldHint), and the description adds real context beyond them: quota consumption, an access prerequisite, and the exclusive end-date boundary. It stops short of saying what a quota miss returns or how failures surface, so it is strong but not exhaustive.

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?

A single dense sentence with zero filler; the range constraint and the quota/access caveats are front-loaded where an agent will see them 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?

With no output schema, 7 parameters, and one fully undocumented parameter (threshold), the description should say more about what comes back and what threshold does. The access and quota notes are good, but the parameter story is incomplete for a tool of this complexity.

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 71%, so the baseline is around 3. The description reinforces end_date exclusivity and ties the 31/7-day cap to resolution, but the undocumented `threshold` parameter (no schema description, not mentioned in prose) and the meaning of `tp` values are left unexplained.

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: reads historical degree-day and irradiance data, with scope limits (end date exclusive, 31 days / 7 hourly). An agent can distinguish it from weatherbit_energy_forecast by the word 'historical', though the sibling is never named 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 useful prerequisites (requires energy API access) and a cost warning (consumes historical API quota), plus the max range per temporal resolution. But it never says when to pick this over weatherbit_daily_history or weatherbit_energy_forecast, which is the main routing ambiguity for an agent.

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 this is a read-only, open-world operation, so the bar is lower, and the description adds genuinely useful context beyond them: the call consumes metered quota and requires a commercial plan. It stops short of saying anything about the response shape, timezone handling, or quota cost per call.

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

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

Two short sentences, zero filler, with the capability stated first and the cost/prerequisite second. Nothing repeats the schema or annotations.

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 should say more about what a forecast entry contains or what the 240 entries represent (hourly steps from when, in what timezone). It adequately covers cost and prerequisites but leaves the return value underspecified for a data-returning 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?

Schema description coverage is 75%, with lat/lon/units documented inline; only 'hours' lacks a schema description, and the description's 'up to 240 hourly forecasts' partially backfills that. With the schema doing most of the work, 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 ('Get') and resource ('240 hourly forecasts'), and the hourly/240-hour scope implicitly separates it from weatherbit_daily_forecast and weatherbit_minutely_forecast. It doesn't name those siblings or state the location-based scope explicitly, but the purpose is unmistakable.

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 a real selection constraint — Weatherbit quota consumption and a required commercial plan — which helps an agent decide whether it can use this at all. However, it never says when to prefer hourly over daily or minutely forecasts, leaving the core choice to inference from the tool names.

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. The description adds useful context about quota consumption and commercial plan requirements, but does not describe the shape or limitations of the returned forecast.

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

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

Two short sentences, front-loaded with the core purpose and followed by the operational caveat. There is no wasted language.

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

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

For a forecast tool with no output schema and fully documented parameters, the description covers purpose, input scope, and key operational constraints. It could say more about the returned precipitation fields, but the core information is present.

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 lat, lon, and units are fully documented in the schema. The description adds no parameter-level meaning beyond what is already structured, making the baseline of 3 appropriate.

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

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

The description names a specific verb and resource ('Get the 60-minute precipitation forecast') with a clear temporal scope and required input ('for a coordinate'). This distinguishes it well from sibling tools like hourly, daily, and current weather forecasts.

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 states a prerequisite ('requires the corresponding commercial plan') and warns about quota consumption, but does not explicitly say when to use this versus siblings such as weatherbit_hourly_forecast or weatherbit_current_weather. Usage is implied rather than guided.

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 genuinely new context: it consumes one standard request against the quota and performs no weather lookup, which is exactly the cost/consumption detail annotations cannot express. Return format is still unstated.

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 the resource front-loaded, followed by cost and negative-capability notes. No filler, and each sentence carries distinct 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?

For a zero-parameter read tool with no output schema, the description covers purpose, cost, and what it does not do. The only meaningful gap is the shape of the returned counters/reset times, which the agent must discover at call time.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly makes no parameter claims and does not mislead about 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?

Specific verb+resource: 'Read quota counters and reset times' tells the agent exactly what is returned. The line 'No weather lookup is made' implicitly separates it from the eleven forecast/history/current siblings, though it never names 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?

Usage is only implied: an agent infers this is the cheap way to check subscription limits rather than calling a data endpoint. There is no explicit 'use this when...' or 'do not use for...' guidance, so the routing must be reconstructed by the caller.

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