30 GPU-powered AI services as MCP tools — LLMs, image generation, audio, video, embeddings, reranking, PDF parsing, NSFW detection & more. x402 native for autonomous AI agents: pay per request on-chain with USDC on Base L2. No API keys. No accounts.
GPU-Bridge is a unified GPU inference API with native x402 support — the open payment protocol that allows AI agents to autonomously pay for compute with USDC on Base L2. No API keys, no accounts, no human intervention required.
This MCP server exposes all 30 GPU-Bridge services as Model Context Protocol tools, giving Claude (and any MCP-compatible AI) direct access to GPU inference.
Related MCP server: hive-mcp-compute
Visit gpubridge.io and grab a free API key, or use the x402 protocol for keyless agent payments.
claude_desktop_config.jsonmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"gpu-bridge": {
"command": "npx",
"args": ["-y", "@gpu-bridge/mcp-server"],
"env": {
"GPUBRIDGE_API_KEY": "your_api_key_here"
}
}
}
}That's it. Claude now has access to 30 GPU-powered AI services.
gpu_runRun any GPU-Bridge service. The primary tool for executing AI tasks.
Parameters:
service (string) — Service key (e.g., "llm-4090", "flux-schnell", "whisper-l4")
input (object) — Service-specific input parameters
priority (string) — Optional: "fast" (lowest latency) or "cheap" (lowest cost)gpu_catalogGet the full catalog of available services with pricing and capabilities.
gpu_estimateEstimate cost before running a service. No authentication required.
gpu_statusCheck the status of a job and retrieve results.
gpu_balanceCheck your current balance, daily spend, and volume discount tier.
Service ID | Description | Notes |
| General purpose LLM | Sub-second via Groq |
| Maximum capability LLM | Largest models |
| Ultra-fast, low cost LLM | Budget option |
| Code generation | Optimized for code |
| Streaming LLM responses | Real-time output |
Service ID | Description | Notes |
| FLUX.1 Schnell | Fast, 4-step generation |
| FLUX.1 Dev | High quality |
| Stable Diffusion XL | Versatile |
| Stable Diffusion 3.5 | Latest SD model |
| Image-to-image | Style transfer, editing |
Service ID | Description | Notes |
| Visual Q&A | Image understanding |
| Text extraction (OCR) | Multi-language |
| Background removal | Instant |
| Image captioning | Auto-describe images |
| Content moderation | NSFW classification |
Service ID | Description | Notes |
| Fast transcription | Sub-second |
| High accuracy transcription | Large files |
| Speaker diarization | Who said what |
Service ID | Description | Notes |
| Voice cloning TTS | 40+ voices |
| Ultra-fast TTS | Lowest latency |
| Expressive TTS | Emotion, laughter |
Service ID | Description | Notes |
| Music generation | Text-to-music |
| Sound effects | Text-to-SFX |
Service ID | Description | Notes |
| Text embeddings | Multilingual |
| Code embeddings | For code search |
| Document reranking | Jina, sub-second |
Service ID | Description | Notes |
| Text-to-video | AnimateDiff |
| Video upscaling | Up to 4K |
Service ID | Description | Notes |
| Document parsing | PDF/DOCX to text |
GPU-Bridge supports the x402 payment protocol, enabling truly autonomous AI agents to pay for compute without human intervention.
Agent Request → GPU-Bridge returns HTTP 402 Payment Required
↓
Agent pays USDC on Base L2 (gas < $0.01, settles in 2s)
↓
Agent retries with payment proof → GPU-Bridge executes and returns resultfrom x402.client import PaymentClient
client = PaymentClient(private_key="0x...", chain="base")
response = client.request(
"POST",
"https://api.gpubridge.io/v1/run",
json={
"service": "flux-schnell",
"input": {"prompt": "A robot painting on a canvas", "steps": 4}
}
)
print(response.json())Category | Starting From |
LLMs | $0.003/1K tokens |
Image Generation | $0.01/image |
Speech-to-Text | $0.005/minute |
Text-to-Speech | $0.005/1K chars |
Embeddings | $0.0001/1K tokens |
Reranking | $0.001/query |
PDF Parsing | $0.005/document |
All prices in USD. x402 payments in USDC on Base L2.
Website: gpubridge.io
Docs: gpubridge.io/docs
Catalog: gpubridge.io/catalog
GitHub: github.com/gpu-bridge
MIT © Healthtech Capital LLC
Check GPU-Bridge credit balance, daily spend, volume discount tier, and job history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists four specific data categories returned (good), but omits operational details: no mention of authentication requirements, rate limits, pagination for job history, or whether data is real-time vs cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action verb. No filler words. Every clause specifies a distinct data category returned. Optimal density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless account-query tool without output schema, listing the four return data categories provides adequate completeness. Missing only operational metadata (Auth, TTL) which would be nice-to-have but not critical for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per schema. With no parameters to document, baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Check' and concrete resources listed (credit balance, daily spend, volume discount tier, job history). While distinct from siblings (gpu_run, gpu_status, etc.) by nature of the data, the description does not explicitly differentiate usage scopes in text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus siblings (e.g., 'Check this before running jobs with gpu_run' or 'For current job status use gpu_status'). Lacks prerequisites or conditional logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available GPU-Bridge services with pricing and model info. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully reveals authentication requirements and return data categories (pricing, model info). Missing operational details like rate limits, caching behavior, or pagination for large catalogs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total with zero waste. Front-loaded with primary purpose ('List all available...'), followed by critical behavioral constraint ('No authentication required'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a simple catalog tool. Mentions return data content (pricing/model info) to compensate for missing output schema. Could be improved by indicating return format (array vs object) or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, meeting the baseline score of 4 per rubric. Description appropriately focuses on behavioral semantics and return data rather than inventing parameter documentation where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'List' with resource 'GPU-Bridge services' and scope details 'pricing and model info'. Effectively distinguishes from operational siblings (gpu_run, gpu_balance) by positioning as a catalog/browse function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'No authentication required' which provides a usage constraint, implying when it can be called safely. However, lacks explicit when-to-use guidance relative to siblings (e.g., 'use before gpu_run to select a model') or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the cost of a GPU-Bridge service before running it. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service key (e.g. llm-4090, image-4090) | |
| seconds | No | Estimated runtime in seconds (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully adds the authentication requirement (no auth needed) which annotations would typically cover. However, missing: idempotency, rate limits, what the estimate returns (format/currency), and error behaviors for invalid service keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First establishes purpose and timing relative to execution; second states auth requirement. Every word earns its place. Well front-loaded with action verb leading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has simple 2-parameter schema with full coverage, but no output schema exists. Description fails to specify what the estimate returns (numeric value? object? currency units?). Given no annotations and no output schema, the description should have disclosed return format. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions and examples (e.g., 'llm-4090'). Description does not need to repeat parameter definitions per calibration guidelines. Baseline 3 is appropriate as description adds no parameter syntax beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Estimate' with resource 'cost' and scope 'GPU-Bridge service'. The phrase 'before running it' clearly distinguishes this from sibling gpu_run, implying this is a pre-flight check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'before running it' implying workflow order (use this prior to gpu_run). Explicitly notes 'No authentication required' which is a critical usage constraint. However, does not explicitly name gpu_run as the alternative or describe when NOT to use it (e.g., when you need actual execution).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any GPU-Bridge AI service. 30 services available: LLM inference (sub-second), image generation (FLUX, SD3.5), video generation, video enhancement (up to 4K), speech-to-text (Whisper, <1s), TTS (40+ voices), music generation, voice cloning, embeddings, document reranking (Jina), OCR, PDF/document parsing, NSFW detection, image captioning, visual Q&A, background removal, face restoration, upscaling, stickers, and more. Use gpu_catalog to see all available services.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service key. Common ones: llm-4090 (text), image-4090 (image), video (video), whisper-l4 (speech-to-text), tts-l4 (text-to-speech), embedding-l4 (embeddings), rembg-l4 (bg removal), upscale-l4 (upscale), ocr (text extraction), caption (image caption), face-restore, musicgen-l4, llava-4090 (visual Q&A), sticker, whisperx (diarized STT), bark (expressive TTS), voice-clone, photomaker, ad-inpaint, animate, image-variation, inpaint, controlnet, clip, segmentation, rerank (document reranking), nsfw-detect (content moderation), video-enhance (video upscaling), pdf-parse (document parsing) | |
| input | Yes | Service-specific input. Examples: LLM {"prompt":"...","max_tokens":512,"model":"llama-3.3-70b-versatile"}, Image {"prompt":"..."}, Whisper {"audio_url":"https://..."}, TTS {"text":"...","voice":"af_alloy"}, Embedding {"text":"..."}, OCR/Rembg/Upscale/Caption {"image_url":"https://..."}, Video {"prompt":"..."} | |
| priority | No | Routing priority. "fast" = lowest latency (default), "cheap" = lowest cost. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable performance context ('sub-second', '<1s', 'fast' vs 'cheap' routing) but omits critical operational details: authentication requirements, error handling patterns, cost implications, and whether operations are idempotent or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and front-loaded with main purpose. The exhaustive service list (30 items) is necessary given the tool's polymorphic nature. Ends with actionable sibling reference. Efficient sentence structure with minimal filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complex multi-service tool with nested input objects but no output schema. Description comprehensively covers input capabilities and service types but fails to describe return values, error formats, or rate limiting—critical gaps given the absence of structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed examples (especially for 'input' object's polymorphic structure). Description adds high-level categorization of services but largely overlaps with schema enumerations; does not significantly augment parameter understanding beyond schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Run) + resource (GPU-Bridge AI service) with explicit scope (30 services). Distinguishes from siblings by directing users to gpu_catalog for discovery while this handles execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to 'use gpu_catalog to see all available services,' establishing clear workflow (catalog for discovery, run for execution). Could strengthen by noting gpu_estimate/balance for cost checking before execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a GPU-Bridge job and retrieve results.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID returned by gpu_run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'retrieve results' indicating output behavior, but omits critical async details: whether this blocks, if repeated polling is expected, result expiration, or what status values (e.g., running, completed, failed) are possible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with no filler. Information is front-loaded (action + subject + outcome). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool, but lacking given the absence of an output schema. For a status retrieval tool, describing the possible status states or result payload structure would significantly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with job_id well-documented. The description mentions 'GPU-Bridge job' which loosely contextualizes the parameter, but adds no syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Check') and resource ('GPU-Bridge job'), plus outcome ('retrieve results'). However, it does not explicitly differentiate from siblings like gpu_run or gpu_catalog within the description text, relying instead on the tool name to signal its polling/retrieval role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives, or that it requires a job_id from gpu_run first. The schema parameter description mentions it returns job IDs from gpu_run, but the main description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0gpu_balancegpu_cataloggpu_estimategpu_rungpu_statusEach tool has a clearly distinct purpose with no overlap: balance checking, catalog listing, cost estimation, job execution, and status monitoring. The descriptions make it unambiguous which tool to use for each task, preventing misselection.
All tools follow a consistent 'gpu_' prefix with descriptive suffixes (balance, catalog, estimate, run, status). This verb_noun pattern is uniform throughout, making the tool set predictable and easy to navigate.
With 5 tools, this server is well-scoped for its GPU service management purpose. Each tool earns its place by covering essential operations: account management, service discovery, cost estimation, job execution, and status tracking, without being overly sparse or bloated.
The tool set provides complete coverage for the GPU service lifecycle: discover services (catalog), estimate costs, run jobs, monitor status, and manage account (balance). No obvious gaps exist; agents can perform end-to-end workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
run any ai model. compose agents, stack knowledge, connect tools. one api, pay per run.
17-model LLM gateway + 350+ data/KYB/sanctions tools. Pay-per-call USDC via x402, no API key.
30 pay-per-call APIs for AI agents: compliance, trade, safety, web, data. USDC on Base via x402.
AI API for marketing, content and outreach. 22 endpoints. Pay with USDC on Base via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gpu-bridge/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
