Skip to main content
Glama

FastGPU

by co.fastgpu
OverviewDiscussionsAdmin

Server Details

Compare live GPU cloud rental prices and match workloads to the cheapest provider.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: list_gpu_prices provides raw market price data, while match_workload provides a decision/recommendation. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (list_gpu_prices, match_workload) with lowercase and underscores. The naming style is identical across the set.

Tool Count3/5

With only 2 tools, the server feels slightly thin but is not unreasonable for a narrowly focused GPU pricing and workload matching domain. It sits at the borderline where the count is justifiable but leaves little room for breadth.

Completeness4/5

The server covers the two core user intents: browsing current prices and getting a tailored workload recommendation. Minor gaps exist (e.g., historical pricing, detailed GPU specs), but the primary workflow is complete.

Available Tools

2 tools
list_gpu_pricesList cheapest GPU pricesA
Read-onlyIdempotent
Inspect

One entry per GPU model with the current cheapest live rental price across the whole market (RunPod, Vast.ai, Lambda, hyperscalers and more). No key required. Use this to compare GPU prices.

ParametersJSON Schema
NameRequiredDescriptionDefault
tierNoFilter by tier.
vendorNoFilter by GPU vendor.

Output Schema

ParametersJSON Schema
NameRequiredDescription
gpusYes
countYes
staleNo
updated_atNo

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description meaningfully adds behavioral context: results are live rental prices, there is one entry per GPU model, and no authentication key is required. These details help the agent predict behavior and call prerequisites without contradicting the readOnly/openWorld/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the core behavior and market scope, then adds auth and usage guidance. Every clause contributes actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only list tool with a full input schema, an output schema, and rich annotations, the description covers the essential operational details: market coverage, live pricing, per-model granularity, and auth-free access. Nothing critical is missing for an agent to select and invoke the tool correctly.

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%, with both parameters (tier and vendor) described in the schema itself. The description does not add parameter-level detail, but according to the baseline this is acceptable since the schema carries the semantic burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb (list), a precise resource (GPU models with current cheapest live rental price), and a well-defined market scope. It also includes an explicit usage directive ('Use this to compare GPU prices') that makes the tool's intent unambiguous.

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?

The description provides clear context for when to use the tool: when comparing GPU prices across the market. It notes that no key is required, which lowers the barrier for use. It does not explicitly name alternatives or exclusions relative to the sibling tool match_workload, so it stops just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

match_workloadMatch a workload to the cheapest GPUA
Read-onlyIdempotent
Inspect

The routing DECISION: describe a job (a model, size, or GPU need) and get the ranked, reasoned recommendation for the cheapest place to run it across the live market, with the required VRAM, GPU count, effective $/hr, and how much cheaper it is than a hyperscaler. No key required. Results mirror the site and apply a small, disclosed partner tie-break between otherwise-equal offers (each match reports partner true/false).

ParametersJSON Schema
NameRequiredDescriptionDefault
spotNoSet true to include interruptible spot capacity for a cheaper rate.
taskNoWhat the job does.
modelNoOpen model name to size against, e.g. "Llama 3 70B", "Qwen 72B", "Mixtral".
queryNoPlain-language job, e.g. "cheapest to serve Llama 3 70B" or "2x H100 for fine-tuning". Provide this OR a structured spec below.
regionNoRestrict to a data-residency region.
vram_gbNoRough VRAM the job needs, in GB, if you already know it.
params_bNoModel size in billions of parameters when no exact model is named.
reservedNoSet true to include reserved / committed-term capacity for a lower rate.
gpu_countNoExact positive GPU count. Overrides a count in query text. Returns no matches if no supported configuration fits; omit for automatic sizing.
precisionNoNumeric precision to size the model at.
budget_usd_hrNoOnly recommend configs at or under this hourly budget.

Output Schema

ParametersJSON Schema
NameRequiredDescription
heroNo
countYes
staleNo
matchesYes
workloadNo
updated_atNo

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: 'No key required' (access prerequisites), 'Results mirror the site', and the disclosed partner tie-break with per-match 'partner true/false'. This enriches behavioral understanding without contradiction.

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?

The description front-loads the core purpose and is logically structured, covering purpose, output, access, and disclosure. It is slightly verbose (about 70 words) but every sentence contributes useful information. Could be tightened without losing meaning.

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?

The description explains the output format (VRAM, GPU count, eff $/hr, savings vs hyperscaler), the partner tie-break, and the no-key requirement. With an output schema present and strong annotations, this is fairly complete for a 11-parameter tool. The only gap is the explicit usage boundary with list_gpu_prices, which is captured under usage guidelines.

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 coverage is 100%, so every parameter has a description in the input schema. The tool description adds no additional parameter-specific meaning; it only paraphrases the general job-description concept. Given the schema does the heavy lifting, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'match' and the resource 'workload', and the outcome is a 'ranked, reasoned recommendation' for the cheapest place to run a job. It implicitly differentiates from the sibling list_gpu_prices by focusing on decision-making rather than raw price listing, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case ('routing DECISION', 'describe a job') but does not explicitly contrast this tool with list_gpu_prices or state when not to use it. There is no mention of alternatives or exclusions, leaving the agent to infer the boundary between the tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedmatch_workload2 fields changed
      • changedInput schema / properties / gpu_count / description
        Previous value: -"Force a specific GPU count instead of letting the engine size it."New value: +"Exact positive GPU count. Overrides a count in query text. Returns no matches if no supported configuration fits; omit for automatic sizing."
      • addedOutput schema / properties / workload / properties / gpu_count
        Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
  2. 2 tool updates
    • First observedlist_gpu_prices
    • First observedmatch_workload

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources