Loading ToolBench
The server defines 27 tools with consistent verb_noun naming (list_, get_, create_, update_, delete_, search_) and reasonable parameter schemas. However, tool descriptions are generic and lack LLM-optimization guidance. Many parameters lack detailed constraint descriptions (e.g., limits, formats, dependencies). Output schemas are not documented. Error handling is basic with no recovery guidance. The schema quality is uneven: some tools like list_tasks have well-structured inputs with enums and defaults; others like get_dashboard_home lack parameter documentation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared. The server is functional but lacks production-grade polish in description clarity, output documentation, and error messaging.
Assign a task to a team member.
Add a comment to a task.
Create a new task. Returns the created task.
Soft delete a task. The task will be marked as deleted but not permanently removed.
Get aggregated dashboard home statistics including users, gifts, and bookings time series data. Returns cumulative counts by day, today/yesterday comparisons, provider distribution, and gift statistics.
Get platform engagement metrics including gift funnel (published → bookings → assigned → delivered), conversion rates, active users today, average gifts per user, and average bookings per gift.
Tool descriptions lack LLM optimization and context. Most descriptions (e.g., 'Get task statistics including today's count, yesterday's count, and status breakdown.') are 50-100 chars, below the 194-char baseline for production tools. They omit WHEN to call the tool and WHAT distinguishes it from similar tools.
Output schemas are not documented. The code returns structured data (e.g., 'returns task list with pagination info' for list_tasks), but LLMs cannot see the field types, required fields, or return shape. This forces LLMs to guess what fields are available and risks failed downstream tool calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get all bookings/reservations for a specific gift. Shows who requested the gift and their status in the booking workflow.
Get complete details for a specific gift including description, images, owner data, location, bookings, and delivery status.
Get aggregated statistics about gifts: total count, assigned count/percentage, delivered count/percentage, gifts with bookings.
Get user growth metrics including total users, new users (today/week/month), active users (DAU/WAU/MAU), stickiness ratio, one-time users percentage, and optionally retention cohorts.
Get geographic impact data showing CO2 saved per city. Returns array of cities with coordinates, gift count, and CO2 statistics. Useful for mapping environmental impact.
Get environmental impact metrics including total completed gifts, CO2 saved (kg, formatted, tons), and top 5 categories by CO2 impact.
Get detailed information about a specific task, including assignee, project, subtasks, and comment count.
Get task statistics including today's count, yesterday's count, and status breakdown.
Get all bookings/reservations made by a specific user. Shows gifts they have requested or received.
Get complete details for a specific user including profile data, stats (points, level, donations, adoptions), and account information.
Get all gifts published by a specific user. Returns gift list with status (assigned, delivered, public).
Get all comments for a task, ordered by creation date (newest first).
Get a paginated list of all platform gifts. Returns gift summaries with basic info like name, category, owner, status, and location.
List all available projects. Use this to find project IDs when creating tasks.
Get all subtasks of a parent task.
List tasks with pagination and filters. Returns task list with pagination info.
Get a paginated list of all platform users. Returns user summaries with basic info like name, email, provider, registration date, and location.
Search and filter gifts with server-side pagination and sorting. Supports search by name, description, or owner. Can filter by status (available, assigned, delivered).
Search and filter users with server-side pagination and sorting. Supports search by name, email, UID, or location. Can filter by authentication provider.
Update an existing task. Only provided fields will be updated.
Quickly update only the status of a task.
Parameter descriptions are minimal or missing constraint details. For example, 'limit' in list_tasks has description 'Items per page (default: 50, max: 100)' but no validation guidance for LLMs on what happens if they exceed the max. Parameters like 'sortBy' list allowed values in description text, not as formal enum constraints, increasing risk of hallucinated values.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server classifies tools by risk (READ_ONLY, WRITE, DESTRUCTIVE) in documentation, but does not emit these as tool annotations in the MCP schema. This prevents clients from applying safety policies (e.g., confirming destructive operations, prioritizing read-only tools).
Error messages are generic and provide no recovery guidance. The error handler (src/tools/index.ts) returns messages like 'Not found: <message>', 'Bad request: <message>', and 'Validation error: <message>' without actionable next steps. Pattern tool-recovery expects 'If X failed, try Y' guidance.
Destructive tool (delete_task) lacks confirmation or dry-run support. Users can soft-delete tasks via a single call with no confirmation step. While the delete is soft (not permanent), the pattern still recommends a confirmation-request for irreversible-appearing operations to prevent accidental deletions triggered by agentic logic errors.