Server Quality Checklist

Tool Scores

• municipal_incomeA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the research nature and adds the 'not advice' disclaimer, plus the computed metrics. However, it doesn't describe the response format, update cadence, or any limitations. For a read-only data tool, this is adequate but not rich.

  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: the first is dense with specific metrics (tax-equivalent yields, brackets, distribution frequency, growth streak, years without a cut) and the second sets expectations ('Impersonal research data, not advice'). Every phrase earns its place, and it's well front-loaded with the subject.

  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 simple zero-parameter nature and no output schema, the description is mostly complete: it explains what the tool returns and the key data points. It could specify the exact output format (e.g., a ranked table), but for a research list tool this is sufficient.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameters and doesn't attempt to; it instead focuses on the returned data, which is appropriate.

  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 clearly identifies the tool's domain (tax-exempt municipal bond funds) and the outputs (ranked list with yields, frequency, etc.). It distinguishes itself from siblings like crypto_research and cheapest_fuel by topic. However, it lacks an explicit verb like 'list' or 'research,' making the action slightly implicit.

  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 through the description: if the user needs municipal income fund data, this is the tool. But there is no explicit when-to-use guidance or mention of alternatives, and no exclusions or prerequisites are stated.

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

• crypto_yieldsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral transparency burden. It adds useful context about the risk-adjustment method (TVL, base vs emission share) and the A/B/C rating scale, which sets expectations about output. However, it omits data sources, update frequency, and any access or rate limitations, leaving notable gaps.

  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 long sentence that front-loads the core purpose ('Where to earn interest or staking rewards') and then packs in categories, risk-adjustment details, and ratings. Each clause adds value, though splitting it into two sentences would improve readability.

  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 there is no output schema and no parameters, the description provides a solid overview: yield types, platforms, risk-adjustment metrics, and rating scale. It does not detail the exact return format beyond ratings, but for a no-param research tool, it is adequately complete.

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

  Parameters4/5

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

  The input schema has zero parameters, so schema coverage is trivially 100% and the baseline is 4. The description does not need to explain parameters; it provides enough context about the tool's scope and methodology to make the lack of parameters obvious.

  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's purpose: finding where to earn interest or staking rewards on crypto and stablecoins. It enumerates specific categories (DeFi staking APY, stablecoin lending, liquidity-pool yields) and platforms (CeFi/DeFi), and the A/B/C rating system distinguishes it from generic crypto research tools like sibling crypto_research.

  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: use when you want to compare crypto yield opportunities. However, it does not explicitly state when not to use it, mention prerequisites, or reference alternatives among sibling tools. Guidance is implicit rather than direct.

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

• crypto_researchA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does not explicitly state that the tool is read-only or free of side effects, though 'Impersonal research data, not advice' implies a non-actionable output. It adds some behavioral context by explaining the macro overlay, but omits details like data freshness or any limitations.

  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, front-loaded with the core purpose and methodology, followed by a helpful disclaimer. Every sentence earns its place with no wasted words.

  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 the tool's simplicity (no parameters, no output schema), the description fully covers what the user can expect: a ranked list of crypto candidates with the technical and macro factors considered. The disclaimer adds a necessary caveat about its non-advice nature.

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

  Parameters4/5

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

  The tool has zero parameters and an empty input schema, so there is nothing to explain. Per the baseline for 0-parameter tools, the score is 4. The description adds context about the methodology but does not need to specify 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 produces ranked cryptocurrency candidates and specifies the exact signals used (RSI, ATR, VWAP, momentum, Fear & Greed, news sentiment). It distinguishes itself from sibling tools like crypto_yields and options_research by focusing on general crypto research rather than yields or options.

  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 usage context is implied through the description – it is for cryptocurrency research based on technical and sentiment signals. However, it does not explicitly state when to use this tool over siblings or mention any exclusions, so it lacks direct guidance on alternatives.

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

• air_qualityA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility. It transparently discloses the data source (Copernicus CAMS), the use of US AQI standards worldwide, the EPA-based verdict, and the forecast-window behavior. It does not mention rate limits or response structure, but the key limitations are well covered.

  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, front-loading the core outputs and ending with a necessary caveat about data quality. No filler words; every clause contributes meaningful 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 there is no output schema, the description explains the main result categories (AQI, pollutants, EPA verdict, clean window) and the window-finding behavior. It could specify how the window is computed or whether AQI is instantaneous versus averaged, but the essential functionality is clearly conveyed.

  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 the baseline is 3. The description reinforces the roles of 'hours' and 'duration' in finding the cleanest window, but the schema already provides clear descriptions for each parameter, so the description adds limited additional semantic value.

  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 enumerates specific deliverables: current US AQI, pollutant breakdown, EPA-based exercise safety verdict, and the cleanest contiguous window. It distinguishes itself from the unrelated sibling tools by focusing on air quality and outdoor activity planning.

  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 implies the main use case (assessing air quality for outdoor exercise) and offers a 'when not' by noting the data is modelled and not from a sensor at the exact spot, which cautions against use when precise local measurements are required. However, it does not explicitly name alternative tools or provide formal 'use this when' guidance.

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

