How do I use Theta EdgeCloud On-Demand API 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., "@Theta EdgeCloud On-Demand API MCP Server Generate an image of a cat in space" 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.

Theta EdgeCloud On-Demand API MCP Server

Official

by thetatoken

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Theta EdgeCloud On-Demand API MCP Server

Official Model Context Protocol (MCP) server for Theta EdgeCloud's On-Demand Model APIs. Access 20+ AI models directly from Claude Desktop, Claude Code, Cursor, and other MCP-compatible clients.

Features

20+ AI Models - Image generation, audio transcription, LLMs, and more
Simple Integration - Works with any MCP-compatible client
Sync & Async - Get results immediately or poll for long-running tasks
File Uploads - Upload local files for processing

Related MCP server: imagine-mcp

Installation

For Claude Desktop

Add to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "theta-edgecloud": {
      "command": "npx",
      "args": ["@thetalabs/on-demand-api-mcp"],
      "env": {
        "THETA_API_KEY": "your-api-key-here"
      }
    }
  }
}

For Claude Code

claude mcp add theta-edgecloud -e THETA_API_KEY=your-api-key-here -- npx @thetalabs/on-demand-api-mcp

Replace your-api-key-here with your actual API key.

Verify it's working:

claude mcp list

You should see theta-edgecloud with status ✓ Connected.

Getting Your API Key

Visit https://www.thetaedgecloud.com/dashboard/api-keys
Create a new API key
Add it to your MCP configuration

Available Tools

`list_services`

Discover available AI models and their capabilities.

list_services()
list_services(category="image")

`infer`

Run AI inference on any model.

# Transcribe audio
infer(service="whisper", input={"audio_filename": "https://example.com/audio.wav"})

# Generate an image
infer(service="flux-1-schnell", input={"prompt": "A sunset over mountains"})

# Chat with an LLM
infer(service="llama-3-1-8b", input={"messages": [{"role": "user", "content": "Hello!"}]})

Parameters:

service (required) - Service alias (e.g., "whisper", "flux-1-schnell")
input (required) - Input parameters (varies by service)
wait (optional) - Seconds to wait for result (0-60, default 30)
variant (optional) - Model variant if available (e.g., "turbo")

`get_request_status`

Check the status of an async inference request.

get_request_status(request_id="infer_abc123")

`get_upload_url`

Get a presigned URL to upload a local file.

get_upload_url(service="whisper", input_field="audio_filename")

Example Conversations

User: "What AI models are available on Theta EdgeCloud?"

Claude: calls list_services() "Here are the available models..."

User: "Transcribe this audio file: https://example.com/meeting.wav"

Claude: calls infer(service="whisper", input={"audio_filename": "..."}) "Here's the transcription..."

User: "Generate an image of a cyberpunk cityscape"

Claude: calls infer(service="flux-1-schnell", input={"prompt": "cyberpunk cityscape at night, neon lights"}) "Here's your image: [URL]"

Configuration

Environment Variables

