How do I use @inferra-trade/mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@inferra-trade/mcp-server compare current GPU rental prices for H100 and H200" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@inferra-trade/mcp-server

Official

by InferraTrade

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@inferra-trade/mcp-server

GPU rental prices for AI agents, over the Model Context Protocol.

The Inferra GPU Index publishes what an hour of an A100, H100, H200 or B200 rents for, aggregated from public rental markets, outlier-filtered, and attested on Solana mainnet through a Chainlink DON every five minutes. This server puts that number one tool call away from any MCP host: a desktop assistant, an IDE, an agent framework of your own.

{
  "mcpServers": {
    "inferra": {
      "command": "npx",
      "args": ["-y", "@inferra-trade/mcp-server"],
      "env": { "INFERRA_API_KEY": "ink_your_key" }
    }
  }
}

The key is free: sign in with a wallet at https://api.inferra.trade, no card, no email. Node 20 or newer.

Tools

Tool	What the agent gets
`get_gpu_price`	one model: USD per GPU-hour, when it is from, whether it is delayed, the state (live / warming / halt), the sources behind it, whether it is attested on chain
`compare_gpu_prices`	every model, or a subset, cheapest first, each as a multiple of the cheapest
`get_gpu_market_summary`	prices, 7-day change and weekly range per model, index health (computation, on-chain feeds, Chainlink delivery, API), the biggest mover
`get_gpu_price_history`	first, last, low, high and change over a range (1d to all), plus a thinned list of points

Every answer comes as readable text and as structured content, and every answer carries the attribution the API's licence asks for: Inferra GPU Index, https://index.inferra.trade.

Related MCP server: llm-oracle

What an agent needs to know, and is told

A halted model has no price. When fewer than three independent sources agree, the index freezes that model rather than printing a number one source could move on its own. This server answers usdPerGpuHour: null with the reason, never the last value. The state is also never delayed, on any tier.

The Free tier is 15 minutes behind. Deliberately: the board at index.inferra.trade is live, and so is the chain, but a service pricing its own product off the API gets the value 15 minutes late unless it pays. Every answer says delayed: true and gives the instant it is reporting.

It is a benchmark of offers, not a trade print. The number is a weighted quantile of what on-demand rental is being offered at, per canonical SKU (H100 80GB SXM is not H100 PCIe). Method in full: https://index.inferra.trade/methodology. Uptime and every incident: https://index.inferra.trade/status.

Configuration

Variable	Default
`INFERRA_API_KEY`		required for every tool; `ink_…` from https://api.inferra.trade
`INFERRA_API_URL`	`https://api.inferra.trade`	a self-hosted index, or a test stub
`INFERRA_TIMEOUT_MS`	`10000`	per request

Without a key the server still starts, and each tool answers with instructions for getting one. An MCP host shows a server that exits at once as an opaque failure; a readable tool error is something the user can act on.

The server makes one API call per tool call, except get_gpu_market_summary, which makes two plus one per live model, one at a time. A Free key allows 60 calls a minute, which is a lot of questions about GPU prices.

Programmatic use

import { InferraApi, createInferraMcpServer } from '@inferra-trade/mcp-server'

const api = new InferraApi({ apiKey: process.env.INFERRA_API_KEY })
const server = createInferraMcpServer({ api })
// connect it to any transport the MCP SDK provides

The answer builders (priceAnswer, compareAnswer, summaryAnswer, historyAnswer) are exported too, for anyone who wants the same text and structure inside a different tool surface.

Without this server

Nothing here is privileged. The same numbers are on https://index.inferra.trade with no key, on https://api.inferra.trade as plain JSON, and in four Solana accounts anyone can read with @inferra-trade/gpu-index or a bare RPC call. This package exists so that an agent does not have to be taught any of that first.

Licence

MIT. If you publish a number from the index, attribute it to the Inferra GPU Index and link https://index.inferra.trade so a reader can check it.

Available Tools

4 tools

compare_gpu_pricesCompare GPU pricesA

Read-onlyIdempotent

Compare current rental prices per GPU-hour across models, cheapest first, with each model's multiple of the cheapest one. Omit models to compare every model in the index (A100, H100, H200, B200). Models that are not publishing are listed without a price.

ParametersJSON Schema

Name	Required	Description	Default
`models`	No	Subset of model ids to compare. Default: all models.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral details beyond that: results are sorted cheapest-first, prices are current, and models not publishing are listed without a price. No contradiction 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.

Conciseness5/5

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

Three sentences with no filler: the first states the core purpose and ordering, the second explains the parameter default, and the third covers an edge case. All sentences earn their place.

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?

