Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_task_reroute_launch_identity

Reroutes a pending, unclaimed task from its current runner to an enabled replacement route, returning an audit receipt with status and route details.

Instructions

COORDINATOR WRITE: explicitly reroute one pending retry launch identity.

Replies with a receipt (aiworkhub.reroute_launch_identity_receipt.v1): task_id, status, worker_status, card_sha256/card_bytes, and every server-derived key the reroute attached (from_runner, to_runner, to_model, refusal and authorization receipts). The whole post-reroute card measured 55,156 chars (NF-2026-00500); include_card = none (default) | summary | full brings it back.

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": {
      "task_id": "<task_id>",
      "from_runner": "<from_runner>",
      "to_runner": "<to_runner>",
      "to_adapter_id": "<to_adapter_id>",
      "to_model": "<to_model>"
    },
    "name": "aiworkhub_task_reroute_launch_identity"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicNoTopic the card is expected to be in; a different live topic is refused. Omit to skip the check.
reasonNoWhy the reroute is needed, recorded in the audit receipt and cut to 500 characters; some reroute paths are refused without one. Default empty.
task_idYesId of the pending, unclaimed card whose launch identity is rerouted; any other state is refused with reroute_not_pending_unclaimed.
to_modelYesModel of the replacement route; it must equal the model the workforce catalog lists for that runner and adapter.
to_runnerYesRunner to route the card to; with to_adapter_id and to_model it must name one enabled, available workforce route whose risk limit covers the card's risk tier.
from_runnerYesRunner the card is pinned to now; a different value is refused with reroute_from_identity_mismatch.
include_cardNoCard view to attach to the receipt: none (default), summary (baselines and evidence folded) or full (the exact post-transition card).none
to_adapter_idYesAdapter id of the replacement route, paired with to_runner.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.12.67
    • addedInput schema / properties / from_runner / description
      Added value: +"Runner the card is pinned to now; a different value is refused with reroute_from_identity_mismatch."
    • addedInput schema / properties / include_card
      Added value: +{
+  "default": "none",
+  "description": "Card view to attach to the receipt: none (default), summary (baselines and evidence folded) or full (the exact post-transition card).",
+  "enum": [
+    "none",
+    "summary",
+    "full"
+  ],
+  "title": "Include Card",
+  "type": "string"
+}
    • addedInput schema / properties / reason / description
      Added value: +"Why the reroute is needed, recorded in the audit receipt and cut to 500 characters; some reroute paths are refused without one. Default empty."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the pending, unclaimed card whose launch identity is rerouted; any other state is refused with reroute_not_pending_unclaimed."
    • addedInput schema / properties / to_adapter_id / description
      Added value: +"Adapter id of the replacement route, paired with to_runner."
    • addedInput schema / properties / to_model / description
      Added value: +"Model of the replacement route; it must equal the model the workforce catalog lists for that runner and adapter."
    • addedInput schema / properties / to_runner / description
      Added value: +"Runner to route the card to; with to_adapter_id and to_model it must name one enabled, available workforce route whose risk limit covers the card's risk tier."
    • addedInput schema / properties / topic / description
      Added value: +"Topic the card is expected to be in; a different live topic is refused. Omit to skip the check."
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the non-read-only, non-destructive, closed-world profile, so the bar is lower, but the description goes further: it states what the reroute attaches server-side (from_runner, to_runner, to_model, refusal and authorization receipts) and the receipt schema version. It omits reversibility and any explicit authorization prerequisites, keeping it below a 5.

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?

The first line front-loads the role and action, and the receipt paragraph is compact and structured. The parenthetical size reference (NF-2026-00500, 55,156 chars) is a slightly eccentric detail but earns its place by justifying the include_card default.

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?

With an output schema present, the description does not need to enumerate return fields, yet it still summarizes the receipt shape and include_card trade-off, covering everything needed to invoke a 5-required-parameter write correctly. Only the manual-vs-automatic reroute distinction is left implicit.

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 description coverage is 100%, so the baseline is 3. The description adds only the include_card semantics and one concrete size datapoint (55,156 chars for a full card), which is genuinely useful but marginal next to the already-detailed schema covering every parameter's refusal semantics.

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?

"COORDINATOR WRITE: explicitly reroute one pending retry launch identity" names a specific verb (reroute), resource (launch identity) and scope constraint (one pending retry). It is clear what the tool does, but it never names or contrasts with the closest siblings (task_retry_terminal, task_stale_recovery_recommend), so differentiation is left to the agent.

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?

The word "explicitly" implies this is the manual counterpart to automatic rerouting, and the schema-level precondition (pending, unclaimed card only) narrows usage. But the description itself states no when-to-use, when-not-to-use, or alternative tools, so guidance is only inferable.

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