A
licenseNot graded
qualityD
maintenanceEnables AI agents to compare LLM benchmarks, get pricing, and receive model recommendations for tasks and budgets.
39 PyPI
1
MIT
Cheapest LLM API
Server Details
Compare LLM API prices, search models and providers, and access reviewed benchmark results.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 70.9% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4/5.0
Scored across 12 tools
Disambiguation4/5
Most tools are cleanly separated by resource+action (catalog_search vs model_detail, benchmark_list vs benchmark_results, coding_agent_list vs coding_agent_detail). The only real overlap is pricing-oriented: offer_compare and price_watch operate on the same workload/evidence model, and coding_agent_releases vs coding_agent_upgrade both surface changelog data. Descriptions do a good job explaining the boundaries, but the pairs can still be confused on first pass.
Naming Consistency4/5
Eleven of twelve names follow a predictable resource_action pattern (catalog_search, provider_list, offer_compare, price_watch, benchmark_list/results, coding_agent_*). 'execute' is the lone outlier with no resource prefix, and 'model_detail' vs 'coding_agent_detail' is a minor asymmetry. Still highly readable and groupable.
Tool Count5/5
12 tools map cleanly onto distinct domain facets: catalog lookup, offer comparison, price watching, benchmarks, providers, coding-agent lifecycle, and a composition escape hatch (execute). No tool feels redundant or bolted on, and the count is well within a useful range.
Completeness4/5
The surface covers discovery (search/list), detail (model, provider, agent), evaluation (benchmarks), and decision-making (compare, watch, upgrade diff), plus execute for custom composition. Minor gaps: no provider_detail tool (only provider_list with counts) and no historical price trend beyond current-offer watching, which agents can partly work around via execute.
Available Tools
12 toolsbenchmark_listDiscover reviewed benchmarksARead-onlyIdempotentInspect
Discover exact benchmark IDs, editions, score units, configurations, provenance, and reviewed result counts before calling benchmark_results. Empty benchmarks are retained with resultCount 0.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: empty benchmarks are retained with resultCount 0, which preempts a likely agent misreading of absent results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The discovery purpose is front-loaded and the edge-case caveat about resultCount 0 is placed last, after the main point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still names the key fields an agent needs to chain into benchmark_results. With no inputs and annotations covering safety, nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to clarify, and it correctly spends no space on nonexistent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Discover) and enumerates the exact resources returned: benchmark IDs, editions, score units, configurations, provenance, and reviewed result counts. It also names the sibling it precedes (benchmark_results), so an agent can distinguish it from benchmark_results without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use it: 'before calling benchmark_results', which is clear sequencing guidance. It does not, however, state when not to use it or name any alternative discovery path (e.g. catalog_search), so it falls short of the full when/when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
benchmark_resultsGet benchmark resultsARead-onlyIdempotentInspect
Get reviewed scores for an exact benchmark_id from benchmark_list. Join result.modelId to catalog_search model.id. Compare scores only within the same benchmark edition and configuration. Includes source provenance and reported coding-agent usage when published. Follow pagination.hasMore.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| benchmark_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| pagination | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds value by disclosing source provenance, conditional coding-agent usage, and pagination.hasMore, which are behaviors beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each carrying distinct operational information (id source, join path, comparison constraint, contents, pagination). Front-loaded with purpose and zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained; the description covers the join, comparison scope, provenance, and pagination. Slightly incomplete on limit/offset semantics but otherwise sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the benchmark_id source (from benchmark_list) and asserts pagination via pagination.hasMore, but limit/offset semantics are not spelled out beyond what schema defaults/min/max provide. It adds partial meaning for one of three params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get reviewed scores') and resource ('benchmark_id'), and distinguishes itself from siblings by referencing benchmark_list for the id and catalog_search for the join. An agent can tell exactly what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directs the agent to obtain an exact benchmark_id from benchmark_list, and tells it to compare only within the same edition/configuration. Lacks explicit exclusions of when-not to use, but the workflow guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
catalog_searchSearch LLM catalogARead-onlyIdempotentInspect
Find canonical model slugs, context limits, and provider prices. Optional provider_slug filters availability, not the provider in bestOffer. bestOffer is selected for 10M input + 2M output tokens; use offer_compare for your workload. Follow pagination.hasMore.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | ||
| page_size | No | ||
| category_slug | No | ||
| provider_slug | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| pagination | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds non-obvious behavior: the exact token mix (10M input + 2M output) underlying bestOffer selection and the availability-vs-provider semantics of provider_slug. It also points at pagination.hasMore for continuation, which is behavior the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, no filler, front-loaded with the primary purpose and followed by the two constraints an agent most needs (bestOffer basis and pagination). Every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers the key selection rule and pagination signal. It is slightly thin on the four undocumented query/pagination parameters, which an agent must infer from defaults alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema documents nothing about page, page_size, query, and category_slug. The description compensates only for provider_slug, explaining its filtering semantics, leaving the other four parameters without meaning beyond their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus the concrete outputs (canonical model slugs, context limits, provider prices), which immediately distinguishes it from siblings like provider_list or model_detail. An agent can tell what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Routes the agent to a sibling ('use offer_compare for your workload') and clarifies that provider_slug filters availability rather than the bestOffer provider. It lacks an explicit statement of when not to use it or of prerequisites, but the alternative routing is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coding_agent_detailGet a coding agentARead-onlyIdempotentInspect
Get a coding-agent profile by agent_slug from coding_agent_list, including official source, latest stable release, freshness, and history coverage. An unavailable archive is explicit in state. This does not assert product benchmark rankings or subscription prices.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety burden is largely carried. The description adds genuine context beyond them: what the payload covers (official source, latest stable release, freshness, history coverage) and that an unavailable archive surfaces explicitly via state rather than as a silent failure. It says nothing about auth or rate limits, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and lookup key, then inclusions, then exclusions. Little waste, though the phrasing 'An unavailable archive is explicit in state' is terse enough to be slightly opaque about what state actually names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be spelled out, and the description still summarizes the covered fields. Annotations cover the safety profile for this read-only lookup. The only real gap is elaborating the agent_slug contract, which is minor for a single-parameter retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 0% schema description coverage, so the schema documents only its type/pattern, not its meaning. The description partially compensates by framing agent_slug as the identifier drawn from coding_agent_list, but it never explains format constraints or what to do if the slug is unknown. Baseline 3 for a low-coverage single-param tool with partial prose compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, resource, and lookup key ('Get a coding-agent profile by agent_slug'), and names coding_agent_list as the source of that slug. It also carves out scope against siblings by disclaiming benchmark rankings and subscription prices, so an agent can separate it from benchmark_results, offer_compare, and price_watch without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: call this with a slug obtained from coding_agent_list for profile-level detail on a single agent. The exclusions ('does not assert product benchmark rankings or subscription prices') implicitly route to other tools but never names which sibling to use when that data is actually wanted, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coding_agent_listList coding agentsARead-onlyIdempotentInspect
List coding-agent profiles, interfaces, model access, official sources, latest stable release, archive counts, freshness, coverage limits, and sourced model/provider compatibility, BYOK, billing and setup facts. Includes agents whose release archive is unavailable; inspect state. Use coding_agent_releases to page through source-linked changelogs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: coverage limits, freshness, sourced compatibility, BYOK/billing facts, and the edge case of included agents whose release archive is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the core action and then adds edge-case and alternative-tool guidance. The first sentence is a long enumeration of returned data domains, which is slightly heavy but still earns its place by helping an agent judge whether this tool covers the needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be fully explained, but the description still gives a robust preview of covered domains. Combined with the zero-parameter, read-only nature of the tool, it provides everything an agent needs to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero input parameters, so there is no parameter semantics to explain. The baseline for 0 params is 4, and the description appropriately does not invent parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List coding-agent profiles') and enumerates the data domains covered. It distinguishes this tool from coding_agent_releases by redirecting changelog paging to that sibling, so an agent can tell the tools apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names an explicit alternative for one use case ('Use coding_agent_releases to page through source-linked changelogs') and notes that agents with unavailable archives are included, with a hint to 'inspect state.' It does not cover when to prefer coding_agent_detail or coding_agent_upgrade, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coding_agent_releasesSearch coding-agent changelogsARead-onlyIdempotentInspect
Search archived coding-agent releases by agent_slug, query (title, version, excerpt), topic, and channel. Stable only by default; channel all includes prereleases. Newest first; advance offset by limit while pagination.hasMore. Includes source URLs, abbreviated excerpts, and per-agent freshness/coverage. Topics are keyword mentions, not assessments. Partial coverage is explicit in meta.completeness; all unavailable returns an error. Archives reflect configured source history, not every product announcement.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| topic | No | ||
| offset | No | ||
| channel | No | stable | |
| agent_slug | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| pagination | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description layers substantial extra context on top: newest-first ordering, offset/limit pagination driven by pagination.hasMore, and the caveat that archives reflect configured source history rather than every product announcement. It also discloses semi-failure semantics ('all unavailable returns an error') and that partial coverage is surfaced in meta.completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the following sentences are dense but each carries a distinct fact (defaults, ordering, pagination, coverage caveats, error case). The clause about topics being 'keyword mentions, not assessments' is arguably optional but guards against a real misinterpretation, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return shape, yet it still names the salient return elements (source URLs, abbreviated excerpts, per-agent freshness/coverage) and flags meta.completeness and the all-unavailable error path. Combined with annotations covering the safety profile, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does well: it explains that query matches title, version, and excerpt, that channel controls prerelease inclusion, and how offset/limit interact during pagination. It leaves boundary details (limit max 50, query 120-char cap, agent_slug pattern) to the schema, which is acceptable since those are structurally specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search archived coding-agent releases') and immediately enumerates the filterable dimensions (agent_slug, query, topic, channel). The scope is clearly distinct from siblings like coding_agent_detail or coding_agent_list, which resolve entities rather than search changelog archives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives condition-like guidance for one option ('Stable only by default; channel all includes prereleases'), which tells the agent when to change the default. However, it never states when to reach for this tool instead of coding_agent_detail or coding_agent_list, leaving the tool-vs-sibling decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coding_agent_upgradeChanges since an installed agent versionARead-onlyIdempotentInspect
Find archived changes published after an installed version or exact release ID. Get agent_slug and source_id from coding_agent_detail; default source_id is primary. Only the same publisher source and recognizable product stream are compared. Stable only by default; use channel all for prereleases. The ready response is publication order, not semantic-version precedence or an upgrade safety assessment; backports may appear. An unknown or ambiguous baseline is explicit in data.status, never treated as no changes. Follow data.pagination.hasMore with offset and limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| channel | No | stable | |
| installed | Yes | ||
| source_id | No | primary | |
| agent_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial behavioral context: results are in publication order rather than semantic-version precedence, this is not an upgrade safety assessment, backports may appear, and an unknown baseline surfaces in data.status rather than being silently treated as no changes. That is exactly the kind of nuance annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then moves through prerequisites, defaults, and caveats in a logical order with no filler sentences. It is slightly dense and long-winded for six parameters, but every clause carries operational meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered-list tool with an output schema, the description covers inputs' provenance, scope limits, ordering semantics, edge-case handling (unknown baseline), and pagination. Nothing an agent needs to invoke and interpret the call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains installed as a version or exact release ID, source_id's default of primary, channel's stable-vs-all behavior, and how to follow offset/limit via data.pagination.hasMore. It adds real meaning, though limit bounds and the agent_slug pattern are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: find archived changes published after an installed version or exact release ID. It is clearly distinguishable from siblings like coding_agent_releases and coding_agent_detail, which are referenced as sources of input rather than competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent where to obtain required inputs (agent_slug and source_id from coding_agent_detail), what the source_id default is (primary), and how to widen scope (channel all for prereleases). It also names the comparison constraint (same publisher source and recognizable product stream), which is genuine when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
executeRun catalog codeARead-onlyIdempotentInspect
Run a JavaScript async function in an isolated sandbox, composing catalog_search, model_detail, offer_compare, benchmark_results, provider_list, benchmark_list, coding_agent_list, coding_agent_detail, coding_agent_releases, coding_agent_upgrade, and price_watch as catalog.* methods. Return a small JSON value. Example: async () => { const page = await catalog.catalog_search({query: 'claude', page_size: 5}); return page.data.models.map(m => ({slug: m.slug, prices: m.bestOffer?.prices})); }. No network, secrets, or database binding is exposed. Shared worldwide execution budgets: 100 per UTC minute and 5000 per UTC day. Limits: 30 executions per client per minute (IPv6 /64), 20 catalog calls and read units (offer_compare and price_watch use 5), at most two concurrent calls, 5 seconds wall time, 50ms sandbox CPU, 32KiB code, 64KiB JSON output. JavaScript only; no imports or TypeScript syntax. Use /mcp?mode=code for only search + execute.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| logs | Yes | |
| calls | Yes | |
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description goes well beyond them: sandbox isolation, no network/secrets/database binding, worldwide budgets (100/min, 5000/day), per-client limits, 20 catalog calls, max 2 concurrent, 5s wall time, 50ms CPU, 32KiB code, 64KiB output, and JavaScript-only with no imports or TypeScript syntax. This is exactly the operational context an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then example, then constraints, then routing — a sensible ordering with no filler sentences. The hard-limits run is dense and slightly overwhelming in one block, but every clause carries an enforceable constraint, so nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity sandbox tool the description covers capability, available methods, example usage, isolation guarantees, all enforced limits, and the runtime restrictions (JavaScript only, no imports/TS). An output schema exists, so it correctly omits return-value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single `code` parameter, so the description must carry the semantic load, and it does: it specifies that the value is an async function body, that it must return a small JSON value, gives a runnable example, and enumerates what the code may call and what it may not (no imports, no TS). The 32KiB ceiling is echoed in maxLength, but the meaning of the code is entirely description-supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (run) and resource (a JavaScript async function in an isolated sandbox) and immediately enumerates the catalog.* surface it can compose, which cleanly distinguishes it from the sibling tools that expose those same capabilities individually. An agent can tell it apart from catalog_search or offer_compare without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: this is the composition/aggregation path over the catalog.* methods, with a concrete example showing a multi-step call, and the closing line routes the agent to /mcp?mode=code when only search + execute are wanted. It never explicitly states when NOT to use it (e.g. prefer the single sibling tool for one simple lookup), so routing is demonstrated rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
model_detailGet model detailsARead-onlyIdempotentInspect
Get capabilities, context/output limits, and current sourced provider offers by model_slug from catalog_search. Prices are base-context rates; long-context tiers, cache writes, batch discounts, and free-tier quotas can change actual cost.
| Name | Required | Description | Default |
|---|---|---|---|
| model_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-obvious business context: prices reflect base-context rates only, and long-context tiers, cache writes, batch discounts, and free-tier quotas can alter real cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, front-loaded with the returned data set and followed by the pricing caveat. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-field detail is unnecessary, and annotations cover safety. The description covers input sourcing, output scope, and the one non-obvious caveat (pricing variability) that an agent would otherwise misreport to a user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load: it identifies model_slug as the key and tells the agent where to source a valid value (catalog_search). It does not restate the pattern/length constraints, but it adds the meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and a concrete resource bundle: capabilities, context/output limits, and sourced provider offers for a given model_slug. It is clearly distinguishable from sibling catalog_search (discovery) and offer_compare (comparison) because it is a single-model detail lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by model_slug from catalog_search' effectively routes the agent: obtain the slug via catalog_search, then call this tool. It gives clear context but names no explicit exclusions or alternative siblings for related questions (e.g., offer_compare).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
offer_compareCompare provider offersARead-onlyIdempotentInspect
Rank current chat offers for up to five canonical model slugs with the website calculator: context-tier prices, cache reads/writes, retries, supported batch rates, capability/benchmark requirements, provider/route preferences, and evidence filters. Input totals include cache shares; cache_hit_percent plus cache_write_percent must be <=100. Average request sizes determine tiers and capacity. Batch is Anthropic direct only. Unknown required evidence excludes offers; missing cache-read rates use standard input rates. Inspect costs, qualification, warnings, assumptions, excludedModels, and pagination.hasMore. Free quotas, non-token fees, and media token accounting are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Coding requires the code capability; extraction requires structured output. Every offer must support chat. | chat |
| limit | No | ||
| offset | No | ||
| execution | No | Batch supports Anthropic direct routes with a published 50% token discount; unsupported routes are excluded. | standard |
| route_type | No | all | |
| model_slugs | Yes | ||
| benchmark_id | No | livebench | |
| input_tokens | No | ||
| open_weights | No | ||
| minimum_score | No | Zero disables score qualification; a positive threshold excludes missing exact benchmark matches. | |
| output_tokens | No | ||
| retry_percent | No | ||
| provider_slugs | No | ||
| cache_hit_percent | No | ||
| require_known_host | No | Exclude routes without a named underlying inference provider. | |
| cache_write_percent | No | ||
| average_input_tokens | No | ||
| average_output_tokens | No | ||
| required_capabilities | No | ||
| minimum_context_tokens | No | ||
| require_official_prices | No | Require official paired input/output price verification. Cache rates may have different source provenance. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| workload | Yes | |
| pagination | Yes | |
| assumptions | Yes | |
| requirements | Yes |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world. Beyond that, the description adds real behavioral rules: batch is Anthropic-direct only, unknown required evidence excludes offers, missing cache-read rates fall back to standard input rates, and free quotas/non-token fees/media token accounting are excluded. This is substantive context an agent cannot get from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is information-dense with essentially no filler, and the purpose and scope are front-loaded. The trade-off is that it reads as one long run-on paragraph with no separation, which slightly hurts scannability for a 21-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to explain return values, and it appropriately just points at costs, qualification, warnings, excludedModels and pagination.hasMore. Given the high parameter complexity and low schema coverage, a little more per-parameter detail would be ideal, but overall it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 24% across 21 parameters, so the description must compensate. It does add meaning for cache shares (cache_hit_percent + cache_write_percent <= 100), average request sizing driving tiers, retries, and evidence/capability filters. However, many parameters (limit, offset, input/output token totals, open_weights, minimum_context_tokens, route_type) get no semantic elaboration, leaving a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Rank current chat offers for up to five canonical model slugs with the website calculator.' This is clearly a cost/offer ranking tool, distinct-ish from catalog_search and price_watch. It does not explicitly name sibling tools, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance relative to siblings like price_watch, model_detail, or catalog_search. The description explains what inputs do and lists constraints, but never states the conditions under which an agent should choose this tool over the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_watchCheck workload price savingsBRead-onlyIdempotentInspect
Read current offers meeting a monthly baseline_usd minus minimum_saving_usd. Uses the same workload, qualifications and evidence filters as offer_compare. Omit model_slugs to watch all qualifying models. Returns up to 50 cheapest matches; no account or delivery subscription is created. The same query is available as RSS at /api/v1/price-watch/feed.xml; your RSS reader handles polling and notifications. Inspect offer warnings before switching.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Coding requires the code capability; extraction requires structured output. Every offer must support chat. | chat |
| limit | No | ||
| offset | No | ||
| execution | No | Batch supports Anthropic direct routes with a published 50% token discount; unsupported routes are excluded. | standard |
| route_type | No | all | |
| model_slugs | No | ||
| baseline_usd | Yes | ||
| benchmark_id | No | livebench | |
| input_tokens | No | ||
| open_weights | No | ||
| minimum_score | No | Zero disables score qualification; a positive threshold excludes missing exact benchmark matches. | |
| output_tokens | No | ||
| retry_percent | No | ||
| provider_slugs | No | ||
| cache_hit_percent | No | ||
| minimum_saving_usd | Yes | ||
| require_known_host | No | Exclude routes without a named underlying inference provider. | |
| cache_write_percent | No | ||
| average_input_tokens | No | ||
| average_output_tokens | No | ||
| required_capabilities | No | ||
| minimum_context_tokens | No | ||
| require_official_prices | No | Require official paired input/output price verification. Cache rates may have different source provenance. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| watch | Yes | |
| workload | Yes | |
| pagination | Yes | |
| assumptions | Yes | |
| requirements | Yes |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely new behavior: capped at 50 cheapest matches, 'no account or delivery subscription is created,' and an RSS feed alternative for ongoing polling. That is useful context beyond the structured fields, though it omits rate-limit or freshness/caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The qualifying condition is front-loaded and each sentence conveys a distinct fact (filters, model_slugs default, 50-cap, no subscription, RSS alternative, warnings). It is slightly dense at six sentences but there is little obvious padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, and the description does cover the core semantics and an RSS alternative. But for a 23-parameter, low-coverage tool it leaves most of the filter space unexplained, so an agent must infer parameter behavior from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 23 parameters and only ~22% schema description coverage, the description carries the compensating burden but only clarifies baseline_usd, minimum_saving_usd, and model_slugs. The many other parameters (route_type, execution, retry_percent, cache hit/write percents, benchmark_id, required_capabilities, etc.) receive no explanation in the description, leaving the majority of the surface undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read current offers') and defines the qualifying condition in terms of the two required params (monthly baseline_usd minus minimum_saving_usd). It also relates itself to the sibling offer_compare by sharing the same workload/qualification/evidence filters, which helps an agent place it. It stops short of a crisp one-line differentiator versus offer_compare, but the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives actionable usage hints: 'Omit model_slugs to watch all qualifying models' and 'Inspect offer warnings before switching,' plus a note that the same query is available as RSS so a reader handles polling. However, it never states explicitly when to pick price_watch over the sibling offer_compare, nor any when-not conditions; the guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provider_listList inference providersARead-onlyIdempotentInspect
Discover accepted provider slugs, roles, and current comparable model/offer counts. Provider minimum input and output prices are independent minima and may belong to different models; use offer_compare for an actual quote.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-obvious data semantics: provider min input/output prices are independent minima that may come from different models. That is real context beyond structured fields, though nothing is said about freshness or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero filler. The payload contents are front-loaded and the pricing caveat with its alternative follows immediately, so the agent reads the most important routing information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description still flags the key interpretation pitfall about independent minima. It is complete enough to call safely; only minor gaps remain (e.g., what 'roles' denote, staleness of counts).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly spends its budget describing output content instead of parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (discover/list) and resource (providers), and enumerates the payload contents: accepted provider slugs, roles, and comparable model/offer counts. It also differentiates itself from offer_compare by name, so an agent can distinguish it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear conditional redirect: use offer_compare for an actual quote, implying provider_list is for discovery/comparison rather than pricing decisions. It doesn't cover when to prefer it over benchmark_list or catalog_search, so it falls short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
benchmark_results1 field changed- changed
Output schema / properties / data / properties / results / items / properties / dateKind / enumPrevious value: -[ - "source-update", - "run" -]New value: +[ + "source-update", + "run", + "observed" +]
1 tool update
- Changed
benchmark_results1 field changed- changed
Output schema / properties / data / properties / results / items / properties / dateKind / enumPrevious value: -[ - "source-update", - "run", - "observed" -]New value: +[ + "source-update", + "run" +]
1 tool update
- Changed
benchmark_results1 field changed- changed
Output schema / properties / data / properties / results / items / properties / dateKind / enumPrevious value: -[ - "source-update", - "run" -]New value: +[ + "source-update", + "run", + "observed" +]
7 tool updates
- Added
coding_agent_detail - Added
coding_agent_list - Added
coding_agent_releases - Added
coding_agent_upgrade - Changed
model_detail7 fields changed- added
Output schema / properties / data / properties / model / properties / offers / items / properties / evidenceAdded value: +{ + "properties": { + "inferenceProvider": { + "type": [ + "string", + "null" + ] + }, + "priceAuthority": { + "type": "string" + }, + "providerUrl": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "inferenceProvider", + "providerUrl", + "priceAuthority" + ], + "type": "object" +} - added
Output schema / properties / data / properties / model / properties / offers / items / properties / prices / properties / cacheWritePerMillionTokensAdded value: +{ + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / data / properties / model / properties / offers / items / properties / prices / requiredPrevious value: -[ - "inputPerMillionTokens", - "outputPerMillionTokens", - "cachedInputPerMillionTokens" -]New value: +[ + "inputPerMillionTokens", + "outputPerMillionTokens", + "cachedInputPerMillionTokens", + "cacheWritePerMillionTokens" +] - added
Output schema / properties / data / properties / model / properties / offers / items / properties / provenance / properties / checkedAt / anyOfAdded value: +[ + { + "format": "date", + "type": "string" + }, + { + "format": "date-time", + "type": "string" + } +] - removed
Output schema / properties / data / properties / model / properties / offers / items / properties / provenance / properties / checkedAt / formatRemoved value: -"date" - removed
Output schema / properties / data / properties / model / properties / offers / items / properties / provenance / properties / checkedAt / typeRemoved value: -"string" - changed
Output schema / properties / data / properties / model / properties / offers / items / requiredPrevious value: -[ - "id", - "model", - "provider", - "routeType", - "prices", - "limits", - "provenance" -]New value: +[ + "id", + "model", + "provider", + "routeType", + "prices", + "limits", + "provenance", + "evidence" +]
- Changed
offer_compare42 fields changed- added
Input schema / properties / average_input_tokensAdded value: +{ + "default": 1500, + "maximum": 10000000, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / average_output_tokensAdded value: +{ + "default": 400, + "maximum": 10000000, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / benchmark_idAdded value: +{ + "default": "livebench", + "enum": [ + "livebench", + "aa-intelligence", + "aa-coding", + "aa-agentic", + "swe-bench-verified-epoch-2-0-2", + "terminal-bench-2-1-terminus-2", + "terminal-bench-2-1-claude-code", + "terminal-bench-2-1-codex", + "gpqa-diamond", + "otis-mock-aime-2024-2025", + "livebench-coding", + "livebench-agentic-coding", + "livebench-reasoning", + "livebench-math" + ], + "type": "string" +} - added
Input schema / properties / cache_hit_percentAdded value: +{ + "default": 0, + "maximum": 100, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / cache_write_percentAdded value: +{ + "default": 0, + "maximum": 100, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / executionAdded value: +{ + "default": "standard", + "description": "Batch supports Anthropic direct routes with a published 50% token discount; unsupported routes are excluded.", + "enum": [ + "standard", + "batch" + ], + "type": "string" +} - added
Input schema / properties / limitAdded value: +{ + "default": 200, + "maximum": 200, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / minimum_context_tokensAdded value: +{ + "default": 0, + "maximum": 10000000, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / minimum_scoreAdded value: +{ + "default": 0, + "description": "Zero disables score qualification; a positive threshold excludes missing exact benchmark matches.", + "maximum": 100, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "maximum": 10000, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / open_weightsAdded value: +{ + "default": false, + "type": "boolean" +} - added
Input schema / properties / require_known_hostAdded value: +{ + "default": false, + "description": "Exclude routes without a named underlying inference provider.", + "type": "boolean" +} - added
Input schema / properties / require_official_pricesAdded value: +{ + "default": false, + "description": "Require official paired input/output price verification. Cache rates may have different source provenance.", + "type": "boolean" +} - added
Input schema / properties / required_capabilitiesAdded value: +{ + "default": [], + "items": { + "enum": [ + "chat", + "tool_use", + "structured_output", + "vision_input", + "code", + "reasoning" + ], + "type": "string" + }, + "maxItems": 6, + "type": "array" +} - added
Input schema / properties / retry_percentAdded value: +{ + "default": 0, + "maximum": 1000, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / route_typeAdded value: +{ + "default": "all", + "enum": [ + "all", + "official", + "cloud", + "gateway", + "unverified" + ], + "type": "string" +} - added
Input schema / properties / taskAdded value: +{ + "default": "chat", + "description": "Coding requires the code capability; extraction requires structured output. Every offer must support chat.", + "enum": [ + "chat", + "coding", + "extraction", + "custom" + ], + "type": "string" +} - added
Output schema / properties / assumptionsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / data / properties / excludedModelsAdded value: +{ + "items": { + "properties": { + "modelSlug": { + "type": "string" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "modelSlug", + "reason" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / data / properties / offers / items / properties / costsAdded value: +{ + "properties": { + "cacheWriteUsd": { + "minimum": 0, + "type": "number" + }, + "cachedInputUsd": { + "minimum": 0, + "type": "number" + }, + "outputUsd": { + "minimum": 0, + "type": "number" + }, + "uncachedInputUsd": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "uncachedInputUsd", + "cachedInputUsd", + "cacheWriteUsd", + "outputUsd" + ], + "type": "object" +} - added
Output schema / properties / data / properties / offers / items / properties / offer / properties / evidenceAdded value: +{ + "properties": { + "inferenceProvider": { + "type": [ + "string", + "null" + ] + }, + "priceAuthority": { + "type": "string" + }, + "providerUrl": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "inferenceProvider", + "providerUrl", + "priceAuthority" + ], + "type": "object" +} - added
Output schema / properties / data / properties / offers / items / properties / offer / properties / prices / properties / cacheWritePerMillionTokensAdded value: +{ + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / data / properties / offers / items / properties / offer / properties / prices / requiredPrevious value: -[ - "inputPerMillionTokens", - "outputPerMillionTokens", - "cachedInputPerMillionTokens" -]New value: +[ + "inputPerMillionTokens", + "outputPerMillionTokens", + "cachedInputPerMillionTokens", + "cacheWritePerMillionTokens" +] - added
Output schema / properties / data / properties / offers / items / properties / offer / properties / provenance / properties / checkedAt / anyOfAdded value: +[ + { + "format": "date", + "type": "string" + }, + { + "format": "date-time", + "type": "string" + } +] - removed
Output schema / properties / data / properties / offers / items / properties / offer / properties / provenance / properties / checkedAt / formatRemoved value: -"date" - removed
Output schema / properties / data / properties / offers / items / properties / offer / properties / provenance / properties / checkedAt / typeRemoved value: -"string" - changed
Output schema / properties / data / properties / offers / items / properties / offer / requiredPrevious value: -[ - "id", - "model", - "provider", - "routeType", - "prices", - "limits", - "provenance" -]New value: +[ + "id", + "model", + "provider", + "routeType", + "prices", + "limits", + "provenance", + "evidence" +] - added
Output schema / properties / data / properties / offers / items / properties / qualificationAdded value: +{ + "properties": { + "benchmark": { + "anyOf": [ + { + "type": "null" + }, + { + "properties": { + "configuration": { + "type": "string" + }, + "id": { + "type": "string" + }, + "minimumScore": { + "maximum": 100, + "minimum": 0, + "type": "number" + }, + "score": { + "maximum": 100, + "minimum": 0, + "type": "number" + }, + "sourceUrl": { + "format": "uri", + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "id", + "minimumScore", + "score", + "version", + "configuration", + "sourceUrl" + ], + "type": "object" + } + ] + }, + "requiredCapabilities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "requiredContextTokens": { + "minimum": 0, + "type": "integer" + }, + "requiredOutputTokens": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "requiredContextTokens", + "requiredOutputTokens", + "requiredCapabilities", + "benchmark" + ], + "type": "object" +} - added
Output schema / properties / data / properties / offers / items / properties / warningsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / data / properties / offers / items / requiredPrevious value: -[ - "offer", - "workloadCostUsd" -]New value: +[ + "offer", + "workloadCostUsd", + "costs", + "qualification", + "warnings" +] - changed
Output schema / properties / data / requiredPrevious value: -[ - "offers" -]New value: +[ + "offers", + "excludedModels" +] - added
Output schema / properties / paginationAdded value: +{ + "properties": { + "hasMore": { + "type": "boolean" + }, + "limit": { + "minimum": 1, + "type": "integer" + }, + "offset": { + "minimum": 0, + "type": "integer" + }, + "page": { + "minimum": 1, + "type": "integer" + }, + "pageCount": { + "minimum": 0, + "type": "integer" + }, + "pageSize": { + "minimum": 1, + "type": "integer" + }, + "total": { + "minimum": 0, + "type": "integer" + } + }, + "type": "object" +} - added
Output schema / properties / requirementsAdded value: +{ + "properties": { + "benchmarkId": { + "type": "string" + }, + "minimumContextTokens": { + "minimum": 0, + "type": "integer" + }, + "minimumScore": { + "maximum": 100, + "minimum": 0, + "type": "number" + }, + "modelSlugs": { + "items": { + "type": "string" + }, + "type": "array" + }, + "openWeights": { + "type": "boolean" + }, + "providerSlugs": { + "items": { + "type": "string" + }, + "type": "array" + }, + "requireKnownHost": { + "type": "boolean" + }, + "requireOfficialPrices": { + "type": "boolean" + }, + "requiredCapabilities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "routeType": { + "type": "string" + } + }, + "required": [ + "modelSlugs", + "providerSlugs", + "requiredCapabilities", + "minimumContextTokens", + "openWeights", + "routeType", + "benchmarkId", + "minimumScore", + "requireOfficialPrices", + "requireKnownHost" + ], + "type": "object" +} - added
Output schema / properties / workload / properties / averageInputTokensAdded value: +{ + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / workload / properties / averageOutputTokensAdded value: +{ + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / workload / properties / cacheHitPercentAdded value: +{ + "maximum": 100, + "minimum": 0, + "type": "number" +} - added
Output schema / properties / workload / properties / cacheWritePercentAdded value: +{ + "maximum": 100, + "minimum": 0, + "type": "number" +} - added
Output schema / properties / workload / properties / executionAdded value: +{ + "enum": [ + "standard", + "batch" + ], + "type": "string" +} - added
Output schema / properties / workload / properties / retryPercentAdded value: +{ + "maximum": 1000, + "minimum": 0, + "type": "number" +} - added
Output schema / properties / workload / properties / taskAdded value: +{ + "enum": [ + "chat", + "coding", + "extraction", + "custom" + ], + "type": "string" +} - changed
Output schema / properties / workload / requiredPrevious value: -[ - "inputTokens", - "outputTokens" -]New value: +[ + "inputTokens", + "outputTokens", + "averageInputTokens", + "averageOutputTokens", + "cacheHitPercent", + "cacheWritePercent", + "retryPercent", + "execution", + "task" +] - changed
Output schema / requiredPrevious value: -[ - "meta", - "workload", - "data" -]New value: +[ + "meta", + "workload", + "requirements", + "assumptions", + "data", + "pagination" +]
- Added
price_watch
7 tool updates
- Added
benchmark_list - Changed
benchmark_results6 fields changed- added
Input schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / properties / benchmark_id / enumRemoved value: -[ - "livebench", - "aa-intelligence", - "aa-coding", - "aa-agentic", - "swe-bench-verified-epoch-2-0-2", - "terminal-bench-2-1-terminus-2", - "terminal-bench-2-1-claude-code", - "terminal-bench-2-1-codex", - "gpqa-diamond", - "otis-mock-aime-2024-2025", - "livebench-coding", - "livebench-agentic-coding", - "livebench-reasoning", - "livebench-math" -] - added
Input schema / properties / benchmark_id / maxLengthAdded value: +120 - added
Input schema / properties / benchmark_id / minLengthAdded value: +1 - added
Input schema / properties / benchmark_id / patternAdded value: +"^[a-z0-9-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "data": { + "properties": { + "benchmark": { + "properties": { + "cohort": { + "enum": [ + "frontier", + "measured" + ], + "type": "string" + }, + "cohortLabel": { + "type": "string" + }, + "configurationNote": { + "type": "string" + }, + "date": { + "description": "Source date, or an empty string when the upstream source supplies none.", + "type": "string" + }, + "description": { + "type": "string" + }, + "evaluator": { + "type": "string" + }, + "id": { + "type": "string" + }, + "label": { + "type": "string" + }, + "provenance": { + "properties": { + "sourceLabel": { + "type": "string" + }, + "sourceUrl": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "sourceUrl", + "sourceLabel" + ], + "type": "object" + }, + "scoreUnit": { + "enum": [ + "points", + "percent" + ], + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "id", + "label", + "description", + "version", + "date", + "scoreUnit", + "evaluator", + "configurationNote", + "cohort", + "cohortLabel", + "provenance" + ], + "type": "object" + }, + "results": { + "items": { + "properties": { + "configuration": { + "type": "string" + }, + "date": { + "format": "date", + "type": "string" + }, + "dateKind": { + "enum": [ + "source-update", + "run" + ], + "type": "string" + }, + "evaluator": { + "type": "string" + }, + "harness": { + "type": "string" + }, + "modelId": { + "type": "string" + }, + "provenance": { + "properties": { + "sourceDataUrl": { + "format": "uri", + "type": "string" + }, + "sourceRecordId": { + "type": "string" + }, + "sourceUrl": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "sourceUrl", + "sourceDataUrl", + "sourceRecordId" + ], + "type": "object" + }, + "reportedAgentUsage": { + "anyOf": [ + { + "properties": { + "agent": { + "type": "string" + }, + "agentVersion": { + "type": "string" + }, + "averageTrialDurationSeconds": { + "minimum": 0, + "type": "number" + }, + "derived": { + "description": "Values derived from the published run totals and rounded benchmark score.", + "properties": { + "costPerSuccessfulTrialUsd": { + "minimum": 0, + "type": "number" + }, + "costPerTrialUsd": { + "minimum": 0, + "type": "number" + }, + "inputCacheShare": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "tokensPerSuccessfulTrial": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "costPerTrialUsd", + "costPerSuccessfulTrialUsd", + "inputCacheShare", + "tokensPerSuccessfulTrial" + ], + "type": "object" + }, + "reportedCostUsd": { + "minimum": 0, + "type": "number" + }, + "tokens": { + "properties": { + "cachedInput": { + "minimum": 0, + "type": "integer" + }, + "output": { + "minimum": 0, + "type": "integer" + }, + "total": { + "minimum": 0, + "type": "integer" + }, + "uncachedInput": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "uncachedInput", + "cachedInput", + "output", + "total" + ], + "type": "object" + }, + "trialCount": { + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "agent", + "agentVersion", + "trialCount", + "tokens", + "reportedCostUsd", + "averageTrialDurationSeconds", + "derived" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "runStartedAt": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ] + }, + "sampleCount": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "score": { + "maximum": 100, + "minimum": 0, + "type": "number" + }, + "scoreUnit": { + "enum": [ + "points", + "percent" + ], + "type": "string" + }, + "sourceModel": { + "type": "string" + }, + "standardError": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] + }, + "version": { + "type": "string" + } + }, + "required": [ + "modelId", + "sourceModel", + "configuration", + "score", + "scoreUnit", + "evaluator", + "harness", + "version", + "date", + "dateKind", + "runStartedAt", + "sampleCount", + "standardError", + "reportedAgentUsage", + "provenance" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "benchmark", + "results" + ], + "type": "object" + }, + "meta": { + "properties": { + "apiVersion": { + "const": "v1" + }, + "currency": { + "const": "USD" + }, + "tokenPriceUnit": { + "const": "per_million_tokens" + } + }, + "required": [ + "apiVersion", + "currency", + "tokenPriceUnit" + ], + "type": "object" + }, + "pagination": { + "properties": { + "hasMore": { + "type": "boolean" + }, + "limit": { + "minimum": 1, + "type": "integer" + }, + "offset": { + "minimum": 0, + "type": "integer" + }, + "page": { + "minimum": 1, + "type": "integer" + }, + "pageCount": { + "minimum": 0, + "type": "integer" + }, + "pageSize": { + "minimum": 1, + "type": "integer" + }, + "total": { + "minimum": 0, + "type": "integer" + } + }, + "type": "object" + } + }, + "required": [ + "meta", + "data", + "pagination" + ], + "type": "object" +}
- Changed
catalog_search5 fields changed- added
Input schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / category_slug / defaultAdded value: +"" - added
Input schema / properties / provider_slug / defaultAdded value: +"" - added
Input schema / properties / query / defaultAdded value: +"" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "data": { + "properties": { + "models": { + "items": { + "properties": { + "author": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "bestOffer": { + "anyOf": [ + { + "properties": { + "prices": { + "properties": { + "inputPerMillionTokens": { + "minimum": 0, + "type": "number" + }, + "outputPerMillionTokens": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "inputPerMillionTokens", + "outputPerMillionTokens" + ], + "type": "object" + }, + "provider": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + } + }, + "required": [ + "provider", + "prices" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Provider selected using 10 million input and 2 million output tokens; not independent minima or a quote for every workload." + }, + "contextTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "family": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "maxOutputTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "offerCount": { + "minimum": 0, + "type": "integer" + }, + "releasedAt": { + "anyOf": [ + { + "format": "date", + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "type": "string" + }, + "weightAvailability": { + "enum": [ + "closed", + "open", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "id", + "slug", + "name", + "author", + "family", + "releasedAt", + "contextTokens", + "maxOutputTokens", + "weightAvailability", + "offerCount", + "bestOffer" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "models" + ], + "type": "object" + }, + "meta": { + "properties": { + "apiVersion": { + "const": "v1" + }, + "currency": { + "const": "USD" + }, + "tokenPriceUnit": { + "const": "per_million_tokens" + } + }, + "required": [ + "apiVersion", + "currency", + "tokenPriceUnit" + ], + "type": "object" + }, + "pagination": { + "properties": { + "hasMore": { + "type": "boolean" + }, + "limit": { + "minimum": 1, + "type": "integer" + }, + "offset": { + "minimum": 0, + "type": "integer" + }, + "page": { + "minimum": 1, + "type": "integer" + }, + "pageCount": { + "minimum": 0, + "type": "integer" + }, + "pageSize": { + "minimum": 1, + "type": "integer" + }, + "total": { + "minimum": 0, + "type": "integer" + } + }, + "type": "object" + } + }, + "required": [ + "meta", + "data", + "pagination" + ], + "type": "object" +}
- Added
execute - Changed
model_detail3 fields changed- added
Input schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / model_slug / patternAdded value: +"^[a-zA-Z0-9._:-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "data": { + "properties": { + "model": { + "properties": { + "author": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "capabilities": { + "items": { + "type": "string" + }, + "type": "array" + }, + "categories": { + "items": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "contextTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "description": { + "type": "string" + }, + "family": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "knowledgeCutoffAt": { + "anyOf": [ + { + "format": "date", + "type": "string" + }, + { + "type": "null" + } + ] + }, + "maxOutputTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "offers": { + "items": { + "properties": { + "id": { + "type": "string" + }, + "limits": { + "properties": { + "contextTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "maxOutputTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "contextTokens", + "maxOutputTokens" + ], + "type": "object" + }, + "model": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "prices": { + "properties": { + "cachedInputPerMillionTokens": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] + }, + "inputPerMillionTokens": { + "minimum": 0, + "type": "number" + }, + "outputPerMillionTokens": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "inputPerMillionTokens", + "outputPerMillionTokens", + "cachedInputPerMillionTokens" + ], + "type": "object" + }, + "provenance": { + "properties": { + "checkedAt": { + "format": "date", + "type": "string" + }, + "sourceUrl": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "sourceUrl", + "checkedAt" + ], + "type": "object" + }, + "provider": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "routeType": { + "enum": [ + "official", + "cloud", + "gateway", + "unverified" + ], + "type": "string" + } + }, + "required": [ + "id", + "model", + "provider", + "routeType", + "prices", + "limits", + "provenance" + ], + "type": "object" + }, + "type": "array" + }, + "releaseChannel": { + "type": "string" + }, + "releasedAt": { + "anyOf": [ + { + "format": "date", + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "type": "string" + }, + "status": { + "type": "string" + }, + "weightAvailability": { + "type": "string" + } + }, + "required": [ + "id", + "slug", + "name", + "description", + "author", + "family", + "status", + "releaseChannel", + "releasedAt", + "knowledgeCutoffAt", + "contextTokens", + "maxOutputTokens", + "weightAvailability", + "capabilities", + "categories", + "offers" + ], + "type": "object" + } + }, + "required": [ + "model" + ], + "type": "object" + }, + "meta": { + "properties": { + "apiVersion": { + "const": "v1" + }, + "currency": { + "const": "USD" + }, + "tokenPriceUnit": { + "const": "per_million_tokens" + } + }, + "required": [ + "apiVersion", + "currency", + "tokenPriceUnit" + ], + "type": "object" + } + }, + "required": [ + "meta", + "data" + ], + "type": "object" +}
- Changed
offer_compare3 fields changed- added
Input schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / model_slugs / items / patternAdded value: +"^[a-zA-Z0-9._:-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "data": { + "properties": { + "offers": { + "items": { + "properties": { + "offer": { + "properties": { + "id": { + "type": "string" + }, + "limits": { + "properties": { + "contextTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "maxOutputTokens": { + "anyOf": [ + { + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "contextTokens", + "maxOutputTokens" + ], + "type": "object" + }, + "model": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "prices": { + "properties": { + "cachedInputPerMillionTokens": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] + }, + "inputPerMillionTokens": { + "minimum": 0, + "type": "number" + }, + "outputPerMillionTokens": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "inputPerMillionTokens", + "outputPerMillionTokens", + "cachedInputPerMillionTokens" + ], + "type": "object" + }, + "provenance": { + "properties": { + "checkedAt": { + "format": "date", + "type": "string" + }, + "sourceUrl": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "sourceUrl", + "checkedAt" + ], + "type": "object" + }, + "provider": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "routeType": { + "enum": [ + "official", + "cloud", + "gateway", + "unverified" + ], + "type": "string" + } + }, + "required": [ + "id", + "model", + "provider", + "routeType", + "prices", + "limits", + "provenance" + ], + "type": "object" + }, + "workloadCostUsd": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "offer", + "workloadCostUsd" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "offers" + ], + "type": "object" + }, + "meta": { + "properties": { + "apiVersion": { + "const": "v1" + }, + "currency": { + "const": "USD" + }, + "tokenPriceUnit": { + "const": "per_million_tokens" + } + }, + "required": [ + "apiVersion", + "currency", + "tokenPriceUnit" + ], + "type": "object" + }, + "workload": { + "properties": { + "inputTokens": { + "minimum": 0, + "type": "integer" + }, + "outputTokens": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "inputTokens", + "outputTokens" + ], + "type": "object" + } + }, + "required": [ + "meta", + "workload", + "data" + ], + "type": "object" +}
- Added
provider_list
4 tool updates
- First observed
benchmark_results - First observed
catalog_search - First observed
model_detail - First observed
offer_compare
Related MCP Connectors
Live LLM API pricing: token prices, comparisons, cheapest-model lookups. No key required.
Find AI model pricing, estimate token costs and compare offers. No API key required.
LLM API prices across 70+ providers: cheapest offer, comparisons, history and cost estimates.
Source-backed AI model pricing, rankings, history, and benchmark data.
Related MCP Servers
- AlicenseAqualityBmaintenanceLive LLM API pricing: current token prices, model comparisons, cheapest-model lookups, and The LLM Price Index for 150+ models across 20+ providers, re-verified daily. No API key required.41MIT
- AlicenseAqualityDmaintenanceProvides access to real-time LLM pricing, speed metrics, and performance benchmarks for over 300 models from Artificial Analysis. It enables users to list, filter, and compare models based on costs, tokens per second, and intelligence indices.219 npm9MIT
Modelglassofficial
AlicenseNot gradedqualityAmaintenanceLive, sourced pricing and benchmark data across image, language, video, and audio AI models, seven tools for comparison, competitor lookups, and cost-aware routing. Also powers the free Modelglass VS Code extension.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.