Skip to main content
Glama

run_script_job

Destructive

Run long Python scripts in a Kit app as jobs and return an ID immediately, enabling work beyond 120-second limits while Kit remains responsive.

Instructions

Start a long Python script inside the Kit app as a job, and answer its id at once: for work that may outlast execute_script's 120 s, such as dropping and settling many objects under physics one after another.

The job runs on Kit's main thread between Kit's updates, so Kit renders and other tools answer while it runs. It must await once a step: await omni.kit.app.get_app().next_update_async() lets one update pass, physics stepping while the timeline plays, up to its end: get_sim_state's timeline line says where that is and whether it loops back there. A script that never awaits at its top level is refused, since its loops would hold Kit from its start to its end; a coroutine the script only defines or schedules doesn't count: await it at the top level, await main(). One that awaits once and then loops, or calls Isaac Sim's world.step(), holds Kit too, and no tool can read or cancel it until it ends. It has execute_script's names (omni, carb, Usd, UsdGeom, UsdLux, UsdPhysics, Sdf, Gf, mcp); assign to result to return data. Print a line a step: the lines are the progress get_job shows. Read it with get_job(id, wait=60), cancel it with cancel_job. One job runs at a time, and the last one is kept until the next starts.

Input Schema

NameRequiredDescriptionDefault
codeNoPython to run as the job; give this or file
fileNoA .py file on the Kit app's machine to run as the job, read there; or give code

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag this as non-read-only, destructive, and open-world, but the description adds substantial behavioral context beyond them: it runs on Kit's main thread, must await at least once at top level or be refused, can become uncancellable if it loops after awaiting or calls world.step, and only one job runs at a time. It also explains progress via printed lines and result assignment. This is unusually complete for a mutation tool.

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?

The purpose and sibling comparison are front-loaded, and most sentences carry necessary constraints. However, several sentences are dense and awkwardly packed, especially the await/update/timeline passage, which could be split for faster parsing.

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 destructive arbitrary-code execution tool with concurrency constraints, the description covers the key operational facts: the 120 s alternative, main-thread scheduling, the await requirement and refusal behavior, one-job-at-a-time semantics, progress reporting, and cancellation. An output schema exists, so return values do not need further explanation.

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 description coverage is 100%, so the two parameters (code and file) are already documented by the schema as alternatives. The description does not add syntax, precedence, or conflict-resolution rules for code versus file beyond what the schema says, so the baseline 3 is appropriate.

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?

States a specific verb and resource: 'Start a long Python script inside the Kit app as a job,' and immediately contrasts it with execute_script's 120 s limit. An agent can distinguish it from both execute_script and get_job without opening any schema.

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?

Explicitly names the alternative (execute_script) and the condition that selects this tool: work that may outlast the 120 s limit. It also gives concrete uses such as dropping and settling many physics objects, and later names get_job and cancel_job as the read/cancel companions.

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