Strategic task prioritization and agent orchestration for multi-project operators
Quarterback has 9 tools with complete input schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (get_*, add_*, update_*, list_*) which is good. However, parameter descriptions are sparse or missing entirely, most params lack explanations of their purpose, constraints, or expected format. Output schemas are not documented anywhere in the visible code. Error handling is absent from tool definitions. The server loads organizational context (goals, constraints, workflows) but does not expose this context to tools via descriptions, leaving LLMs unable to understand when/why to call tools like assess_task_value or detect_conflicts. Schemas are present and mostly well-formed (enums, min/max constraints), but descriptions do not explain what the tool returns or when to use it instead of similar tools.
Add a new project.
Add a new task with full metadata.
Assess whether a proposed task aligns with organizational goals.
Detect conflicting priorities and resource constraints.
Get tasks that are blocking other work.
Get prioritized list of tasks based on organizational context.
Identify quick win tasks (high impact, low effort).
Parameter descriptions are missing or trivial. Most params (e.g., 'project_name', 'status', 'limit') lack explanations of their purpose, valid ranges, or constraints. LLMs cannot infer whether 'status' means task status, project status, or something else.
Output schemas are not documented. Tool descriptions do not explain what fields are returned, their types, or how to use them in downstream calls. This forces LLMs to guess the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
List all projects.
Update an existing task.
detect_conflicts and assess_task_value have minimal descriptions (35-40 chars). These tools reference organizational context (goals, constraints) but do not explain what they do, when to call them, or what they return. LLMs cannot determine if these tools are relevant.
No error handling guidance in tool definitions. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. Error responses will likely be raw exceptions.
add_task and add_project lack confirmation/dry-run patterns for irreversible operations. Agents can create tasks/projects without preview or confirmation, risking accidental data creation.