aristocles-api

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 the tool's behavior: calculates totals, returns breakdown, supports fuzzy matching, and has a default country. It does not explicitly state it is read-only or detail rate limits, but for a calculation tool the description is sufficient.

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

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

The description is well-structured with sections for purpose, usage, args, returns, and an example. Every sentence adds value, and the docstring-style Args section is efficient. No wasted words.

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?

Given the tool has two parameters (one required, no enums) and an output schema exists, the description covers all necessary aspects: input format, default behavior, return structure, and an example. It is fully complete for an agent to use correctly.

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

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

The schema coverage is 0%, yet the description provides thorough parameter details: service_names are 'Comma-separated service names or slugs with fuzzy matching,' and country is 'ISO country code with default AU.' This adds significant meaning beyond the bare schema.

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

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

The description clearly states 'Calculate total monthly and annual spend for a list of subscriptions.' The verb 'calculate' and resource 'subscriptions' are specific. It distinguishes itself from sibling tools like 'get_subscription_price' by operating on a list and providing totals.

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 says 'Use this to help users understand their total subscription spending,' which provides clear context. However, it does not explicitly mention when not to use it or list alternative tools, though the sibling set implies alternatives for single-service queries.

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?

No annotations are provided, so the description must convey behavioral traits. It mentions fuzzy matching and returns savings, but it does not explicitly confirm it is a read-only operation, nor does it disclose error handling or rate limits. The behavior is implied but not fully transparent.

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

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

The description is concise (a few sentences) and well-structured with a purpose statement, usage instruction, separated Args, Returns, and Example. Every sentence adds value.

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?

Given the tool has two parameters, no schema descriptions, and an output schema (not shown), the description covers purpose, parameters, and return structure. It includes an example invocation. It is complete enough for typical use, though it lacks details on error scenarios.

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 0%, so the description adds meaning for both parameters: service_name (with example and fuzzy matching) and country (with default value). This is helpful but could include more detail on allowed values or formats.

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 clearly states the tool compares monthly vs annual pricing for a subscription service, with a specific verb and resource. It distinguishes from siblings like get_subscription_price and compare_prices_across_countries by focusing on billing period savings.

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 says 'Use this to show users how much they can save by switching from monthly to annual billing', providing clear context. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools.

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?

No annotations are provided, so the description carries full burden. It details the return format (JSON with pricing per country, plan tiers, monthly equivalents) and default behavior for countries parameter, which is transparent.

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

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

The description is concise, well-structured with Args, Returns, and an Example sections, and no unnecessary text. It front-loads the purpose.

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?

Given the presence of an output schema, the description adequately covers return values. Parameters are well explained, and the example clarifies usage. The tool is simple enough that referencing sibling tools is not essential.

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

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

The input schema has 0% coverage (no descriptions), but the tool description compensates by explaining both parameters: service_name as the service name, and countries as optional list of ISO codes with default behavior and example.

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 clearly states the tool compares subscription service prices across countries, using a specific verb and resource. It distinguishes from sibling tools like get_subscription_price which likely focuses on a single country.

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 indicates use for showing price differences and offers an example, but does not explicitly state when not to use this tool or mention alternatives among the 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?

No annotations are provided, so the description carries the full burden. It states the return format (JSON with rent history) and defaults, but does not disclose data freshness, potential errors for invalid suburbs, or any rate limits. For a read-only comparison tool, this is adequate but could be improved.

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

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

The description is concise and well-structured, using clear sections (overall purpose, Args, Returns, Examples). No unnecessary words; every sentence adds information. Two examples demonstrate typical usage efficiently.

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?

Given no annotations but presence of an output schema, the description adequately explains return values (JSON with rent history) and parameters. It covers all 4 parameters with defaults. Missing details about error handling or data source, but overall complete for a comparison 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 coverage is 0% (no descriptions in schema). The description fully compensates by listing each parameter with allowed values and formats: state codes, comma-separated suburbs, bedroom filter with 0 meaning all, and property type options. This adds significant value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Compare rental prices across multiple Australian suburbs.' It specifies the action (compare), resource (rental prices), and scope (multiple suburbs). This distinguishes it from siblings like 'get_suburb_rent' (single suburb) and 'get_cheapest_rental_suburbs' (finding minimum).

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 provides clear usage context: side-by-side median rent comparison with recent quarterly history. Examples show typical invocation patterns. However, it does not explicitly say when not to use this tool or mention alternatives like 'get_suburb_rent' for single suburb queries.

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?

