Skip to main content
Glama

aiworkhub_manager_bootstrap

Call this first to load the mandatory repository manager contract and callback workflow, then receive repository readiness, task health, and dispatcher state on every reply.

Instructions

CALL FIRST: mandatory repository manager contract and callback workflow.

The identity block -- role, verified route, repository and storage readiness, task health, the last hygiene pass and the Claude-route dispatcher state -- is on every reply, so repository_current and aiworkhub_task_health need no call of their own. The contract prose is delivered once per verified session and then suppressed with its sha; pass include_contract=true to re-read it, or known_contract_sha256 to prove you already hold it.

A reply that suppresses the contract (contract_delivered=false) is the steady-state one, and it was measured at up to 11 KB -- most of it the last hygiene pass's per-task detail and the reconciler's own internals, which no caller gates on (NF-2026-01447). Those bodies are dropped from task_hygiene/task_health and replaced by the names omitted plus the block's sha256/bytes, so nothing silently disappears; the verdicts and counts beside them stay exact. include_diagnostics=true keeps them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aiworkhub_manager_bootstrap"
  }
}

Input Schema

NameRequiredDescriptionDefault
include_contractNotrue re-delivers the full contract prose even when it was already delivered this session; default false.
include_diagnosticsNotrue keeps the full task_hygiene and task_health diagnostic bodies on a reply that suppresses the contract; default false folds them to the omitted names plus sha256 and bytes.
known_contract_sha256Nocontract_sha256 from an earlier reply, proving you already hold that contract so its prose stays suppressed; omit if you do not hold it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / include_contract / description
      Added value: +"true re-delivers the full contract prose even when it was already delivered this session; default false."
    • addedInput schema / properties / include_diagnostics / description
      Added value: +"true keeps the full task_hygiene and task_health diagnostic bodies on a reply that suppresses the contract; default false folds them to the omitted names plus sha256 and bytes."
    • addedInput schema / properties / known_contract_sha256 / description
      Added value: +"contract_sha256 from an earlier reply, proving you already hold that contract so its prose stays suppressed; omit if you do not hold it."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With readOnlyHint=false already signalling a stateful write, the description goes well beyond annotations: it discloses that the identity block is returned on every reply, that contract prose is delivered once and then suppressed by sha256, that the steady-state response was measured at up to 11 KB, and exactly what gets elided from task_hygiene/task_health (names plus sha256/bytes) and how to restore it. The disclosure that folded content is replaced by names so 'nothing silently disappears' is precisely the kind of side-effect context annotations cannot carry.

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

Conciseness3/5

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

The imperative directive is correctly first and the suppression rule follows logically, but the prose is dense, jargon-heavy and includes internal ticket references (NF-2026-01447) that do not help an agent act. The middle paragraph spends several clauses re-explaining the same elision twice, which is more than a 3-parameter tool needs.

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 session-bootstrap tool with a full output schema and full schema coverage, the description supplies everything an agent needs: when to call it, what always appears on the reply, how contract delivery is gated, and what was omitted from the bulky sections. The cross-tool note that repo_current and task_health need no separate call is exactly the routing information a sibling-heavy catalog demands.

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 schema already defines all three parameters; the description earns above baseline by adding rationale rather than restating types — re-reading via include_contract, proving possession via known_contract_sha256, and keeping diagnostic bodies via include_diagnostics. The added context is the response-size/steady-state consequence, which is what actually drives the parameter choice.

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

Purpose4/5

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

The opening 'CALL FIRST: mandatory repository manager contract and callback workflow' plus the enumeration of the identity block (role, verified route, repo/storage readiness, task health, hygiene pass, dispatcher state) makes clear this is the session bootstrap that returns manager context. It also implicitly differentiates from siblings by noting repo_current and aiworkhub_task_health 'need no call of their own.' The remaining vagueness is the promised 'callback workflow,' which is named but never described.

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

Usage Guidelines4/5

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

The guidance is explicit and front-loaded: call this first, it is mandatory, and the contract is delivered once per verified session then suppressed. It also tells the agent how to opt back in (include_contract=true) or prove prior possession (known_contract_sha256). It does not state whether re-invocation mid-session is expected or wasteful, but the conditional parameter guidance covers most of the decision.

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