FitLLM

Check if an LLM fits on hardware

check_llm_fit

Read-onlyIdempotent

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).

Input Schema

Name	Required	Description
`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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / env

Added 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"
+}

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / gpu_count / description

Previous 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."

Changed2 schema fields changedSep 3, 2026

changedInput schema / properties / context_tokens / description

Previous value: -"Context length in tokens (default 8192)"New value: +"Context length in tokens (default 8192). Alias: ctx (same field as the REST API)."

addedInput schema / properties / ctx

Added 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"
+}

First observedJul 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All FitLLM tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Check if an LLM fits on hardware

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources