Loading ToolBench
FastMCP server for Celery Root - Command & Control for Celery Workers. Provides tools for querying task state, worker status, database schemas, and executing SQL queries against Celery task event stream and worker monitoring data.
Celery Root MCP server demonstrates solid tool definition quality with comprehensive parameter schemas and consistent descriptions. All 14 tools have documented input schemas with type definitions and parameter descriptions. Tool names follow verb_noun conventions (get_*, create_*, update_, delete_*) and are appropriately specific. However, output schemas are not documented in the source code, parameter descriptions lack detailed constraints (enums, ranges, formats), and descriptions are moderate length but could be more LLM-optimized with dependency hints. Error handling guidance is not visible in the source. The server uses fastmcp with HTTP transport (compliant), but lacks optional MCP features like sampling, elicitation, and structured error reporting.
Returns database schema catalog with table descriptions, query examples, and notes about available tables (tasks, task_events, task_relations, workers, worker_events, broker_queue_events, schedules, schema_version) and usage instructions.
Execute read-only SQL queries against the Celery Root database. Supports named parameters (e.g. :root_id) for parameterized queries. Returns query results as structured data.
Fetch detailed column-level schema information for a specified database table. Returns column names, types, and nullability for tables like tasks, task_events, workers, etc.
Retrieve broker queue depth snapshots with optional filtering. Returns message counts, consumer counts, and timestamps for queues. Supports filters by broker URL and queue name.
Retrieve Beat schedules stored in the database. Returns schedule definitions, task names, enabled status, last run time, and run count for each scheduled task.
Retrieve detailed information about a specific task by its task_id. Returns task state, worker, timing information, arguments, results, and traceback if available.
Output schemas are not documented in source code. LLMs cannot determine what fields to expect from tool responses, forcing them to reason about downstream data extraction and limiting composability.
Parameter descriptions lack concrete constraints. 'SQL query to execute (read-only)' doesn't specify which SQL dialects are allowed, max length, or blacklisted keywords. 'Maximum number of tasks to return (default: 100)' lacks minimum/maximum bounds. Descriptions should follow the pattern: 'The X (format: Y, range: Z, e.g. example)'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Retrieve task event stream records with optional filtering. Returns raw task events including state transitions, timing information, and task metadata. Supports filters by task_id, state, worker, and time range.
Retrieve task relationship/dependency graph for tasks within a workflow identified by root_id. Returns parent-child task relations showing workflow structure.
Retrieve tasks with optional filtering by task name, state, worker, time range, search query, group_id, or root_id. Returns a list of task records matching the filter criteria.
Retrieve raw worker event stream records with optional filtering. Returns worker lifecycle events including online/offline transitions, heartbeats, and status changes. Supports filters by hostname and time range.
Retrieve information about all workers or a specific worker by hostname. Returns worker status, heartbeat timestamp, pool size, active task count, registered tasks, and assigned queues.
Fetch aggregated task statistics grouped by task name. Returns count, average runtime, min/max runtime, and percentile metrics (p95, p99) for each task name.
No error handling guidance visible in source code. When db_query fails with invalid SQL or get_tasks filters fail, LLMs receive raw errors with no recovery path. Error responses should state: 'Invalid status: got X, must be one of: Y, Z' and suggest corrective tools.
Enum parameters not declared as enums. The 'state' parameter in get_tasks and schedule format in create_schedule/update_schedule accept only specific values ('pending', 'success', 'failed' for state; 'cron' or 'interval' format) but are defined as generic strings. This invites hallucinated values. Convert to JSON Schema enums.
Destructive tool (delete_schedule) lacks confirmation pattern. No evidence of dry-run support or explicit confirmation step. Agents should never delete irreversible resources in one step. Implement a confirmation_before_delete pattern.
Tool descriptions do not include dependency hints. For example, create_schedule takes a 'task' parameter but doesn't state 'Call get_tasks() first to discover available task names'. This forces agents to guess when to call discovery tools.
Pagination not explicitly documented. get_tasks, get_task_events, get_worker_events have a 'limit' parameter but no indication whether results are paginated, whether a cursor or offset is returned, or whether there is a total count. Large result sets could blow the context window.