Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_manager_recipe_run

Runs a persisted recipe by ID with typed parameters and returns a bounded digest of exit code, duration, and output tails, keeping full logs retrievable.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipe_id": "<recipe_id>"
    },
    "name": "aiworkhub_manager_recipe_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
detachNoWhen true, queue the run as a detached host process and return its run_id at once; read the outcome with aiworkhub_manager_recipe_run_status. At most one detached run per repository executes at a time.
paramsNoValues for the recipe's typed argument slots, keyed by the slot names its manifest declares; omit when the recipe takes none.
versionNoRecipe version to run, as listed by aiworkhub_manager_recipe_list; omit to run the highest stored version.
recipe_idYesId of a persisted recipe, as listed by aiworkhub_manager_recipe_list.
accept_task_idNoAccept-gate binding, passed together with accept_request_id: the task whose review_ready candidate this run must cover. Implies detach; the recipe, version and params must equal .aiworkhub/config/accept_gate.json and the run executes on the combined candidate tree. Omit for an ordinary run.
accept_request_idNoAccept-gate binding, passed together with accept_task_id: the review_ready worker request whose exact candidate this run is bound to. Accept is refused until this run completed with returncode 0 on that candidate.
grant_capabilitiesNoCapabilities granted to this run; it must name every capability the recipe declares. Omit for a read-only recipe; a write or network recipe also needs the repository write gate open.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.82
    • addedInput schema / properties / accept_request_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Accept-gate binding, passed together with accept_task_id: the review_ready worker request whose exact candidate this run is bound to. Accept is refused until this run completed with returncode 0 on that candidate.",
+  "title": "Accept Request Id"
+}
    • addedInput schema / properties / accept_task_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Accept-gate binding, passed together with accept_request_id: the task whose review_ready candidate this run must cover. Implies detach; the recipe, version and params must equal .aiworkhub/config/accept_gate.json and the run executes on the combined candidate tree. Omit for an ordinary run.",
+  "title": "Accept Task Id"
+}
  2. Changed1 schema field changedv0.12.80
    • addedInput schema / properties / detach
      Added value: +{
+  "default": false,
+  "description": "When true, queue the run as a detached host process and return its run_id at once; read the outcome with aiworkhub_manager_recipe_run_status. At most one detached run per repository executes at a time.",
+  "title": "Detach",
+  "type": "boolean"
+}
  3. Changed4 schema fields changedv0.12.67
    • addedInput schema / properties / grant_capabilities / description
      Added value: +"Capabilities granted to this run; it must name every capability the recipe declares. Omit for a read-only recipe; a write or network recipe also needs the repository write gate open."
    • addedInput schema / properties / params / description
      Added value: +"Values for the recipe's typed argument slots, keyed by the slot names its manifest declares; omit when the recipe takes none."
    • addedInput schema / properties / recipe_id / description
      Added value: +"Id of a persisted recipe, as listed by aiworkhub_manager_recipe_list."
    • addedInput schema / properties / version / description
      Added value: +"Recipe version to run, as listed by aiworkhub_manager_recipe_list; omit to run the highest stored version."
  4. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the annotations: explains execve spawning with no shell, capability validation, the write gate, that non-zero exit is a result not an error, and that each run persists an invocation receipt. The 'read-only by default' claim is consistent with readOnlyHint=false (writes are possible only when explicitly granted), so no contradiction.

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 action and the persisted-manifest constraint, then security model, then result semantics. Dense and mostly waste-free, though the three-paragraph structure is slightly heavier than needed for the amount of new information.

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?

Covers execution model, permission gating, error semantics, and output shape (return code, duration, capped tails, truncation flags, artifact path/SHA-256) even though an output schema exists. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so all seven parameters are already documented in detail; the description only adds conceptual framing ('vector built from typed slots') and the capability/write-gate rule. Baseline 3 is appropriate when the schema carries per-parameter meaning.

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 and resource ('run one PERSISTED recipe and return a bounded digest') and immediately clarifies the crucial distinction that it executes the immutable stored manifest rather than an ad-hoc mapping. An agent can distinguish this from recipe_list/recipe_show/recipe_run_status without opening any schema.

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?

It gives conditions (read-only by default; grant_capabilities must name declared capabilities; write/network needs the write gate open) but never explicitly routes the agent among siblings — the only sibling routing ('use run_status for detached runs') lives in the schema, not the description. Usage is implied rather than prescribed.

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