Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
Scored across 3 tools
The three tools occupy distinct query shapes: check_llm_fit takes a specific model+hardware pair, what_fits_on_hardware takes hardware only and ranks models, and list_supported is a pure lookup. There is mild conceptual overlap since what_fits_on_hardware implicitly answers many 'does it fit' questions, but the 'model named vs. not named' boundary in the descriptions keeps routing clear.
All names use consistent snake_case, which helps, but the verb conventions are mixed: check_llm_fit is verb+noun, list_supported drops the noun object, and what_fits_on_hardware is an interrogative phrase. Readable, but not a predictable pattern across the set.
Three tools is lean for a specialized LLM-fitting checker, and each one earns its place (single check, enumeration of known names, hardware-driven ranking). It borders on thin, but nothing feels redundant or missing for the stated narrow scope.
The surface covers the core lifecycle: discover supported names, check a specific model/hardware pair, and rank models for given hardware, with fit verdicts returning breakdowns and fixes. Minor gaps exist, such as no explicit multi-model comparison or context-length/quantization query tool, but agents can work around these via the existing checks.
Check whether a specific local LLM fits in the memory of a specific GPU or Apple Silicon Mac. Returns fits/tight/won't-fit verdict with the memory breakdown (weights, KV cache, linear-attention state when present, runtime overhead, reserve), max context, and a concrete fix if it doesn't fit. Use this whenever a user asks anything like "can I run on my <GPU/Mac>?", "will fit in GB?", or "what do I need to run ?". Estimates using curated, config-derived architecture fields (MLA, sliding-window, hybrid attention, MoE modeled).
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | Alias of context_tokens — accepted because the REST API uses this name. Do not pass both with different values. | |
| env | No | Discrete-GPU OS reserve: windows-display (default, 2 GB/card) · linux-display (1.2 GB) · linux-headless (0.6 GB, a second card with no display). Not for Macs or DGX Spark-class systems. | |
| gpu | No | GPU name, fuzzy — e.g. "RTX 4090", "RX 7900 XTX", "A100 80GB". Multi-GPU rigs: join with + — e.g. "RTX 5090 + RTX 3090" (VRAM pools across cards). Provide gpu OR mac_ram_gb. | |
| model | Yes | LLM name, fuzzy — e.g. "GLM-4.7-Flash", "gpt-oss-20b", "gemma 31b" | |
| quant | No | Weight quantization. GPU: Q4_K_M(default)/Q5_K_M/Q6_K/Q8_0/FP16. Mac: 4/8(default)/16 (bits). | |
| kv_bits | No | KV-cache quantization bits (default 16 = F16) | |
| gpu_count | No | Number of identical copies of the gpu (e.g. gpu="RTX 3090", gpu_count=2 for a 2×3090 rig; gpu="DGX Spark 128GB", gpu_count=2 or 4 for linked units under vLLM+Ray or TensorRT-LLM). Default 1. | |
| mac_ram_gb | No | Apple Silicon unified memory in GB — e.g. 16, 64, 512. Provide gpu OR mac_ram_gb. | |
| context_tokens | No | Context length in tokens (default 8192). Alias: ctx (same field as the REST API). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, closed-world computation, but the description adds genuinely useful behavior beyond them: the three-tier verdict (fits/tight/won't-fit), what the breakdown contains, that a fix is returned on failure, and that results are estimates from curated architecture fields (MLA, sliding-window, hybrid attention, MoE) rather than measured numbers. This tells the agent to present results as estimates—context the annotations do not carry.
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?
Purpose is front-loaded in sentence one, followed by return shape, then routing triggers, then methodology. It is dense but each clause carries information; the long mid-sentence enumerating the breakdown is the only place it 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 describes the return payload, and the annotations cover the safety profile. The remaining gap is that it never says what happens if neither gpu nor mac_ram_gb is supplied, and it does not distinguish itself from the near-identical sibling what_fits_on_hardware.
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 all nine parameters in detail (aliasing of ctx/context_tokens, env presets, multi-GPU joining, per-platform quant formats). The description adds no parameter-level detail of its own beyond referencing KV cache and context in the output breakdown, so the baseline of 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 first sentence states a specific verb (check) and resource (whether a named LLM fits in the memory of a named GPU/Mac), so the agent immediately knows the direction of the query. It is not, however, differentiated from the sibling what_fits_on_hardware, which is the inverse question; the example user phrasings imply the model-to-hardware direction but the sibling is never named.
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?
Explicit trigger conditions are given: 'Use this whenever a user asks ... can I run <model> on my <GPU/Mac>?', which is stronger than most definitions. There is no when-not clause and no named alternative, so the agent gets positive routing but no explicit exclusion against what_fits_on_hardware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in model names and hardware names this fit-checker knows (for mapping user wording to exact names). Standard text-only HuggingFace transformer configs can also be checked via fitllm.run; unsupported architectures are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds behavioral context beyond that: the known set is built-in/closed, standard text-only HuggingFace transformer configs are additionally checkable, and unsupported architectures are rejected. No contradiction with 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?
Two tightly written sentences with no filler. The first sentence front-loads the action and purpose, and the second adds eligibility and rejection behavior without 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 zero-parameter, read-only list operation with annotations already covering safety, the description is complete: an agent knows what will be listed, why it exists, and what constraints apply to checkable configs. The return shape is self-ident from the listing semantics.
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 no parameter documentation is needed; the zero-parameter baseline applies. The description still adds useful context about what the returned names are for, which is sufficient.
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?
Clearly states a specific verb ('List'), a specific resource ('built-in model names and hardware names'), and an explicit purpose ('mapping user wording to exact names'). This also distinguishes it from the sibling fit-checking tools, which answer different questions.
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 identifies a clear use context: when an agent needs to map user wording to exact built-in model or hardware names. It does not explicitly name sibling tools or provide when-not-to-use guidance, but the stated purpose makes the boundary sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank which popular local LLMs fit on a given GPU or Apple Silicon Mac (at ~4-bit quantization, 8K context) — models that fit come first, biggest first, with max context each. Use when a user asks "what can I run on my <GPU/Mac/N GB>?", "best local model for my machine?", or gives hardware without naming a model.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | GPU name, fuzzy. Multi-GPU rigs: join with + (e.g. "RTX 5090 + RTX 3090"). Provide gpu OR mac_ram_gb. | |
| gpu_count | No | Number of identical copies of the gpu. Default 1. | |
| mac_ram_gb | No | Apple Silicon unified memory GB. Provide gpu OR mac_ram_gb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: it assumes ~4-bit quantization and 8K context, ranks fitting models first and largest first, and reports max context per model. This meaningfully informs the agent about how results are produced.
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 sentences, front-loaded with the core purpose, and contains no filler. Every clause contributes either the behavior, the assumptions, or the trigger conditions for use.
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 tool with a fully documented schema, the description covers what the tool does, when to use it, and the shape of the output (ordered list with max context). It does not specify the exact return format, but the absence of an output schema is mitigated by the description's clarity about ranking and included fields.
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 parameters are already fully documented. The description adds high-level context by mentioning GPU/Apple Silicon and 'N GB', which maps to gpu and mac_ram_gb, but it does not add 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?
The description uses a specific verb ('Rank') and a clear resource ('popular local LLMs fit on a given GPU or Apple Silicon Mac'), and it states the ranking criteria. It is clearly differentiated from the likely sibling tools by focusing on hardware-to-model matching rather than checking a specific fit or listing all supported 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 explicitly says when to use the tool ('Use when a user asks...') and includes concrete example queries. It does not explicitly mention when not to use it or name sibling alternatives, so it stops short of full exclusion guidance.
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.
check_llm_fit1 field changedInput schema / properties / envAdded value: +{
+ "description": "Discrete-GPU OS reserve: windows-display (default, 2 GB/card) · linux-display (1.2 GB) · linux-headless (0.6 GB, a second card with no display). Not for Macs or DGX Spark-class systems.",
+ "enum": [
+ "linux-headless",
+ "linux-display",
+ "windows-display"
+ ],
+ "type": "string"
+}check_llm_fit1 field changedInput schema / properties / gpu_count / descriptionPrevious value: -"Number of identical copies of the gpu (e.g. gpu=\"RTX 3090\", gpu_count=2 for a 2×3090 rig). Default 1."New value: +"Number of identical copies of the gpu (e.g. gpu=\"RTX 3090\", gpu_count=2 for a 2×3090 rig; gpu=\"DGX Spark 128GB\", gpu_count=2 or 4 for linked units under vLLM+Ray or TensorRT-LLM). Default 1."check_llm_fit2 fields changedInput schema / properties / context_tokens / descriptionPrevious value: -"Context length in tokens (default 8192)"New value: +"Context length in tokens (default 8192). Alias: ctx (same field as the REST API)."Input schema / properties / ctxAdded value: +{
+ "description": "Alias of context_tokens — accepted because the REST API uses this name. Do not pass both with different values.",
+ "minimum": 1024,
+ "type": "integer"
+}check_llm_fitlist_supportedwhat_fits_on_hardwareDoes an LLM fit on your GPU? VRAM, KV cache and GPU count for any Hugging Face model.
Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
Read-only: which local LLMs a GPU or Mac can run - VRAM fit, tokens/sec, model specs.
LLM serving capacity planner: VRAM, KV cache, GPU topology, latency, and cost.
Add one secure layer between your agents and this server.
