Loading ToolBench
A server for managing tickets using Model Context Protocol and Firestore
The server defines 7 tools with generally clear naming and basic schemas. Tool names follow verb_noun convention (create_ticket, get_tickets, update_ticket, delete_ticket, run_gemini, monitor_process). However, several issues limit overall quality: (1) Most tools lack per-parameter descriptions in their descriptions text (parameter descriptions exist in schema but are minimal); (2) Output schemas are not documented, tools return generic {content:[{type:text, text:...}]} with no structured schema definition; (3) Some parameter descriptions are vague (e.g., 'executionPlan' in create_ticket lacks context on format or length); (4) Error handling is minimal, most tools return text responses without guidance on recovery; (5) The 'run_gemini' tool description says 'This execute a task' (grammatical error) and lacks clarity on what happens if the ticket doesn't exist or if Gemini fails. Average tool score: 58. The server is serviceable but has noticeable gaps in description quality, schema documentation, and error messaging.
Creates a new ticket in the system. Requires title, description, and execution plan.
Deletes a ticket by its ID.
Returns a ticket by its ID.
Returns all tickets in the system.
Monitors the Gemini process for a given ticket. Gets logs, status and output.
Runs the Gemini model with a given prompt for a ticket. This execute a task.
Updates an existing ticket by ID. You can update title, description, execution plan, or status.
Output schemas not documented. All tools return generic {content:[{type:'text', text:...}]} with no structured schema definition. LLMs cannot parse field names, types, or nested structures. This violates the pattern:tool requirement to document output schema.
run_gemini description has grammatical error ('This execute a task') and lacks clarity on failure modes. What happens if the Gemini process fails? What does 'execute a task' mean to an LLM? Description is too vague to guide tool selection.
get_tickets tool has no pagination support (no limit, offset, or page_size parameters). If hundreds of tickets exist, returning all in one response will exhaust context window and waste tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Parameter descriptions are minimal or missing context. E.g., 'executionPlan' in create_ticket is described only as 'Execution plan for the ticket', no guidance on format (free text? step list? code?), length constraints, or examples.
Error handling lacks recovery guidance. When get_ticket or update_ticket fails (e.g., ticket not found), the tool returns plain text but does not guide the LLM on what to do next. Per pattern:recovery-guide, errors must tell the LLM what to do: 'Ticket not found. Try search_tickets() or call get_tickets() to list available tickets.'
delete_ticket lacks a confirmation or dry-run mode. Destructive operations should support a confirm step to prevent accidental data loss. Per pattern:confirmation-request, irreversible operations should warn or require confirmation.
monitor_process tool description is vague: 'Monitors the Gemini process for a given ticket. Gets logs, status and output.' What format are logs? Is status a string, enum, or object? What does 'output' contain? LLMs cannot plan with this level of ambiguity.
Tool names do not clearly distinguish intent. 'run_gemini' is generic, does it run a model, execute a task, or call an API? A clearer name like 'execute_ticket_task_with_gemini' or 'start_ticket_execution' would self-document better.