EXZA Remote

Start background job

exza_start_background_job

Destructive

Launch a detached shell command on the approved computer and immediately return a job ID, without waiting for the command to finish. Use exza_get_background_job_status to poll bounded progress and output; exza_stop_background_job to interrupt it. Commands may delete files, start programs or access the network; local owner authorization and full-computer scope must already be active. For a short synchronous command use exza_run_shell_command. Requires account-bound computer:write OAuth and any prompted local owner approval.

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": {
      "command": "<command>"
    },
    "name": "exza_start_background_job"
  }
}

Input Schema

Name	Required	Description	Default
`command`	Yes	Shell command executed on the owner computer; review for side effects, credentials and network access.
`maxMinutes`	No	Maximum permitted duration in minutes; server enforces a limit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint, openWorldHint and non-idempotency, so the description's job is to add context — and it does: detachment semantics, immediate job-ID return, potential file deletion, program launch and network access, plus the auth/approval requirements. This goes well beyond the structured flags and warns the agent about side effects before invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each carrying distinct load: what it does, which siblings to use next, what the command may do plus prerequisites, and the synchronous alternative. The key differentiator (detached, returns immediately) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation tool with no output schema, the definition covers the return value (job ID), the follow-up lifecycle tools, and the authorization model. Nothing an agent needs in order to call it correctly or safely is missing.

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 100%, so both `command` and `maxMinutes` are already documented in the schema, which sets the baseline at 3. The description adds only general caution about side effects and credentials, and says nothing about the maxMinutes duration cap or what happens when the server-enforced limit is hit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — 'Launch a detached shell command on the approved computer' — and immediately names the distinguishing behavior: returning a job ID without waiting for completion. It is clearly separable from exza_run_shell_command (synchronous) and from the status/stop siblings it references by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing is provided in both directions: use exza_get_background_job_status to poll and exza_stop_background_job to interrupt, while short synchronous work belongs to exza_run_shell_command. Preconditions (local owner authorization, full-computer scope, computer:write OAuth, prompted approval) are stated up front rather than left to inference.

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

All EXZA Remote 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?