Which open models fit your GPU or Mac, measured. Model momentum, GPU rental prices, weekly pick.
Scored across 6 tools
Each tool targets a distinct resource: hardware catalog (list_hardware), fit computation (find_fit), current market prices (gpu_prices), daily price rows (price_history), model heat ranking (trending_models), and a curated weekly issue (weekly_pick). The only near-pair, gpu_prices vs price_history, is explicitly separated by descriptions that state history is the source rows and never blended with current medians. No two tools appear to do the same thing.
Names mix verb_noun (find_fit, list_hardware) with noun phrases (gpu_prices, price_history, trending_models, weekly_pick). Each name is readable and meaningful, but there is no single predictable pattern an agent can generalize from. This is a mixed convention rather than a consistent one.
Six tools is well-scoped for a compute-market intelligence server. Each tool covers a distinct lane (catalog, fit, pricing snapshot, price history, model trends, editorial pick) with no filler. Pairs naturally into three coherent capabilities.
The surface covers the full loop for its stated purpose: discover hardware, test fit, read current and historical prices, rank models, and get a weekly pick. Minor gaps remain, such as no direct lookup of a single model's full profile (trending_models returns a ranked list) and no way to query a specific GPU class outside the price feeds. These are workaroundable but noticeable.
Which tracked models run on a given GPU or Mac: measured GGUF weights + computed context cache + runtime overhead versus usable memory. Returns the best recommendation and every verdict (EXCELLENT/GOOD/TIGHT/OFFLOAD_REQUIRED/NOT_RECOMMENDED/UNKNOWN) with plain-language reasons. Get hardware ids from list_hardware.
| Name | Required | Description | Default |
|---|---|---|---|
| kv | No | KV-cache quantization (default f16). | |
| model | No | Restrict to one model slug. | |
| context | No | Context length in tokens (default 8192). | |
| hardware | Yes | Hardware id or page slug, e.g. rtx-4090, mac-studio-m3-ultra-96gb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well by disclosing the computation basis and the full set of possible verdicts (EXCELLENT through UNKNOWN) with plain-language reasons. As a read-only analysis tool it implies no side effects, and the absence of mutation behavior is reasonably inferable from 'returns' and 'verdicts'.
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?
Three sentences, every one earning its place: purpose/first sentence, output detail/second sentence, and prerequisite/third sentence. No filler or repetition of schema fields.
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?
Although there is no output schema, the description compensates by enumerating the verdict values and stating that a best recommendation plus reasons will be returned. Inputs, defaults, and hardware-id sourcing are all covered via schema and description, making this complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter clearly. The description adds extra meaning by linking the context and kv parameters to the measured/computed analysis, and by telling the agent where hardware ids come from (list_hardware), which is beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific question—'Which tracked models run on a given GPU or Mac'—and goes on to name the exact analysis (GGUF weights, context cache, runtime overhead vs. usable memory). This clearly differentiates find_fit from siblings like gpu_prices, list_hardware, and trending_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?
The description makes the core use case obvious: when a user has a target GPU or Mac and wants to know which models fit. It also gives a concrete prerequisite by pointing to list_hardware for obtaining hardware ids, but it does not explicitly state when to avoid this tool or prefer gpu_prices/trending_models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median verified on-demand rental price per GPU class on Vast.ai (USD per hour), with min/p75 and offer counts, the collection timestamp, and per class the Rent Index: this week's median against last week and against the first week collected, a trend word, and the days excluded as marketplace glitches, plus RunPod's lowest posted on-demand price per class (a list price, not a median), Clore.ai's median for the same class (a second marketplace, never blended), and the AWS, Azure and Oracle Cloud pay-as-you-go list prices per GPU-hour, each with the instance type, VM size or bare-metal shape the price sits in (list prices, read four times a day, no statement about capacity). The index describes what prices did; it never forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses that RunPod is a list price rather than a median, that Clore.ai is a separate marketplace 'never blended', that cloud list prices are 'read four times a day', that no statement is made about capacity, and that the index 'never forecasts'. These caveats and freshness notes are genuine behavioral context, though read-only/auth characteristics remain unstated.
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?
It is a single run-on sentence of roughly 150 words with heavily nested clauses separated by commas, which hurts scannability. It is front-loaded with the core resource (median price per GPU class) and most clauses carry non-redundant information, but the structure is poor for an agent parsing it quickly.
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?
No output schema exists, so the description must describe return values and it does so thoroughly — sources, per-class fields, the Rent Index components, the trend word, and the excluded-glitch days. For a zero-parameter data tool this is close to complete, with only response shape/format left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 — there is no argument semantics for the description to clarify, and it correctly spends no words on inputs.
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 names a specific resource and scope — median verified on-demand rental price per GPU class on Vast.ai, plus named comparison sources. It is clearly distinct from siblings like find_fit, list_hardware, trending_models and weekly_pick, though it never states an explicit verb (fetch/return) and the purpose is buried inside a long enumeration of contents.
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?
There is no when-to-use guidance, no prerequisites, and no named alternative or exclusion condition. The agent is left to infer that this is the price-lookup tool by reading the contents alone; nothing routes it against find_fit or list_hardware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated GPU and Mac profiles the fit engine knows — ids, memory, usable memory after margins, bandwidth. Use an id with find_fit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that profiles are 'curated', scoped to what the fit engine knows, and lists the exact data dimensions returned, including usable memory after margins. For a zero-parameter list operation, this adequately sets expectations without hiding important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the resource and key fields, then adds the actionable follow-up instruction. Every clause contributes useful 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?
For a simple zero-parameter list tool with no output schema, the description covers the scope (GPU/Mac), the returned fields, and the intended usage with find_fit. It omits formatting and pagination details, but those are not essential for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete and the description has nothing to add at the parameter level. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides curated GPU and Mac profiles known to the fit engine, with fields like ids, memory, usable memory, and bandwidth. The verb is implied by the title and the resource is unambiguous, but it does not explicitly differentiate from sibling tools such as gpu_prices or trending_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?
The description gives a clear follow-up instruction: 'Use an id with find_fit', which tells the agent what to do after listing. However, it does not explicitly state when to prefer this tool over the alternatives or provide exclusions, leaving some usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily price history per GPU class and source, up to 90 days: the rows the Rent Index and the 30-day range are computed from. Marketplace days (Vast.ai, Clore.ai) are medians over the day's counted hourly medians with min, p75 and offer count; list-price days (RunPod, AWS, Azure, Oracle Cloud, Lambda, Nebius, CoreWeave, Hyperstack) carry the posted price. Each row says which kind it is; never blend the two. Describes what prices did; it never forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | One class by slug or name, e.g. rtx-4090, h100. Every class without it. | |
| days | No | Days back from today (default 30, max 365; the series starts 26 August 2026). | |
| source | No | One source key, e.g. vast, runpod, aws. Every published source without it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does substantial work: it explains that marketplace days are medians with min/p75/offer count while list-price days carry posted prices, that each row identifies its kind, and that the two must never be blended. It omits operational traits an agent might want — pagination, row volume, permissions, error behaviour for unknown GPU slugs.
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?
Three tight sentences with no filler, and the core scope statement leads. The marketplace-vs-list-price rule is dense but earns its place as the fact most likely to be misused; only the 'never forecasts' clause is marginally redundant with 'price history'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param read tool with no annotations and no output schema, the description covers semantics well and the schema covers parameter shapes. It leaves the agent without return-shape guidance (row fields beyond the median/p75 mention), ordering, and the resolution of the 90-vs-365-day conflict — gaps an agent would hit on first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains gpu, days and source, giving a baseline of 3. The description arguably undercuts this by stating 'up to 90 days' while the days parameter allows a maximum of 365 — a conflict that could cause an agent to reject valid requests or mis-set the window. Because the description's only parameter-relevant claim is the one that contradicts the schema, it adds risk rather than meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource combination — daily price history per GPU class and source — plus its scope (up to 90 days) and its role in feeding the Rent Index. It is clearly distinguishable from list/trend tools in substance, but never names the sibling it replaces, so an agent must infer that gpu_prices (not this) is the current-price tool.
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 the use case (historical series underlying the Rent Index and 30-day range) and states one boundary — it never forecasts. However, it gives no explicit when-to-use/when-not guidance and never routes the agent to gpu_prices, find_fit or the other siblings, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracked AI models ranked by Heat Score (0–100, weighted percentiles of measured Hugging Face/OpenRouter signals) with the raw signals, local-run facts (GGUF size, quantization) and links. Models still collecting a week of history have heat=null and rank after scored ones.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Return a single model by slug. | |
| limit | No | How many models to return (default 12). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the Heat Score calculation basis, the meaning of heat=null for models with less than a week of history, and that such models rank after scored ones. This goes well beyond a minimal description, though it does not cover response format details or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but efficient, with the main point front-loaded and the null-ranking edge case in a second sentence. The first sentence is somewhat heavy with parentheticals, but every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the absence of an output schema, the description covers the important return concepts: ranking metric, raw signals, local-run facts, links, and null-heat handling. It does not spell out the exact response shape or sort direction, but for a low-complexity list-like tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond the schema; both slug and limit are already well documented in the input schema, so no extra semantic guidance is needed.
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 names a specific resource (tracked AI models) and the key behavior (ranked by Heat Score), clearly distinguishing this from the hardware/GPU-focused siblings like gpu_prices and list_hardware. Even though no explicit sibling comparison is made, the domain and content are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would call this when it needs trending model rankings or model comparison data. However, there is no explicit statement about when to choose this tool over find_fit, gpu_prices, or list_hardware, and no exclusions or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current pick of the week: one tracked model chosen by a published rule (largest counted Heat Score rise among models that run comfortably on a consumer card of up to 24 GB), with the numbers frozen at selection time, a device-by-device fit ladder and the written report including its caveats. Pass week (e.g. 2026-w37) for a past issue. issue is null until the first issue is published.
| Name | Required | Description | Default |
|---|---|---|---|
| week | No | ISO week label of a past issue, e.g. 2026-w37 (default: the current issue). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that numbers are frozen at selection time, that the output includes a fit ladder and report with caveats, and that issue is null until first publication. It does not mention errors or authentication, but for a read-only retrieval tool, this is sufficient transparent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the purpose and rule, then covering the parameter and null behavior. The run-on first sentence is dense but information-rich. Overall, every sentence earns its place with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the return content (fit ladder, report, caveats), the selection rule, and the null edge case. It lacks explicit info about error handling or response format, but these are minor gaps for this kind of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already includes the format, example, and default behavior. The tool description reiterates the parameter usage (pass week for past issue) but adds no new semantic detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the pick of the week, a specific model chosen by a published rule, along with fit ladder and report. It distinguishes itself from siblings (find_fit, gpu_prices, etc.) by naming the unique selection rule and the specific resource, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the weekly pick and explains the parameter for past issues, but it does not explicitly contrast it with sibling tools or state when not to use it. There is no mention of alternatives like gpu_prices or find_fit. The context is clear, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
price_history2 fields changedInput schema / properties / days / descriptionPrevious value: -"Days back from today (default 30, max 90)."New value: +"Days back from today (default 30, max 365; the series starts 26 August 2026)."Input schema / properties / days / maximumPrevious value: -90New value: +365price_historyfind_fitgpu_priceslist_hardwaretrending_modelsweekly_pickWhich open models fit your GPU or Mac, measured. Model momentum, GPU rental prices, weekly pick.
Independent test scores for open-weight LLMs: best model for your GPU or Mac, comparisons.
Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
Find open-weight AI models that fit your hardware, with weight sizes, memory and sources.
Add one secure layer between your agents and this server.