No annotations are provided, so the description carries the full burden. It states that returns include all tiers and monthly prices, and gives a JSON comparison table, which is adequate but does not disclose non-obvious behaviors like rate limits or data freshness.

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

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

The description is reasonably concise with a brief opening sentence followed by a structured docstring. It could be slightly tighter without the docstring format, but it remains clear and front-loaded.

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?

Given an output schema exists, the description adequately covers behavior (what it compares, number of services, parameter formats, example). No gaps remain for this simple comparison 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 0%, but the description adds full parameter clarity: 'service_names' is explained with an example format and the 'country' parameter includes default and format. This significantly compensates for the missing schema descriptions.

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 clearly states 'Side-by-side price comparison of multiple subscription services.' This verb+resource combination is specific and distinct from siblings like 'compare_billing_periods_tool' or 'get_subscription_price'.

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 advises using this tool to compare pricing across 2-10 services, providing a clear count constraint. However, it does not explicitly mention when not to use it (e.g., single service) or alternative tools like 'get_subscription_price' for single services.

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?

No annotations are provided, so the description carries the full burden. It discloses the return type ('JSON with prices side by side') and provides an example usage. However, it does not mention whether the tool is read-only, data freshness, authentication needs, or error handling for invalid locations. The information is adequate but not comprehensive.

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

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

The description is well-structured with clear sections (Args, Returns, Example) and no extraneous text. Every sentence serves a purpose. The example at the end reinforces clarity without redundancy.

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?

Given the tool has 4 parameters and an output schema, the description covers required inputs, default values, and expected output format. It could be more explicit about the location codes (e.g., 'state/region codes') and where to find trade/service slugs, but overall it provides sufficient context for an AI 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.

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

Schema description coverage is 0%, but the tool description compensates by explaining each parameter in the Args section (trade, service, locations, country) with types and examples. It adds value beyond the bare schema, though it could specify the location code format more precisely.

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 clearly states it compares tradesperson pricing across states/regions, with a specific verb ('compare'), resource ('trade prices'), and scope ('across different states or regions'). It distinguishes itself from siblings like 'compare_prices_across_countries' by focusing on trades and regional within-country comparison.

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 explicitly says 'Use this to help users understand price differences between states (e.g. is a plumber cheaper in California vs New York?)', providing clear context. It does not explicitly state when not to use or list alternatives, but the purpose is unambiguous given the sibling 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?

With no annotations, the description fully explains the output (low/high/avg cost, unit, location context) and shows usage. It implies a read-only estimation, but does not detail failure modes or authentication needs. Still sufficient.

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

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

The description is well-organized: a one-sentence summary, usage directive, argument list, return description, and example. No superfluous text.

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?

All 8 parameters are documented, the return structure is described, and an example is provided. Given the tool's complexity (8 params, external location sensitivity), this is fully adequate.

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?

Despite 0% schema description coverage, the description enumerates each parameter with its purpose, type, and defaults (e.g., 'trade slug', 'quantity: How many units... Default 1.0'). This adds complete meaning beyond the raw JSON schema.

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

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

The opening sentence states the exact function: estimate total cost for a trade job. It specifies the key dimensions (trade service, quantity, location) and distinguishes from sibling tools focused on listing prices or comparing billing periods.

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 explicitly says 'Use this to calculate an estimated cost' and gives a concrete example. It does not explain when to avoid this tool or compare it with siblings, but the context is clear enough 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?

With no annotations, the description discloses behavioral traits: results sorted by price, includes feature overlap score and notes. It explains defaults and example. It does not mention auth, rate limits, or side effects, but for a read-only search tool the transparency is adequate.

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

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

