Skip to main content
Glama

aiworkhub_manager_recipe_run

MANAGER EXECUTE: run one PERSISTED recipe and return a bounded digest.

Instructions

MANAGER EXECUTE: run one PERSISTED recipe and return a bounded digest.

What runs is the immutable stored manifest resolved from the registry, not a mapping typed at call time: argv[0] is a manifest literal, the vector is built from typed slots, and it is spawned as an execve list with no shell. Read-only by default -- tool_recipes.validate_invocation refuses a recipe whose declared capabilities grant_capabilities does not name, and a write/network recipe additionally requires the repository write gate to be open.

A non-zero exit is a RESULT, not an error: the digest carries the return code, the duration, stdout/stderr tails capped at 4096 characters with explicit truncation flags, and the path plus SHA-256 of the full output file, so the whole stream stays retrievable without being carried here. Every run persists a tool_recipes invocation receipt.

Input Schema

NameRequiredDescriptionDefault
paramsNo
versionNo
recipe_idYes
grant_capabilitiesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: immutable stored manifest, no shell, read-only default, capability validation, write/network gate requirement, non-zero exit treated as a result, and a persisted invocation receipt. What it doesn't say is what happens to partial runs or how truncation flags are set beyond the cap.

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 the verb+resource, then progressive detail. Some density (backticked identifiers, long sentence on the digest) but every sentence adds signal; no filler.

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

Completeness4/5

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

For a mutation-shaped execute tool with no annotations, the safety semantics, return digest contents, and error-as-result convention are covered. Gaps remain around parameter payload semantics and any re-run/idempotency behavior.

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?

At 0% schema coverage the description should explain all four params. It clarifies recipe_id (resolved manifest), version (registry-resolved version), and grant_capabilities (declared capabilities authorized for the run), but the `params` object, which is the actual payload for the typed slots, is never explained.

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 (run) and specific resource (one PERSISTED recipe) plus the return shape (bounded digest). Clear scope and distinguishes it from sibling recipe_register/recipe_show/recipe_list tools, which inspect or create rather than execute.

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

Usage Guidelines3/5

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

Implies when it can run via the capability validation and write-gate rules, but never states when to use this versus inspecting a recipe first (recipe_show) or registering one (recipe_register). Usage conditions are described but alternatives are not named.

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

Deploy Server

Other Tools