Server Quality Checklist

Tool Scores

• air_compare_locationsB
  3.1/5.0
  Behavior2/5

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

  Annotations already cover read-only/idempotent behavior, so credit is only for added context. The phrase 'default: AirGradient public sensors' conflicts with the schema requiring 'locationIds', creating confusion about necessary inputs. No further behavioral details such as response format or limits are disclosed.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no verbosity. It front-loads the core function, though the parenthetical default could be clearer given the required parameter. Minor structural improvement needed.

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

  Completeness2/5

  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 should explain what the tool returns. It does not. The conflicting mention of a default also undermines completeness, leaving the agent uncertain about required inputs and expected output.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what the schema already provides, justifying the baseline of 3.

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

  Purpose5/5

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

  States a specific verb ('Compare') and resource ('current readings') across multiple location IDs, clearly distinguishing it from single-location tools like air_current_reading. The scope and subject are unambiguous.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives like air_current_reading or air_search_public_sensors. The only hint is the default to AirGradient public sensors, but no explicit conditions or exclusions are given.

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

• air_daily_summaryB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations by disclosing the version limitation: v0.1 returns only the current reading framed as a daily snapshot, with richer aggregation deferred to v0.2. This is exactly the kind of caveat an agent needs to set expectations correctly.

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

  Conciseness5/5

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

  Two sentences with zero filler. The core purpose is front-loaded in the first sentence, and the version caveat is appended in the second. Every word earns its place.

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

  Completeness3/5

  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 burden of explaining return values, yet it never states what a synthesized daily snapshot contains (AQI metrics, pollutant breakdown, units, etc.). The tool is simple and read-only with strong annotations, so the gaps are not severe, but the relationship to air_current_reading and the actual snapshot contents remain unexplained.

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

  Parameters2/5

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

  Schema description coverage is 67%, covering date and privacy_mode with meaningful descriptions, but locationId is completely undocumented in both schema and description. The description adds no parameter information at all, leaving the agent to guess what identifier locationId expects and what 'synthesized daily snapshot' means in terms of privacy_mode behavior.

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

  Purpose4/5

  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: 'Returns a synthesized daily snapshot for a location,' which clearly states the tool's purpose. However, the honest caveat that 'v0.1 returns the current reading framed as a daily snapshot' blurs the boundary with the closely named sibling air_current_reading, so differentiation is imperfect.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. The most similar sibling, air_current_reading, is never mentioned, which is a significant omission given the description admits v0.1 effectively returns the current reading. The 'daily snapshot' framing implies a use case but never states when to prefer this tool over air_trend or air_current_reading.

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

• air_search_public_sensorsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe/read-only nature is covered. The description adds the behavior of returning a 'curated list' and a 'hint' (not raw search results), which clarifies the tool's lightweight scope. However, it doesn't disclose details like filtering logic, rate limits, or what 'well-maintained' means.

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

  Conciseness4/5

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

  The description is a single sentence, concise and front-loaded with the core purpose. It earns its place by stating what the tool returns and provides a pointer to additional resources. No redundant information.

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

  Completeness3/5

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

  Given the tool's simplicity (no required params, no output schema, annotations cover safety), the description is adequate but not rich. It mentions the hint to the map, which adds context, but doesn't explain the structure of the 'curated list' or how the query parameter influences results beyond 'hint for the human.' For a discovery helper, this is reasonably complete, yet could specify that it's a lightweight lookup rather than an exhaustive search.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters are fully described in the schema. The description adds minimal value beyond that—'query' and 'privacy_mode' are already well-documented. Baseline 3 is appropriate because the schema does the heavy lifting and the description doesn't add further semantics.

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

  Purpose4/5

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

  Description clearly states the tool's purpose: 'Helper for discovering AirGradient public sensors.' It specifies the resource (public sensors) and the action (discovering). The mention of returning a 'curated list' plus a hint distinguishes it from sibling tools like air_list_devices or air_current_reading, though it doesn't explicitly name a sibling to contrast with.

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

  Usage Guidelines3/5

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

  The description implies usage for discovering public sensors but doesn't provide explicit when-to-use guidance or contrast with alternatives. The 'hint to the AirGradient map' suggests a complementary action but doesn't state when to prefer this over other tools. No exclusions or alternatives are mentioned.

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

