Skip to main content
Glama
Sign In
OpenGPU-Network

relaygpu-mcp

Official
by OpenGPU-Network
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Run a Relay model

run_model

Run any Relay model by name to generate text, images, video, audio, or embeddings. Long-running media jobs return a task_id to poll instead of resubmitting.

Instructions

Runs 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.

Input Schema

NameRequiredDescriptionDefault
inputYesRequest body per get_model's request_schema, without model, store_output or async (run_model sets them). Pass media as *_url links (upload_file makes one). mode: direct (Relay's providers, the default) or opengpu (the decentralized network, priced separately).
modelYesExact model name from search_models / get_model, e.g. google/gemini-nano-banana-2.1.
store_outputNoKeep result media longer: a media_storage SKU from get_pricing (e.g. relay7d, adds its per-file fee), or provider (default, 1 h).
wait_secondsNoSeconds to wait for it to finish (0–45, default 45); 0 returns the task_id at once.
inline_imagesNoAlso return images ≤ 1 MB as image content blocks (default false: links only).
idempotency_keyNoYour key for this submit (task models; a chat answer is not replayed): a retry with the same key and the same input replays the first task instead of starting (and billing) a new one; the same key with a changed input is refused with 422 IDEMPOTENCY_KEY_REUSED.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it's a non-read-only, open-world, non-idempotent call; the description adds the material behavior: billing to the caller's key, a 45 s wait ceiling before returning a task_id, inline vs. task submission by schema type, 1 h link expiry, and the idempotency replay/422 semantics. That is substantially more than the annotations provide.

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?

It is front-loaded with the core action and scope, and every clause carries operational content, but the prose is dense and run-on ('45 s', '1 h', SKU references) in places. Slightly more sentence splitting would improve scanability without losing 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 6-parameter, open-world, mutating tool with no output schema, the description covers what matters: how to build input, what the return looks like (inline answer vs. task_id), how long result links last, and how to extend retention. Nothing an agent needs before invoking it 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?

With 100% schema coverage the schema already documents each parameter, so the baseline is 3. The description still adds cross-tool guidance for constructing `input` (follow get_model's request_schema, request_example runs as is) and ties store_output to a media_storage SKU from get_pricing, which the schema alone does not connect.

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 opening sentence states a specific verb and resource ('Runs any Relay model by name') and immediately marks it as billed, which distinguishes it from the free/metadata siblings like search_models and get_model. The model-by-name framing implicitly separates it from run_workflow.

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

Usage Guidelines5/5

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

It names concrete alternatives and the conditions selecting them: call check_task instead of resubmitting a timed-out async task, pass idempotency_key if you may retry, and use store_output/get_pricing when results must outlive the 1 h expiry. It also states the credential prerequisite, so no routing decision is left to inference.

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

Deploy Server

Other Tools