Loading ToolBench
AI-powered children's education platform with microservices for text generation, user management, content delivery, and API gateway. Provides story and quiz generation, user authentication, and content management for an educational platform.
The server exposes 27 tools across multiple services (text generation, user management, API gateway) with significant quality gaps. While most tools have basic descriptions and identified input schemas, the schemas are severely underspecified (missing type information for nested objects), parameter descriptions are generic or absent, and error handling is not visible in the provided source. The tool set shows poor composition with generic proxy tools (proxy_request) that violate single-responsibility principles. Service-to-service communication is exposed directly as MCP tools rather than being abstracted into coherent user-facing operations. No evidence of output schemas, pagination parameters for list operations, or idempotent operation markers. Descriptions average 80-120 characters but lack actionable context about when to use each tool.
Cancel a pending or processing task. Attempts to cancel a task that is still in the pending or processing state. Returns an error if the task is not found or cannot be cancelled.
Reset password using a reset token
Create a child account for current user (parent role)
Delete a child
Start a quiz generation task. Creates an asynchronous task to generate a quiz based on the provided parameters. Returns a task ID that can be used to check the status and retrieve the result.
Start a story generation task. Creates an asynchronous task to generate a story based on the provided parameters. Returns a task ID that can be used to check the status and retrieve the result.
Nested object schemas lack type definitions. Every tool with a 'request' or 'user_update' parameter shows `{"type":"object","description":"..."}` with no properties defined. This violates JSON Schema best practices and prevents LLM parameter inference.
Generic proxy_request tool exposes raw HTTP routing as an MCP tool, violating single-responsibility principle. This tool accepts arbitrary paths and methods, making it impossible for LLMs to understand what it does or when to use it. It should be removed and replaced with domain-specific tools.
No pagination parameters visible for list operations (get_user_tasks, get_templates, get_current_user_children). While skip/limit appear in some, most list tools lack documented limits and next_cursor fields. Large result sets could overflow context windows.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Get a child by ID
Get child preferences
Get child restrictions
Get all children for current user (parent role)
Get current user profile
Get current user settings
Get the result of a completed generation task. Returns the generated content for a completed task. Returns an error if the task is not found or not completed.
Get the status of a generation task. Returns the current status of the specified task, including timestamps for creation, start, and completion (if applicable).
Get a story template by ID. Returns the details of a specific story template.
Get story templates. Returns a list of available story templates, with optional filtering.
Get tasks for the current user. Returns a list of tasks for the authenticated user, with optional filtering by status.
List all available API routes.
List all registered services and their status.
Login and get access token
Proxy all requests to the appropriate service. Routes incoming HTTP requests to the appropriate backend microservice.
Request a password reset token
Update a child
Update child preferences
Update current user password
Update current user profile
Update current user settings
Parameter descriptions are generic and do not explain when to use tools or what constraints apply. Example: 'Update child preferences' with a single 'preferences' object parameter tells the LLM nothing about what fields are valid or how to structure the object.
No evidence of output schemas for any tool. LLMs cannot plan downstream operations or understand what fields to extract without knowing the response structure. This blocks tool chaining.
Destructive operations (delete_child, confirm_password_reset, update_current_user_password) lack confirmation/dry-run patterns. No error handling guidance visible. Agents could trigger irreversible actions without safeguards.
Password parameters (login.password, confirm_password_reset.new_password) are exposed as tool parameters. Credentials in parameters risk logging and leaking into agent traces. Should use server-side secret injection.
Tool naming shows inconsistency: get_current_user_profile vs get_child (not 'get_current_child'). Some tools accept child_id parameters forcing LLMs to reason about family relationships, others expose parent-only operations. No clear separation of parent vs child capabilities.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). This prevents MCP clients from rendering appropriate UI warnings or preventing accidental destructive operations.
List endpoints (get_templates) have theme, age_min, age_max, educational_focus as free-form strings. No enums, patterns, or valid value lists provided. LLMs will guess at valid theme names.