Loading ToolBench
A comprehensive educational platform and documentation site for AI-powered development workshop with 30 modules covering fundamentals to enterprise mastery. Built with Docusaurus for documentation hosting and Python/FastAPI for example microservices.
This server presents a fundamental architectural mismatch for MCP: it is a documentation platform (Docusaurus) with embedded FastAPI microservice examples, not an actual MCP server implementation. No MCP protocol is present in the codebase. Tool definitions are inferred from exercise starter files scattered across module directories, not from a cohesive MCP server registration. Descriptions exist but are minimal (20-50 chars). Schemas are present but incomplete, many lack comprehensive type definitions for nested object parameters (e.g., 'user' object in create_user has no visible nested schema). No error handling, no output schemas documented, no security patterns visible. The 'tools' listed are actually FastAPI endpoints from educational exercise starters, not MCP tool registrations.
Create a new user via POST endpoint
Delete a user by ID
Aggregate order details from multiple microservices
Get a specific user by ID
Health check endpoint for User Service
Gateway health check with service status
List all users with pagination support
Proxy requests to appropriate microservices via API Gateway
No MCP server implementation detected. Repository is a documentation platform (Docusaurus) with embedded educational FastAPI exercise code. Tools are inferred from exercise starter files, not registered via MCP protocol. This is not a functional MCP server.
Tool definitions are scattered across exercise starter files with no centralized MCP registration. Tools are not explicitly registered with MCP; definitions must be inferred from FastAPI endpoint code in modules/module-11/exercises/. This violates tool registration best practices.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Update an existing user
Input schemas for complex objects (user, user_update, request in proxy_request) lack detailed nested type definitions. The 'user' parameter in create_user is defined as type:object with generic description 'User creation payload (UserCreate model)' but the actual UserCreate schema is not visible or documented.
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses. list_users should document returned fields (id, name, email, created_at, etc.); create_user should document the created user object structure.
Descriptions are minimal (20-50 chars) and lack action clarity. 'Create a new user via POST endpoint' is procedural, not intent-based. Better: 'Create a new user account with email, name, and password. Returns the created user with id and created_at timestamp.' Include WHEN to use (new signup), WHAT is returned, and any prerequisites.
No error handling guidance. Tools declare risk (WRITE, DESTRUCTIVE) but provide no recovery steps. delete_user has no error schema documenting what happens if user_id is invalid, not found, or if the user is referenced by other records. Agents need: 'If user not found, call list_users() to find the correct ID.'
proxy_request is a generic pass-through tool that accepts arbitrary service_name, path, and request objects. This violates the single-responsibility principle and creates a security risk (allows agents to invoke any microservice without explicit tool definition or permission gates). Split into specific microservice tools: create_order, get_inventory, check_payment_status, etc.
No pagination support visible in schema. list_users accepts skip and limit but no output documents total_count or next_cursor. Without this, agents cannot iterate large result sets. Add total_count to response and cap default limit (e.g., limit defaults to 20, max 100).
No permission checks or scope declarations visible. create_user, update_user, and delete_user lack any mention of required permissions (write:users, admin:users, etc.). Agents cannot be configured with least-privilege access.
Parameter descriptions are sparse. user_id is described as 'UUID of the user to retrieve' but does not state format (e.g., 'UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx') or what to do if the format is wrong. limit and skip lack range constraints (should be: 'Positive integer, 1 - 100').