MCP

Why use MCP

A Kimura workspace is more than a mapping to a local path. It maintains workspace state, keeps file operations consistent, and stays connected to the server.

Because of that, workspace loading is non-trivial. For many small, repeated operations, one-shot CLI usage can spend meaningful time reloading workspace state.

kscm mcp addresses this by running KSCM as a long-lived MCP server over stdio. Clients can call KSCM commands as tools against the same live process.

Workspace lifecycle in MCP mode

• A workspace is loaded when a workspace-scoped tool is first invoked.
• KSCM keeps one workspace in memory at a time.
• Subsequent tool calls reuse that loaded workspace when workspace and connection context remain compatible.
• If a later call targets a different workspace, KSCM unloads the current workspace and loads the requested workspace.

In practice, this gives fast follow-up operations for multi-step workflows on the same workspace.

Request model

• MCP mode is long-lived: one KSCM process handles many tool calls.
• Tool calls are processed one at a time. Concurrent tool calls are rejected while a call is already running.
• The command surface mirrors regular KSCM commands, exposed as MCP tools.

When to use MCP

Use MCP when you need repeated workspace operations over time:

• Assistant- and LLM-driven workflows.
• Integrations that issue many small workspace calls.
• Automation that benefits from a persistent workspace session.

Start command

Start MCP mode with:

kscm mcp

Legacy note

host-workspace remains available for legacy integrations (for example, older Unreal Engine plugin flows). For new long-lived integrations, MCP is the preferred path.