MCP server for the Herdr Orchestrator workflow tools. Provides durable manifest-based workflow orchestration with parent-child agent coordination, goal management, and message routing.
11 tools with mixed quality. All have descriptions (10 - 200 chars, mostly adequate) and input schemas with types. However, critical gaps: (1) Tool names lack action verbs, 'herdr_goal', 'herdr_plan', 'herdr_observe' are noun-heavy and ambiguous about what action occurs. (2) Parameter descriptions are minimal (5 - 30 chars); many lack context on valid ranges, formats, or dependencies. (3) Output schemas are completely undocumented, no response structure defined for any tool. (4) Error handling is absent; no guidance on retryability, user-fixable errors, or recovery paths. (5) Composition issues: herdr_goal, herdr_complete, herdr_close all terminate workflows but differ subtly; naming does not disambiguate. (6) No idempotency guarantees stated. (7) Destructive tools (herdr_operator_close, herdr_close) lack confirmation/dry-run patterns. Baseline: 90% of A+ tools start with action verbs; 100% document return types; 94% have docstrings. This server has docstrings but fails on naming clarity, output documentation, and error guidance.
Bootstrap the root orchestrator identity and initialize the durable manifest for a new orchestration session
Close a workflow and all its lanes, marking them as terminated with a final status
Mark a workflow as complete with a summary, triggering parent notification and manifest update
Dispatch a planned workflow to child agents, launching them with their lane assignments and initial goals
Manage parent goal lifecycle: start, pause, resume, or complete the orchestrator's parent goal with status tracking and supervisor state management
Observe and retrieve current state of workflows, lanes, messages, and goals from the durable manifest
Tool names lack action verbs. 'herdr_goal', 'herdr_plan', 'herdr_observe' are noun-centric and do not signal the action (start, create, get). LLMs infer intent from names first, ambiguous names cause wrong tool selection.
No output schemas documented. Tools return structured data but LLMs cannot plan downstream calls without knowing response fields. E.g., herdr_observe returns 'workflows', 'lanes', 'messages', 'goals', 'manifest', none documented.
Parameter descriptions are minimal (5 - 30 chars). E.g., 'pauseReason' is 'Reason for pausing (required when action is pause)', lacks context on format, length, or examples. LLMs cannot infer constraints from bare names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Close extension-owned resources (workflows, lanes, messages) with evidence of completion, requiring explicit authorization
Create a workflow plan with lanes for child agents, defining the orchestration structure and lane mappings
Answer a parent question that was previously requested by a child workflow, routing the response back through the durable message system
Reconcile root state with controller, syncing goal status, workflow state, and message delivery across the durable system
Resume a paused or blocked workflow lane, continuing execution with optional new instructions
Destructive tools (herdr_operator_close, herdr_close) lack confirmation or dry-run patterns. Agents can irreversibly close workflows without a safety gate. No error guidance on recovery.
Three tools terminate workflows (herdr_goal with 'complete', herdr_complete, herdr_close) but naming does not disambiguate. Unclear when to use each. Composition violates single-responsibility principle.