The description is well-structured with summary, usage, args list, returns, and example. It is clear and front-loaded, though the 'Args:' and 'Returns:' sections could be integrated for slightly more conciseness.

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 search tool with 3 parameters (1 required) and an output schema, the description covers all aspects: parameter explanations, example call, and output field meanings. It is complete for typical use.

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 0%, but the description fully explains each parameter: service_name as name of service, country as ISO code, max_results as limit. It also details the return structure with field meanings, adding significant value beyond the schema.

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

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

The description clearly states the tool finds cheaper alternatives to a subscription service, with specific verb 'find' and resource 'cheaper alternatives'. It distinguishes itself from siblings like get_subscription_price or compare_services by focusing on cost savings and sorted results.

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

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

The description includes an explicit usage statement: 'Use this to help users save money by switching to a similar but cheaper service.' While it provides clear context, it does not specify when not to use or compare directly to sibling tools.

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?

With no annotations provided, the description carries the full burden. It discloses the return format (JSON with states ranked by average price) and default country. It does not cover error handling or rate limits, but given the tool's read-only nature, it is sufficiently transparent.

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

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

The description is concise, about 10 lines, and well-structured with Args, Returns, and Example sections. Every sentence adds value without redundancy.

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?

The description covers the tool's functionality, parameters, and output adequately. It does not mention error handling for invalid inputs or empty results, but for a search tool with an output schema, this is a minor gap. Overall, it is complete for typical usage.

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 0%, so the description must compensate. It fully explains each parameter: trade and service slugs with examples, states as comma-separated codes with default, and country code with examples. An example invocation is also provided. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Find the cheapest state or region for a trade service in a country.' It uses a specific verb-resource combination and distinguishes itself from siblings like 'get_trade_price' and 'compare_trade_prices_tool' by focusing on geographical cost comparison.

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 explicitly says 'Use this when a user wants to know where they can get the best price for a particular trade job.' This provides clear usage context. However, it does not explicitly mention when not to use it or list alternative tools for related queries, though the sibling set implies different scopes.

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?

Describes return format (JSON) and behavior for both parameter combinations. No annotations exist, so description carries full burden. Adequate for a read-only query tool.

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?

Extremely concise with clear sections (Args, Returns, Example). Every sentence adds value. No wasted words.

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 all essential aspects: two usage modes, parameter behavior, return type. Minor omission: no list of tracked major currencies, but output schema likely provides that.

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?

Adds significant meaning beyond the bare schema: explains currency as 3-letter ISO code, effect on history vs snapshot, and periods as number of observations only when currency is given. Schema coverage is 0%, making this description essential.

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 clearly states 'Get AUD exchange rates', specifies the two modes (latest snapshot vs history), and distinguishes from siblings that handle other financial data.

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?

Provides explicit usage context: 'Use this to get current and historical AUD exchange rates.' Examples show both modes. No explicit when-not-to-use, but sibling context makes it clear.

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?

With no annotations, the description fully carries the burden. It discloses that the tool returns quarterly data from 1948, three series, and JSON format. No destructive or permission-related issues are expected for a read-only data retrieval tool, making the description sufficiently transparent.

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

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

The description is concise, front-loaded with the main purpose, followed by details and examples. Every sentence adds value without redundancy.

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?

Given the tool's simplicity and the presence of an output schema, the description is adequately complete. It specifies the data series and time range, though it could mention the unit (e.g., percentage change). Overall, sufficient for the task.

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 0%, but the description explains the single parameter 'periods' in detail: number of quarterly observations, default of 20 (5 years), and provides examples. This adds significant meaning beyond the schema's type and default.

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 clearly states the tool retrieves Australian CPI inflation data, specifies the source (RBA), includes headline CPI, trimmed mean, and weighted median, and notes quarterly frequency back to 1948. It distinguishes from sibling tools focusing on other economic indicators like mortgage rates or exchange rates.

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 provides clear context for when to use the tool (for Australian inflation data) but does not explicitly state when not to use it or mention alternatives among sibling tools. The usage is implied by the tool's name and description.

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?

