Apple Route Or Run Shortcut

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

Annotations already cover the safety profile (idempotentHint=false, destructiveHint=false, openWorldHint=false), and the description adds routing context without contradicting them. But it omits meaningful behavioral facts for a tool that executes user-defined automation: that running a shortcut may trigger arbitrary side effects, and that `dry_run` exists as a preview path. The description adds only modest value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single 22-word sentence that front-loads the core purpose and places the conditions after it. There is no wasted prose or repetition of the title. It earns a 4 rather than 5 because the same space could have carried one more useful fact (e.g., dry-run behavior or a side-effect note) without losing tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a router/executor with five parameters, one required opaque field, and zero schema description coverage, a one-sentence description is insufficient. The agent is left without guidance on how to phrase `request`, when to set `dry_run`, how routing decisions resolve when no shortcut is named, and how this relates to the sibling `shortcuts_run_shortcut`. An output schema exists but does not compensate for the missing usage semantics.

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

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

Schema description coverage is 0%, and the description mentions none of the five parameters. The required `request` field is completely unexplained — an agent cannot tell whether it is a natural-language instruction, a routing query, or an action name. `input_text`, `input_paths`, `shortcut_name_or_identifier`, and `dry_run` are guessable from names but receive no semantic confirmation from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's role — using Apple Shortcuts as an explicit bridge — and names its two trigger conditions (insufficient native coverage, direct shortcut naming), which distinguishes it from the family of native apple_* tools. However, the verb 'use' is less specific than 'runs' or 'executes', and the operational distinction between the routing and the running behavior implied by the name is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives two explicit when-to-use conditions: 'when native Apple MCP coverage is insufficient' and 'when the user names a shortcut directly.' This effectively implies the when-not case (use native tools when coverage is sufficient). It does not name the overlapping sibling `shortcuts_run_shortcut` or state how to choose between them, so the guidance is strong but not fully explicit about alternatives.

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