omni-kit-mcp
This server exposes only a tool-refresh operation, so its usable capability is refreshing the MCP tool registry from the Kit bridge.
Re-discover the bridge registry and register any newly available tools.
Use it after
reload_tools, enabling a project, or restarting Kit.It does not expose bridge tools like
run_python, file transfer, or project tools through this schema.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@omni-kit-mcp list all available tools"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
omni-kit-mcp
https://github.com/user-attachments/assets/14507203-4fae-4e2a-bfbf-894facf8c864
Infrastructure for driving Omniverse Kit apps — Isaac Sim, Isaac Lab, or any Kit-based app — over the Model Context Protocol.
One bridge, one port, per Kit process. Projects register tools under a
namespace; name collisions between projects are impossible by construction
(two projects can each ship a play_scene — they land as arm.play_scene
and rover.play_scene), so co-loaded projects share the single socket.
flowchart TB
subgraph kit["Kit process (Isaac Sim · Isaac Lab · any Kit app)"]
direction BT
BRIDGE["<b>omni.kit.mcp</b><br/>NDJSON TCP :9009 · owner/namespace registry<br/>main-thread dispatch<br/>builtins: run_python · list_tools · reload_tools · list_bridges · put_file · get_file · stat_file · status"]
ARM["arm_tools/<br/>MCP_NAMESPACE = 'arm'"] -->|register| BRIDGE
ROVER["rover_tools/<br/>MCP_NAMESPACE = 'rover'"] -->|register| BRIDGE
PANEL["omni.kit.mcp.panel<br/>registry-driven UI"] -->|"dispatch (click == agent call)"| BRIDGE
end
GW["kit-mcp gateway<br/>operator view: all tools + run_python"] -->|MCP ⇄ NDJSON| BRIDGE
GWF["kit-mcp gateway (filtered)<br/>KIT_MCP_NAMESPACE=arm · KIT_MCP_BUILTINS=0"] -->|MCP ⇄ NDJSON| BRIDGE
CLI["kit_mcp.client<br/>scripts · tests · doctors · CLI"] -->|NDJSON| BRIDGESetup (once per machine)
Register the bridge permanently (afterwards, launches need no flags or env vars):
python3 scripts/install.py # add --dry-run to previewThis edits the Kit app's persistent user.config.json (the scriptable
equivalent of the Extensions window's AUTOLOAD checkbox): adds exts/ as a
search path, auto-enables omni.kit.mcp + omni.kit.mcp.panel, and sets the
bridge port (default 9009). Restart the app; the bridge binds with the
built-in tools. --remove undoes it.
Run it while the app is down; a running app overwrites the file on exit (why).
Connect an agent/IDE — install the front-end (pip install -e . or uv sync)
and add to .mcp.json (Claude Code, Cursor, etc.):
{
"mcpServers": {
"kit": { "command": "kit-mcp" }
}
}No port needed — the gateway discovers a lone running bridge. Pin one with
"env": { "OMNI_KIT_MCP_PORT": "9009" } when several Kit processes run.
That alone is fully usable: run_python executes arbitrary Python on Kit's
main thread (persistent sessions supported; saved session vars auto-clear when
a new stage opens — they hold prim/handle references the new stage kills),
which reaches everything in the sim. Tools discovered from the bridge appear as native MCP tools
(robot_demo.spawn_robot → robot_demo__spawn_robot; dots are illegal in MCP names).
Related MCP server: simliverse-mcp
Adding a project (the contract)
A project is a plain Python package — not a Kit extension. It declares a
namespace and either exposes one entrypoint (copy examples/demo_tools/) or
none at all (declared toolsets):
# ~/myproj/isaac/myproj_tools/__init__.py
MCP_NAMESPACE = "robot_demo" # defaults to the module name
DOORWAY_ADMISSION = 1 # the admission contract, docs/protocol.md
def register(registrar): # receives an owner-bound registrar
@registrar.tool("Spawn a robot into the scene.", {"name": {"type": "string"}})
def spawn_robot(name: str = "robot_1"):
import omni.usd # Kit imports live inside handlers
...
return {"path": f"/World/{name}"} # payload only — no envelopeRegister it persistently (once per project):
python3 scripts/install.py add-project --path ~/myproj/isaac --module myproj_toolsNext launch, the bridge advertises robot_demo.spawn_robot; the panel grows a robot_demo
section; agents see it after refresh_tools. Per-launch override instead of
persistence: KIT_MCP_TOOL_PATHS=~/myproj/isaac KIT_MCP_TOOL_MODULES=myproj_tools.
One registration, three surfaces. A registered tool isn't just an agent verb: the control panel renders it as a clickable widget automatically, and the reference client/CLI can call it from scripts — all three go through the same dispatch entrance. Write the tool once; button, agent call, and script call come with it.
A package with no register() is introspected instead: every public function
becomes a tool, its schema derived from the signature. See
docs/tool-authoring.md for declared toolsets, the handler
contract and curated per-project agent views.
Scripting the bridge (no MCP needed)
The bridge's wire protocol is not MCP — the gateway above is the only MCP speaker. For scripts, tests, and health checks, use the reference client (stdlib-only, single-file, also copyable as-is):
from kit_mcp.client import call, BridgeClient, BridgeError
call("demo.ping", {"message": "hi"}) # one-shot; endpoint auto-discovered
with BridgeClient() as c: # persistent + reconnect
c.call("run_python", {"code": "result = 1"}) # (pass host=/port= to pin)python3 -m kit_mcp.client <tool> ['{"json":"params"}'] [--port N]
python3 -m kit_mcp.client --list-bridges # what's running
# exit codes: 0 success · 1 bridge answered with an error · 2 unreachableWith exactly one bridge running you need no port: the client discovers it
(endpoint resolution).
import kit_mcp.client works without the mcp SDK installed — only the
gateway needs it.
What else it does
Hot reload — edit a tool package and reload it without restarting Kit. docs/tool-authoring.md
Remote files — ship code and assets to a remote box through the bridge. docs/tool-authoring.md
Control panel — every registered tool becomes a clickable widget. docs/tool-authoring.md
Request admission and doorway hold — one queue with typed refusals, and a way to reserve the bridge for one caller. docs/protocol.md
Multiple instances and remote access — one port per Kit process, discovery, binding beyond localhost. docs/configuration.md
Isaac Lab — the bridge inside standalone train/play scripts. docs/isaac-lab.md
Tool-author gotchas — Kit facts that cost real debugging time. docs/tool-authoring.md
Layout
exts/omni.kit.mcp/ the bridge extension (protocol, bridge, builtins, autoload)
exts/omni.kit.mcp.panel/ registry-driven control panel (optional)
kit_mcp/ the MCP front-end (FastMCP server, TCP client to the bridge)
scripts/install.py permanent registration: base install + add-project
examples/demo_tools/ the template tool package — copy to onboard a project
tests/ protocol / registry / autoload / live-socket tests (no Kit needed)
docs/ protocol, configuration, tool authoring, Isaac LabDevelopment
python3 -m pytest tests/ # the socket server runs under plain asyncio in testsAvailable Tools
1 toolrefresh_toolsA
Re-discover the bridge registry and register any new tools (use after the bridge's reload_tools, after enabling a project, or after Kit restarts).
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 1 tool
With only one tool, there is no risk of confusion. The tool's purpose is clearly described and distinct from any hypothetical other tools.
The single tool uses a clear snake_case verb_noun pattern ('refresh_tools'), which is consistent and readable. No other tools exist to create inconsistency.
The server provides only one tool, which is too few for a meaningful tool surface. The tool, while not trivial, suggests a broader scope (e.g., managing a registry) that is not supported.
The server lacks essential operations for managing a tool registry, such as listing or removing tools. The single 'refresh' tool leaves significant gaps that would cause agent failures.
Maintenance
Related MCP Connectors
Connect AI clients to your Dactic work context through a hosted MCP service.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Build and run AI workflows, agents, data tables and 1000+ API integrations from any MCP client.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables natural language control of NVIDIA Isaac Sim through the Model Context Protocol, allowing you to create robots, build scenes, run simulations, and debug physics from any MCP-compatible IDE.4234 PyPI69MIT

simliverse-mcpofficial
AlicenseNot gradedqualityBmaintenanceProvides a unified MCP server for the SimLiverse Physical AI Platform, enabling LLM copilots to access Isaac Sim knowledge via NVIDIA NIM and execute/control simulation through a TCP socket.MIT- AlicenseNot gradedqualityBmaintenanceEnables AI agents to inspect and control a running WARUDO scene, including assets, character pose and IK, expressions, blueprints, camera, and captures, through an MCP client.16 npm10MIT
- AlicenseDqualityCmaintenanceEnables AI clients to control and inspect a Unity Editor through MCP tools for scene and play-mode operations, logs, screenshots, assertions, Lua execution, UI interaction, world observation, and bridge management; advanced UI/Lua/world features require project-specific adapters.41MIT