• air_quickstartA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful context about personalization based on current agent/env state, but doesn't disclose any further behavioral details like response shape or side effects, which is acceptable given the annotation coverage.

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

  Conciseness5/5

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

  Two short sentences, each earning its place: the first defines the outcome, the second defines the trigger condition. No redundancy or filler.

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

  Completeness3/5

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

  For a simple quickstart tool with two optional enum parameters and no output schema, the description covers the core function and usage cue. However, it omits guidance on the client parameter and what the 3 steps might look like, leaving some ambiguity for an agent deciding how to invoke it correctly.

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

  Parameters2/5

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

  Schema coverage is only 50%: privacy_mode has a description in the schema, but client has none. The tool description does not explain what client should be set to or how it affects the walkthrough. The enums are listed but their use cases are not elaborated, leaving a gap that the description fails to fill.

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

  Purpose4/5

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

  The description states a specific verb ('Returns') and resource ('personalized 3-step setup walkthrough'), and ties it to a clear user intent ('how do I use this?'). It is distinguishable from generic help tools, though it doesn't explicitly differentiate from sibling air_onboarding or air_demo.

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

  Usage Guidelines4/5

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

  The description gives a clear when-to-use trigger ('Call this first when the user asks...') and implies priority ('first'). It does not mention when not to use it or name alternatives, but the provided context is actionable enough.

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

• air_agent_manifestA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral details beyond the returned contents, but it does not contradict the annotations. It provides a moderately useful inventory of what the manifest includes.

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

  Conciseness5/5

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

  The description is a single, tightly packed sentence that front-loads the resource name and immediately lists the contained elements. Every item in the list earns its place, and there is no fluff or repetition.

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

  Completeness4/5

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

  For a read-only manifest tool with two optional parameters and no output schema, the description covers the essential contents comprehensively. It could benefit from noting that the return is a structured object or listing example fields, but the listed items provide enough context for an agent to decide to call it.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both 'client' and 'privacy_mode' fully explained in the schema (including enums). The description itself does not add meaning beyond what the schema provides, 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.

  Purpose5/5

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

  The description uses the specific verb 'Returns' with a definite resource ('the wellness-air agent manifest') and enumerates its contents (tool list, supported clients, env vars, etc.). This clearly distinguishes it from sibling tools like air_current_reading or air_capabilities, which return different resources.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. While the description lists what is returned, it does not mention scenarios, prerequisites, or how this differs from siblings such as air_capabilities or air_quickstart. The agent must infer its role as a general overview.

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

• air_capabilitiesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the operation's safety profile. The description adds context about listing configured providers via env vars, which gives a slight behavioral clue about data sourcing, but no additional behavioral traits beyond what annotations convey are disclosed.

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

  Conciseness5/5

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

  The description is a single, near-emotional sentence that front-loads the verb 'Lists' and enumerates exactly what is returned. There is zero wasted wording, making it highly efficient and easy to parse.

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

  Completeness4/5

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

  For a simple, read-only, optional-parameter inspection tool with a fully documented schema, the description is adequate. It covers the tool's purpose clearly. Minor gaps like explicitly stating that the operation requires no mandatory parameters or that it does not modify state are already implicit in the annotations and parameter count, so nothing critical is missing.

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

  Parameters3/5

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

  The schema has 100% description coverage, including a clear explanation of the privacy_mode enum and its effect on output. The tool description itself does not add any parameter-specific meaning beyond the schema, which is sufficient; baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists supported providers, configured providers (via env vars), metrics, and privacy modes, which is a specific verb-resource combination. It distinguishes itself from siblings like air_current_reading or air_connection_status, which focus on current data or connection state, by indicating this is an enumeration/capability inspection tool.

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

  Usage Guidelines2/5

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

  No explicit guidance is provided about when to use this tool versus alternatives. The description only states what it lists; it does not mention scenarios like 'to check available integrations' or 'when you need to see what providers are configured' or any exclusions. The agent is left to infer the intended context.

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

