An MCP server that tells you whether an open-weight LLM fits a given GPU's VRAM, and what would fit instead.
can_i_run — asks if a specific model (name/id, Hugging Face repo, or manual architecture) fits a specific GPU: returns fits/tight/no, the weights + KV cache + overhead split, a decode-speed ceiling, the longest context that still fits, and on a "no", every change that would make it fit (quant, KV cache, context, another card, smaller model).
what_fits — ranks every model in its table against one GPU at a chosen quantisation/context, giving a recommended everyday pick, the largest that fits, the best at Q8, and the first out of reach.
estimate_vram — computes weights + KV cache + overhead for a model at one or all six quantisations, plus the smallest common card class that holds each.
estimate_from_hf_repo — reads any Hugging Face repo's config.json live and reports its attention layout (standard, sliding-window, hybrid, latent), memory per 1,000 context tokens, and totals at every quantisation.
list_models / list_gpus — browsable, searchable lists of verified models (size, attention design, native context, licence, Q4/8k memory) and GPUs (memory, usable memory, bandwidth), each with a nodegrove.io page link.
Accepts flexible inputs — model names as people type them, HF repo ids, GPU names or raw vram_gb/bandwidth, Apple unified memory flags, and MoE active-parameter counts for speed estimates.
All six tools are read-only; every answer returns the numbers as fields along with the assumptions behind them.
Reads any public Hugging Face model repository's config.json and metadata to estimate its memory requirements: the attention layout, the cost of each 1,000 tokens of context, memory at every quantisation, and whether the model fits a given GPU. Also backs the built-in model table, which was read from each model's config.json and checked against Hugging Face.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nodegrove VRAM: can I run it? can I run Llama 3.3 70B on an RTX 4090?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Can my RTX 4090 run Llama 3.3 70B?
No: Llama 3.3 70B at Q4_K_M with 8,192 tokens of context needs 45.8 GB, and the RTX 4090 holds 22.8 GB after headroom. Short by 23 GB. What would work instead:
No context length helps: the weights alone are 43.1 GB before a single token of conversation.
RTX 6000 Ada (48 GB) is within a whisker: 45.8 GB against 45.6 GB after headroom. With the KV cache at Q8 it needs 44.4 GB and fits.
The smallest card here that runs it exactly as asked: A100, 80 GB usable.
The biggest model your card does run at these settings, counting mixture-of-experts models at their dense equivalent: Gemma 4 31B, 20.9 GB at ~39 tokens/s.
That is the server's own answer, word for word, from the same code as the GPU compatibility checker on nodegrove.io. Every figure is a stated formula over the model's config.json and the card's published specs: no benchmarks, no guesses. It is free, read-only, and needs no account or key.
https://mcp.nodegrove.io/mcp
# Claude Code (add --scope user to have it in every project)
claude mcp add --transport http nodegrove-vram https://mcp.nodegrove.io/mcp
# Codex CLI
codex mcp add nodegrove-vram --url https://mcp.nodegrove.io/mcp
# Gemini CLI
gemini mcp add -s user --transport http nodegrove-vram https://mcp.nodegrove.io/mcpClaude (claude.ai and the desktop app): Customize → Connectors → Add → Add custom connector. Name it Nodegrove VRAM, paste the URL, choose No sign-in, then turn it on in a chat from + → Connectors.
ChatGPT: Settings → Security and login → turn on Developer mode. At chatgpt.com/plugins, add the URL with No Authentication, then pick it in a chat from + → Developer mode.
Most other clients take this in their mcp.json. Cline, Zed, Open WebUI, Devin Desktop and the rest are covered step by step at nodegrove.io/mcp.
{ "mcpServers": { "nodegrove-vram": { "url": "https://mcp.nodegrove.io/mcp" } } }Needs Node.js 20 or newer:
{
"mcpServers": {
"nodegrove-vram": {
"command": "npx",
"args": ["-y", "@nodegrove/vram-mcp"]
}
}
}Related MCP server: chimeraforge
Tool | Ask it | It answers with |
| Can my RTX 4090 run Llama 3.3 70B with 32k of context? | Fits, tight or no; the memory split; a speed ceiling; the longest context that fits; and on a no, every change that would make it fit |
| What is the best model for my 16 GB card? | Every model checked on one card, with a recommended everyday pick, the largest that fits, the best at Q8 and the first out of reach |
| How much VRAM does Qwen3 32B need at 64k? | Weights, KV cache and overhead at each quantisation, and the smallest common card that holds each |
| How much memory does | Any Hugging Face repo, read from its |
| Which GPUs do you know? | The models and cards with their specs, ids and pages |
Models can be named the way people type them ("llama 3.3 70b", Llama-3.3-70B-Instruct) or given as any Hugging Face repo id. Cards can be named ("4090", "M4 Max") or described by their memory and bandwidth. Every answer carries the numbers as fields, links to the model and card pages on nodegrove.io, and the assumptions behind each figure. All six tools are read-only.
Memory is weights + KV cache + overhead. Weights are parameters × bytes per parameter at the quantisation: FP16 2.00, Q8_0 1.06, Q6_K 0.82, Q5_K_M 0.71, Q4_K_M 0.58, Q3_K_M 0.47. Overhead is 0.5 GB plus 4% of the weights.
The KV cache is counted the way each model caches. Sliding-window layers stop at their window, hybrid models (linear attention or Mamba) grow a cache only on their few full-attention layers, and latent attention stores one compressed vector per layer. A standard-transformer formula would overstate these models several times over at long context.
Fit means at most 95% of the memory a runtime can address; above 85% it is tight. Apple silicon gives the GPU about 75% of unified memory.
Speed is 0.7 × memory bandwidth ÷ bytes of active weights read per token. It is a single-stream ceiling, not a measurement, and the faster the figure, the further real runtimes fall below it.
The model table was read from each model's config.json and checked against Hugging Face. Any other repo is read live by the same rules, which reproduce every row of the table; anything the reader cannot model is named in the answer, never guessed.
The full method, with every constant, is at nodegrove.io/data. The same figures are an open dataset under CC BY 4.0, DOI 10.5281/zenodo.22966137.
The server is a thin layer over @nodegrove/llm-math, the package nodegrove.io's pages and calculators are built on:
npm install @nodegrove/llm-mathimport { modelById, estimate } from '@nodegrove/llm-math';
estimate({ ...modelById('llama-3.3-70b')!, quant: 'q4', context: 8192 }).totalGb; // 45.77The remote server runs on Cloudflare Workers. Nodegrove keeps no request logs and no record of what you ask: each request is answered by a fresh, stateless instance and forgotten. Cloudflare keeps standard edge logs for a short period, as for any website. Requests are rate-limited to 120 a minute per address. When you ask about a Hugging Face repo, the server fetches that repo's public config.json and metadata; only the repo name is sent. The local version contacts nothing but huggingface.co, and only when you ask about a repo there. Details: nodegrove.io/privacy.
The remote endpoint is mcp/src/worker.ts. To deploy a copy to your Cloudflare account, change the route in mcp/wrangler.jsonc, then:
cd mcp && npm install && npx wrangler deploycd llm-math && npm install && npm test
cd mcp && npm install && npm test && npm run buildllm-math/ is the package of formulas and data; mcp/ is the server, with the stdio entry (src/stdio.ts), the Worker (src/worker.ts) and the tools (src/tools.ts). This repository is published from Nodegrove's main repository, where the site uses the same package. Issues and pull requests are welcome here; accepted changes are applied upstream and credited.
Found a figure that disagrees with its source? Open an issue with the model or card and the link. To report a security problem, see SECURITY.md.
The code is MIT. The model and GPU data, llm-math/src/models.ts and llm-math/src/gpus.ts, is CC BY 4.0: use it for anything, and credit Nodegrove (nodegrove.io).
Model and GPU names are trademarks of their owners.
Can this GPU run this open-weight LLM? Returns fits, tight or no, the memory split (weights, KV cache, overhead), a decode-speed ceiling, the longest context that fits and, on a no, every change that would make it fit: quantisation, KV cache, context, another card or a smaller model. Model: a name or id from list_models, any Hugging Face repo id, or its architecture. GPU: a name or id from list_gpus, or vram_gb for any other card.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | A GPU from list_gpus (id or name, e.g. "rtx-4090", "4090" or "M4 Max"). | |
| model | No | A model from list_models (id or name, e.g. "llama-3.3-70b" or "Llama 3.3 70B"), or any Hugging Face repo id (e.g. "Qwen/Qwen3-8B"), read live from its config.json. | |
| quant | No | Weight quantisation: fp16 (FP16 / BF16), q8 (Q8_0), q6 (Q6_K), q5 (Q5_K_M), q4 (Q4_K_M), q3 (Q3_K_M). q4 is the common default. | q4 |
| context | No | Tokens held in context: prompt plus conversation. | |
| vram_gb | No | Memory of a card not in list_gpus, GB. For a Mac, its unified memory with apple_silicon: true. | |
| kv_cache | No | KV cache precision. fp16 is what most runtimes use; q8 halves the cache. | fp16 |
| architecture | No | A model described by its config.json values instead of a name. | |
| apple_silicon | No | vram_gb is Apple unified memory; the GPU can use about 75% of it by default. | |
| bandwidth_gb_s | No | Memory bandwidth from the maker's spec, GB/s, for a speed ceiling. | |
| active_params_b | No | Parameters read per token, billions, for a mixture-of-experts model read from Hugging Face (from its model card). Sets the speed ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), and with no output schema the description carries the return-value burden itself: it names the verdict values, the memory breakdown, the decode-speed ceiling, the longest fitting context, and the remediation list returned on a 'no'. That is substantial behavioral disclosure well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose sentence, then the return contents, then the accepted input forms for model and GPU. Dense but no sentence is filler; the return enumeration is longer than strictly necessary but earns its place given there is no output schema.
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 10-parameter tool with nested architecture objects and no output schema, the description covers both the answer shape and the input domains, which is what an agent needs to call it correctly. Only minor gaps remain, such as what the speed ceiling is expressed in or how partial/unknown inputs are treated.
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 every parameter (quant, context, kv_cache, architecture sub-fields) is already documented at the schema level. The description restates the accepted input forms for model and gpu but adds no syntax, units, or format detail the schema does not already supply.
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 question the tool answers ('can this GPU run this open-weight LLM') and enumerates the verdicts (fits, tight, no) plus the memory split and speed ceiling it computes. That is enough for an agent to distinguish it from estimate_vram and what_fits 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear input-selection context: model can come from list_models or be any Hugging Face repo id or raw architecture, and GPU can come from list_gpus or a manual vram_gb. It does not explicitly say when to prefer this over siblings like estimate_vram or what_fits, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads any Hugging Face model repo's config.json and parameter count and estimates its memory: the attention layout found (standard, sliding-window, hybrid or latent), how much each 1,000 tokens of context costs, and weights + KV cache + overhead at every quantisation. For models nodegrove.io has not reviewed; anything the reader cannot model is listed in warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Hugging Face repo id, e.g. "Qwen/Qwen3-8B", or its huggingface.co URL. | |
| context | No | Tokens held in context: prompt plus conversation. | |
| kv_cache | No | KV cache precision. fp16 is what most runtimes use; q8 halves the cache. | fp16 |
| active_params_b | No | Parameters read per token, billions, for a mixture-of-experts model read from Hugging Face (from its model card). Sets the speed ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, open-world operation, so the safety profile is covered. The description adds real behavioral context beyond that: it reads config.json, may emit warnings for anything it cannot model, and always returns a full breakdown across quantisations. It does not discuss failure modes (e.g. gated/private repos, malformed configs) or latency from fetching the repo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, but front-loaded with the action and resource before enumerating outputs, and the scope qualifier (unreviewed models) plus the warnings note are placed at the end. Every clause carries information, though the output enumeration could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully summarises what comes back (attention layout, context cost, per-quant memory, warnings), which is enough for an agent to interpret results. It omits anything about input constraints or what a warning implies for the returned numbers, but is otherwise sufficient for this 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 repo, context, kv_cache and active_params_b are all documented in the schema, including enum values and defaults. The description adds no parameter-specific meaning beyond that; per the rubric, a 3 is the correct baseline when the schema does the heavy lifting.
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 (estimates memory) and resource (a Hugging Face model repo's config.json and parameter count), and enumerates the outputs: attention layout, per-1k-token context cost, weights + KV cache + overhead per quantisation. An agent can distinguish it from estimate_vram because it works on arbitrary HF repos rather than the reviewed catalog.
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?
"For models nodegrove.io has not reviewed" gives a clear condition that routes the agent away from the sibling estimate_vram for catalog models. It does not, however, name estimate_vram explicitly or state when-not to use it (e.g. for already-reviewed models), so it stops short of full when/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much memory an LLM needs: weights + KV cache + overhead at each quantisation (or one), at a given context, and the smallest common card class that holds each. Model: a name or id from list_models, any Hugging Face repo id, or its architecture (params_b, layers, kv_heads, head_dim).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | A model from list_models (id or name, e.g. "llama-3.3-70b" or "Llama 3.3 70B"), or any Hugging Face repo id (e.g. "Qwen/Qwen3-8B"), read live from its config.json. | |
| quant | No | Weight quantisation: fp16 (FP16 / BF16), q8 (Q8_0), q6 (Q6_K), q5 (Q5_K_M), q4 (Q4_K_M), q3 (Q3_K_M). Omit it for all 6. | |
| context | No | Tokens held in context: prompt plus conversation. | |
| kv_cache | No | KV cache precision. fp16 is what most runtimes use; q8 halves the cache. | fp16 |
| architecture | No | A model described by its config.json values instead of a name. | |
| active_params_b | No | Parameters read per token, billions, for a mixture-of-experts model read from Hugging Face (from its model card). Sets the speed ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, and the description adds genuine substance: it breaks the estimate into weights + KV cache + overhead, notes per-quantisation and per-context variation, and discloses the derived card-class output. It stops short of noting that model lookups hit Hugging Face live (rate limits/latency), which the schema mentions but the description does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with what is computed before the input forms. Nothing is padded, though the second sentence packs three alternative input modes into one clause and could be slightly clearer.
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 six-parameter tool with a nested object and no output schema, the description covers the computation, the quantisation/context levers, and the headline output (smallest common card class). It does not describe the full return shape (a per-quantisation memory list) or flag live HF fetches, leaving a small gap.
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 documents all six parameters, including enums for quant and kv_cache and the nested architecture object. The description only restates the model-source options and names four architecture fields, adding little beyond the structured data, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific computation (weights + KV cache + overhead) plus the derived output (smallest common card class), which is far more than a restated title. However, it never distinguishes itself from the sibling estimate_from_hf_repo, which it partly overlaps with by accepting HF repo ids, so an agent still has to guess which estimator to pick.
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 lists accepted model-reference forms but gives no when-to-use guidance and names no alternatives. With siblings can_i_run, what_fits, and estimate_from_hf_repo in the same family, the agent gets no signal about when this estimator is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The GPUs and machines nodegrove.io covers: memory, the memory a runtime can use and bandwidth, from the makers' specs, with each one's page.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Words to filter by, e.g. "qwen" or "24 GB". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is fully covered by structured data. The description adds that values come from makers' specs and each entry links to a page, a modest but real behavioral detail. It does not address pagination or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, so nothing is wasted, but its grammar is awkward ('memory, the memory a runtime can use and bandwidth') and reads as a comma-spliced list rather than a clean, front-loaded statement. Adequate but not crisp.
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 read-only list tool with full annotation coverage and no output schema, the description usefully previews the returned fields (memory, usable memory, bandwidth, page). The omission of result ordering or paging is minor at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'search' parameter is well documented with examples ('qwen', '24 GB'). The description adds no filtering semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource (GPUs and machines nodegrove.io covers) and enumerates the attributes returned: memory, usable memory, bandwidth, and a per-GPU page. The catalog nature distinguishes it from estimation siblings like estimate_vram, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or exclusion criteria. The agent is not told how this catalog differs from list_models or when to reach for it instead of what_fits/estimate_vram, leaving the routing decision to inference from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The open-weight LLMs nodegrove.io has verified against their config.json (data version 2026-10-16): id, size, attention design, native context, licence, memory at Q4 with 8k context and each model's page.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Words to filter by, e.g. "qwen" or "24 GB". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine context beyond them: the data provenance (verified against config.json) and a data version stamp (2026-10-16), plus a preview of what the list contains. It stops short of describing pagination or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the resource and then lists the payload. It is dense but every clause carries information; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields (id, size, attention design, native context, licence, Q4 memory at 8k context, model page). The version stamp also helps an agent judge data freshness. Only the omission of result limits/pagination keeps it from a 5.
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?
Only one optional parameter and schema description coverage is 100%, so the schema already documents 'search' fully (including examples). The description adds nothing about search behavior, which is the baseline-3 outcome when the schema carries the load.
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?
Names a specific resource (open-weight LLMs verified by nodegrove.io against config.json) and enumerates the exact fields returned, which is far more concrete than a bare 'List models'. It does not explicitly contrast itself with siblings like what_fits or can_i_run, but the catalogue framing is 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 contains no when-to-use guidance, no exclusions, and never names an alternative. Nothing tells the agent to reach for this tool rather than estimate_vram or what_fits, leaving routing to be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which open-weight LLMs fit this GPU: every model in list_models checked at one quantisation and context, with a recommended everyday model (the biggest class that fits with room for context at conversational speed), the largest that fits, the best at Q8 and the first out of reach. GPU: a name or id from list_gpus, or vram_gb for any other card.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | A GPU from list_gpus (id or name, e.g. "rtx-4090", "4090" or "M4 Max"). | |
| quant | No | Weight quantisation: fp16 (FP16 / BF16), q8 (Q8_0), q6 (Q6_K), q5 (Q5_K_M), q4 (Q4_K_M), q3 (Q3_K_M). q4 is the common default. | q4 |
| context | No | Tokens held in context: prompt plus conversation. | |
| vram_gb | No | Memory of a card not in list_gpus, GB. For a Mac, its unified memory with apple_silicon: true. | |
| apple_silicon | No | vram_gb is Apple unified memory; the GPU can use about 75% of it by default. | |
| bandwidth_gb_s | No | Memory bandwidth from the maker's spec, GB/s, for a speed ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful behavioral context beyond that: it defines what 'recommended everyday model' means operationally (biggest class that fits with room for context at conversational speed) and frames the output as a comparison set. It does not discuss latency, cost, or model of computation, but the added output semantics are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A compact two-sentence block that front-loads the purpose and the ranked outputs before the input guidance. Dense but every clause carries information; no filler or repetition of the title. It is close to the upper bound for a description of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does reasonably well by naming the four model classes reported. It omits that no parameter is required and does not mention defaults (q4, 8192 tokens), though the schema covers those. For a 6-param analytical tool with zero required inputs, the description is largely 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 every parameter is already documented in the schema, including the quant enum, context defaults and the Apple unified-memory caveat. The description only restates the gpu/vram_gb input choice and adds no format, syntax, or interaction detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Which open-weight LLMs fit this GPU') and enumerates the exact outputs returned: a recommended everyday model, the largest that fits, the best at Q8, and the first out of reach. An agent immediately knows what the tool computes. It stops short of naming or contrasting sibling alternatives like can_i_run or estimate_vram, so it is clear but not sibling-differentiating.
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?
It tells the agent where GPU inputs come from ('a name or id from list_gpus, or vram_gb for any other card'), which is useful routing guidance. However, it never states when this tool is preferable to siblings such as estimate_vram or can_i_run, nor any exclusions or prerequisites. Usage is implied rather than specified.
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.
v0.1.0can_i_runestimate_from_hf_repoestimate_vramlist_gpuslist_modelswhat_fitsScored across 6 tools
Tools are separated along reasonable axes (model+GPU pair, model-only, GPU-only, arbitrary HF repo), but can_i_run, estimate_vram, estimate_from_hf_repo, and what_fits all return overlapping memory-fit information, so an agent must read descriptions carefully to pick the right entry point.
Names use consistent snake_case, but conventions are mixed: list_* and estimate_* follow a verb_noun pattern while can_i_run and what_fits are question phrases. Still readable but not a single predictable scheme.
Six tools is well-scoped for a VRAM-estimation server, with each tool covering a distinct query direction (catalog, forward estimate, reverse fit).
The surface covers model and GPU catalogs, both fit directions, and memory estimation for known and unknown models, forming a near-complete lifecycle. Minor gaps exist around exploring quantisation/context spaces without committing to a model, but most workflows are supported.
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
Does an LLM fit on your GPU? VRAM, KV cache and GPU count for any Hugging Face model.
Read-only: which local LLMs a GPU or Mac can run - VRAM fit, tokens/sec, model specs.
Read-only GPU advisor: model VRAM needs, fit checks and rental prices, with evidence grades.