No annotations provided, so description carries full burden. It mentions 'Monthly data' and that it returns JSON with series, but does not state read-only nature, side effects, auth requirements, or rate limits. For a data retrieval tool, this is minimal disclosure.

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?

Description is concise with structured sections (Args, Returns, Example). Every sentence adds value; no redundancy. Appropriate length for a simple tool.

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?

Given there is an output schema (implied) and one optional parameter, the description covers the tool's purpose and expected result. It mentions specific rate types and monthly frequency. Could benefit from noting data source reliability (RBA) or constraints on time range, but is mostly complete.

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 has one optional parameter 'periods' with default 24 but no description. The tool description adds 'Number of monthly observations (default 24 = 2 years)', providing clear meaning beyond the schema. This compensates for 0% schema description 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?

Description clearly states 'Get Australian housing lending rates from the RBA'. It specifies the verb 'Get' and the resource 'housing lending rates', and mentions specific rate types (variable, fixed 1/2/3 year, new loan rates). This distinguishes it from sibling tools like get_rba_cash_rate or get_australian_inflation.

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

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

Explicitly says 'Use for mortgage calculators and rate comparison tools', providing clear use context. However, it does not specify when not to use this tool or mention alternatives, which could further aid 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?

With no annotations, description covers the return format (JSON with specific fields). It is transparent about what the tool does but does not mention potential limitations like data freshness or if it's a read-only operation (though implied).

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?

Description is well-structured with intro, args, returns, and example. It is informative but could be slightly more concise; however, every sentence adds value.

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?

Given 2 parameters and an output schema (described in returns), the description comprehensively explains inputs, outputs, and usage with an example. No gaps identified for this tool's 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?

Input schema has no descriptions (0% coverage), but the description adds full parameter semantics: clarifies category accepts name or slug, gives example format, explains country as ISO code with default 'AU'. This adds significant value beyond the schema.

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

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

Description clearly states verb 'Get an overview' and specifies resource 'spending category'. It details what the overview includes (service count, price range, average cost, ranked list), distinguishing it from sibling tools that focus on individual prices or comparisons.

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?

Description explicitly says 'Use this to understand an entire category' and provides an example, giving clear context. However, it does not state when not to use it or name alternatives, which would improve guidance.

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

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

Discloses output format (JSON list ordered by cheapest), default values, and max limit. With no annotations, this is good transparency, though it could mention error handling or data freshness.

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?

Well-structured with separate sections for description, args, returns, and examples. Every sentence is informative and necessary, with no wasted words.

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 purpose, all parameters with details, return format, and examples. Given the tool's complexity and lack of annotations or output schema, the description is complete.

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 has zero description coverage, but the description fully explains each parameter, including allowed values, defaults, and examples, adding significant meaning beyond the schema.

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

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

Clearly states it finds the most affordable suburbs to rent in an Australian state, ranked by lowest median weekly rent for a specific bedroom count. The description uses a specific verb-resource combination and distinguishes from sibling tools like compare_rental_suburbs.

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?

Provides clear argument descriptions and examples, indicating when to use the tool. However, it does not explicitly state when not to use it or contrast with alternatives.

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?

No annotations are provided, so the description carries the full burden. It describes the tool as a simple read operation ('Get current...'), but does not disclose potential latency, authentication requirements, or data freshness guarantees. As a read-only tool, this is acceptable but not comprehensive.

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

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

The description is extremely concise: three short paragraphs covering purpose, return types, and an example call. Every sentence adds value with no redundancy. Front-loaded with the core action.

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?

Given no parameters and the presence of an output schema, the description is mostly complete. It specifies the return format (JSON with general copayment, concessional copayment, safety net limits). However, it could mention the geographical scope (Australia) more prominently or note that data is real-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?

There are no parameters, so the description does not need to add semantics beyond the schema. The description mentions the return fields, which adds value. Baseline score of 4 is appropriate for zero-parameter tools with high schema 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?

The description clearly states the tool retrieves Australian PBS patient copayment thresholds, specifying the types of data (general copayment, concessional copayment, safety net limits). This differentiates it from siblings like get_pbs_drug_price, though it could explicitly contrast with related tools.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for obtaining copayment thresholds, but lacks context like 'use this when you need safety net thresholds, not drug-specific prices.'

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?

No annotations provided, so the description carries full burden. It fully describes the return data including benefit price, patient copay, forms/brands, originator vs generic, and safety net thresholds. It does not mention authentication or rate limits, but the read-only nature is implied.

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

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

The description is concise, front-loaded with the purpose, and structured with Args/Returns sections and examples. Every sentence adds value without redundancy.

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?

Given one parameter, an output schema (though not shown), and detailed return description, the description is complete. It covers all needed information for an agent to use the tool correctly.

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

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

The single parameter 'drug_name' is well-described with examples and clarification that it accepts both generic and brand names. The input schema has 0% description coverage, so the description fully compensates.

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 clearly states 'Get Australian PBS pricing for a medication' with specific verb and resource. It distinguishes from siblings like search_pbs_drugs_tool and get_pbs_copayments by focusing on returning both the subsidised price and patient cost for a single drug.

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 says it works for generic and brand names and provides examples, but does not explicitly state when to use over alternatives or mention prerequisites or 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only describes the data returned and filtering options, but does not mention any side effects, authentication needs, rate limits, or caching. This lack of behavioral context is a significant gap.

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

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

The description is structured with a brief overview, bulleted Args, and Returns section. It is concise, though the phrase 'ideal for LLM context injection' appears twice in slightly different forms, which is minor redundancy.

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?

Given the tool has three optional parameters and an output schema, the description covers the essential usage context: filtering options, output format (JSON array sorted by category and service), and an example call. It does not need to detail the output schema since it is provided separately.

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 0%, but the description compensates well by explaining each parameter: category, country, and format. It clarifies defaults ('if not specified, returns all'), provides examples, and notes the difference between 'summary' and 'detailed' output. This adds meaning beyond the raw schema.

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

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

The description clearly states that the tool retrieves 'bulk pricing data for all services' and emphasizes its use for LLM context injection and analysis. It distinguishes from siblings like get_subscription_price which targets single services, making the purpose specific and differentiating.

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 identifies ideal use cases such as LLM context injection, analysis, and chart generation. However, it does not explicitly mention when not to use the tool or provide direct alternatives among the sibling tools, though the context of bulk vs. specific is implied.

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?

Describes return format (chronological price history with effective date, price amount, percentage change) and example use. With no annotations, more behavioral context like error handling, permissions, or rate limits would improve transparency.

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?

Description is concise with clear sections for args, returns, and example. No wasted words; every sentence serves a purpose.

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?

Given the tool's low complexity and presence of output schema, description covers purpose, parameters, return format, and usage example. Distinguishes from siblings adequately, making it complete for an AI agent to use.

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 0%, but description adds meaning to all three parameters: service_name example, country default, months default. Also provides a usage example. Adds significant value beyond schema titles and defaults.

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?

Description clearly states it shows price history of a subscription service, using verb 'show' and specifying resource 'price history'. It distinguishes from siblings like get_subscription_price (current price) and compare_prices_across_countries.

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

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

Explicitly says 'Use this to see price increases or decreases', providing clear context. Does not mention when not to use or name alternatives, but purpose is straightforward and sibling tools imply other use cases.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions current and historical data but lacks details on data freshness, rate limits, or the interpretation of 'periods.' The description is partially adequate but not complete.

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

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

The description is concise with a clear header, explanatory paragraph, and structured Args/Returns/Examples sections. Every sentence adds value, and the essential information is front-loaded.

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?

Given low complexity (1 optional parameter, no required fields, and an output schema present), the description adequately covers the tool's purpose and return format. However, it could specify the frequency of observations (e.g., monthly?).

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

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