Variable	Description	Required
`THETA_API_KEY`	Your Theta EdgeCloud API key	Yes
`THETA_API_BASE_URL`	API base URL (default: https://api.thetaedgecloud.com)	No

Development

# Clone the repo
git clone https://github.com/thetalabs/on-demand-api-mcp
cd on-demand-api-mcp

# Install dependencies
npm install

# Build
npm run build

# Run locally
THETA_API_KEY=your-key npm start

Publishing

1. Publish to npm

# Login to npm (if not already)
npm login

# Publish the package
npm publish --access public

The package will be available as @thetalabs/on-demand-api-mcp on npm.

2. Register with MCP Registry

The MCP Registry is the official directory for MCP servers. Registering makes the server discoverable by MCP-compatible clients.

# Clone the registry repo
git clone https://github.com/modelcontextprotocol/registry
cd registry

# Build the publisher tool
make publisher

# Publish your server (requires authentication)
./bin/mcp-publisher --help

Namespace options:

Namespace Type	Example	Verification
GitHub-based	`io.github.thetalabs/on-demand-api-mcp`	GitHub OAuth
Domain-based	`thetaedgecloud.com/on-demand-api-mcp`	DNS or HTTP challenge

3. Automated Publishing (CI/CD)

For GitHub Actions, use GitHub OIDC authentication:

# .github/workflows/publish.yml
name: Publish to MCP Registry
on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci && npm run build
      - run: npm publish --access public
      # Add MCP registry publishing step here

License

MIT

Available Tools

4 tools

get_request_statusA

Check the status of an inference request. Use this to get results of async requests.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	The inference request ID (returned from infer tool)

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the transparency burden. It communicates that this is a read/status retrieval operation rather than a mutation, and that it relates to async requests. It does not disclose polling behavior, possible statuses, or whether the request must be complete, but it provides a reasonable baseline.

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 short sentences, no filler, and the key purpose is front-loaded. Every word earns its place.

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

Completeness3/5

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

For a single-parameter tool, the description covers the essential use case but lacks detail on what the status response looks like, especially since there is no output schema. It is adequate but not fully complete for an agent that may need to interpret the result.

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?

The schema already documents request_id fully, including its source ('returned from infer tool'). The description adds no parameter-specific meaning, but since schema coverage is 100%, the baseline of 3 applies.

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

Purpose4/5

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

The description clearly states the action ('Check the status') and the resource ('an inference request'), and adds that it retrieves results of async requests. It does not explicitly name sibling tools, but the async framing distinguishes it enough from infer.

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 after an async inference request to get its results. It does not explicitly state when not to use it or name alternatives, but the intended scenario is clear.

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

get_upload_urlA

Get a presigned URL to upload a file for inference. Use this when you need to upload a local file (audio, image, etc.) before running inference.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Service alias (e.g., "whisper", "sdxl")
`input_field`	Yes	Which input field needs the file (e.g., "audio_filename", "image")

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It mentions the action (get a presigned URL) and its role in the workflow, but it doesn't explain the nature of the URL (e.g., temporary, one-time), potential authentication requirements, or what happens after upload. It also doesn't describe the expected response format. While the core purpose is clear, the absence of these details leaves the agent without full behavioral context. A score of 3 reflects that the description is adequate but lacks rich transparency.

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 compact, consisting of two sentences with no extraneous content. The primary action is front-loaded ('Get a presigned URL'), followed immediately by the usage condition. Every sentence contributes meaning, and there is no repetition of schema or annotation details. This exemplifies excellent conciseness and logical structure.

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 two-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use it, and its role in the inference workflow. It could elaborate on the return value (the URL) or prerequisites, but these are not critical for a straightforward call. Given the tool's simplicity and the guidance it provides, it is nearly complete; a 4 is justified.

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?

The schema documents both parameters ('service' and 'input_field') with descriptions, achieving 100% coverage. The description adds no parameter-specific information beyond what the schema already provides; it mentions examples like 'audio, image' but doesn't clarify how those map to the parameters. Following the guideline that high schema coverage yields a baseline of 3, the description adds no extra value, so a 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 a specific action ('Get a presigned URL') and the purpose ('to upload a file for inference'), distinguishing it from siblings like 'infer' (which runs inference) and 'list_services'. The phrase 'for inference' ties it to the workflow, making the tool's role unambiguous. It avoids tautology and is specific about the resource (a presigned URL).

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 explicitly says 'Use this when you need to upload a local file... before running inference.' This provides a clear condition for when to invoke the tool. It doesn't explicitly mention alternatives or when not to use it, but the context of siblings (infer, list_services) makes the appropriate use apparent. It's slightly shy of a 5 because it doesn't explicitly state exclusions or directly contrast with siblings, but it offers sufficient guidance.

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

inferB

Run AI inference on a Theta EdgeCloud model. Supports image generation, audio transcription, text generation, and more. IMPORTANT: Call list_services first to see available services and their required inputs.

ParametersJSON Schema

Name	Required	Description
`wait`	No	Seconds to wait for result (0-60, default 30). Use 0 for async processing.
`input`	Yes	Input parameters for the model (varies by service)
`service`	Yes	Service alias (e.g., "whisper"). Use list_services to see all available options.
`variant`	No	Model variant to use (e.g., "turbo", "large-v3") if available
`prediction`	No	Specific prediction method if service has multiple (usually not needed)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It mentions the list_services prerequisite but omits async behavior (wait=0), result retrieval via get_request_status, timeout handling, and output format. These are significant gaps for an inference tool that suports multiple models.

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?

Two sentences with a clear purpose and a critical prerequisite. The 'IMPORTANT' caps are slightly noisy but the content is focused and front-loaded. No wasted words.

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

Completeness2/5

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

For a 5-param tool with nested input and no output schema or annotations, the description doesn't explain the response format, async workflow, or how to retrieve results. The list_services note helps, but the agent is left without a complete picture of how to correctly invoke and consume this tool.

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%, so baseline 3 applies. The description's list of supported tasks (image gen, transcription, text gen) hints at what input may contain, but it adds no concrete parameter-level details beyond what the schema already states. Service param already points to list_services.

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

Purpose4/5

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

States a specific verb and resource: 'Run AI inference on a Theta EdgeCloud model.' Lists supported task types (image generation, audio transcription, text generation). Sibling names (list_services, get_request_status, get_upload_url) make the distinction clear implicitly, though the description does not explicitly name them.

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?

Explicitly instructs the agent to 'Call list_services first to see available services and their required inputs,' which is a clear prerequisite and routing to a sibling tool. It does not discuss exclusions like when to use get_request_status instead, so it's a bit incomplete on alternatives.

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

list_servicesA

List all available AI models and services on Theta EdgeCloud. Returns service names, descriptions, and input/output specifications.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional filter by category (e.g., "image", "audio", "text")

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the operation (listing) and what is returned (service names, descriptions, input/output specs). It does not explicitly state there are no side effects or permissions required, but the read-only nature is strongly implied by 'list.' This is adequate for a simple discovery tool.

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 fluff, and the primary action is front-loaded. The return-value detail is useful and placed second. Every sentence earns its 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 list tool with one optional parameter and no output schema, the description explains what it does and what the response contains. It could mention that the category parameter filters results or that the tool is useful before calling infer, but these are somewhat inferable. The definition is effectively complete for its simplicity.

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?

The schema has 100% description coverage for the only parameter, category, including examples. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.

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: 'List all available AI models and services on Theta EdgeCloud.' It also states the return payload (service names, descriptions, input/output specifications). This clearly distinguishes it from siblings like infer, get_request_status, and get_upload_url.

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 this is a discovery tool for enumerating available services, but it does not explicitly state when to use it versus alternatives or mention relationships with sibling tools. Usage context is clear enough from the name and description, but no direct exclusions or alternative conditions are given.

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 updatesv0.1.7Aug 30, 2026
- First observedget_request_status
- First observedget_upload_url
- First observedinfer
- First observedlist_services

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/5.0

Scored 2026-08-30 12:25 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: listing services, running inference, checking request status, and obtaining upload URLs. There is no meaningful overlap or ambiguity between them.

Naming Consistency4/5

Most tools follow a verb_noun pattern (list_services, get_request_status, get_upload_url), but infer is a single verb without an object. This is a minor deviation and the overall naming is still clear and predictable.

Tool Count5/5

Four tools is well-scoped for this server's purpose: service discovery, inference execution, asynchronous status checking, and upload support. Each tool earns its place without unnecessary bloat.

Completeness5/5

The tool surface covers the full lifecycle of an on-demand inference request: discover services, upload inputs when needed, trigger inference, and poll for results. No obvious gaps exist for the stated domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
mcp-seedream-proOAuth
io.github.AceDataCloud
MCP server for ByteDance Seedream AI image generation
Image & Video Processing Multimedia Processing
23

Related MCP Servers

universal-image-mcp
AI & Machine Learning Image & Video Processing
manu-mishra
A
license
A
quality
D
maintenance
MCP server for multi-provider AI image generation (AWS Bedrock, OpenAI, Google Gemini) enabling image generation, transformation, and editing through a unified interface.
Updated 6 months ago (2026-03-04 19:20 UTC)
4
1
MIT
imagine-mcp
Image & Video Processing AI & Machine Learning
n24q02m
A
license
A
quality
F
maintenance
Production-grade MCP server for image and video understanding and generation across Gemini, OpenAI, and Grok.
Updated 2 days ago (2026-09-13 07:41 UTC)
5
4
Apache 2.0
Wiro MCP Serverofficial
AI & Machine Learning Developer Tools
wiroai
A
license
A
quality
C
maintenance
Official MCP server for Wiro AI that provides access to hundreds of AI models for generation, editing, and analysis from any MCP-compatible assistant.
Updated 16 days ago (2026-08-30 10:56 UTC)
13
98 npm
4
MIT
KieAI MCP
Image & Video Processing Audio Processing Multimedia Processing
paione-ai
A
license
A
quality
C
maintenance
MCP server for AI-powered media generation: images, videos, audio, and upscaling using 99 AI models.
Updated 6 months ago (2026-03-21 15:55 UTC)
6
MIT

Theta EdgeCloud On-Demand API MCP Server

Features

Installation

For Claude Desktop

For Claude Code

Getting Your API Key

Available Tools

list_services

infer

get_request_status

get_upload_url

Example Conversations

Configuration

Environment Variables

Development

Publishing

1. Publish to npm

2. Register with MCP Registry

3. Automated Publishing (CI/CD)

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Wiro MCP Serverofficial

`list_services`

`infer`

`get_request_status`

`get_upload_url`