# Transloadit over MCP We run a Model Context Protocol server, so an agent can encode video, resize images, convert documents, and read the results back. It runs on the same platform behind our API, and the agent works out the pipeline itself.  ## What your agent can do Connecting gives it seven tools, which fall into four jobs: * **Find out what is possible.** `transloadit_list_robots` returns the catalogue with a summary per Robot, and `transloadit_get_robot_help` returns the parameters for one of them. The agent does not have to have been trained on our documentation to use us correctly. * **Check its work before it costs anything.** `transloadit_lint_assembly_instructions` validates a set of Assembly Instructions without creating an Assembly, and returns structured issues rather than prose. * **Run the job.** `transloadit_create_assembly` creates or resumes an Assembly, uploading files and waiting for the result if you ask it to. * **Follow it to the end.** `transloadit_get_assembly_status` and `transloadit_wait_for_assembly`track a running Assembly, and `transloadit_list_templates` reuses the Templates you already have. ## It can explore before it can spend The catalogue and the linter need no credentials. An agent can list every Robot, read the parameters for the ones it likes, and have a draft validated, all before an account exists. Ask it to lint a Step with a mistake in it and it gets back the mistake: ```json { "severity": "error", "path": "instructions", "message": "Path `steps.resized` has unrecognized keys: `widht`" } ``` Anything that touches an account is a different matter. Listing your Templates or creating an Assembly without credentials returns `mcp_missing_auth`, not a guess and not a partial result. So the exploring is free, and the spending is deliberate. ## Why this beats handing an agent an API key An agent pointed at a REST API has to already know the shape of the thing. It guesses a parameter name, sends the request, and finds out it was wrong once the job has failed — which costs a round trip at best, and an encoding charge at worst. Assembly Instructions are declarative JSON, which is the kind of artifact an agent produces well. Pairing that with discovery and a linter closes the loop before anything runs: it can ask what exists, write the Steps, have them checked, and only then create the Assembly. The processing itself happens on our infrastructure, so there is no FFmpeg to install and no local disk to fill. ## Connect it The quickest path is the hosted endpoint: ``` https://api2.transloadit.com/mcp ``` Clients that scan for capabilities can read the machine-readable card at[/.well-known/mcp/server-card.json⁠](https://api2.transloadit.com/.well-known/mcp/server-card.json), which lists the tools and their input schemas. Running it yourself over stdio is usually the better option once you are past trying it, because the process then holds your `TRANSLOADIT_KEY` and `TRANSLOADIT_SECRET` and handles authentication for you. The [MCP Server documentation](/docs/sdks/mcp-server.md) has both setups, including the client configuration snippets. ## What it will not do * It orchestrates Transloadit. It does not run arbitrary code against your files, and it cannot do anything the API could not. * Encoding is charged as usual. An agent that retries a failing Assembly in a loop spends real money, so give it a Workspace whose limits you are comfortable with. * The tools cover Assemblies, Robots, and Templates. Account administration, billing, and credentials stay outside it, deliberately. * It is not a substitute for reading the [Robot documentation](/docs/robots.md) when you are the one designing the pipeline. It is what you reach for when the agent is. [Create a free Workspace](/c/signup/) to get the credentials, or read the[MCP Server documentation](/docs/sdks/mcp-server.md) first.