recipe_installInstalls a community SKILL by id (from recipe_discover) onto this Mac so recipe_run can use it. Installing only stores the skill. If a skill with the same name already exists, it's saved under a non-colliding name. Returns {name, installed}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The community skill id from recipe_discover. | |
| confirm | No | Ignored; kept for older clients. |
Changes observed during successful MCP inspections.
Input schema / properties / confirm / descriptionPrevious value: -"Must be true to download and save the skill. Without it the call returns a preview and contacts nothing."New value: +"Ignored; kept for older clients."Input schema / properties / confirmAdded value: +{
+ "description": "Must be true to download and save the skill. Without it the call returns a preview and contacts nothing.",
+ "type": "boolean"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true and openWorldHint=true, but the description adds useful behavior beyond them: it states that installing only stores the skill, that a name collision is handled by saving under a non-colliding name rather than overwriting, and it gives the return shape {name, installed}. It does not discuss trust or safety implications of installing executable community content, which would raise this score.
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?
Three short sentences with no wasted text. The install action is front-loaded, then the storage semantics, then the collision behavior and return value.
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?
It is complete enough for a simple tool with two parameters: it explains what installation does, how name collisions are resolved, and what the tool returns, even though there is no output schema. Failure modes, such as an invalid id or a network error, are not mentioned.
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?
The schema already documents both parameters at 100% coverage, including that confirm is ignored. The description repeats the 'id from recipe_discover' origin already stated in the schema and adds nothing new about parameter handling, so the baseline of 3 is appropriate.
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 uses a specific verb and resource ('Installs a community SKILL by id') and also explains its downstream purpose ('so recipe_run can use it'). It names related siblings (recipe_discover, recipe_run), which lets an agent distinguish it from the other recipe_* tools.
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?
It specifies that the id comes from recipe_discover and clarifies that installing only stores the skill, distinguishing installation from execution. That gives clear context for when to call it, but it lacks explicit when-not guidance (for example, when to use recipe_import or recipe_save instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.