Will a local LLM run on your hardware? GGUF quant, buy-vs-rent-vs-API cost, used-GPU prices.
Will a given local LLM run on given hardware? Returns fit, the best quant that fits, theoretical tok/s, and real owner-measured tok/s where available.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name, e.g. 'Llama 70B', 'gpt-oss-120B', 'Qwen 32B'. Use list_models to see known names. | |
| mxfp4 | No | True if the model ships natively in MXFP4 (e.g. gpt-oss) | |
| context | No | Context window in tokens (default 8192) | |
| total_b | No | For an unlisted model: total parameters in billions | |
| unified | No | True for unified-memory machines (Macs, Strix Halo, CPU+RAM) | |
| vram_gb | No | For custom hardware: VRAM or unified memory in GB | |
| active_b | No | For an unlisted model: active params in billions (= total for dense, less for MoE) | |
| hardware | No | Hardware name/id, e.g. 'rtx-3090', 'Mac 128GB', 'Strix Halo'. Use list_hardware to see known ones. | |
| kv_precision | No | KV cache precision (default f16) | |
| bandwidth_gbps | No | For custom hardware: memory bandwidth in GB/s |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It describes the output (fit, quant, tok/s) but lacks disclosure of read-only nature, side effects, or safety considerations. For a query tool, this is adequate but not comprehensive.
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 a single, front-loaded sentence that efficiently conveys the tool's function and return values. Every word adds value with no 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?
Given the absence of an output schema, the description adequately explains return values (fit, quant, tok/s, real tok/s) and the default context. Combined with full schema coverage, it provides sufficient information for an agent to use the 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 coverage is 100%, and the description adds valuable context beyond parameter names, such as recommending list_models/list_hardware for known values and explaining default contexts. This significantly enhances usability.
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's purpose: it checks if a given local LLM runs on given hardware and returns specific outputs (fit, quant, tok/s). This distinguishes it from sibling tools like recommend_hardware or cheapest_hardware_for_model, which have different goals.
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 implies usage when you have a specific model and hardware in mind, and references related tools (list_models, list_hardware) for input preparation. However, it does not explicitly state when not to use this tool or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cheapest catalogued, buyable machine that runs a given model at Q4 with the requested context.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name, e.g. 'Llama 70B', 'gpt-oss-120B', 'Qwen 32B'. Use list_models to see known names. | |
| mxfp4 | No | True if the model ships natively in MXFP4 (e.g. gpt-oss) | |
| context | No | Context window in tokens (default 8192) | |
| total_b | No | For an unlisted model: total parameters in billions | |
| active_b | No | For an unlisted model: active params in billions (= total for dense, less for MoE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the tool returns a 'catalogued, buyable machine' but does not explain data sourcing, update frequency, pricing accuracy, or any side effects. This is insufficient for an agent to assess reliability.
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 a single, front-loaded sentence with no wasted words. It conveys the essential idea economically. However, it could be more structured by grouping constraints or clarifying scope, preventing the need for a longer description.
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 5 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the output format, data source reliability, or how the 'cheapest' is determined (e.g., price vs. availability). The agent needs more context to use this tool effectively.
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 5 parameters. The description adds no extra meaning beyond the schema. It mentions Q4 and context, but those are inherent in the tool's purpose, not parameter-level details. 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 identifies the tool's purpose: finding the cheapest hardware for a given model with specific constraints (Q4 quantization, context). It uses a specific verb 'cheapest' and resource 'hardware for a model', which differentiates it from siblings like 'recommend_hardware' or 'compare_hardware'.
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 guidance is provided on when to use this tool versus its siblings. The description does not mention alternatives or when not to use it. Given the context signal of 7 sibling tools, the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side memory, bandwidth, price, and (with a model) fit + tok/s for 2 to 4 machines.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name, e.g. 'Llama 70B', 'gpt-oss-120B', 'Qwen 32B'. Use list_models to see known names. | |
| mxfp4 | No | True if the model ships natively in MXFP4 (e.g. gpt-oss) | |
| context | No | Context window in tokens (default 8192) | |
| total_b | No | For an unlisted model: total parameters in billions | |
| active_b | No | For an unlisted model: active params in billions (= total for dense, less for MoE) | |
| hardware | Yes | 2 to 4 hardware names/ids, comma-separated | |
| kv_precision | No | KV cache precision (default f16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists what is compared (memory, bandwidth, price, etc.) but does not mention side effects, mutability, or data sources. For a read-only comparison tool, this is acceptable but not enriched beyond the core behavior.
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 a single sentence that conveys the tool's purpose and scope efficiently with no redundant information. Every element (side-by-side, specific metrics, machine count) is directly relevant.
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 the tool has 7 parameters, no output schema, and 8 sibling tools, the description is relatively sparse. It does not clarify what 'fit' means, how to use the optional model-related parameters, or the output format. The schema descriptions partially compensate, but the description could be more helpful.
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 baseline is 3. The description hints that the 'model' parameter enables fit and tok/s calculation but adds no new meaning beyond the schema's parameter descriptions. It does not elaborate on how parameters interact or their formats.
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?
Description clearly states side-by-side comparison of specific hardware attributes: memory, bandwidth, price, and with a model also fit and tokens/second. It specifies the tool handles 2 to 4 machines, distinguishing it from sibling tools like 'cost_compare' which focuses only on price.
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 implies usage for comparing multiple hardware options but does not explicitly state when to use this tool versus siblings like 'cheapest_hardware_for_model', 'recommend_hardware', or 'can_i_run_it'. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy vs rent vs API cost to run a model locally: monthly/1y/3y totals, break-even months, and the energy cost per 1M tokens. Same math as /cost-calculator/.
| Name | Required | Description | Default |
|---|---|---|---|
| api | No | API $/million tokens (default 1.0) | |
| kwh | No | Electricity $/kWh (default 0.16) | |
| rent | No | Cloud GPU $/hour (default 0.59) | |
| hours | No | Active hours per day (default 3) | |
| tdp_w | No | For custom hardware: board power draw in watts | |
| tokens | No | Tokens generated per day, for the API comparison (default 300000) | |
| hardware | No | Catalogued hardware name/id (see list_hardware), e.g. 'rtx-3090-used' | |
| price_usd | No | For custom hardware: price in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the type of outputs but does not explicitly state that the tool is read-only, safe, or idempotent. For a computation tool, this is adequate but lacks explicit safety or side-effect information.
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 long, front-loaded with the core purpose, and contains no filler. Every word adds value, making it highly efficient and easy to parse.
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 8 parameters and no output schema, the description covers the high-level outputs but omits details on parameter dependency (e.g., hardware vs custom fields) and default behavior. Schema descriptions compensate partially, but the description could be more 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 the baseline is 3. The tool description does not add meaning beyond the schema; it repeats output types but does not explain parameter interactions (e.g., when to use hardware vs custom fields). The description offers no extra semantic value.
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 compares costs of buying, renting, or using API for running a model locally. It specifies outputs (monthly/1y/3y totals, break-even months, energy cost) and distinguishes itself from sibling tools like cheapest_hardware_for_model or compare_hardware by focusing on cost scenarios.
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 provides no guidance on when to use this tool versus alternatives like compare_hardware or recommend_hardware. It does not mention prerequisites, contexts, or when not to use it, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current typical used-GPU prices for local-AI rigs (eBay Browse API median asking + hand-verified, monthly).
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | Optional name/id filter, e.g. "3090" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses data source, verification method, and update frequency, which is good. However, it omits details like rate limits, whether results are real-time, or any potential staleness beyond the monthly update cycle.
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 a single focused sentence of 20 words that front-loads the core purpose. Every word adds value, with no redundancy or filler.
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 the lack of an output schema, the description should hint at the return format (e.g., list of prices, single price, GPU names). It mentions 'prices' but does not clarify structure, leading to potential confusion for the agent. The tool is simple, but completeness is lacking.
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% for the single parameter, so baseline is 3. The description adds context about the tool's purpose but does not elaborate on the parameter's behavior beyond what the schema says. No additional semantics are provided.
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 specifies the verb ('get'), resource ('used-GPU prices'), context ('local-AI rigs'), and data source/frequency ('eBay Browse API median asking + hand-verified, monthly'). It effectively distinguishes from siblings like 'cost_compare' or 'list_hardware' which cover different price types.
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 implies when to use (when needing used GPU prices) but lacks explicit guidance on when not to use or alternatives among siblings. No exclusion criteria or comparison with tools like 'recommend_hardware' is provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the machines the tools know about (memory, bandwidth, price, buy link).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses a read-only listing operation, but does not mention any behavioral traits like rate limits, authentication needs, or if results are cached.
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?
Single, front-loaded sentence with no wasted words. Efficiently communicates the tool's purpose and output content.
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 listing tool without output schema, the description adequately explains what the tool returns. However, it could mention if the list is complete or limited, and whether ordering is predictable.
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 exist, so the baseline is 4. The description adds value by listing the fields included in the output (memory, bandwidth, price, buy link), which enriches understanding beyond the empty input schema.
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 verb 'List', resource 'machines', and specifies included fields (memory, bandwidth, price, buy link). Distinguishes from siblings that provide more specific hardware-related 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?
No guidance on when to use this tool vs alternatives. The description only states what it does, lacking context for when to choose it over search or comparison tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the local LLM model classes the tools know about (params, dense/MoE, native context).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as a read-only listing of model metadata, which is clear. It does not mention authentication or rate limits, but for a simple list tool, the description is sufficient.
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 a single, focused sentence with no unnecessary words. It efficiently conveys the tool's purpose and output content.
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 and no annotations, the description provides a solid overview. It is complete for a parameterless list tool, though it could mention whether the list is exhaustive or paginated. Still, it's adequate.
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?
With zero parameters, the description adds significant meaning by specifying the output includes params, dense/MoE, and native context. This goes beyond the empty schema and helps the agent understand what information will be returned.
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 lists local LLM model classes with specific attributes (params, dense/MoE, native context). The verb 'list' and resource 'model classes' are precise, and it distinguishes itself from sibling tools like list_hardware.
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 explicit guidance on when to use this tool vs alternatives. While the name and description imply it's for listing models, there is no mention of when not to use it or comparison with siblings like can_i_run_it or recommend_quant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked list of catalogued, buyable machines that run a model at the requested context, cheapest first, with an optional budget cap.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name, e.g. 'Llama 70B', 'gpt-oss-120B', 'Qwen 32B'. Use list_models to see known names. | |
| mxfp4 | No | True if the model ships natively in MXFP4 (e.g. gpt-oss) | |
| budget | No | Optional max price in USD | |
| context | No | Context window in tokens (default 8192) | |
| total_b | No | For an unlisted model: total parameters in billions | |
| active_b | No | For an unlisted model: active params in billions (= total for dense, less for MoE) | |
| kv_precision | No | KV cache precision (default f16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full transparency burden. It discloses the ranking criterion ('cheapest first') but does not mention what happens if no machines match, auth requirements, or rate limits. The behavioral scope is partially clear.
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 a single sentence of 18 words, front-loading the key information (ranked list, buyable machines, context, cheapest-first, budget cap). No wasted words.
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 7 parameters and no output schema, the description only states the return is a ranked list, but does not specify the fields in each machine entry, pagination, or how the ranking is derived beyond price. Adequate for a simple list but missing return structure details.
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 baseline is 3. The description adds no extra meaning beyond the schema; it only reiterates the optional budget. The description does not provide parameter-level detail beyond what is already in the schema.
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 returns a 'ranked list of catalogued, buyable machines' that run a model at a given context, sorted cheapest first. The verb 'recommend' and resource 'hardware' are explicit, and it distinguishes from siblings like 'can_i_run_it' (binary check) and 'cheapest_hardware_for_model' (single result).
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 implies usage when needing a ranked list of hardware for a model, but does not explicitly state when to use this tool versus alternatives like 'compare_hardware' or 'cost_compare'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which GGUF quantization to download for a model on given hardware: the full quant ladder with file size, max context, and tok/s for each, plus the recommended pick.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name, e.g. 'Llama 70B', 'gpt-oss-120B', 'Qwen 32B'. Use list_models to see known names. | |
| mxfp4 | No | True if the model ships natively in MXFP4 (e.g. gpt-oss) | |
| context | No | Context window in tokens (default 8192) | |
| total_b | No | For an unlisted model: total parameters in billions | |
| unified | No | True for unified-memory machines (Macs, Strix Halo, CPU+RAM) | |
| vram_gb | No | For custom hardware: VRAM or unified memory in GB | |
| active_b | No | For an unlisted model: active params in billions (= total for dense, less for MoE) | |
| hardware | No | Hardware name/id, e.g. 'rtx-3090', 'Mac 128GB', 'Strix Halo'. Use list_hardware to see known ones. | |
| kv_precision | No | KV cache precision (default f16) | |
| bandwidth_gbps | No | For custom hardware: memory bandwidth in GB/s |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the output (full ladder with file size, max context, tok/s, recommended pick). However, it does not mention any side effects, authentication, or rate limits, which are less critical for a recommendation tool.
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 a single, front-loaded sentence that efficiently conveys purpose and output without extraneous words. Every part earns its place.
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?
The description explains the output clearly (full quant ladder with file size, max context, tok/s, recommended pick), compensating for the lack of an output schema. However, it does not cover error handling or what happens if hardware/model is not found, leaving minor gaps.
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 baseline is 3. The description does not add any additional meaning beyond what the schema provides for parameters, leaving all semantic weight to the schema.
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's purpose: to recommend a GGUF quantization for a model on given hardware, providing a ladder with file size, max context, tok/s, and a pick. This distinguishes it from sibling tools like 'can_i_run_it' or 'recommend_hardware'.
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 implies usage when needing quantization recommendations but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or context for sibling differentiation is provided.
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. Dates show when Glama detected each change.
can_i_run_itcheapest_hardware_for_modelcompare_hardwarecost_compareget_used_gpu_priceslist_hardwarelist_modelsrecommend_hardwarerecommend_quantClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
LLM and GPU rental prices: model price lookup, GPU listings, cheapest-GPU search, price history
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
GPU and LLM inference benchmarks, hardware evidence, deployment recommendations, and launch configs.
Compare LLM API pricing, estimate workload costs, and benchmark cloud compute. By OptimNow.
Add one secure layer between your agents and this server.
Tools have mostly distinct purposes, though there is some overlap between cheapest_hardware_for_model and recommend_hardware, which both suggest machines for a model. Can_i_run_it also partially overlaps with these. However, descriptions clearly differentiate them.
Most tools follow verb_noun pattern (list_hardware, compare_hardware), but can_i_run_it is a question and cost_compare is noun_verb, creating minor inconsistency.
9 tools is well-scoped for a domain of hardware/model comparison, covering all key actions without being excessive.
Covers main workflows: compatibility check, cost analysis, recommendations, and listings. Lacks advanced filtering or detailed hardware specs, but core functionality is present.