• air_current_readingA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safe-read profile is fully covered. The description adds useful context about the default public sensor and location constant, but does not disclose additional behavioral traits such as rate limits, staleness of data, or failure behavior. No contradiction with annotations.

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

  Conciseness5/5

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

  Two tight sentences with zero filler. The primary purpose is front-loaded, and the default-location behavior is packed into the second sentence efficiently. Every word earns its place.

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

  Completeness4/5

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

  For a simple read-only tool with 0 required params, rich annotations, and fully documented schema, the description is nearly complete. It covers the operation, default behavior, and the key parameter path (locationId). It does not need to explain return values since output schema is absent, though a brief note on response shape could push it to 5.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter (provider, locationId, privacy_mode) having meaningful descriptions including enums and the default provider. The description's prose redundantly mentions locationId but adds no meaning 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.

  Purpose4/5

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

  The description states a specific verb ('Fetches'), resource ('most recent air-quality reading'), and scope ('for a location'). It is distinguishable from siblings like air_daily_summary and air_trend by the 'most recent reading' framing, though it does not explicitly name or contrast those alternatives.

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

  Usage Guidelines3/5

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

  Usage context is implied by the purpose ('most recent reading' = current conditions snapshot), and the default behavior (AirGradient public sensor, default location) gives a sense of when it applies. However, there is no explicit when-to-use or when-not-to-use guidance, nor any reference to sibling tools like air_aqi_check for alternative needs.

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

• air_aqi_checkA
  3.7/5.0
  Behavior3/5

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

  Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints, so the description carries low burden. It adds that the response is intentionally minimal ('just the AQI number + band'), which is useful behavioral context. No contradictions.

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

  Conciseness5/5

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

  A single, front-loaded sentence that states the output and the typical use case with no fluff. Every word serves a purpose.

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

  Completeness3/5

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

  The tool has one required parameter? Actually zero required parameters (both optional), no output schema, and simple structure. The description adequately conveys the minimal response but omits how locationId is determined or passed, and it doesn't describe privacy_mode behavior. Given the simplicity, this is moderately complete but has notable gaps in parameter usage.

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

  Parameters3/5

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

  Schema description coverage is only 50% (locationId lacks a description), and the tool description does not mention either parameter. The description's phrase 'configured location' hints at locationId but doesn't explain its format or usage. The schema covers privacy_mode, but the description fails to compensate for the uncovered locationId, so it edges toward a lower score.

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

  Purpose4/5

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

  The description states the tool returns just the AQI number and band for the configured location, which is a clear verb-plus-resource statement. It implies a streamlined, fast result but does not explicitly name or contrast with sibling tools like air_health_bands or air_current_reading, though the 'just' phrasing hints at a lean scope.

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

  Usage Guidelines4/5

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

  It gives a direct use case: 'is the air OK to go outside?' prompts, which tells an agent when to invoke this tool. It doesn't mention when not to use it or point to alternatives, but the use case is specific and actionable.

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

• air_data_inventoryA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a meaningful behavioral detail beyond annotations: it explicitly states 'no remote calls', which informs an agent about latency and dependency implications. This is valuable context that annotations do not provide.

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

  Conciseness5/5

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

  One sentence with no filler. It front-loads the core function, adds the availability hint detail, and closes with a key behavioral caveat. Every word contributes value.

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

  Completeness4/5

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

  With no output schema, the description appropriately explains what is returned: an inventory of metrics and availability hints. The single optional parameter is fully documented in the input schema. The only minor gap is not describing the response structure, but for a zero-argument invocation this is adequate.

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

  Parameters3/5

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

  Schema coverage is 100% and the single parameter is fully documented with its enum values and the behavioral difference between them. The description adds no parameter-specific information, but the schema alone is sufficient. Baseline 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb 'Returns' and clearly identifies the resource: the inventory of air-quality metrics this connector exposes, plus per-provider availability hints. This distinguishes it from sibling tools like air_current_reading or air_capabilities, making the tool's purpose immediately clear.

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

  Usage Guidelines2/5

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

  No explicit when-to-use guidance or alternative routing is provided. The phrase 'no remote calls' hints that it is a fast metadata operation, but there is no comparison to siblings such as air_capabilities or air_connection_status, leaving the agent to infer the appropriate usage context.

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