The schema has 0% description coverage for the 'periods' parameter. The description adds meaning by stating 'Number of observations to return (default 24),' which clarifies the parameter's purpose beyond the schema's type and default.

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 clearly states 'Get the RBA cash rate — current and historical,' specifying the verb, resource, and scope. It distinguishes itself from sibling tools like get_rba_series and list_rba_series_tool by focusing specifically on the cash rate.

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 does not explicitly state when to use this tool versus alternatives. While examples show usage patterns, there is no guidance on when to prefer it over related tools like get_aud_exchange_rates or get_rba_series.

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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes the parameters and return format, but does not explicitly state that the operation is read-only, mention error handling, or any restrictions. While the purpose is clear, more explicit safety or behavior details would improve transparency.

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

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

The description is well-structured: one-line summary, usage guidance, parameter descriptions with examples, return format, and three concrete examples. Every sentence adds value, and there is no redundancy or verbosity.

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?

Given that the tool has an output schema (so return values are defined there), the description provides sufficient context: it tells the agent when to use this tool, how to discover series codes, and what the return format contains. The examples cover typical usage patterns. The description is complete for the tool's 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?

The input schema has no descriptions (0% coverage). The description compensates fully by explaining series_code as 'RBA series identifier' with concrete examples (ARBAMPCNCRT, FXRUSD, GCPIAG) and periods as 'Number of observations to return (default 40)' with examples showing how the argument maps to time periods (365 days, 20 years). This adds significant meaning beyond the schema.

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

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

The description clearly states the verb (Get) and resource (any RBA statistical series by its series code). It distinguishes itself from sibling tools like list_rba_series_tool (by suggesting to call it first) and get_rba_cash_rate (by covering any series, not just the cash rate).

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

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

Explicitly states when to use ('advanced queries when you know the exact RBA series code') and what to do before using ('Call list_rba_series_tool() first to discover available codes'). This provides clear guidance on context and alternatives.

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?

No annotations are provided, so the description carries full burden. It describes the output structure and gives examples, but does not disclose authentication requirements, data freshness, or any side effects. It is adequate but lacks depth.

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

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

The description is well-structured with a one-line summary, followed by detailed parameter descriptions, return type, and examples. Every sentence is informative and concise.

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?

Given that an output schema exists (as per context signals), the description's explanation of the return format is sufficient. All parameters are described, and the tool's behavior is clear for its 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 description coverage is 0%, but the description compensates fully by explaining each parameter's meaning, valid values (e.g., bedrooms 1-4 or 0 for all), and providing examples. Adds significant value beyond the schema.

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

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

The description clearly states it gets rental prices for a specific Australian postcode, which is a specific verb and resource. It distinguishes from siblings like get_suburb_rent by focusing on postcode input.

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 implies usage when you have a postcode and want rental prices, but it does not explicitly mention when not to use or compare with alternative tools like get_suburb_rent or search_rental_market.

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?

No annotations are provided, so the description carries full burden. It explains returns (JSON with price details), fuzzy matching, defaults, and optional parameters, but does not explicitly state read-only behavior or lack of side effects.

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

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

The description is well-structured with sections for usage, args, returns, and example. It is slightly redundant ('Get the current price' and 'Use this tool to look up' are similar), but overall front-loaded and clear.

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?

Given the presence of an output schema, the description still covers all aspects: parameters, defaults, behavior, and return structure. It provides a complete picture for a simple lookup 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 0%, yet the description thoroughly explains each parameter: service_name with fuzzy matching, country with format and default, plan_tier with options, plus an example. This adds significant meaning.

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 clearly states 'Get the current price of a subscription service' and specifies how it differs from sibling tools like compare_services or find_cheaper_alternatives by focusing on a single service lookup.

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 says 'Use this tool to look up how much a subscription service costs right now', which implies when to use it, but it does not explicitly state when not to use it or mention alternatives among 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?

Without annotations, the description carries full burden for behavioral disclosure. It discloses the data source (official government, VIC DFFH), update frequency (quarterly), and that data is returned as JSON with a specific structure. It does not mention auth needs, rate limits, or potential side effects, but given the read-only nature, the disclosure is sufficient.

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

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

The description is well-structured with clear sections: a one-line summary, a data source note, Args list with inline explanations, Returns description, and two examples. Every sentence adds value; no redundancy or filler.

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

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

