Local MCP

Run Terminal Command

run_terminal_command

Destructive

Runs a shell command on the user's Mac and returns its output. Always active. Disabled when LMCP is in read-only mode. Three kinds of command are refused, because they cannot be undone: formatting or overwriting a disk (mkfs, newfs, fdisk, diskutil erase/partition, dd to or from a disk device), a recursive delete of a system folder, of the user's home folder or one of its data folders (Documents, Desktop, Downloads, Library, Pictures, Movies, Music), of everything directly inside one of them, or of a target or folder the command's text does not settle (a variable, a command substitution, a cd inside a subshell), and a fork bomb. A command that names a credential location (keychains, ~/.ssh private keys, ~/.aws, ~/.config/gh, browser logins, another user's home) writes a file that runs code later (LaunchAgents, shell startup files, AI clients' folders), opens a script or a terminal app, controls a system service or power, pipes a downloaded script into a shell, writes to a device file or changes permissions recursively on a system path is NOT refused: the preview and the result carry a warning that says what it does. Controlling another app from the terminal is not available, whether or not the app is turned on in LMCP: a script that names another app (System Events included) is refused before it runs, and the refusal names the LMCP tool to use instead. Before confirming, tell the user what it will read or change, unless they asked for exactly this. The warnings read only the command's text, so a command that hides a path gets none. Commands run in a macOS sandbox that protects only Local MCP itself: the terminal cannot open or change Local MCP's own files by their path (its settings and token, binaries, activity log, messaging and web sessions, start-up item), cannot talk to its socket, and cannot open the files of an account whose Read or Write box the user turned off. No setting re-opens these. Because of that sandbox, setuid system programs other than ps and top cannot start (sudo, su, crontab, at, traceroute): the warning says so before the command runs, and the log command does not run. Inside the sandbox SwiftPM needs --disable-sandbox. Destructive: it previews the command first — pass confirm:true to actually run it. Output and runtime are capped.

Input Schema

Name	Required	Description
`command`	Yes	The shell command to run (a single command line, executed with /bin/zsh -lc).
`confirm`	No	Must be true to actually run. Without it, a preview of the command is returned.
`remember`	No	With confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.
`working_dir`	No	Optional absolute working directory. Defaults to the user's home directory.
`timeout_seconds`	No	Max seconds to run before it is terminated (default 20, max 60).

Output Schema

Name	Required	Description
`output`	No
`command`	No
`warnings`	No	Present when the command names something worth telling the user about (a credential location, a file that runs code later, a script that would control another app). Not a refusal: the command ran.
`exit_code`	No
`sandbox_note`	No	Present when the sandbox stopped the command: one of Local MCP's own files or the files of an account the user closed ("Operation not permitted"), a setuid program or the `log` command. Says what was stopped and what to do instead.
`automation_note`	No	Present when the command tried to control another app, which the terminal can't do (or, for -1743, the macOS Automation permission said no). Says what to use instead.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedOutput schema / properties / automation_note / description

Previous value: -"Present when macOS did not let the command control another app. Says where that permission is and what to use instead."New value: +"Present when the command tried to control another app, which the terminal can't do (or, for -1743, the macOS Automation permission said no). Says what to use instead."

changedOutput schema / properties / warnings / description

Previous value: -"Present when the command names something worth telling the user about (a credential location, a file that runs code later, another app driven by a script). Not a refusal: the command ran."New value: +"Present when the command names something worth telling the user about (a credential location, a file that runs code later, a script that would control another app). Not a refusal: the command ran."

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / remember

Added value: +{
+  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 22, 2026

addedOutput schema / properties / automation_note

Added value: +{
+  "description": "Present when macOS did not let the command control another app. Says where that permission is and what to use instead.",
+  "type": "string"
+}

changedOutput schema / properties / sandbox_note / description

Previous value: -"Present when a failed command hit \"Operation not permitted\": the sandbox may have refused a protected location."New value: +"Present when the sandbox stopped the command: one of Local MCP's own files or the files of an account the user closed (\"Operation not permitted\"), a setuid program or the `log` command. Says what was stopped and what to do instead."

addedOutput schema / properties / warnings

Added value: +{
+  "description": "Present when the command names something worth telling the user about (a credential location, a file that runs code later, another app driven by a script). Not a refusal: the command ran.",
+  "items": {
+    "properties": {
+      "class": {
+        "type": "string"
+      },
+      "text": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 10, 2026

addedOutput schema / properties / sandbox_note

Added value: +{
+  "description": "Present when a failed command hit \"Operation not permitted\": the sandbox may have refused a protected location.",
+  "type": "string"
+}

AddedSep 19, 2026
RemovedJul 30, 2026
AddedJul 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructive=true and openWorld=true, but the description adds substantial behavioral context: what is refused and why, which risky-but-allowed commands carry warnings, how the preview/confirm flow works, sandbox limitations, setuid restrictions, and output/runtime caps. No contradictions with annotations.

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 description is front-loaded and every major point is relevant to safe invocation, but it is a very dense single paragraph with some repetition around preview/confirm and warnings. Structuring the refusal categories and sandbox rules as bullets would improve scanability.

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 high-risk, open-world, destructive terminal tool, the description covers refusals, warnings, preview/confirm, sandbox constraints, app-control alternatives, and runtime/output caps. An output schema exists, so return values need not be explained further.

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 schema already documents all five parameters. The description reinforces confirm:true behavior and mentions caps, but it does not add meaningful semantics for remember, working_dir, or timeout_seconds beyond what the schema provides; 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?

The first sentence states a specific verb and resource: runs a shell command on the user's Mac and returns its output. It also frames the scope against siblings by explaining that controlling another app from the terminal is refused and that the refusal names the LMCP tool to use instead.

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?

It gives explicit when-not guidance: three categories of irreversible commands are refused, read-only mode disables the tool, and app-control commands are refused with a pointer to the appropriate LMCP tool. It also tells the agent to inform the user before confirming unless the user asked for exactly that command.

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

All Local MCP 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.