FitLLM
Server Details
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: checking a specific model fit, listing known names, and ranking models that fit on given hardware. There is no overlap in functionality.
All names use lowercase with underscores, but the pattern is not perfectly uniform: 'check_llm_fit' and 'list_supported' are imperative verb_noun, while 'what_fits_on_hardware' is a descriptive phrase. Still, naming is predictable and readable.
With only 3 tools, the server is tightly scoped to its purpose of fit-checking. Each tool earns its place, covering specific check, listing, and ranking needs without redundancy.
The tool surface covers the core workflow: checking a specific model, listing supported names, and finding what fits. The fix suggestion in check_llm_fit adds practical value, and the domain is fully addressed.
Available Tools
3 toolscheck_llm_fitCheck if an LLM fits on hardwareARead-onlyIdempotentInspect
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 full memory breakdown (weights, KV cache, overhead), 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 ?". Architecture-aware math (MLA, sliding-window, hybrid attention, MoE) — more accurate than rule-of-thumb estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds useful context: architecture-aware math, returns verdict with breakdown, max context, and fix. Does not contradict 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 concise paragraphs: purpose then usage. No wasted words, front-loaded with key information. Every sentence adds value.
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 tool with 7 params and no output schema, the description covers what it returns, key constraints, and accuracy. Lacks error handling details but is adequate for typical use.
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 covers 100% of parameters, so baseline is 3. The description adds value by explaining multi-GPU syntax ('join with +'), default quantizations, and the mutual exclusivity of gpu and mac_ram_gb.
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 the tool checks if a specific local LLM fits in GPU or Apple Silicon memory, with specific verbs and resource. Distinguishes from siblings by focusing on a model+hardware pair rather than listing all fits or supported items.
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 explicit usage examples ('can I run <model> on my <GPU/Mac>?') and indicates when to use this tool over alternatives. While it doesn't explicitly state when not to use it, the examples are sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_supportedList supported models & hardwareARead-onlyIdempotentInspect
List the built-in model names and hardware names this fit-checker knows (for mapping user wording to exact names). Any public HuggingFace model also works via fitllm.run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond readOnlyHint and idempotentHint annotations by specifying that any public HuggingFace model also works via fitllm.run. No contradictions.
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 sentences with no wasted words. Front-loaded with action verb. Every sentence adds value.
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 parameterless list tool, the description fully covers purpose, scope, and an important behavioral detail (HuggingFace support). No output schema needed.
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?
No parameters; baseline 4 applies. Description adds context but parameter semantics not applicable.
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 it lists built-in model and hardware names for mapping user wording to exact names, and distinguishes from sibling tools like check_llm_fit that perform different functions.
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?
Explicitly describes the use case (mapping user wording to exact names). Implicitly suggests using this tool before other fit-related tools when needing exact names. Could be improved with explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
what_fits_on_hardwareWhat LLMs fit on this hardwareARead-onlyIdempotentInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable behavioral details: ranking order (models that fit first, biggest first), quantization level (~4-bit), and context length (8K). No contradictions 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?
The description is extremely concise: two sentences. The first sentence explains the core functionality and ranking logic, the second provides usage examples. No wasted words, front-loaded with key 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?
Given no output schema, the description partly addresses output by mentioning 'models that fit come first, biggest first, with max context each.' This provides enough context for an agent to understand what will be returned. However, the exact output format is not specified, which is a minor 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 parameters. The description reinforces that gpu or mac_ram_gb should be provided but does not add new semantic meaning beyond what the schema 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 ranks which popular local LLMs fit on given hardware with specific constraints (4-bit quantization, 8K context). It uses a specific verb 'rank' and resource 'popular local LLMs', and the usage examples help distinguish from siblings by targeting hardware-first queries.
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 lists three example user queries that should trigger this tool, such as 'what can I run on my <GPU/Mac/N GB>?'. This provides clear when-to-use guidance and implicitly distinguishes from sibling tools for model-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!