Given the tool has 4 parameters and returns structured data, the description covers all essential aspects: purpose, all parameters with valid values, return format, data source, and update frequency. The presence of an output schema does not detract, and the examples clarify typical usage. No gaps are apparent.

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

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

The description adds significant meaning beyond the input schema. For 'state', it lists valid codes; for 'suburb', it gives examples; for 'bedrooms', it specifies meaning of 0 as 'all sizes'; for 'property_type', it enumerates options. This is critical since the schema has no descriptions (0% coverage) and only provides titles and defaults.

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 clearly states the tool's verb ('Get') and resource ('rental price history for an Australian suburb'), specifying the output includes median weekly rent by property type and bedroom count. This purpose is distinct from sibling tools like 'compare_rental_suburbs' or 'get_rent_by_postcode', though not explicitly contrasted.

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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., compare_rental_suburbs, get_rent_by_postcode). It provides examples but no when-to-use or when-not-to-use context, requiring the agent to infer from the tool's name and purpose.

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?

Despite no annotations, the description discloses the tool is read-only, returns structured price data with range and unit, and requires location parameters. It does not mention rate limits or data freshness, but covers core behavior adequately.

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?

Well-structured with Args, Returns, and Example sections. Every sentence adds value, no redundant information. Efficient use of space while being informative.

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?

Given 7 parameters and output schema exists, the description covers purpose, all parameter meanings, return shape (JSON with price ranges, unit, source, location), and includes an example. Fully sufficient for an agent to use correctly.

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

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

The description adds detailed explanations for all 7 parameters in the Args section, far beyond the schema which has no descriptions and examples. It compensates fully for 0% schema 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?

Description clearly states it retrieves trade pricing for a specific trade, location, and country. It specifies the output includes price ranges per unit and location data, distinguishing it from sibling tools that compare prices or find cheapest locations.

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

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

Explicitly says 'Use this to look up how much a tradesperson costs' and provides an example, implying it is for single trade queries. However, it does not explicitly mention when not to use it or contrast with alternatives like compare_trade_prices_tool.

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?

With no annotations, the description carries the full burden. It explains the comparison logic (current vs year ago), return format (JSON list with suburb, medians, % change), and provides examples. It does not mention any destructive actions or rate limits, but for a read-only data fetch this is 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?

The description is concise and well-structured with explicit 'Args:', 'Returns:', and 'Example:' sections. It front-loads the core purpose in the first sentence. Every sentence adds value with no redundancy.

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?

Given the tool has an output schema and no nested objects, the description is complete enough. It specifies all required input details and gives a clear overview of the output. The examples further solidify understanding.

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 0%, so the description must compensate. It fully explains all four parameters: state with example codes, direction with 'up'/'down' and default, bedrooms with range and default, property_type with 'flat'/'house' and default. Examples demonstrate valid usage.

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 clearly states the tool finds Australian suburbs with fastest rising or falling rents, contrasting with siblings like 'compare_rental_suburbs' or 'get_cheapest_rental_suburbs'. The verb 'Find' and resource statement are specific and distinguishing.

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 explains when to use: to identify hot or cooling markets. It does not explicitly say when not to use or list alternatives, but the purpose is clear enough. The examples further illustrate usage.

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?

No annotations are provided, so the description carries full burden. It describes the tool as a list/read operation, but does not mention any potential side effects, rate limits, or authentication needs. However, for a simple list tool, the description is sufficient.

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

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

The description is concise and well-structured with separate sections for Args, Returns, and Examples. While a bit verbose in listing values, it is clear and front-loaded.

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?

Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description covers all necessary context: purpose, usage guidance, parameter details, and output format.

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

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

The description thoroughly explains the single optional 'category' parameter, listing all valid values and providing examples. This fully compensates for the schema's lack of parameter descriptions.

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 clearly states the tool lists all available RBA economic data series with latest values. It distinguishes itself from the sibling get_rba_series() by advising to use this first.

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

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

