FastMCP server: project context, configurable assistants, and task delegation.
Single tool 'agent_handoff' has a complete input schema with proper types and enums, but the description is verbose (250+ chars) and mixes implementation details with usage guidance. Parameter descriptions are present but generic. No output schema is documented. The tool performs multiple distinct actions (write/read/resolve) under one name, violating single-responsibility principle. Error handling and recovery guidance are absent.
Write, read, or resolve handoff notes between agents. Notes persist locally (JSON) until resolved. Args: action: write (leave a note), read (fetch open notes addressed to `to`), or resolve (close a note by id). to: Recipient — an agent or context name (e.g. "frontend-agent"). message: Note body (required for write). from_agent: Name of the agent leaving the note (default "default"). note_id: Note id (required for resolve). Returns: JSON result.
Tool name 'agent_handoff' combines three distinct actions (write, read, resolve) into one tool. Should split into separate tools: create_handoff_note, list_handoff_notes, resolve_handoff_note. LLMs struggle with multi-action tools and cannot compose them independently.
No output schema documented. Tool description states 'Returns: JSON result' but does not specify what fields are in that result. LLMs cannot plan downstream calls or extract required data without knowing the response structure.
Description is 250+ characters and mixes implementation details ('Notes persist locally (JSON)') with usage guidance. Baseline for A+ tools is 50-200 chars. Trim to: 'Create, retrieve, or close handoff notes between agents. Notes are stored locally and persist until resolved.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Parameter 'message' has default empty string but is marked required for 'write' action. Undocumented dependency: message is only required when action='write'. This must be stated in the parameter description to prevent LLM errors.
No error handling or recovery guidance. Tool description does not explain what happens if note_id is invalid, if 'to' recipient does not exist, or if the local store is corrupted. LLMs need actionable error messages to self-correct.