Source-backed AI model pricing, rankings, history, and benchmark data.
Scored across 11 tools
Most tools have clearly distinct purposes: cost calculation, benchmark lookup, news search, and historical changes are well separated. However, several model-discovery tools (search_models, find_cheapest, find_best_value, recommend_model, compare_models) overlap in filtering or ranking models, which could occasionally cause misselection.
All names use snake_case consistently, which is readable. However, the pattern is not uniformly verb_noun: several are noun phrases (benchmark_lookup, pricing_history, provider_summary, latest_changes), creating minor inconsistency in verb style.
11 tools is well within the ideal range for a pricing hub. Each tool serves a clear function, and the set feels appropriately scoped without obvious redundancy.
The surface covers core pricing workflows: search, cost estimation, comparison, recommendation, benchmarks, history, changes, provider summaries, and news. Minor gaps exist, such as no direct tool to fetch a single model's full details or list all providers, but agents can work around these via existing tools.
Find sourced benchmark rows by model, provider, or benchmark ID.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| cursor | No | cursor | |
| model_id | No | model id | |
| provider | No | provider | |
| benchmark_id | No | benchmark id |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which is consistent with the description implying a read operation. However, beyond that, the description discloses only filtering capabilities but lacks details on pagination behavior, data source, or any side effects. Given the annotation coverage, the description adds some but not rich behavioral context.
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 a single concise sentence that captures the essential purpose with no wasted words. It is efficiently front-loaded and focused.
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 5 parameters including pagination (limit, cursor) and an output schema, the description is minimal. It does not explain how pagination works, what constitutes a 'sourced' benchmark row, or provide enough detail for an agent to correctly compose queries without additional context.
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% but parameter descriptions are minimal (e.g., 'limit', 'cursor'). The description adds value by specifying that the tool can filter by model, provider, or benchmark ID, but doesn't explain the role of limit and cursor or provide any additional semantics 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 benchmark rows using a specific verb 'Find' and resource 'benchmark rows'. It mentions filtering by model, provider, or benchmark ID, which distinguishes it from sibling tools like 'compare_models' or 'search_models' that have different purposes.
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 guidance on when to use this tool versus alternatives. There is no mention of when not to use it, prerequisites, or comparison with sibling tools like 'search_models' or 'latest_changes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate cost from total input tokens, their cached subset, output tokens and request count. Optional batch_mode uses available batch rates with standard-rate fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | No | model id | |
| requests | No | requests | |
| batch_mode | No | batch mode | |
| input_tokens | No | input tokens | |
| output_tokens | No | output tokens | |
| cached_input_tokens | No | cached input tokens |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description does add one genuine behavioral detail beyond annotations — that batch_mode uses batch rates with a standard-rate fallback — but says nothing about units, currency, or how optional parameters default, which matters for a 6-param tool with zero required fields.
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, with the core operation front-loaded ahead of the optional-mode caveat. Every clause carries 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?
An output schema exists, so return values need not be described, and the batch_mode caveat is a useful addition. However, with six parameters all optional and none marked required, the description leaves the agent guessing which inputs are actually needed and in what units, so it is only minimally sufficient.
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 nominally 100%, so the baseline is 3, though those schema descriptions are bare name restatements. The description adds real value for two params: it clarifies that cached_input_tokens is a subset of input_tokens, and explains batch_mode's fallback behavior. It says nothing about model_id, the most consequential parameter, nor about the accepted string/number/array forms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Estimate cost") and enumerates the inputs it operates on: input tokens, cached subset, output tokens, request count. It is clearly distinguishable from siblings like find_cheapest or compare_models, but it never explicitly names or contrasts those siblings, so it stops short of a 5.
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 only usage signal is that batch_mode is optional and falls back to standard rates. There is no guidance on when to reach for this tool versus benchmark_lookup, find_best_value, or find_cheapest, and no stated prerequisites (e.g., that a model_id is effectively needed for a meaningful result).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare pricing, context, and sourced benchmarks for model IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| model_ids | No | model ids |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to reiterate read-only behavior. It adds no further behavioral traits (e.g., limits on model count, data freshness), thus providing minimal extra value beyond 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?
The description is a single concise sentence that front-loads the core purpose. It is efficient, though it could benefit from slight restructuring for clarity (e.g., listing comparison axes).
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?
Despite having an output schema, the description omits crucial details about what 'context' and 'sourced benchmarks' entail. For a comparison tool, users need to know the output format and scope, making the description incomplete.
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 the parameter description 'model ids'. The tool description rephrases this without adding new semantic details (e.g., accepted formats, number of IDs). Given high schema coverage, 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 action 'compare' and the objects 'pricing, context, and sourced benchmarks for model IDs', distinguishing it from sibling tools like benchmark_lookup or calculate_cost. However, 'model IDs' is slightly ambiguous as it may imply comparing the IDs themselves rather than the models they represent.
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?
No explicit guidance on when to use this tool versus alternatives like recommend_model or find_best_value. The description lacks context for selection, making it hard for an agent to decide without additional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank models by available benchmark signal per listed token price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| cursor | No | cursor | |
| provider | No | provider | |
| benchmark_id | No | benchmark id |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description is not required to restate safety. It adds the behavioral detail of ranking by a value metric but does not disclose pagination behavior, data freshness, or how 'available benchmark signal' is computed.
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 a single, concise sentence (10 words) with no filler. It is front-loaded with the verb 'Rank' and efficiently conveys the tool's core functionality.
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 is too brief given the tool has 4 optional parameters and a ranking operation. It lacks explanation of how the ranking is performed or how parameters influence results. The presence of an output schema partially compensates for missing return value details.
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?
Although schema description coverage is 100%, all parameter descriptions are minimal (e.g., 'provider', 'benchmark id'). The tool description provides high-level context but does not explain individual parameter usage, meaning, or valid values.
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 ranks models by benchmark signal per token price, directly specifying the verb, resource, and criterion. This distinguishes it from sibling tools like find_cheapest (price-only) and compare_models (general 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find cheapest models by combined listed input plus output token price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| cursor | No | cursor | |
| provider | No | provider | |
| workload | No | workload |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is read-only. The description adds that price is combined input+output token cost, but does not disclose other traits like sorting order or grouping. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and straight to the point, but could be slightly more structured with bullet points or examples for brevity and clarity.
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?
Despite having an output schema, the description is too brief for a tool with 4 parameters. It does not explain what 'cheapest' means in case of ties, how limit works, or how to use cursor for pagination. More detail is needed.
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% but each parameter description is just the parameter name (e.g., 'limit', 'cursor'), providing no meaningful information. The tool description does not mention or explain parameters, so it adds no 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 cheapest models by combined input+output token price, which is a specific verb+resource. It distinguishes from siblings like find_best_value and calculate_cost by focusing on price-based ordering.
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 (when seeking cheapest models by price), but lacks explicit guidance on when not to use or comparisons to alternatives. No exclusions or context for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent model launches, removals, and pricing changes.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | type | |
| limit | No | limit | |
| cursor | No | cursor | |
| provider | No | provider |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent ('return'). No additional behavioral details (e.g., pagination, rate limits) are added beyond what annotations provide.
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 a single sentence with no wasted words. It could benefit from brief structure (e.g., listing parameter purposes) but is 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?
Output schema exists but is not described; given the tool's simplicity, the description is adequate. However, parameter meanings are unclear, which reduces completeness for an agent.
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 100% coverage but each parameter description is just its name (e.g., 'type', 'limit'). The description does not add meaning or usage context beyond the minimal schema entries.
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 returns recent model launches, removals, and pricing changes. It uses a specific verb ('return') and resource ('changes'), distinguishing it from sibling tools like search_models or pricing_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is to get recent updates, but no explicit when-to-use or when-not-to-use guidance is provided. No alternatives are mentioned despite having many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return historical pricing snapshots for a model ID.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | No | model id |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by stating 'Return,' indicating a safe read operation. However, it does not disclose additional behavioral traits like data range, granularity, or error handling. The annotation already covers safety, so the description adds limited context.
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 a single, front-loaded sentence with no wasted words. It is efficient, though slightly terse.
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 simplicity of the tool (one parameter, read-only, output schema exists), the description is mostly adequate. It could mention that model_id accepts multiple types or that it returns an array, but the schema covers 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?
Schema description coverage is 100%—the only parameter has a schema description 'model id.' The tool description adds no further meaning beyond what the schema provides, so 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 action (Return), resource (historical pricing snapshots), and target (model ID). It distinguishes the tool from siblings like latest_changes or calculate_cost by focusing on historical pricing 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?
The description provides no guidance on when to use this tool versus alternatives such as latest_changes (presumably for recent changes) or benchmark_lookup. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize model count, prices, benchmarks, and changes for a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | provider |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds value by specifying what is summarized (count, prices, benchmarks, changes). No contradiction.
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?
Single sentence, no filler words. Every part is necessary and 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 the tool has one optional parameter and an output schema, the description adequately covers what the tool does (summarize multiple aspects). Could be improved by noting that output is structured, but output schema handles 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?
Schema description coverage is 100% for the single parameter 'provider', but both schema and description provide minimal detail. Description adds context that summary is 'for a provider', which is slightly more than schema's bare 'provider'. 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?
Description uses specific verb 'summarize' and resource 'provider', and lists specific aspects (model count, prices, benchmarks, changes). Clearly distinguishes from siblings like compare_models or search_models.
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?
No guidance on when to use this tool vs alternatives like latest_changes or calculate_cost. No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend models for a workload using price, context, and benchmark evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| budget | No | budget | |
| provider | No | provider | |
| workload | No | workload | |
| min_context_tokens | No | min context tokens |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description is consistent. The description adds that it uses price, context, and benchmark evidence, which is slightly beyond the annotation but does not provide deep behavioral insight.
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?
One sentence, no wasted words. Front-loaded with the core 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?
With an output schema present and 100% schema coverage, the description is somewhat complete but could be improved by explaining how recommendations are generated and what the output contains.
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%, but param descriptions are just names (e.g., 'limit'). The description adds some context by mentioning workload, price (budget), and context (min_context_tokens), but does not fully explain all parameters like provider.
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: recommending models based on workload, price, context, and benchmarks. It distinguishes from siblings like benchmark_lookup and calculate_cost, but could be more specific about what 'context' and 'price' refer to.
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?
No guidance on when to use or not use this tool versus siblings like compare_models or find_best_value. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the pricing catalog with provider, workload, context, and price filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| query | No | query | |
| cursor | No | cursor | |
| provider | No | provider | |
| workload | No | workload | |
| max_combined_price | No | max combined price | |
| min_context_tokens | No | min context tokens |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description carries a lower burden. It adds no behavioral details such as pagination behavior, sorting, or error conditions. The description's only behavioral clue is the cursor parameter, but it is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of approximately 10 words. Every word serves a purpose—no redundancy or fluff.
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?
Despite an output schema existing, the description is insufficient for a tool with 7 parameters and pagination. It does not explain cursor usage, how query interacts with other filters, or what the output represents beyond the schema. Sibling tools like 'search_news' indicate a need for clearer scope differentiation.
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% (all 7 parameters described in schema), baseline is 3. The tool description adds meaning for four parameters (provider, workload, context, price) beyond the schema's minimal descriptions, but does not cover limit, query, or cursor. The addition is marginal, maintaining the 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 'Search the pricing catalog with provider, workload, context, and price filters,' specifying the verb 'search' and the resource 'pricing catalog' with explicit filters. It distinguishes from siblings like 'benchmark_lookup' and 'calculate_cost' by focusing on searching and filtering, but does not detail the output.
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?
No guidance on when to use this tool versus alternatives like 'compare_models' or 'find_best_value'. The description only states what it does, lacking explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AI Pricing Hub news items.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | limit | |
| query | No | query | |
| cursor | No | cursor | |
| source | No | source | |
| language | No | language |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is already present, but the description adds no additional behavioral context (e.g., pagination, sorting, rate limits, or that it returns a list of news items). The description merely restates the tool's 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 a single sentence with no wasted words, achieving conciseness. However, it may be too terse for adequate guidance, but conciseness is still high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no required fields, and no enums, the tool is relatively simple. However, the description offers no insight into the return structure (though output schema exists), filtering behavior, or relationship to other tools, leaving gaps for an AI agent.
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 descriptions are minimal (e.g., 'query' repeated without details), and the tool description does not clarify parameter usage, such as expected formats or constraints for 'limit', 'cursor', 'source', or 'language'. Despite 100% schema coverage, the descriptions add no value.
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 the verb 'Search' and resource 'AI Pricing Hub news items', clearly indicating what the tool does. However, it could be more specific about the scope (e.g., which aspects of news), but it's sufficiently distinct from siblings like search_models.
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?
No explicit guidance on when to use this tool versus alternatives. With siblings like search_models, the description should clarify if search_news is for textual news content versus model data, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_cost1 field changedInput schema / properties / batch_modeAdded value: +{
+ "description": "batch mode",
+ "type": "boolean"
+}benchmark_lookupcalculate_costcompare_modelsfind_best_valuefind_cheapestlatest_changespricing_historyprovider_summaryrecommend_modelsearch_modelssearch_newsAI model prices per provider, benchmarks, own AI behavior tests and AI economy data, with sources.
Sourced AI-model pricing and capability data — compare and route to the cheapest capable model.
Compare LLM API prices, search models and providers, and access reviewed benchmark results.
LLM rankings from public benchmarks, model comparisons and source-linked results. Updated daily.
Add one secure layer between your agents and this server.