Why long editor operations are jobs, not tool calls
A lighting bake does not fit in an MCP request timeout. Here is why MCP4Unreal moved builds, bakes, renders, and imports onto job semantics — start, status, cancel, result — instead of pretending a blocking call would survive.
The problem nobody’s marketing mentions
MCP is a request/response protocol. A lighting bake takes minutes. A Movie Render Queue submission can take an hour. If your automation bridge exposes those as blocking tool calls, one of two things happens: the client times out and the operation keeps running with nobody attached to it, or the bridge holds the connection open and prays. Either way, the agent ends up with a half-finished editor state it cannot reason about — which is exactly the situation an automation bridge exists to prevent.
Most MCP-for-Unreal plugins expose long operations anyway and let the timeout be your problem. We decided it was our problem.
Job semantics
MCP4Unreal ships a dedicated jobs service domain. Operations that are declared long-running —
builds, lighting bakes, MRQ renders, imports, exports, reimports — execute as jobs with a
full lifecycle API:
startreturns a job id immediately instead of blocking the request.statusreports progress without touching the operation.cancelstops a job cleanly.resultretrieves the outcome once the job completes.- A bounded
log tailexposes recent output without flooding the context window. cleanupandrecoveryhandle the unglamorous part: jobs that outlived their client.
Job contracts include timeouts and idempotency, so an agent that retries does not double-bake
your lightmaps. Async metadata is advertised through discovery and system.health, so a
client can know which operations are jobs before calling them.
Why this matters for agents specifically
A human watching a progress bar can decide when to intervene. An agent cannot — it needs the state machine to be explicit. Job semantics turn “fire and hope” into a loop the agent can actually reason about: start, poll, decide, cancel or collect. Combined with the bounded log tail, the agent gets observability without dragging megabytes of build output into its context.
This is also why the static and live async runtime gates are wired into our validation pipeline: the job lifecycle is part of the product surface, so it gets validated like one. Long-running operations are where automation usually goes to die quietly. We would rather they be where it proves it can be trusted.