AI Pricing Hub
Server Details
Source-backed AI model pricing, rankings, history, and benchmark data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 11 of 11 tools scored.
Each tool has a distinct, clearly described purpose. Even similar-sounding tools like find_best_value and find_cheapest are differentiated by their criteria (benchmark signal vs. pure price). No two tools are easily confused.
Most tools follow a verb_noun pattern (e.g., search_models, calculate_cost). However, 'latest_changes' and 'pricing_history' deviate from this pattern, and 'benchmark_lookup' uses noun_noun. Overall, the pattern is recognizable, but not perfectly uniform.
With 11 tools, the server is well-scoped for its purpose: querying AI model pricing, benchmarks, and news. Each tool serves a clear function, and the count is within the ideal 3-15 range.
The tool set covers core operations like searching, comparing, calculating costs, and checking history. However, there is no dedicated 'get_model' tool for fetching full details on a single model, which is a minor gap. Overall, the surface is complete for most user queries.
Available Tools
11 toolsbenchmark_lookupBenchmark lookupARead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 restate read-only behavior. Beyond that, the description adds no additional behavioral details such as pagination, rate limits, or result ordering. With an output schema present, some behavior is inferred, but minimal extra context is provided.
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 efficiently conveys the tool's purpose and filtering options. 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 the tool's simplicity (read-only lookup with 5 parameters), an output schema, and clear annotations, the description is mostly complete. It could be improved by clarifying the term 'sourced' or how results are paginated, but these are minor gaps.
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 the schema descriptions are minimal (e.g., 'limit', 'cursor', 'model id'). The tool description does not add deeper meaning or usage context for any parameter (e.g., format of cursor, default limit, valid values). Baseline 3 is appropriate given full schema coverage, but no extra 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 clearly states the tool's purpose: 'Find sourced benchmark rows by model, provider, or benchmark ID.' It uses a specific verb ('Find') and resource ('sourced benchmark rows'), and explicitly lists filtering criteria, which distinguishes it from sibling tools like 'search_models' (which searches models) and 'calculate_cost' (which computes cost).
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 (filtering benchmarks) but provides no explicit guidance on when to use this tool vs. alternatives, nor any exclusions or prerequisites. For example, it doesn't mention that it's read-only (though annotations cover that) or when to prefer it over 'compare_models' or 'best_value'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_costCalculate costARead-onlyInspect
Estimate cost from model pricing and token volumes.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | No | model id | |
| requests | No | requests | |
| input_tokens | No | input tokens | |
| output_tokens | No | output tokens | |
| cached_input_tokens | No | cached input tokens |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds no further behavioral detail. It is consistent but does not disclose assumptions or accuracy.
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, front-loaded, no unnecessary words. Efficiently communicates 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?
Output schema covers return values. Description is adequate given simplicity; could mention required combinations but 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?
Schema coverage is 100%, so baseline is 3. Description adds context linking parameters to pricing, but no deeper semantics beyond 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 estimates cost using model pricing and token volumes, with a specific verb and resource. It distinguishes from siblings like compare_models or find_cheapest.
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 versus alternatives. The context is clear but lacks exclusions or explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_modelsCompare modelsARead-onlyInspect
Compare pricing, context, and sourced benchmarks for model IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| model_ids | No | model ids |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it compares pricing, context, and benchmarks, but no additional behavioral traits beyond that. Consistent.
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 waste, front-loaded with key verb and resources.
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?
Simple tool with one parameter, annotations, and output schema. Description is sufficient for understanding purpose; output schema covers return 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?
Schema has 100% description coverage. Description says 'model ids', which adds no meaning beyond the schema's description. Baseline 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?
Description uses specific verb 'compare' and resources 'pricing, context, and sourced benchmarks for model IDs', clearly distinguishing from sibling tools like benchmark_lookup 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?
Implies use when comparing multiple models, but no explicit when-not or alternatives mentioned. Siblings exist but description doesn't differentiate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_valueFind best valueARead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safe read operation; the description adds that ranking is by benchmark signal per token price. However, it does not disclose additional behavioral traits such as pagination behavior (cursor parameter) or rate limits, which would be useful 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 sentence with no unnecessary words, making it concise and easy to parse. However, it could be slightly more structured by briefly explaining the parameters or output, though it remains effective.
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 4 parameters and no required ones, and an output schema existing, the description covers the ranking logic but does not explain parameters like cursor or provider. This leaves gaps for the agent; the description could be more complete by clarifying parameter roles despite the schema descriptions being minimal.
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 (just parameter names). The description does not add any meaning beyond what the schema provides, such as how limit, cursor, provider, or benchmark_id affect the ranking. Baseline is 3, but this fails to add value, so score is 2.
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 ranks models based on benchmark signal per token price, which is a specific verb+resource. This distinguishes it from siblings like 'find_cheapest' (focuses on price) and 'compare_models' (focuses on 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 implies usage for ranking models by value, but it does not explicitly state when to use this tool versus alternatives like 'recommend_model' or 'find_cheapest'. No exclusions or examples of when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_cheapestFind cheapestBRead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, indicating read-only behavior. However, it does not elaborate on pagination, result ordering, or edge cases, which would be beneficial beyond the annotation.
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, clear sentence with no unnecessary words. It is appropriately concise, though it could be slightly more structured for readability.
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 four parameters and a complex search task, the description is insufficient. It does not explain how parameters interact, expected output, or any constraints, leaving significant gaps for proper invocation.
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 parameter descriptions are trivial ('limit', 'cursor', 'provider', 'workload'). The tool description adds no extra meaning. Baseline of 3 applies due to high coverage, but no improvement.
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 based on combined input and output token price. It specifies the action and criteria, though it does not explicitly differentiate from siblings like find_best_value or compare_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 versus alternatives. The description lacks context about prerequisites or typical use cases, leaving the agent uncertain about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latest_changesLatest changesBRead-onlyInspect
Return recent model launches, removals, and pricing changes.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | type | |
| limit | No | limit | |
| cursor | No | cursor | |
| provider | No | provider |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a read-only operation. The description adds no further behavioral details (e.g., ordering, pagination, rate limits), but does not contradict 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, clear sentence with no unnecessary words. It efficiently states the tool's 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?
Despite an output schema existing, the description omits details about default behavior, parameter usage, and output format. For a tool with 4 parameters and no required ones, this is insufficient guidance.
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 coverage is 100%, the parameter descriptions in the schema are just names ('type', 'limit', 'cursor', 'provider') with no additional meaning. The tool description does not clarify what these parameters do or how to use them, failing to compensate for the weak 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 the tool returns recent model launches, removals, and pricing changes, but the verb 'Return' is generic and does not specify the scope or source of changes, which slightly reduces clarity.
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 siblings like pricing_history or search_models. No when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_historyPricing historyCRead-onlyInspect
Return historical pricing snapshots for a model ID.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | No | model id |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safety. The description adds only that the tool returns historical snapshots, but omits any details about data range, pagination, or potential limitations.
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, concise and front-loaded. 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?
With an output schema present, return values are covered, but the description fails to explain the historical nature, time range, or any filters. It is incomplete for a tool expected to provide temporal data.
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 parameter 'model_id' is described in the schema. The tool description adds no extra meaning beyond what the schema provides.
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 specific verb 'Return' and resource 'historical pricing snapshots for a model ID', making the tool's purpose clear. It distinguishes itself from sibling tools like find_best_value or latest_changes, though not explicitly.
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. It does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provider_summaryProvider summaryARead-onlyInspect
Summarize model count, prices, benchmarks, and changes for a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | provider |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description is consistent as 'Summarize' implies a read operation. The description adds behavioral context by listing what is summarized (model count, prices, benchmarks, changes), going beyond the annotation to clarify the tool's output scope.
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 of 9 words, efficiently stating the tool's purpose. It is front-loaded with the verb and resource, containing no extraneous 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 one parameter, an output schema, and annotations, the description adequately covers the tool's purpose. It could optionally detail the scope of 'models' or 'benchmarks', but the output schema likely handles the return structure. The description is sufficiently complete for a summary tool with good structured metadata.
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 described as 'provider', which is minimal. The tool description adds the context 'for a provider', reinforcing the parameter's purpose. With high coverage, the baseline is 3, and the description provides no additional syntax or format details.
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 'Summarize' and identifies the resource as a 'provider'. It clearly indicates the tool produces a summary of model count, prices, benchmarks, and changes, distinguishing it from more specific sibling tools like benchmark_lookup or calculate_cost.
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 for when a broad provider overview is needed, but provides no explicit guidance on when not to use it or how it differs from alternatives. Sibling tool names give context, but the description itself lacks usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_modelRecommend modelBRead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the read-only nature is clear. The description does not contradict this and adds little beyond the annotation. No additional behavioral traits (e.g., sorting, result format) are disclosed, but with annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 10 words, front-loading the core purpose. It is lean but could benefit from an additional sentence about output or parameter hints without becoming verbose.
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 and annotations cover read-only, the description provides the basic intent but lacks details on when to prefer this over the 10 siblings. It is adequate for a straightforward recommendation tool but leaves gaps in usage 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 (just names). The description adds meaningful context by stating the criteria used (price, context, benchmark), which helps map to parameters like budget and min_context_tokens. However, it does not explicitly link each parameter, so it adds moderate 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 recommends models for a workload using price, context, and benchmark evidence. The verb 'recommend' and resource 'models' are specific, and it hints at distinguishing criteria from siblings, but it does not explicitly differentiate from search_models or compare_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 like find_cheapest or compare_models. The description implies usage for recommendation based on criteria, but lacks direction on scenario-specific selection or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_modelsSearch modelsCRead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context beyond that. It states the tool searches filters but doesn't disclose pagination (cursor), rate limits, or behavior on empty results.
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 fluff, but it is too brief to convey necessary detail. It could be slightly expanded to include key filter meanings without losing 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?
Given 7 parameters, no required ones, and the presence of an output schema, the description is insufficient. It does not explain the query parameter, pagination via cursor, or how filters combine, leaving significant gaps 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?
Schema description coverage is 100%, but each parameter's description is merely its name. The tool description maps some parameters (provider, workload, min_context_tokens, max_combined_price) to filter types, adding some meaning, but leaves limit, query, and cursor unexplained.
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 'Search' and the resource 'pricing catalog', and mentions the types of filters (provider, workload, context, price). It distinguishes from siblings like search_news and calculate_cost by specifying the catalog domain, though it could be more precise about what each filter means.
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_cheapest. No exclusion criteria or context provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_newsSearch newsBRead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description mentions 'Search', which aligns. No additional behavioral traits are disclosed beyond what annotations already provide. The description does not contradict 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, short sentence with no redundancy. It is front-loaded and contains only essential 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 presence of an output schema (not shown) and high schema parameter coverage, the description is minimally adequate. However, it lacks details about search behavior, return format, or edge cases. Usage guidelines are missing, reducing completeness.
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 parameter descriptions are minimal (just the parameter names). The tool description does not add any meaningful context about how parameters are used or their expected format. Baseline 3 is appropriate due to 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 searches AI Pricing Hub news items. It specifies the domain and resource, distinguishing it from sibling tools like search_models. However, it could be more specific about the type of news or search capabilities.
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 search_models or other news-related tools. The description does not provide any context about prerequisites, intended use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!