• air_privacy_auditA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context about what the tool returns (local storage, provider data, non-logged items, agent rules), which goes beyond annotations. However, it does not disclose details like output format or potential side effects, though none are expected given the read-only nature.

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

  Conciseness5/5

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

  A single, well-structured sentence that packs essential information without any filler. It is front-loaded with the verb and resource, and the list of returned items is comprehensive yet concise.

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

  Completeness4/5

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

  Given the tool's low complexity (one optional parameter, no output schema, and comprehensive annotations), the description covers the core behavior adequately. It explains what the tool returns, and the schema defines the parameter. Minor gaps remain around return format or how privacy_mode affects the output, but these are partially addressed in the parameter description. Overall, this is sufficient for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  The schema description covers 100% of the parameter, including the enum values and their effect (summary omits identifiers, structured/raw return full payload). The tool description itself adds nothing beyond the schema, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description starts with a concrete verb 'Returns' and specifies the exact resource: wellness-air's local storage, provider transmissions, non-logged items, and agent rules. This clearly distinguishes it from sibling tools like air_data_inventory or air_connection_status by focusing on privacy audit content.

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

  Usage Guidelines3/5

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

  The description implies the tool is used to retrieve privacy-related information about wellness-air, but it does not explicitly state when to use it over alternatives or mention any exclusions. Usage context is inferable from the name and content, but no direct guidance is given.

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

• air_connection_statusA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint = false, covering the safety profile. The description adds behavioral value by specifying exactly what the tool reports (providers, default, warnings) and instructing that warnings should be surfaced to the user. This goes beyond annotations and helps the agent understand the operational behavior without any contradiction.

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

  Conciseness5/5

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

  A single, focused sentence that conveys the entire scope: what is reported and that warnings should be surfaced. There is no filler or redundancy; every word earns its place.

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

  Completeness4/5

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

  For a simple read-only tool with one optional parameter and no output schema, the description is sufficiently complete. It tells the agent what data to expect (providers, default, warnings) without requiring detailed return format specification. The only minor gap is the structure of the 'warnings' but this does not block correct use.

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

  Parameters3/5

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

  The input schema fully describes the only parameter 'privacy_mode' with its enum values and explanation. Schema coverage is 100%, so the description adds nothing about parameters. The baseline of 3 applies, and the description appropriately omits redundant parameter details.

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

  Purpose5/5

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

  The description clearly states the tool 'reports which providers are configured, which is the default, and any warnings'. This uses a specific verb ('reports'), identifies the resource (provider configuration), and includes additional output (warnings). It is unambiguous and distinguishes itself from sibling tools like air_measurement or air_health which focus on data rather than connection status.

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

  Usage Guidelines3/5

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

  The description implies usage: this is the tool to call when an agent needs to know the current connection state (providers, default, warnings). However, it does not explicitly state when NOT to use it or mention alternatives. Sibling tools suggest different purposes, so the context is clear but without exclusions the guidance is only implied.

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

• air_health_bandsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context by noting that omitted readings are fetched from the default provider and that the tool returns per-pollutant bands, the worst signal, deduplicated actions, and source citations. This goes beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Two well-structured sentences: the first states the core classification function, the second covers both usage modes and summarizes return values. No filler, every sentence earns its place, and key information is front-loaded.

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

  Completeness4/5

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

  The tool has 7 optional parameters, a complex return concept (multiple bands + actions + citations), and no output schema. The description covers the main return elements and the fetch-fallback behavior, but it does not mention the privacy_mode parameter or potential error cases. Still, it is sufficiently complete for an agent to invoke the tool correctly in most situations.

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

  Parameters3/5

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

  Input schema coverage is 100% with detailed descriptions for every parameter (e.g., 'If omitted, pulled from air_current_reading'). The description itself adds no extra parameter-level details, but since the schema carries full weight, a baseline score of 3 is appropriate.

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

  Purpose5/5

  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: 'Classify PM2.5, PM10, CO2, and VOC readings into WHO 2021 / EPA / ASHRAE / UBA health bands.' This clearly differentiates the tool from siblings like air_current_reading (which fetches readings) and air_aqi_check (which likely computes AQI), making its purpose unmistakable.

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

  Usage Guidelines3/5

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

  The description explains two modes of use ('Pass readings directly, or omit them and the tool will fetch the current reading') and mentions the default provider, but it does not explicitly state when to choose this tool over alternatives such as air_aqi_check or air_health_recommendation. Usage context is implied rather than explicitly contrasted with siblings.

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

• air_list_devicesA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds value by clarifying it's for the configured provider account and charging environment variable requirements for AirThings, but it doesn't disclose return format or pagination. With strong annotation coverage, a 3 is appropriate.

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

  Conciseness5/5

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

  The description is three concise sentences with zero fluff. The main action is front-loaded, followed by a version note and routing to the sibling. Each sentence earns its place with distinct value.

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

  Completeness4/5

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

  Given that this is a read-only list tool with solid annotations and no output schema, the description covers the key points: what it does, scope, version support, and when to use an alternative. Missing a description of return format or pagination, but those might be acceptable for a list tool. The characterization of the sibling is complete.

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

  Parameters2/5

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

  Schema description coverage is exactly 50%, with only privacy_mode having an explicit description. The provider property has an enum but no schema description, and the tool description does not clarify what each provider value does beyond mentioning AirThings. It doesn't explain 'provider account' semantics for the provider parameter, leaving the agent to infer from enum values alone. This deserves a 2 because the description should compensate for the 50% coverage but doesn't.

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

  Purpose5/5

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

  The description clearly states it 'Lists devices owned by the configured provider account,' giving a specific verb, resource, and scope. It distinguishes itself from air_search_public_sensors by naming that sibling explicitly for AirGradient sensors, so an agent can tell them apart without opening schemas.

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

  Usage Guidelines5/5

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

  The description gives explicit routing: 'For AirGradient owned sensors use air_search_public_sensors instead,' which is a clear when-not condition. It also notes that v0.3 supports AirThings and requires airthings client ID/secret, providing a setup precondition. That's strong usage guidance.

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

• air_onboardingA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful context by stating 'Read-only', clarifying that only non-secret data is involved, and specifying the storage location (~/.delx-wellness/profile.json), which goes beyond what annotations alone provide.

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

  Conciseness5/5

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

  The description is two sentences long, front-loading the core purpose ('Returns the 11-question onboarding flow') and immediately explaining usage, data sensitivity, and storage. Every clause adds value with no redundant or filler information.

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

  Completeness4/5

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

  Given the annotations cover safety and idempotency, and the schema covers all parameters, the description provides enough context for an agent to decide to call and invoke correctly. It explains the flow's role, data storage, and usage intent. The absence of an output schema is acceptable since the description already states the flow is an 11-question set.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters (locale, privacy_mode) already fully documented via enums and descriptions in the schema. The tool description does not add any additional meaning or context for these parameters beyond what is already present, matching the baseline for high coverage.

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

  Purpose5/5

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

  The description clearly states the tool returns an 11-question onboarding flow for the shared Delx Wellness profile, using a specific verb ('Returns') and resource ('onboarding flow'). It distinguishes itself from sibling tools like air_profile_get and air_profile_update by focusing on the flow rather than the profile itself.

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

  Usage Guidelines4/5

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

  The description explicitly says 'The agent should ask these questions next', providing a direct usage context for personalizing responses. However, it does not explicitly state when not to use this tool or mention alternative tools such as air_profile_get for retrieving existing profile data, stopping short of full exclusion guidance.

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

