Symbioza

npx add-mcp 'https://symbioza.dev/mcp'

A job to run.A limit to respect.

Use Symbioza for containerized GPU work that has a defined end and files to return. Your agent prepares the job; Symbioza manages the compute.

Send a workload.Skip the machine hunt.

Good for finite GPU jobs

Training, evaluation and batch inference with your container, command, accessible data and a clear output contract.

Choose a different tool for live services

This workflow is not a persistent web server, an interactive workstation or a promise of low-latency inference. It is a job that runs and ends.

THE JOB CONTRACT

YOU DEFINE The work + limit

WE HANDLE Cloud execution

Declare genuine compatibility requirements. Your agent does not need to choose a provider or shop for a GPU.

Make each step explicit.

Use the tools exposed by your connected client as the current schema authority.

Tool	What your agent should do
describeDataset	Inspect a reachable dataset URL and prepare its metadata. Check that the URL is authorized and suitable for the job.
estimateExecution NO COMPUTE BOOKED	Send the intended job spec, with no spending limit needed. Show the estimate and anything missing, then ask for the limit and estimate again with it. With nothing measured about the job it is not a quote: it gives the price of each hour of running. An estimate is not a fixed price or a reservation.
submitJob PAID STEP	Review the job and limit with the user, then submit with the estimate digest and request identifier required by the tool. Prepaid credit is required.
getStatus / listJobs	Save the execution identifier and check progress later from the same account. The original client session does not need to stay open.
listSecrets	Read the names and types of the user's saved secrets, never a value. Attach a set by name in the job's secrets. When access is missing, give the user the Symbioza setup link the estimate returns, never one you compose, and continue once the set is listed.
getArtifact	Inspect available files and delivery state. Download the outputs and verify their hashes. Check whether the charge is still provisional.
cancelJob	Request cancellation when needed. Used compute can still be charged, within the job’s total spending limit.

Connector and submission details

Symbioza runs a containerized GPU job on a rented cloud machine under a hard dollar ceiling and collects available artifacts. An agent submits an image, a command and a budget through one MCP connector. Symbioza selects compute, runs the job and reports output delivery and billing separately. Recovery depends on job policy, available compute, remaining budget and compatible checkpoint support.

Connector: https://symbioza.dev/mcp.

Three required fields: image, command and budgetUsd, which is required to submit and optional to estimate: estimate first, then ask the user for it. The gpu block is optional: every job runs on a GPU machine Symbioza sizes. Declare it only for gpu.minCudaVersion or an evidenced floor.

Send the reviewed spec with specDigest from the estimate and a stable clientRequestId. A changed spec needs a fresh estimate. Keep the same clientRequestId for every resend of the same submission: a resend returns the original job, whatever became of it. To run a failed, cancelled or lost job again, send retryOf set to the executionId of that job, with a new clientRequestId.

Do not ask the user to predict runtime. The limit is derived from the budget and booked machine rate, with a cap of 48 hours (172800 seconds). The budget usually binds first. maxRuntimeSeconds is optional and can set a shorter cap.

A retry on a larger machine must fit the remaining budgetUsd and job policy. With pinHost, no second machine is bought. Recovery and completion are not guaranteed.

Paid submission requires a prepaid balance. Top up after reviewing your estimate. Credit can be added in any whole-dollar amount within Symbioza's limits. When the estimate's coversThisJob is false, shortfallUsd is the credit the job still needs and topupUrl is prefilled with it: give the user that link as returned. A checkout that opened is not credit; estimate again before submitting.

Credentials never go in env, which is non-sensitive configuration stored in clear with the job. The user saves them as Secrets at symbioza.dev/app/secrets; attach a set by name in secrets. listSecrets shows names and types only. When access is missing, estimateExecution and submitJob return a Symbioza setup link: give the user that link, never compose one, and continue only once listSecrets shows the set.

What the agent must keep straight.

The budget covers the whole job.

Retries share the same total spending limit. Recovery depends on policy, available compute and remaining budget; a job can stop without completing.

Checkpointing belongs in the workload.

Saving a checkpoint is only useful when your command can load the saved checkpoint. Do not describe every retry as a seamless resume.

Submission is separate from estimation.

Ask the user to review the job before spending. The review interaction depends on the MCP client; do not assume every client has the same approval screen.

Keep credentials out of the spec.

Never ask the user to paste API keys, access tokens, passwords or cloud credentials into chat. Job environment variables are for non-sensitive configuration: they, commands, links and log tails may be retained. Credentials belong in the user's saved Secrets on symbioza.dev/app/secrets, attached to a job by name. A saved secret is stored encrypted and no page, API or tool returns its value; a job that attaches it receives the values in plain form, and the machine running that job can technically read them. Saved values are removed from a job's printed output by exact match only, and files the job writes are not scanned. Never provide SSH private keys. Read the Privacy notice before submitting data.