Loading ToolBench
A Frisbee Team MCP server for managing players
This server has 19 tools with consistent naming, moderate description quality, and complete JSON schemas. However, there are systematic issues: (1) descriptions are generic and lack actionable context for LLM tool selection, most are under 100 chars and don't explain WHEN to use the tool or how it differs from similar tools; (2) parameter descriptions are minimal and missing constraints (e.g., 'surface' accepts only 'grass' or 'beach' but this is not documented in the param description, only implied); (3) no error handling guidance, tools have no documented recovery paths or error categorization; (4) output schemas are not documented, LLMs cannot predict what fields to expect from responses; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels being tracked internally; (6) composition gaps, several tools operate on the same entities with potential ambiguity (e.g., 'mark-payment' and 'clear-payment' both modify tournament payment state but lack guardrails). The server follows basic patterns (naming is clear with action verbs, schemas are present and typed) but lacks the rigor expected of production-grade agent tools.
Add a federation payment for a player.
Add a new player to the database.
Add a new tournament to the database.
Backup the database to a file.
Clear a player's tournament payment status.
Import players from a CSV file, updating existing players. CSV must have headers. The following headers are recognized: - name/nombre: The player's name (required) - phone/telefono: The player's phone number (required) - email: The player's email address (optional)
List all federation payments for a player.
Parameter descriptions lack constraints and formats. 'surface' accepts only 'grass' or 'beach' but this is documented only in the tool description text, not in the parameter description itself. LLMs cannot parse free-text constraints, they need formal enums or explicit format rules in param descriptions.
No output schemas documented. Tools return strings (e.g., 'Player X added successfully') with no structured field definitions. LLMs cannot predict the response schema or extract specific fields for downstream tool calls. This violates the pattern:response-shaper pattern and breaks tool chaining.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
List all tournaments a player is registered for.
List players in the database.
List all players registered for a tournament with their payment status.
List tournaments in the database.
Mark a player's tournament payment as completed.
Register a player for a tournament.
Remove the most recent federation payment for a player.
Remove a player from the database.
Remove a tournament from the database.
Search for players who have paid for a tournament with fuzzy name matching.
Unregister a player from a tournament.
Update an existing tournament.
Tool descriptions are generic and lack WHEN/WHY guidance. 'List players in the database' is functional but does not explain when an LLM should call this instead of a related tool, what structure is returned, or what a common follow-up action might be. Descriptions should be 50 - 200 chars and answer: What does it do? When to use it? What does it return?
No error handling or recovery guidance. Tools have no documented error paths, categorization (retryable vs fatal), or actionable error messages. If a tool fails, the LLM has no guidance on what to try next. This violates pattern:recovery-guide.
No tool annotations despite clear risk levels. The internal risk enum tracks WRITE, READ_ONLY, and DESTRUCTIVE, but these are not exposed to the MCP protocol via readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot determine tool safety without this metadata.
Ambiguous 'remove-last-federation-payment' naming. The name does not clearly signal irreversibility or what 'last' means (chronologically? by amount?). The description is minimal. This should be 'delete-last-federation-payment' and include a note on what 'last' means.
Date parameter formats are documented as 'YYYY-MM-DD' in descriptions but not as format constraints in JSON Schema. LLMs may ignore free-text format hints and pass invalid dates. Use JSON Schema 'format': 'date' or add explicit validation guidance.
No pagination or limit enforcement documented. 'list-players' and 'list-tournaments' accept a limit parameter but do not document the maximum allowed value, default behavior on missing limit, or what happens if more results exist than the limit. This can cause context window exhaustion.
Potential non-idempotent operations without guardrails. 'mark-payment' with optional payment_date could be called multiple times with different dates, causing repeated state changes. No confirmation step or dry-run option exists. Consider idempotent-operation pattern for payment tools.