• air_profile_updateA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the action is a 'partial patch' (selective update), that explicit user intent is mandatory, and that it rejects secrets. This goes beyond a simple 'update' and gives valuable constraint context without contradiction.

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

  Conciseness5/5

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

  The description is two sentences with zero fluff. The main purpose is front-loaded, followed by the required intent and a critical limitation. Every sentence contributes to correct usage without redundancy.

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

  Completeness4/5

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

  For a mutation tool with no output schema, the description covers the necessary call conditions: a patch, explicit intent, and secret rejection. It does not describe the return value, but that is not critical for mutation. The missing side effect (shared profile impact) is a minor gap, making it a strong but not perfect definition.

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

  Parameters3/5

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

  Schema coverage is 100%: both parameters have descriptions in the schema. The description adds some context (e.g., that the patch is partial and the profile is for non-secret wellness context) but largely reiterates schema info. Baseline 3 is appropriate when schema already documents the parameters.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Persist a partial patch to the shared Delx Wellness profile.' This clearly indicates an update operation on a specific profile, which is distinct from read tools like air_profile_get. The name 'air_profile_update' is supported by the action and resource.

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

  Usage Guidelines4/5

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

  It explicitly requires 'explicit_user_intent: true', providing a clear precondition. It also warns against including secret-bearing fields, which is an important exclusion. While it does not explicitly name alternative tools, the mutation vs read nature is implicit from the name and the sibling list, so the guidance is adequate.

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

• air_profile_getA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces 'Read-only' and adds valuable behavioral context: the file location, what fields it surfaces, and the consumer of this data. No contradictions with annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: location, read-only flag, and purpose/content. No fluff, no repetition of schema data, and the most critical fact (this returns a profile) is front-loaded.

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

  Completeness5/5

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

  For a simple read-only tool with one optional parameter, the description fully equips an agent: it names the exact path, the fields returned, the reason an agent would call it, and the safety profile is confirmed via annotations. No output schema is needed because the description adequately describes the payload's nature.

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

  Parameters3/5

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

  The input schema documents the only parameter 'privacy_mode' with a complete enum and a description, achieving 100% schema coverage. The tool description does not add further detail about this parameter, so it meets the baseline without exceeding it.

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

  Purpose5/5

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

  The description states a specific verb ('Returns'), a specific resource (the shared Delx Wellness profile with exact path), and the key contents (preferred location, sensitivity flags, units). It clearly distinguishes this read tool from its sibling 'air_profile_update' by focusing on retrieval rather than modification.

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

  Usage Guidelines4/5

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

  The description provides a clear usage context: this profile is used so wellness-air can choose tighter AQI thresholds. It does not explicitly mention alternatives or exclusions, but the read-only nature and the presence of the sibling 'air_profile_update' make the boundary obvious for an agent.

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

• air_health_recommendationA
  4.4/5.0
  Behavior4/5

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

  Annotations already show readOnlyHint=true and idempotentHint=true, so the expected read-only behavior is covered. The description additionally discloses the composed output (bands per pollutant, overall worst band, deduplicated actions), adding meaningful behavioral context beyond 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.

  Conciseness5/5

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

  The description is tight and front-loaded: opens with 'Quick PM2.5-centric health recommendation,' then summarizes inputs and outputs in one sentence, then provides usage direction and alternative. Every sentence carries unique value with no repetition.

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

  Completeness4/5

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

  For a tool with five parameters and no output schema, the description adequately conveys the main inputs, output shape, and the intended use case. It could mention that response_format/privacy_mode are optional, but those are already described in the schema, and the core usage instructions are complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description restates the role of PM2.5, CO2, and VOC and their units but does not add any semantics beyond the schema. It omits mention of privacy_mode and response_format, but those are fully self-explanatory in the schema.

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

  Purpose5/5

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

  The description names a specific action ('returns WHO/EPA-aligned bands...', 'plain-language actions') and concrete resource scope (PM2.5-centric with optional CO2/VOC). It clearly distinguishes itself from sibling air_health_bands by stating 'For richer four-pollutant classification... use air_health_bands.'

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

  Usage Guidelines5/5

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

  It explicitly says 'Use this when you have a reading already and just want a what-should-I-do answer' and points to the alternative tool for more detailed classification. This covers the key when-to-use/when-not-to-use condition and the named alternative.

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

