LLM Hosting Pricing
Server Details
LLM and GPU rental prices: model price lookup, GPU listings, cheapest-GPU search, price history
- 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 3.9/5 across 5 of 5 tools scored.
Each tool targets a distinct purpose: GPU rental prices, model pricing, price history, GPU listing, and model search. No overlap, clear boundaries.
All names use snake_case and are descriptive, but pattern varies: some start with verbs (get_, list_, search_), others with adjectives (cheapest_) or nouns (gpu_price_history). Minor inconsistency.
Five tools cover the core functionalities for a pricing lookup server without being excessive or insufficient. Well-scoped.
Covers key areas: current GPU prices, model prices, history, and search. Missing provider-specific details or bulk queries, but core workflows are supported.
Available Tools
5 toolscheapest_gpuAInspect
Cheapest GPU rentals right now, optionally filtered by minimum VRAM (GB).
| Name | Required | Description | Default |
|---|---|---|---|
| min_vram_gb | No | minimum VRAM in GB, e.g. 80 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as read-only nature, side effects, authentication requirements, or rate limits. The description only states the basic function without transparency.
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 sentence, front-loaded with key information. No unnecessary words. Efficient and clear.
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?
Tool is simple with one optional parameter and no output schema. Description covers purpose and filter but could be improved by hinting at output format or expected results. Still adequate for basic 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 coverage is 100% with one parameter described. The description repeats the schema's 'min_vram_gb' definition without adding deeper semantics or usage nuances. Baseline 3 due to high coverage.
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 the tool's purpose: finding the cheapest GPU rentals with an optional VRAM filter. It is distinct from sibling tools like 'list_gpus' or 'gpu_price_history' that serve different purposes.
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?
Description implies usage: when you need cheapest GPU rentals with optional VRAM filtering. Does not explicitly state when not to use but sibling names provide indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_model_pricesAInspect
All provider prices for one LLM model: input/output/cache price per 1M tokens and context window per provider, cheapest first.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | model slug or name, e.g. "deepseek-v4-flash" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. Mentions sorting and units but lacks details on read-only nature, authentication, rate limits, error handling, or data freshness.
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 sentence that is concise and informative, front-loading the key purpose and output details without unnecessary 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?
No output schema, but description compensates by specifying units and sorting. However, it does not detail exact return structure (e.g., JSON array of objects) or error behavior.
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% with a single parameter 'model' described as 'model slug or name, e.g. deepseek-v4-flash'. The description adds context about what the parameter represents (the model to get prices for).
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 provides all provider prices for one LLM model, specifying input/output/cache price per 1M tokens and context window, sorted cheapest first. Distinguishes from siblings like cheapest_gpu and search_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?
Implied usage for fetching prices for a specific model, but no explicit when-to-use or when-not-to-use, nor mention of alternatives like search_models to find model slugs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gpu_price_historyAInspect
Daily minimum rental price history for a GPU (recorded daily since 2026-07-06).
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | Yes | GPU name, e.g. "H100 SXM" or "RTX 4090" | |
| days | No | how many most-recent days to return (default 30) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the data frequency (daily) and start date but does not mention read-only nature, response format, or any side effects. The minimum price qualifier adds useful context.
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 concise sentence that communicates the essential information without any fluff. Every word 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?
For a simple tool with 2 parameters and no output schema, the description covers the basics but lacks details on return format or any constraints beyond the start date. It is adequate but not fully comprehensive.
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%, but the description adds value by specifying the start date (since 2026-07-06), which affects how the 'days' parameter should be used. This goes beyond what the schema alone provides.
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 provides 'daily minimum rental price history for a GPU' with a specific start date. This is a specific verb+resource combination that distinguishes it from sibling tools like cheapest_gpu or list_gpus.
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 does not provide any guidance on when to use this tool versus alternatives. Sibling tools are listed but no explicit when-to-use or when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_gpusAInspect
Every GPU with live rental pricing: cheapest $/hr, provider, tier, and VRAM.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only query by stating it returns pricing data, but does not explicitly confirm no side effects. For a simple list tool, this is minimally acceptable.
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 concise sentence that front-loads the key information: 'Every GPU with live rental pricing'. No redundant or unnecessary text.
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 tool, the description covers the essential output fields. However, it lacks details on ordering, pagination, or whether the list is exhaustive. Still, it is mostly complete given the tool's simplicity.
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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter info. Baseline 4 applies, and the description is adequate.
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 all GPUs with live rental pricing, including cheapest $/hr, provider, tier, and VRAM. This distinguishes it from siblings like 'cheapest_gpu' (which likely returns only the cheapest) and 'gpu_price_history' (historical data).
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 is provided on when to use this tool versus alternatives. With siblings like 'cheapest_gpu', 'search_models', and 'gpu_price_history', a brief note on when to use this comprehensive list vs. the others would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_modelsAInspect
Search LLM models by name. Returns matching models with provider count and the cheapest input/output price per 1M tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | model name or fragment, e.g. "deepseek" or "llama 70b" |
Tool Definition Quality
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 that the tool searches and returns specific data. While it does not explicitly state read-only behavior, the described functionality implies no side effects.
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 that front-load the action and return value with no redundant or unclear language. Every sentence 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?
For a low-complexity tool with one parameter, the description sufficiently covers purpose and output. Could mention pagination or result limits, but not necessary 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 coverage is 100% with a single parameter 'query' having a description. The description adds value by providing examples like 'deepseek' or 'llama 70b', clarifying the expected input format beyond 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 action ('Search LLM models by name') and specifies the exact return value: matching models with provider count and cheapest prices. This distinguishes it from siblings like 'get_model_prices' and 'list_gpus'.
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 the tool (when searching models by name) but does not explicitly state when not to use it or compare with sibling tools. Context is clear, but lacks explicit exclusions.
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!