rent.dev

Start a background process

rent_start_process

Destructive

Starts a command in the background and answers at once with its process id. The process id is valid while the sandbox runs; read its output with rent_get_process_output. The process ends with the sandbox. Arguments not listed here go to the REST route as they are, which refuses them by name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sandbox_id": "<sandbox_id>",
      "cmd": "<cmd>"
    },
    "name": "rent_start_process"
  }
}

Input Schema

Name	Required	Description
`cmd`	Yes
`cwd`	No
`env`	No
`user`	No
`stdin`	No	Keep stdin open.
`sandbox_id`	Yes	Sandbox id (`lse_…`) from rent_create_sandbox or rent_list_sandboxes. It names the sandbox for its whole life and keeps answering rent_get_sandbox, with the final state, after it ends.

Output Schema

Name	Required	Description	Default
`cmd`	Yes
`running`	Yes
`exit_code`	Yes
`process_id`	Yes
`started_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds lifecycle facts the annotations lack: the pid is only valid for the lifetime of the sandbox, the process ends with the sandbox, and unlisted arguments are rejected by name at the REST route. That last point signals a failure mode, although it does not state the permission or side-effect profile of the spawned command.

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?

Three short sentences that front-load the behavior and then the follow-up route, with no filler. The closing sentence about unlisted arguments is slightly awkward ("refuses them by name") but still earns its place by disclosing an error path.

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 destructive, non-idempotent spawner, the description covers the essential mechanics: immediate pid return, output retrieval, and the sandbox-bound lifetime. Because an output schema exists, return values do not need spelling out. With only 33% schema description coverage, though, the definition should say more about the four undocumented parameters.

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 coverage is only 33%, with cwd, env, user, and cmd undocumented, so the description has to carry more weight than it does. It clarifies that parameters not listed here pass straight through to the REST route, which is modest but real added meaning about the additionalProperties behavior. It still leaves cwd, env, and user semantics unexplained.

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 uses a specific verb and resource ("starts a command in the background") and states the immediate return ("answers at once with its process id"). That is enough to tell it apart from output-reading tools, and it names rent_get_process_output as the follow-up. It never mentions rent_exec, so the distinction from foreground execution is left implicit.

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?

It clearly implies when to use this tool (background work, asynchronous start) and explicitly routes the agent to rent_get_process_output for output, which is useful guidance about alternatives. The only gap is an explicit contrast with rent_exec and no stated exclusions such as commands that need to finish before returning.

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

All rent.dev tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?