verified-ai-free-tiers

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool returns verified data and highlights the two common surprises (changed allowances and unknown figures). It does not mention error handling, rate limits, or data source freshness, but covers the key behavioral nuances of the audit.

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 compact yet information-dense. It front-loads the purpose with a colon list, then provides usage context and value-add in a second sentence. No wasted words; every sentence earns its place.

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

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

Given the tool's complexity (multi-tool audit), the description effectively explains what it returns (four data points per tool) and when to use it. Since there is no output schema, the description adequately substitutes by listing the output fields, making the tool's behavior transparent and 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 description coverage is 100%, so parameters are already well-documented. The description adds an example of tool names ('Cursor, Runway and Kimi') but does not add extra semantics beyond the schema, which is acceptable given the high 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 audits several AI tools at once and enumerates the four specific data points it returns (free-tier limit, commercial use, changes, publication status). It distinguishes itself from siblings by being a multi-tool, multi-aspect aggregate, unlike single-purpose siblings like check_free_tier_claim or get_free_tier_limit.

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 when a user names the stack they rely on' and contrasts with the alternative of 'four lookups per tool'. This gives concrete when-to-use guidance and differentiates from sibling tools that handle individual checks.

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 burden of behavioral disclosure. It adds useful context about the output being a step-by-step recipe, the use of verified free tools, and the inclusion of money playbooks. However, it doesn't explain how results are returned, limitations, or handling of out-of-scope topics, so transparency is moderate.

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 front-loaded with the main purpose and then provides a comprehensive list of covered tasks and the playbook addition. While the list is long, it is within a two-sentence structure and each part earns its place, making it appropriately sized for the tool's broad scope.

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 output schema, the description does a good job explaining what the user gets (a complete step-by-step recipe) and the order of operation. It also covers a wide range of task categories and mentions 'and more', giving an agent enough context to decide when to invoke it. It falls short of a 5 by not specifying output structure or handling of unsupported tasks.

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

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

Schema description coverage is 100%, so the baseline is 3. The description doesn't add additional meaning to the parameters (kind, lang, task); it only indirectly echoes the recipe/playbook distinction already present in the kind parameter's enum description. No extra parameter semantics are provided.

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: to provide a complete step-by-step recipe for doing a task on free tiers. It explicitly distinguishes itself from sibling tools that list tools one by one by emphasizing the ordered workflow, making it a specific and differentiated definition.

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 explicit guidance on when to use the tool: 'Use this for "how do I do X without paying" questions instead of listing tools one by one.' This contrasts with sibling tools like find_free_alternatives or search_ai_tools, but doesn't explicitly name them or give exclusions, so it's slightly short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the computation method ('divides the officially published limits by that load'), the output categories (providers inside caps, exceeded, one-time credit duration, unknown figures), and clarifies a non-obvious behavior: providers with no published figure are reported as 'unknown rather than generous.' This is strong disclosure beyond basic function.

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 front-loaded with the core purpose and then details the computation and outputs. It is a single sentence plus an explicit usage recommendation. While a bit long, every clause adds useful information—no filler or repetition. It could be tightened, but it is well structured.

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 tool has no output schema, so the description must explain what the tool returns. It does so: it reports which providers stay inside caps, which are exceeded, how long one-time credit grants last, and which publish no figure. It also explains the input parameters. The only minor omission is not explaining the lang parameter, but given the tool's simplicity and the schema's enum, the description is sufficiently 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 description coverage is 100%, so the baseline is 3. The description adds context by mapping 'expected calls per day' to requests_per_day and 'average tokens per call' to tokens_per_call, and clarifies that tokens include input plus output (though the schema already says this). It does not add meaning for the lang parameter, but the schema enumerates its options. The description provides marginal 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: 'Work out which verified free LLM API tiers can actually carry a given workload.' It identifies the specific verb ('work out'), the resource ('verified free LLM API tiers'), and the input needed ('expected calls per day and average tokens per call'). This distinguishes it from siblings like compare_free_tiers (which likely compares tiers) and get_free_tier_limit (which likely retrieves a single limit).

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: when you need to assess workload fit against free tier caps. The final sentence, 'Use this instead of guessing whether a free tier is 'enough',' gives explicit usage guidance. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough that an agent could infer appropriate 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?

With no annotations, the description discloses expected output (verdicts: yes/no/conditional/depends on model/not stated) and qualifies itself as not legal advice with details on the publish-check page. This is meaningful behavioral context beyond the schema.

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

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

Two sentences with front-loaded purpose. The first sentence states exactly what the tool checks; the second adds a caveat that is short and relevant. 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?

Given the tool's simplicity (two parameters, no output schema), the description fully covers what the tool does and what to expect. It even points to external details for obligations. Sibling context further clarifies scope.

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

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

