Loading ToolBench
A backend application with Express.js, MongoDB, Redis caching, and RabbitMQ message queue integration. Includes user authentication, database operations, and microservice architecture components.
This MCP server has severe definition quality gaps. Tool names lack clear action verbs (e.g., 'fetch_and_cache_posts' violates single-responsibility; 'test_with_rate_limiting' is vague). Descriptions are present but generic (avg ~60 chars, well below the 194-char baseline). Input schemas exist but lack depth: most parameters have minimal descriptions, no enums for constrained values, no format specifications. Output schemas are completely undocumented. Error handling is absent from tool definitions. Security concerns: register/login/delete_user expose authentication logic without permission gates or audit trails. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server appears to be a learning project rather than production-grade tooling.
Create a new task and produce it to RabbitMQ queue
Delete a user account by username
Fetch data from JSONPlaceholder API and store it in Redis cache with key 'posts'
Retrieve posts data from Redis cache with key 'posts'
Log in with username and password, get authentication response
Invalidate session and log out user
Create new account with username, email, and password
Test endpoint that fetches cached posts with IP-based rate limiting (10 requests per hour)
Tool 'fetch_and_cache_posts' violates single-responsibility principle: combines fetching external data AND caching. Should split into 'fetch_posts' and 'cache_posts'.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. E.g., does 'login' return a token? Does 'get_cached_posts' return pagination info?
Authentication tools (register, login, delete_user) lack permission gates and audit trail declarations. No scope declarations (e.g., 'write:user', 'delete:user'). Destructive operations not marked with destructiveHint annotation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
Parameter descriptions are minimal (avg ~15 chars). E.g., 'username' param lacks guidance on format, length, or allowed characters. No enums for constrained values (e.g., task status).
Tool 'test_with_rate_limiting' is vague: unclear whether it tests the rate limiter itself or just calls a rate-limited endpoint. Name does not reflect actual action (get_posts_with_rate_limit would be clearer).