Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
Scored across 6 tools
can_i_run is essentially a superset of estimate_vram (it also returns the memory split and per-quantisation breakdown) and overlaps with what_fits (both determine compatibility). The directionality differs (model→GPU vs GPU→models) and estimate_from_hf_repo is scoped to unreviewed repos, which helps, but an agent could plausibly reach for the wrong one.
Most tools follow a verb_noun pattern (list_gpus, list_models, estimate_vram, estimate_from_hf_repo), but can_i_run and what_fits are question-style phrases. Readable but mixed conventions, so not fully predictable.
Six tools is well-scoped for a VRAM-estimation server: two listing tools, two estimation tools, and two fit-checking tools. Each earns its place with no filler.
The surface covers the core lifecycle well: list GPUs/models, estimate memory (including arbitrary HF repos), and check fit in both directions. Minor gaps exist (no get_gpu/get_model detail lookup beyond the list output, no side-by-side comparison), but agents can work around these.
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.
can_i_runestimate_from_hf_repoestimate_vramlist_gpuslist_modelswhat_fitsDoes an LLM fit on your GPU? VRAM, KV cache and GPU count for any Hugging Face model.
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
Will a local LLM run on your hardware? GGUF quant, buy-vs-rent-vs-API cost, used-GPU prices.
Read-only: which local LLMs a GPU or Mac can run - VRAM fit, tokens/sec, model specs.
Add one secure layer between your agents and this server.