For a simple read-only comparison tool with no output schema, the description covers purpose, ordering, default behavior, and an edge case. It could add return-format expectations or explicit sibling routing, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers `models` as a subset defaulting to all, so baseline is 3. The description adds concrete model IDs (A100, H100, H200, B200) and clarifies the omission behavior, providing useful supplementary meaning beyond the schema.

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 states a specific verb ('compare'), a clear resource ('current rental prices per GPU-hour across models'), and distinct output behavior ('cheapest first, with each model's multiple of the cheapest one'). This makes it immediately distinguishable from siblings like get_gpu_price, get_gpu_price_history, and get_gpu_market_summary.

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 gives clear usage context: use this tool to compare current prices across models, and omit `models` to compare every model in the index. It does not explicitly mention alternatives or when not to use it, but the core use case is well implied.

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

get_gpu_market_summaryGPU market summaryA

Read-onlyIdempotent

One-call overview of the GPU rental market: every model's current price per GPU-hour, its 7-day change and weekly range, how many sources price it, whether its on-chain feed is fresh, plus the health of the index itself (computation, on-chain feeds, Chainlink delivery, API) and the biggest mover of the week. Use this first when asked "what do GPUs cost right now".

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the behavioral scope: it is a one-call overview and includes index health and feed freshness, which are useful beyond the structured annotations. It 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.

Conciseness5/5

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

Two sentences, no filler. The first sentence front-loads the purpose and enumerates the return contents compactly; the second gives a concrete usage trigger. Every clause adds 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?

With no parameters, no output schema, and a rich annotation set, the description carries the burden of explaining what the agent will receive. It does so thoroughly, covering price data, trend data, source counts, freshness, index health, and the biggest mover. Nothing essential is missing for calling this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is effectively complete because there is nothing to document. The description still clarifies that the tool returns a market-wide summary rather than a specific GPU price, which is the closest thing to parameter context needed here.

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 uses a specific verb and resource ('One-call overview of the GPU rental market') and enumerates exactly what is included: per-model prices, 7-day changes, weekly ranges, source counts, feed freshness, index health, and biggest mover. This clearly distinguishes it from sibling tools that focus on a single price, comparison, or history.

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 gives an explicit trigger: 'Use this first when asked "what do GPUs cost right now"'. This provides clear context for when to choose this tool, though it does not explicitly name sibling alternatives or state when not to use it.

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

get_gpu_priceGPU rental priceA

Read-onlyIdempotent

Current rental price of one GPU model in USD per GPU-hour from the Inferra GPU Index, with the timestamp, whether the value is delayed, the model state (live / warming / halt), the number of sources behind it and whether it is attested on Solana mainnet. A halted model returns no price. Models: A100, H100, H200, B200.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	GPU model id: A100, H100, H200 or B200 (case-insensitive).

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag the tool as read-only, idempotent, and non-destructive, and the description adds meaningful behavior beyond that: timestamp, delayed-value flag, model state, source count, Solana attestation, and the key rule that a halted model returns no price.

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 core purpose is front-loaded, and every clause carries useful information. The list of return characteristics and the halted-model behavior are dense but efficient, with no filler or repetition.

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?

Despite having no output schema, the description enumerates exactly what the agent should expect: price, timestamp, delay status, model state, source count, attestation, and the no-price condition. With one well-documented parameter and safety annotations, nothing essential is missing.

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%, and the schema already documents the 'model' parameter with valid values and case-insensitivity. The description repeats the allowed model IDs but adds no substantial semantics beyond the schema.

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?

States a specific verb and resource: 'Current rental price of one GPU model in USD per GPU-hour from the Inferra GPU Index.' It also distinguishes itself from siblings by focusing on a single model and a current snapshot, not comparison, history, or market summary.

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?

Provides clear context that this tool is for a current, single-GPU price lookup, which implies when to use it versus the historical and comparison tools. It does not explicitly name alternatives or say when not to use it, but the scope is unambiguous.

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

get_gpu_price_historyGPU price historyA

Read-onlyIdempotent

Price history of one model in USD per GPU-hour over a range (1d, 3d, 7d, 14d, 30d, 90d, 1y, all), with the first and last value, the change, the low and the high, and a thinned list of points. The Free API tier sees 30 days; longer ranges are clamped and the answer says so.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	GPU model id: A100, H100, H200 or B200 (case-insensitive).
`range`	No	Look-back window. Default 7d.
`maxPoints`	No	How many points to include in the structured result. Default 60.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the Free API tier is limited to 30 days, longer ranges are clamped, and the answer explicitly says so. It also discloses that the point list is thinned and specifies the output components, which goes beyond the 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?

Two sentences with no filler. The first sentence front-loads the core purpose and output contents; the second sentence adds a crucial limitation. Every word earns its place.

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?

Even though there is no output schema, the description enumerates the output components. Combined with full schema descriptions for all three parameters and the read-only/idempotent annotations, an agent has everything needed to invoke the tool correctly, including the important Free-tier clamping edge case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds extra meaning to the range parameter by explaining the Free-tier clamp behavior and 30-day visibility, and it clarifies that maxPoints produces a thinned list. These details go beyond the schema's plain property descriptions, justifying a 4.

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 resource (one GPU model), unit (USD per GPU-hour), and scope (historical range). It distinguishes the tool from siblings by specifying 'one model' and 'history,' and it enumerates the output fields (first/last value, change, low/high, thinned points), so an agent can tell it apart from price, comparison, and market summary tools without opening schemas.

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 a single-model historical price use case but never names alternatives like get_gpu_price or compare_gpu_prices, nor states when this tool should be preferred. It gives no explicit exclusions or when-not-to-use guidance, which is a gap given the sibling 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.

4 tool updatesv1.0.0Sep 21, 2026
- First observedcompare_gpu_prices
- First observedget_gpu_market_summary
- First observedget_gpu_price
- First observedget_gpu_price_history

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-09-21 19:40 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: single-model current price, cross-model price comparison, full market overview, and historical price trends. No two tools overlap in what they return, making misselection unlikely.

Naming Consistency4/5

Three of four tools follow the 'get_gpu_*' pattern, while 'compare_gpu_prices' uses a verb-object form without 'get'. This is a minor deviation, but the naming is otherwise predictable and readable.

Tool Count5/5

Four tools is well-scoped for a GPU price index server: current price, comparison, summary, and history cover the main use cases without unnecessary redundancy.

Completeness4/5

The tool surface covers the core lifecycle of price queries (individual, comparative, overview, history). A minor gap is the lack of a dedicated endpoint to list available models, though the summary and comparison tools implicitly provide this information.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
compute.pangle.online — GPU rental market B
online.pangle.compute
Live GPU rental market: 2,500+ offers across a dozen provider feeds. History, watches, limit orders.
Cloud Platforms AI & Machine Learning
251
AIsa Shopping & Marketplace AOAuth
one.aisa
Your agent needs marketplace data — what a product costs on Amazon and Google Shopping, who the sellers are, what reviewers actually complain about. **What you can ask for** • "What is this ASIN's price history, rating and seller list?" • "Who else sells this product, and at what price?" • "Pull the reviews for this product and group the complaints." • "What comes up on Google Shopping for this query in the UK?" • "Compare these products across both marketplaces." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-merchant/mcp and sign in with OAuth — there is no key to create or paste. 22 tools: Amazon products, ASIN detail and sellers; Google Shopping products, product info, sellers and reviews; live and queued forms, with raw HTML where you need it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Price the product here, then ask the same agent what the brand's site traffic or ad spend looks like — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.
E-commerce & Retail Search
271
Energy AT IT
com.energyatit.app
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Cloud Platforms Agent Orchestration Virtualization
2

Related MCP Servers

flopsindex-mcp
Cloud Platforms Finance
zeroatflops
A
license
A
quality
B
maintenance
Provides public price indices for GPU rentals (spot, on-demand, DePIN) with verify URLs, enabling agents and users to query and verify compute economics rates.
Updated 2 months ago (2026-08-01 01:29 UTC)
5
1
Apache 2.0
llm-oracle
AI & Machine Learning Developer Tools
weiseer
F
license
Not graded
quality
D
maintenance
Provides real-time LLM pricing and availability data as an MCP server, enabling AI agents to make optimal model routing decisions at inference time with cited pricing sources.
Updated 4 months ago (2026-06-01 09:28 UTC)
-
EVIDIQ Compassofficial
Research & Data Web3 & Decentralized Tech Blockchain
evidiq
F
license
Not graded
quality
B
maintenance
Provides pricing and demand intelligence for the OKX.AI agent market via MCP. It offers market rate, price guidance, competitor analysis, demand signals, and attestation tools.
Updated a month ago (2026-08-09 03:03 UTC)
1
-
Cralo
Agent Orchestration App Automation
amrnth
F
license
Not graded
quality
C
maintenance
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Updated 22 days ago (2026-08-31 05:21 UTC)
-

@inferra-trade/mcp-server

Tools

What an agent needs to know, and is told

Configuration

Programmatic use

Without this server

Licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

EVIDIQ Compassofficial