Loading ToolBench
An MCP server for managing a team of agents with task assignment, messaging, and agent lifecycle management
GooseTeam has 12 tools with basic schema definitions via Zod validators and JSON Schema conversion. All tools are explicitly registered in src/goose-team.ts with names, descriptions, and inputSchemas. However, descriptions are uniformly terse (10-45 chars), well below the 194-char baseline for production tools. Parameters lack rich documentation, most have minimal descriptions ('Task ID', 'Agent ID') rather than actionable guidance. Output schemas are undocumented; return types are inferred from code but not declared in tool definitions. Error handling is minimal: most tools throw or return success strings without recovery guidance or actionable error messages. The server demonstrates basic MCP compliance but lacks the depth of documentation needed for confident LLM usage in ambiguous scenarios.
Add a new message
Add a new task
Allow an agent to leave the team
Wait for a specified number of seconds
Assign a task to an agent
Clear all messages
Complete a task
List all registered agents
Retrieve all messages
Tool descriptions are uniformly terse (10-45 chars), far below the 194-char baseline. E.g., 'Register a new agent' (22 chars), 'Retrieve recent messages' (24 chars). Descriptions lack WHAT the tool does, WHEN to use it vs similar tools, and output structure. LLMs cannot confidently select tools without richer context.
Parameter descriptions are minimal or missing context. 'Agent ID is required' and 'Task ID' state existence but not meaning, is this a system UUID, a numeric ID, or a display name? No guidance on format, range, or dependencies. Pattern baseline expects 72 chars per param; these average 20-30 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
List all tasks
Retrieve recent messages
Register a new agent
Output schemas are not documented in any tool definition. The ListToolsRequestSchema response includes only 'name', 'description', and 'inputSchema', but what does each tool return? E.g., register_agent returns JSON, but the structure (fields, types) is not declared in the tool definition. LLMs cannot plan downstream calls without knowing return types.
Error handling lacks recovery guidance. In src/goose-team.ts CallToolRequestSchema handler, errors from schema.parse() are not caught; they propagate as uncaught exceptions. No try/catch wraps tool handlers to return structured error responses. LLMs receive stack traces or bare exceptions instead of actionable messages like 'Agent not found. Available agents: [list]'.
Destructive tool clear_messages has no confirmation step or dry-run mode. An LLM could irreversibly delete all messages without user approval. Pattern tool:confirmation-request recommends guards on irreversible operations.
Tool names lack consistent verb_noun structure. Examples: 'agent_leave' (leave_agent would be clearer), 'list_messages' vs 'list_tasks' (consistent), but 'add_message' and 'add_task' vs 'register_agent' (inconsistent verbs, register vs add). LLMs may conflate similar tools when naming conventions vary.
No parameter constraints declared for numeric fields. agent_wait accepts 'seconds' with 'minimum: 0' in Zod schema, but there is no maximum, LLM could pass 999999999 seconds. Numeric parameters should have bounds in description: 'seconds: 0 - 3600'.