Explicitly states to use this tool to discover data before calling get_rba_series(), providing clear context on when to use it versus alternatives.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool returns JSON grouped by category with cheapest prices, implying read-only behavior. No side effects or limitations are mentioned, but it is fairly transparent for a listing tool.

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

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

The description is well-structured: purpose sentence, usage sentence, then Args/Returns/Example in clear blocks. No redundant information; every sentence adds value.

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?

Given only 2 parameters and existence of output schema, the description explains the return structure (JSON grouped by category with cheapest price) and includes an example call, making it complete for this tool's 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 0%, but the description adds significant value: specifies ISO 3166-1 alpha-2 format for country, gives examples ('AU', 'US', 'IN', 'GB'), and explains category as optional slug with examples ('streaming-video', 'ai-tools'). This greatly exceeds the schema alone.

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 clearly states it lists subscription services available in a specific country, grouping by category and showing cheapest price. It does not explicitly differentiate from sibling tools, but the verb 'list' and resource 'services by country' are specific enough.

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 says 'Use this to discover what subscriptions are available in a given market', which provides clear usage context. However, it does not mention when not to use it or suggest alternatives among sibling tools.

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?

No annotations are provided, so the description carries the burden. It describes the tool as listing data, implying a read operation. However, it does not disclose potential limitations like pagination, rate limits, or authentication needs. It is adequate but not thorough.

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

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

The description is concise, well-structured, and front-loaded. The first sentence states the purpose, followed by usage guidance, parameter description, return format, and an example. Every sentence adds value, no wasted words.

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?

Given the low complexity (one optional parameter, output schema present), the description covers purpose, usage, parameter, return format, and an example. It lacks details on pagination or sorting, but for a simple listing tool, it is fairly complete.

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

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

The schema has zero description coverage for the parameter, but the tool description explains 'search: Optional search term to filter trades by name.' This adds meaning beyond the schema's type definition, and an example is provided. It compensates well for the lack of schema descriptions.

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 clearly states it lists all available contractor/trade types and their services in Australia. It uses specific verbs and resources, and the sibling tools are all about pricing and subscriptions, so it is well-differentiated.

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 says 'Use this to discover what trades are tracked', providing a clear context for use. It does not explicitly mention when not to use it or suggest alternatives, but the context is sufficiently clear for an AI 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool searches both generic and brand names, returns a JSON list with prices, and provides default and max limit. It does not mention rate limits or error handling, but overall behavior is clear for a search tool.

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

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

The description is well-structured with a summary, usage paragraph, args, returns, and examples. It is front-loaded with the key purpose and uses bullet-like formatting for args, making it easy to parse. No unnecessary 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?

Given the tool has an output schema, the description appropriately summarizes return values as a JSON list with prices. It provides examples but does not address no-result scenarios or error cases. For a simple search tool, this is adequate.

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 0%, so the description fully compensates. It describes the 'query' parameter with explicit examples and the 'limit' parameter with default and maximum values, adding meaning beyond the basic type and title in the schema.

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

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

The description clearly states the tool searches the Australian PBS schedule for medications by name, distinguishing it from exact-price lookup tools like get_pbs_drug_price. It specifies it handles both generic and brand names, making the purpose 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?

The description guides usage by specifying 'when you don't know the exact drug name' and provides examples like 'statin' and 'blood pressure'. It implicitly contrasts with exact name lookup but does not explicitly mention alternative tools for known 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?

Discloses partial match, optional state filter, and JSON list output. Could mention case sensitivity or rate limits, but adequate given no annotations.

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

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

Concise and well-structured with sections: one-liner, args, returns, examples. No unnecessary words.

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?

Complete for a simple search tool with output schema; covers input, output, and usage fully.

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?

Adds full meaning for both parameters: q (suburb name, partial match) and state (optional, state codes). Compensates for 0% schema 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?

The description clearly states it searches suburbs by name in Australia's rental market and returns median weekly rent, distinguishing it from siblings like get_suburb_rent and compare_rental_suburbs.

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?

Provides clear usage instructions and examples, but lacks explicit guidance on when not to use or direct comparison to alternatives.

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