Local MCP

Shortcuts Run

shortcuts_run

Destructive

Runs one of the user's macOS Shortcuts (Atajos) by name or identifier — the way Mac users already automate HomeKit, Focus modes, and third-party app actions the catalog doesn't cover. It runs the shortcut's OWN actions under the shortcut's own permissions, not a sandboxed subset — the same as clicking Run in the Shortcuts app, so it can do anything that shortcut does (send messages, change or delete files, call web services, control the Mac), including effects LMCP cannot preview or undo. This is a write operation: the first call (confirm=false) returns a preview naming the shortcut, its identifier, and its folder, without running anything; set confirm=true to actually run it. A name that matches more than one shortcut is refused with both identifiers — call again with one of those, never guessed. A shortcut that waits on a dialog or runs long is stopped after a bounded timeout with a clear message instead of hanging this call.

Input Schema

Name	Required	Description
`confirm`	No	Must be true to actually run the shortcut. Without it, returns a preview.
`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.
`input_text`	No	Optional text input for the shortcut, passed via a temp file — omit if the shortcut takes no input.
`name_or_identifier`	Yes	Shortcut name or identifier, from shortcuts_list. An ambiguous name is refused — pass the identifier instead.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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"
+}

AddedSep 30, 2026
RemovedSep 29, 2026
AddedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructive/openWorld) by disclosing that the shortcut's OWN permissions apply, that it can send messages, mutate/delete files, or call web services with effects LMCP cannot preview or undo, and that long/dialog-waiting runs hit a bounded timeout. These are exactly the risk facts an agent needs before invoking.

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?

Front-loaded with what it does, then risk, then the confirm workflow, then edge cases. Dense and mostly waste-free, though the em-dash-heavy sentences and the parenthetical '(Atajos)' are slightly heavier than necessary.

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, open-world tool with 4 documented params and an output schema, the description covers purpose, permissions risk, confirmation protocol, ambiguity handling, and timeout behavior. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning to confirm by describing the preview-then-run two-step and to name_or_identifier by explaining the ambiguity refusal. remember and input_text are left to the schema, which documents them well.

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+resource ('Runs one of the user's macOS Shortcuts') by name or identifier, and scopes it as the escape hatch for actions 'the catalog doesn't cover'. An agent can tell this apart from shortcuts_list and shortcuts_view without opening a 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 routes the agent: preview with confirm=false, run with confirm=true, resolve ambiguous names by re-calling with an identifier rather than guessing, and pull identifiers from shortcuts_list. When-to-use, when-not, and the alternative tool are all named.

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.