InferIndex vs Relay
A side-by-side look at the InferIndex and Relay MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose InferIndex for conversational ai work over a hosted endpoint; choose Relay for conversational ai as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose InferIndex when
- You need dedicated capabilities in the Conversational AI domain.
- You prefer a remote HTTP/SSE transport.
- You want tools like
search_models, cheapest, compare_providers.
Choose Relay when
- You need dedicated capabilities in the Conversational AI domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
RELAY_API_KEY, RELAY_BASE_URL. - You want tools like
search_models, get_model, get_pricing.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Conversational AI | Conversational AI |
| Quality signal | 57/100 · Good | 61/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | RELAY_API_KEYRELAY_BASE_URL |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 8 | 14 |
| Full listing | View InferIndex | View Relay |
Tools & capabilities
InferIndex tools 8
search_modelsFind the exact id of an LLM tracked by InferIndex from a name or partial name (e.g. 'deepseek', 'qwen3 max', 'claude opus'). Returns matching model ids and names, best match first.cheapestCheapest current API offers for one model across direct providers and aggregators, in USD per 1M tokens (input, output, blended 3:1). Stale prices, and flex/batch tiers, are excluded by default. Optional filters (context, tools, JSON, vision, region, no training on prompts, open sign-up) and usage (tokens per request, requests per day) to get an estimated cost per request and per month. Returns the winner in detail and one short line per following offer. A condition that is absent was not published by the provider, it never means "no"; a flag not listed in signals is false.compare_providersCurrent offers for one model, one line per provider and source (direct or via an aggregator), cheapest first (10 by default), with price, quantization, signals and training on prompts when published; the cheapest offer comes in detail. Pass detail: "full" for context, every published condition (data regions, sign-up) and reliability from official status pages on each offer.price_historyPrice history of one model: every offer tracked by InferIndex (daily or weekly min/max/last price in USD, or raw price changes), plus the official price of the model's lab over time. Give either days, or from/to (YYYY-MM-DD), or at (a date) for the prices in effect that day.estimate_costEstimated cost of a workload on one model at each provider: cost per request, and per month if requests_per_day is given, taking the provider's tiered pricing and prompt-cache price into account. Offers sorted by estimated cost, cheapest first: the cheapest in detail, then one short line per offer with its estimated cost.list_gpusGPU types whose rental price InferIndex tracks (H100, A100, L40S…), with the lowest price per GPU per hour in USD for each tier (guaranteed, community, spot) and the number of GPUs of that configuration. Prices are per GPU per hour, as published by each provider, and dated. Tiers are different products and are never compared with each other.gpu_rentalsRental offers for one GPU type: provider, price in USD per GPU per hour, number of GPUs in the published configuration, billing and region when published. One block per tier (guaranteed, community, spot), each with its own cheapest offer, also given per configuration (cheapest_by_gpu_count: the price per GPU of a single GPU and of a multi-GPU node are not comparable); tiers are never compared with each other. guaranteed: capacity the provider presents as not interrupted; community: third-party hosts; spot: interruptible capacity. Prices are as published by the provider, and dated. Get the GPU id from list_gpus.self_host_or_apiIs it cheaper to host an open-weights model yourself on rented GPUs, or to use the cheapest API offer? Returns a one-sentence verdict (headline) and the numbers behind it: the break-even volume in million tokens per day, the throughput the whole configuration must deliver for self-hosting to cost less (required_tokens_per_second: compare it with what your setup does), the break-even utilization when a throughput is known, the GPU configuration and its hourly price, and what the verdict rests on (confidence). Without a volume you still get the verdict and the break-even volume. It is an estimate: the throughput is a published measurement (measured), an estimate scaled from one (derived; estimated for a wide range), or a published minimum (lower_bound: a floor, valid for requests of up to 2,048 tokens in total, that can show self-hosting wins, never that the API is cheaper); or you give your own tokens_per_second. When no published figure decides, the headline gives the break-even volume and the required throughput, to compare with yours, rather than a yes or no, and may point out a dearer setup that published figures do decide (settled_alternative: for comparison, not a recommendation). headline_kind and headline_values give the headline as fields. It declines to give a number (status refused, with a reason) when it cannot do so reliably, for example a closed model, weights that do not fit the requested GPU, or a GPU nobody rents. Hardware rental only: the hourly price the provider publishes for the machine. It does not count the engineering to deploy and run the model, monitoring, redundancy, start-up time, or storage and network costs billed separately.
Relay tools 14
search_modelsLists Relay models by tag and/or text. Common tags: text-to-image, image-to-image, text-to-video, image-to-video, video-to-video, text-to-speech, speech-to-text, text-to-text, text-to-embedding. image-to-image also lists every image model that takes an input image. Returns name, tag, route and accepts (input media the model takes, e.g. ["image"]; [] for none) per model (at most 50). Then call get_model with a name for its input schema.get_modelReturns one model's route, request_schema (what run_model's input must follow), request_example, pricing and availability. Then call run_model with an input shaped like request_example.get_pricingReturns Relay's public list prices (USD), optionally for one model, plus media_storage: the per-file fees of the store_output / upload retention SKUs (relay1d, relay7d, …). Then estimate_cost for a number.estimate_costEstimates the USD cost of a call from the public price list: an estimate, not an invoice (the bill uses provider-reported usage and any custom pricing on your account). Pass only the usage fields the model's billing_type (see get_model or get_pricing) reads: per_token: input_tokens, output_tokens, cached_input_tokens; per_image: image_count, resolution_tier; per_second_video: duration_seconds, quality_mode, sound; per_second_audio: duration_seconds; per_character: character_count; per_media_token: media_input_tokens, media_output_tokens. Add store_output / retention / file_count for storage fees.run_modelRuns any Relay model by name (billed to your key). input follows get_model's request_schema (request_example runs as is). Every model whose schema takes async (image, video, audio) is submitted as a task: it waits up to 45 s, past that it returns a task_id — do not resubmit, call check_task. Chat models answer inline. Result links expire 1 h after completion unless store_output names a media_storage SKU from get_pricing. Pass an idempotency_key if you may retry the same submit. Needs a Relay credential.check_taskChecks a task run_model returned (no key needed: the task_id is the capability). Waits up to 30 s for it to finish; returns the result when completed, else its status: then call check_task again, never resubmit. Task results are kept 1 h after they finish.upload_fileHosts an image, video or audio file on Relay and returns its url: pass that url to any *_url input of run_model. Give exactly one of path (local server only, ≤ 100 MB), base64 (≤ 4 MB) or url (a public link Relay copies). retention: relay1h (default, free within a daily quota) or a media_storage SKU from get_pricing. Needs a Relay credential.list_workflowsList Relay's workflow templates: multi-step pipelines (e.g. script → voiceover) run as one call. Each entry has workflow_id, input_schema and its steps (step_id + model). Run one with run_workflow; inputs follow input_schema.run_workflowStart a workflow run (one submit) and wait up to wait_seconds (≤ 45) for it to finish. Completed → the final output; still running → run_id: call check_workflow_run with it, never resubmit (a new run bills again). Each step is billed as an ordinary request. webhook_url gets ONE signed workflow.completed / workflow.failed delivery when the run ends. Get workflow_id and the inputs shape from list_workflows. Needs a Relay credential.check_workflow_runPoll a workflow run by run_id, waiting up to wait_seconds (≤ 30) for it to end. Completed → the final output; failed / cancelled → the error; still running → its steps so far: call check_workflow_run again. No key needed: the run_id is the access token.cancel_workflow_runCancel a workflow run. Cancels between steps only: a step already running completes and bills. A run that has already ended answers WORKFLOW_RUN_NOT_CANCELLABLE. Needs a Relay credential.get_creditsRead the account's credit balance, active promo credits and consumption. Needs a dashboard JWT or a custom-tier superkey; a plain inference key gets PERMISSION_DENIED (403). Needs a Relay credential.- +2 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
InferIndex
{
"mcpServers": {
"inferindex": {
"url": "https://mcp.inferindex.dev/mcp"
}
}
}
Relay
{
"mcpServers": {
"relay-4": {
"command": "npx",
"args": [
"-y",
"@relaygpu/mcp"
],
"env": {
"RELAY_API_KEY": "YOUR_RELAY_API_KEY_HERE",
"RELAY_BASE_URL": "YOUR_RELAY_BASE_URL_HERE"
}
}
}
}
Frequently asked questions
InferIndex is categorized under Conversational AI and uses a remote HTTP/SSE transport. Relay belongs to Conversational AI and uses a local stdio subprocess. Pick InferIndex for conversational ai work and Relay for conversational ai.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
InferIndex has no declared pricing — check the project's own site. Relay has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add inferindex and relay-4 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, InferIndex has a quality signal of 57/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Relay has 61/100 (Good) with 1 views, 0 installs and 0 GitHub stars.