• air_demoA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark this as read-only and idempotent. The description adds valuable context beyond annotations by disclosing that the sample is contract-tested against real handlers via a build script, meaning field names are not invented. This reassures the agent about the fidelity of the output without contradicting the annotations.

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

  Conciseness5/5

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

  Two sentences with no unnecessary words. The core purpose is front-loaded in the first sentence, and the second sentence adds credible context about the contract test without bloating the description.

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

  Completeness5/5

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

  For a demo tool that exists to show example output, the description sufficiently explains what the return value represents and why it is trustworthy. The lack of an output schema is acceptable because the tool's entire purpose is to reveal the shape of other tools' outputs. The privacy_mode parameter is documented in the schema, so nothing critical is missing here.

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

  Parameters3/5

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

  The input schema already fully documents the only parameter (privacy_mode) with its enum and description, so baseline is 3. The description does not add additional meaning about how privacy_mode affects the sample payload, which could have been useful but is not necessary for correct invocation.

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

  Purpose5/5

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

  The description clearly states that the tool returns a realistic example payload of air_current_reading, air_aqi_check, and air_daily_summary. This specific verb and resource scope, plus naming the three sibling tools it demonstrates, makes its purpose unambiguous and distinguishes it from the actual data-fetching tools.

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

  Usage Guidelines5/5

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

  Explicitly says to use this tool to help users understand what the connector will return BEFORE configuring anything. This conveys a clear timing/context for use and implies it is not for obtaining real current readings, effectively separating it from siblings.

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

• air_trendA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, idempotentHint), the description discloses important behavioral nuances: time_above_threshold_minutes integrates real sample spacing and is affected by sensor downtime, and it warns to check coverage_ratio and last_sample_at before treating results as full-window figures. This goes well beyond the basic safety profile and genuinely helps an agent understand data quality caveats.

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

  Conciseness5/5

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

  The description is dense yet well-organized: it opens with the core purpose, then details the statistical outputs and the important caveat about coverage_ratio, and closes with usage examples. Every sentence contributes meaningful information without redundancy. Despite its length, it remains highly scannable and front-loads the key purpose.

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

  Completeness5/5

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

  Given there is no output schema, the description compensates by explicitly listing the returned fields (mean, median, min, max, current, rate_of_change_per_hour, etc.) and the optional natural-language observation. It also mentions fallback behavior for locationId and the effect of pollutant='all', covering the essential contexts an agent needs to correctly call and interpret results. No critical gaps remain.

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

  Parameters3/5

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

  The schema already provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds value by explaining the effect of pollutant: 'all' (array + worst_pollutant) and mentioning privacy_mode's impact, but it doesn't elaborate on hours, locationId fallback, or response_format beyond what the schema states. No parameter is left undocumented, but the description provides only modest additional semantic depth.

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

  Purpose5/5

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

  The description clearly states it performs 'Windowed trend analysis for PM2.5 / CO2 / VOC' and lists the exact return metrics (mean, median, etc.). It distinguishes itself from siblings by focusing on past measurements and trends, while tools like air_current_reading imply current state. The inclusion of example questions ('is PM2.5 climbing?') further clarifies its intent.

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

  Usage Guidelines4/5

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

  The description gives an explicit 'Use this for ...' statement with concrete example queries, which effectively communicates when to invoke it. However, it does not explicitly mention when not to use it or name alternative sibling tools for other scenarios, leaving some room for interpretation. The context is clear but lacks explicit exclusions.

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