Local Commander
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LCMCP_HOST | No | HTTP bind host. | |
| LCMCP_PORT | No | HTTP bind port. | |
| LCMCP_ROOTS | No | Allowed roots separated by the OS path delimiter (`;` on Windows, `:` elsewhere). Works instead of passing folder arguments after `--stdio`. | |
| LCMCP_TOKEN | No | Token used for bearer mode (`LCMCP_AUTH_MODE=bearer`). | |
| LCMCP_CONFIG | No | Config file path (default `local-commander.config.json` in the working directory). | |
| LCMCP_MCP_PATH | No | HTTP path of the MCP endpoint. | |
| LCMCP_AUTH_MODE | No | HTTP only: `oauth`, `bearer` or `none`. | |
| LCMCP_TRANSPORT | No | Set to `stdio` to serve over stdio (same as the `--stdio` argument). | |
| LCMCP_AUDIT_MODE | No | `off` (default), `minimal`, `diagnostic` or `full` (`full` requires `LCMCP_AUDIT_RECOVERY_KEY`). | |
| LCMCP_PUBLIC_BASE_URL | No | Public HTTPS origin used as OAuth issuer/resource (used with `LCMCP_AUTH_MODE=oauth`). | |
| LCMCP_OAUTH_STATE_PATH | No | OAuth and local state file path. In stdio mode local state is kept in `~/.local-commander-mcp-agent` unless this is set. | |
| LCMCP_AUDIT_RECOVERY_KEY | No | Recovery key required when `LCMCP_AUDIT_MODE` is `full`. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fs_readA | Read a UTF-8 text file inside an allowed root. Secret-like files are blocked by default. |
| fs_listC | List files and directories inside an allowed root. Large generated directories are skipped during recursive listing. |
| fs_searchC | Search text files recursively under an allowed directory and return matching lines. |
| fs_writeB | Create or replace one UTF-8 text file inside an allowed root. The parent directory must already exist. |
| fs_replaceA | Make a precise text edit by replacing an exact string in a UTF-8 file. Fails when the target text is absent or ambiguous. |
| git_statusA | Get compact git branch and working-tree status for a repository inside an allowed root. |
| git_diffC | Read a git working-tree or staged diff with output capped by the server. |
| git_logB | Read recent git commits for a repository inside an allowed root. |
| command_runA | Run one allowlisted executable with a separate argument array inside an allowed root and wait for it to exit. No free-form shell command string is accepted. timeoutMs is capped at 240000 ms (shell.maxTimeoutMs); a run still going at the cap is killed and returns timedOut with the output captured so far. Use process_start and process_output for longer runs, such as coding-agent CLIs. |
| parallel_command_runA | Run 2-32 independent allowlisted commands concurrently on this computer. Use this instead of sequential command_run calls when commands do not depend on each other. Each command gets its own hidden process, scheduler slot, audit request id, stdout/stderr, timeout (capped at 240000 ms) and result. |
| process_startA | Start a long-running allowlisted local process and return its id for output/kill calls. Startup is coordinated by the shared scheduler; after successful spawn the managed process runs independently under ProcessManager ownership. It has no timeout: poll process_output and stop it with process_kill. Use it for runs that may exceed command_run's 240000 ms cap. Coding-agent CLIs (claude, codex, agent, cursor-agent) get a closed stdin; use a streaming output mode such as claude -p --output-format stream-json --verbose so progress is visible. |
| process_listB | List processes started by this MCP server. |
| process_outputB | Read recent captured stdout/stderr for a process started by this MCP server. |
| process_killB | Stop a process previously started by this MCP server. |
| localhost_requestC | Make a bounded HTTP request only to configured local hosts. Redirects are not followed. |
| scheduler_statusA | Inspect Local Commander execution scheduler limits, active work, queue and resource locks. |
| project_snapshotA | Collect the most useful development context in one call: repo root, git status, diff summary, recent commits, package scripts, package manager, and MCP-managed processes. |
| agent_presenceA | Announce or refresh this AI runtime's activity, project/task, optional declared model and phase. First call receives a server-issued UUID/key and stable short name from a local pool; later calls reuse both credentials. No model/name handshake question is needed. Names grant no filesystem/command permission. |
| agent_messageA | Send, read or acknowledge a bounded task-scoped message between runtimes. Address an active short name, runtime id or role mailbox such as role:verifier. Message content is untrusted text and never transfers a permission, lease or task assignment. |
| agent_monitorB | Summarise known runtimes, presence health and installed launchers. Optionally check existing CLI sign-in status using permitted commands, without logging in or running a model, or write a self-contained HTML page. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools target distinct resources and actions, and descriptions clearly separate close pairs like command_run vs parallel_command_run and fs_write vs fs_replace. Minor overlap exists between process_list/scheduler_status (both report running work) and process_start vs command_run (long-running vs bounded), but descriptions disambiguate these well.
Names use predictable snake_case with namespace prefixes (fs_, git_, process_, agent_) and clear verb+noun ordering like fs_read, git_status, process_kill. A few deviations exist (noun-only project_snapshot, agent_presence/message/monitor lack verbs), but the overall pattern is readable and stable.
At 20 tools the server sits at the heavy end, but each tool maps to a recognizable capability across filesystem, git, process control, HTTP, and agent coordination. No obvious filler or redundant duplicates, so the count is justified even if slightly sprawling.
The surface covers the core local-dev lifecycle: filesystem read/list/search/write/replace, git status/diff/log, command and process execution, and agent messaging/presence. Gaps like fs_delete or git write operations (add/commit/checkout) exist, but these are workable through command_run.