• border_crossingsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It explains the ranking methodology (all-in time), the data source (live CBP data across 85 ports), and the lane eligibility consideration. It does not cover error handling or data freshness, but the core behavioral aspects are transparent.

  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 concise and front-loaded. Two sentences convey the purpose, scope, and a key insight without any wasted words. It is easy to scan and understand.

  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 7 parameters and no output schema, the description covers the essential aspects: what is ranked, by what metric, for which traffic types, and with live data. It does not explain the return format or error conditions, but the ranking behavior is sufficiently described 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.

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds context about the all-in time metric and lane honoring, which helps interpret the parameters, but it does not add specific parameter-level details beyond 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 clearly states the tool ranks US ports of entry by all-in time (drive + wait), covering passenger, commercial, and pedestrian traffic. It distinguishes itself from the sibling tools (which are unrelated) and the note about nearest not being fastest adds a specific behavioral insight.

  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 clear context on when to use the tool: to find the fastest border crossing by all-in time, explicitly contrasting with the nearest crossing. It does not explicitly mention when not to use it or alternatives, but the usage scenario is well implied.

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

• cheapest_fuelA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It truthfully discloses that US results are only official regional averages, not station-level prices, and it reveals the smart=true caveat that the cheapest sign is not always the cheapest tank. This adds meaningful behavioral nuance beyond the input schema, though it does not mention request limits or exact response format.

  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 compact at two sentences, with the primary purpose front-loaded. The second sentence earns its place by explaining a critical behavioral nuance (smart=true) that would otherwise be ambiguous. No filler or repetition exists.

  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 medium complexity and lack of output schema, the description adequately covers key selection factors: country-specific data granularity, required location inputs, and smart mode semantics. It does not explicitly state the return format (e.g., whether a list or a single result is returned), but the description is sufficient for an agent to decide when to invoke it and with what parameters.

  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 provides 100% parameter coverage, including descriptions for lat/lon (required for station-level countries), region (US state code), and country (ES/FR/IT station-level vs US regional). The description's added detail about data sources and smart=true behavior is useful but largely paraphrases or reinforces what the schema already documents, so it only marginally raises the baseline.

  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 'Cheapest fuel for a location and grade,' a specific verb+resource statement that clearly identifies the tool's function. It further differentiates station-level pricing (Spain, France, Italy) from regional averages (US), and introduces the smart=true refinement, making it distinct from any other possible fuel-related tool.

  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 clear context on when station-level versus regional pricing applies, and explicitly explains what smart=true does ('weighs the pump price against the fuel and time spent on the detour'). It stops short of naming alternative tools or saying 'when not to use,' but the sibling tools are unrelated, so the lack of explicit alternatives is not a major gap.

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

• options_researchA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that data is deterministic ('identical for every buyer'), impersonal, and excludes trade plans or verdicts. It lists the metrics provided, offering transparency about what the output includes, though it omits operational details like data freshness or limitations.

  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 no wasted words. The first sentence efficiently lists the core purpose and metrics, while the second sentence is essential for setting expectations about non-advice. Both sentences earn their 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 no-parameter tool with no output schema, the description is quite complete. It explains what is returned (ranked candidates with metrics and illustrative contract) and what is not (advice or trade plan). It lacks details on interpretation or data source, but this is sufficient for basic tool selection.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline of 4 applies. The description adds value by enumerating the metrics that appear in the output (signal strength, ATR%, RSI, etc.), which helps the agent anticipate the result even without 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 clearly states the tool provides ranked short-term US equity options candidates with specific metrics. It uses a specific verb ('ranked') and resource ('options candidates'), distinguishing it from sibling tools like crypto_research or municipal_income by focusing on US equity options.

  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 use for obtaining research data, but does not explicitly say when to use it versus alternatives. It does clarify what it is not (advice, trade plan, buy/sell verdict), which helps set expectations, but lacks direct comparison to sibling tools or explicit use cases.

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

• payment_statusA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does a good job by clearly stating that the tool makes no network request and costs nothing, signaling a non-mutating, safe operation. It also lists the exact data reported. It could mention authentication needs or response format, but the provided behavioral details are strong.

  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, front-loaded with specific, useful data points and no wasted words. The second sentence adds a valuable safety note without bloat.

  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 zero-parameter tool with no output schema, the description covers the essential information: what it reports and that it is free/non-network. A minor gap is the lack of response shape or units, but the tool's low complexity means this is not a significant omission.

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

  Parameters4/5

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

  The input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed because there are no parameters to document.

  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 ('Reports') and resource ('payment status') while enumerating concrete outputs: whether paid calls are enabled, session spend, price per call, and accepted payment rails. This makes the tool's purpose unmistakable and distinguishes it from the unrelated sibling research tools.

  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?

  No explicit when-to-use guidance or exclusions are provided. The line 'Makes no network request and costs nothing' implies safe, cost-free usage, but it does not state specific situations such as 'check before making paid calls' or compare to alternatives. For a simple status tool, this is adequate but not fully explicit.

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