Schema description coverage is 100%: both 'lang' and 'tool' are documented in the schema. The description adds no parameter-specific detail, so the baseline of 3 applies.

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

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

The description uses a specific verb and object ('Check whether output... may be used commercially') and specifies the basis (vendor's official terms). It clearly distinguishes itself from sibling tools like get_free_tier_limit and search_ai_tools, which address different concerns.

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 when to use this tool: whenever a commercial-use determination for AI free-tier output is needed. It does not explicitly name alternatives or exclusions, but the clear scope and sibling context provide sufficient 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns ('what the official pages actually say and whether the widely-quoted figure has any official source at all') and warns that 'many do not'. This gives the agent an accurate expectation of both the read-only nature and the probabilistic outcome. It doesn't mention pagination or return format, but the description's explanation is well above the minimum.

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 exactly two sentences, front-loaded with the action verb and immediately followed by return behavior and a concrete usage trigger. Every sentence earns its place; there is no fluff or repetition.

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

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

For a tool with two optional parameters, no output schema, and no annotations, the description provides a complete picture: purpose, return value, and the precise condition for invocation. It could mention what happens if the tool slug is invalid or whether output is a structured object, but the absence of an output schema lowers the bar, and the description addresses the core needs well.

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 already covers both parameters fully: lang has enum/default, tool has a description including the 'omit to list' behavior. The description adds context about claim examples but does not add new parameter semantics beyond the schema. Baseline for 100% coverage is 3.

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 opens with a specific verb-resource pair, 'Fact-check a circulating claim about an AI tool's free tier', and clearly distinguishes itself from siblings like compare_free_tiers or get_free_tier_limit by focusing on verifying sourcedness against official pages. It also clarifies the tool's unique value: identifying whether widely-quoted figures have any official source, which many do not.

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 states when to use the tool: 'Use this when a user cites a specific number... and you need to know whether it is sourced or folklore.' This is clear contextual guidance. However, it does not explicitly name sibling tools as alternatives or state when not to use it, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses that output is structured data (not prose), includes source and check date for each row, and lists the attributes compared. This gives agents a clear behavioral model. However, it does not mention whether the tool caches data, has rate limits, or how recent the check date is, which would be helpful for a comparison 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 front-loaded with the core purpose, then provides specific examples and use cases. It is concise at about 4 sentences, but could be slightly more streamlined by moving the category examples to the schema or a separate note. Every sentence adds value, but the long list of categories in the middle might be better as a structured list.

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 2 parameters, no output schema, and no annotations, the description is fairly complete. It explains the output format (structured data, rows with source and date), the categories, and the attributes compared. However, for a comparison tool, it would be helpful to know if the output is a table or JSON, and how missing data is handled (e.g., if a vendor doesn't publish a figure). The sibling tools like 'explain_missing_figure' suggest that handling missing data is relevant.

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

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

Schema description coverage is 100% with both parameters having enum descriptions. The description adds value beyond the schema by explaining what each category means (e.g., 'chat (where the wall is - only 1 of 10 vendors publishes a message count)') and giving examples of the data structure. However, the 'lang' parameter is not elaborated in the description beyond the enum, so the value add is marginal for that parameter.

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 free tiers of AI tools side by side with structured data, listing specific attributes (grants, metering, reset, unmetered items, publication status). It distinguishes itself from siblings like 'compare_free_tiers' vs 'check_free_tier_claim' or 'find_free_alternatives' by emphasizing structured comparison. The verb 'compare' and resource 'free tiers' are specific and 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 provides explicit when-to-use guidance: 'Use this for "which free tier should I pick" and "how do these compare" questions.' It also lists example categories (chat, coding, etc.) implying context. However, it does not explicitly state when NOT to use this tool versus alternatives like 'check_free_tier_claim' or 'get_free_tier_limit', leaving some ambiguity for edge 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?

With no annotations, the description carries the transparency burden. It discloses that absence is intentional and lists specific recorded reasons (vendor states outright, official pages contradict, allowance changes, no official page). This gives the agent insight into returned explanations, though it doesn't specify the 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.

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

Two sentences, no filler. Front-loaded with purpose, then provides essential behavioral context. Every sentence earns its place.

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

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

Given the tool's low complexity and complete parameter schema, the description covers the main use cases. It doesn't state what happens for an unknown tool or the exact output format, but the explanation kinds are listed, making it sufficient for an AI agent to understand the tool's role.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about tool omission (in the tool schema) and the reason categories, but doesn't add meaning beyond the schema's parameter descriptions. The tool's purpose is reinforced, but parameter semantics are adequately covered by 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: 'Explain why this dataset publishes no figure for a given tool.' It uses a specific verb ('explain') and identifies the resource ('this dataset' and 'a given tool'), distinguishing it from sibling tools that retrieve limits or alternatives.

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: 'Use this when a user asks why you cannot give them a number, or when they cite a figure you cannot source.' It also frames absence as 'a finding, not an oversight,' providing context that prevents misuse.

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 of behavioral disclosure. It adds value by stating that results are 'verified' and include 'check dates', implying a research/read operation and giving insight into output characteristics. It does not mention side effects, but as a search tool, none are expected. This goes beyond a bare function statement.

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 two sentences long, front-loaded with the primary action, and every phrase contributes meaning. It efficiently covers both purpose and usage without 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?

The description adequately covers purpose, usage context, and return content ('verified allowances and check dates'). For a simple 3-parameter tool with no output schema, this is sufficient. It could slightly improve by explicitly stating the return format (e.g., a list of alternatives), but the current wording implies it.

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

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

The input schema already provides descriptions for all three parameters (lang, tool, works_in_china), achieving 100% coverage. The description adds context for the 'tool' parameter by framing it as a tool whose free tier is insufficient, but it does not elaborate on the optional parameters or add new semantic details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool finds entirely free alternatives in the same category for a given tool, with verified allowances and check dates. This distinguishes it from sibling tools like check_free_tier_claim or compare_free_tiers, which focus on checking claims or comparing tiers rather than discovering substitutes.

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 when to use the tool: when a user's free tier is insufficient, cannot access a service from their region, or wants a no-cost substitute. This provides clear context and implicitly excludes situations where a paid tool is acceptable, distinguishing it from 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?

With no annotations, the description carries transparency burden. It discloses that the returned question differs by category, gives concrete examples of what it considers decisive for specific categories, and lists the taxonomy components. This goes beyond the schema and sets accurate expectations, though it doesn't mention any side effects (not relevant for a read-only lookup).

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 front-loaded with the core purpose. It packs substantive examples and taxonomy details into two sentences without redundancy. Every clause earns its place, and the structure flows from purpose to examples to usage guidance.

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

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

There is no output schema, so the description must convey what the tool returns; it does list the decisive question and the taxonomy with examples. It also provides usage context. It could be more explicit about the exact structure of the output (e.g., fields per category), but for a reference-style tool the description is sufficiently 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 coverage is 100%, so the baseline is 3. The description adds value by explaining what the category parameter returns (e.g., video, design, API, chat examples) and that omitting category returns the full taxonomy, but these meanings are already largely captured in the schema descriptions. The description doesn't introduce syntax or format details 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 returns the decisive question for a category of AI tools and the free-tier metering taxonomy, with specific verb 'Get' and resource. It distinguishes itself from siblings like get_free_tier_limit and compare_free_tiers by focusing on the 'question to ask' before comparing numbers.

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 advises 'Use this before recommending anything in a category' and frames it as a pre-comparison step, providing clear usage context. It doesn't name sibling tools as alternatives, but the context is sufficient for an agent to decide when to invoke it.

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

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

With no annotations, the description carries the burden and explains the two independent gates, what the tool returns (issuer, effective date, obligations, optional tool list), and includes a 'Not legal advice' disclaimer. It does not describe any additional side effects or rate limits, but for this kind of informational tool, it 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 three sentences with no filler. It front-loads the purpose, explains the nuance of the two gates, and ends with a concise return-value summary plus legal disclaimer. Every sentence earns its place.

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

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

The tool has no output schema, and the description compensates by explicitly naming the return fields: regulation issuer, effective date, obligations, and optionally the tool list. It also contextualizes why the regulation matters, making it sufficient for an agent to understand the tool's full behavior.

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

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

Schema description coverage is 100%, and both parameters (lang, category) have clear descriptions in the schema. The tool description adds a little context about the category parameter being optional and related to the reachable-from-China list, but does not need to do much more. Baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Check what applies when publishing AI-generated content to mainland China platforms' and 'which AI tools are reachable from mainland China without a VPN'. It clearly distinguishes from sibling tools focused on free tiers and commercial use.

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: when dealing with publishing AI content to mainland China or checking VPN-free tool reachability. It does not explicitly mention alternatives or exclusions, but the context is unambiguous, so it slightly misses the top score.

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 takes on the disclosure burden. It reveals that vendors do not announce changes and that the data comes from 'daily re-checks against official pages,' which informs the agent that the log is independently maintained and may include unofficial but verified findings. This adds valuable behavioral context beyond just listing changes.

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 two sentences: the first states the core function, the second explains the data collection method and provides concrete use cases. Every sentence earns its place with no filler, making it highly concise and well-structured.

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 purpose, data source, and use cases. There is no output schema, but the description already conveys the returned information (vendor, change, date). It lacks explicit return-format details but is sufficiently complete for a simple list 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?

All 4 parameters have descriptions in the schema, with the 'since' parameter explaining the delta contract. The tool description itself doesn't add parameter-level detail, but since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'List recently verified changes to AI free tiers - which vendor changed what and on which date.' This distinguishes it from siblings by emphasizing the verified-change log aspect, making it unique among tools like watch_free_tier_changes or compare_free_tiers.

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 lists use cases: 'did anything change recently', 'is my information still current', and 'when a user quotes a figure that may be stale.' It provides clear when-to-use guidance but does not explicitly name alternative tools or exclusions, so it's not a perfect 5.

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

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

With no annotations, the description takes on the burden of behavioral disclosure. It explains the output content (source, date, allowance details), the absence behavior, and the data quality policy ('publishes no unsourced figures'). This goes beyond a basic read operation, though it does not mention side effects or error conditions.

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 two sentences, front-loaded with the primary purpose, then expanding into result details and a usage caveat. Every sentence earns its place 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's simplicity (2 params, no output schema), the description thoroughly covers what the tool returns, how to interpret the absence of results, and the verification policy. This is complete for a lookup tool and compensates for the lack of an output schema.

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

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

The input schema already fully describes both parameters (tool slug/name and lang enum with default). The description does not add parameter-specific guidance, but with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('verified free-tier limit of an AI tool'), listing concrete return items (allowance extent, wall behavior, source page, check date). It distinguishes itself from sibling tools like check_commercial_use and search_ai_tools by focusing on free-tier limits and verification.

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 context: retrieving verified free-tier allowance details for an AI tool. It also provides guidance on interpreting absence results ('Absence of a tool means no officially verifiable number exists'). It does not explicitly name alternatives, but the sibling tool names make differentiation 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 carries the full burden. It adds context about data verification ('Every verified entry carries its official source and check date') and cites a source, which is useful. However, it does not disclose potential behavior like rate limits, result pagination, or whether the directory is static or updated, though as a search tool it is inherently non-destructive.

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 three sentences, front-loaded with the core purpose, and each sentence adds value: purpose, filters, and data provenance/citation. No unnecessary words or repetition.

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

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

Given no output schema, the description provides some return context by mentioning that each entry has source and check date, but it does not describe the full result structure or pagination. The 6 optional parameters are well-covered by the schema, and the search tool's behavior is adequately conveyed for a directory search.

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

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

Schema description coverage is 100%, providing full parameter documentation, so the baseline is 3. The description adds a partial list of category values (missing a few like 'study', 'local', 'safety') and maps 'fully-free flag' and 'works-in-mainland-China flag' to the boolean parameters, but this is only marginal extra 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 'Search a verified directory of 218 AI tools with genuine free tiers', using a specific verb ('Search') and resource ('verified directory'). It also lists distinct filters (category, fully-free, works-in-mainland-China, keyword), distinguishing it from sibling tools like find_free_alternatives or check_free_tier_claim.

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: searching for AI tools with free tiers, with filters matching the schema. However, it does not explicitly name alternatives or state when not to use it, such as saying 'for verifying a free tier claim, use check_free_tier_claim'.

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 discloses triggers (allowance, wall, commercial terms changes), verification cadence, payload contents, and token requirements. It also notes that the token is the only way to update/delete a watch. It lacks details on retry behavior or failure handling, but otherwise provides strong 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 concise, front-loads the primary action, and every sentence adds essential detail—subscription purpose, webhook payload, limits, and token notice. No fluff or repetition.

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

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

The tool has no output schema, but the description compensates by explaining exactly what the webhook receives (changed fields, current wording, verification date, source page). It also covers setup, limits, and token management. For a tool with only three parameters and no complex return structure, this 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 coverage is 100%, so the baseline is 3. The description adds meaningful context: it explains 'key' as a Pro license that unlocks all tools, and 'slugs' with a free-tier maximum of 3. The 'hook' parameter is partly explained by 'webhook URL' in the schema, and the description reiterates HTTP POST. This extra guidance elevates the score above baseline.

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

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

The description states 'Subscribe a webhook to verified free-tier changes,' using a specific verb and resource. It clearly distinguishes from the sibling 'get_free_tier_changes' by emphasizing subscription and webhook delivery rather than an on-demand fetch.

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: when continuous monitoring of free-tier changes is needed, with daily verification. It also states usage limits (max 3 tools free, Pro license unlocks everything) and the importance of keeping the token for updates/deletions. However, it does not explicitly mention alternatives or when not to use it, so it misses the top bar.

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