Loading ToolBench
A FastAPI-based educational MCP server demonstrating stateful chat sessions with Redis backend, rate limiting, and AI integration across multiple modules
This server exhibits critical deficiencies across naming, descriptions, and schema definition. Tool names are inconsistent and often vague (e.g., 'read_root', 'handle_chat', 'start_chat_session' vs 'continue_chat_session', no consistent verb_noun pattern). Most critically, NO EXPLICIT TOOL REGISTRATION is visible in the provided source code. The code shows FastAPI route handlers and Flask endpoints, but there is no visible MCP server implementation, no explicit tool schema definitions, and no evidence that these are actually registered as MCP tools with proper JSON Schema. Parameter schemas are largely inferred from parameter names in docstrings rather than formally defined. Descriptions vary wildly in quality: some are single sentences in Turkish without WHEN/WHY context (e.g., 'Yeni, benzersiz bir oturum ID'si oluşturur ve döndürür', 'Creates and returns a new unique session ID'), others are slightly better but still lack detail. No output schemas are documented. No error handling guidance is present. The server architecture shows multiple independent modules (modul1, modul2, modul3, modul5) suggesting educational scaffolding rather than a unified MCP implementation.
Mevcut bir sohbet oturumuna devam eder.
Yeni, benzersiz bir oturum ID'si oluşturur ve döndürür.
Handles stateless chat requests; processes user messages without maintaining conversation history
Uygulamanın çalışıp çalışmadığını kontrol etmek için basit bir endpoint.
Belirtilen oturumu ve tüm konuşma geçmişini Redis'ten siler.
Yeni bir sohbet oturumu başlatır.
NO VISIBLE MCP TOOL REGISTRATION: The provided source code shows FastAPI and Flask HTTP endpoints, but there is NO explicit MCP server implementation, no ToolCall handlers, no tool schema definitions in JSON Schema format, and no evidence these endpoints are registered as MCP tools. Tool definitions appear to be INFERRED from docstrings rather than formally declared. This violates the MCP protocol contract.
INCONSISTENT NAMING CONVENTIONS: Tool names do not follow verb_noun pattern consistently. 'read_root' is not an action verb applied to a resource (read what? root what?). 'handle_chat' is generic (handle = unclear action). 'continue_chat_session' is clear, but 'start_chat_session' and 'create_session' both create, why two names? Missing consistent verb_noun structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
INPUT SCHEMAS MISSING OR NOT VISIBLE: Most tools lack formal JSON Schema definitions visible in source code. 'create_session' shows empty input {}, which is correct, but others (e.g., 'handle_chat', 'start_chat_session') have parameters documented in docstrings only, not in registered schema definitions.
DESCRIPTIONS LACK LLM-OPTIMIZED CONTEXT: Many descriptions are under 50 characters and written in Turkish without WHAT/WHEN/WHY structure. Example: 'Yeni, benzersiz bir oturum ID'si oluşturur ve döndürür' (Creates and returns a new unique session ID), missing: when to call this, what to do with the returned ID, any prerequisites.
NO OUTPUT SCHEMA DOCUMENTATION: None of the tools document what they return. LLMs need to know: what fields are in the response? Are there pagination fields? What IDs are available for chaining to other tools? Absence of return schema documentation violates pattern:response-shaper.
NO ERROR HANDLING GUIDANCE: Tools lack error response documentation. What if session_id is invalid? What if Redis is unavailable? What should the LLM do? No recovery guidance, no error classification (retryable vs fatal). Per pattern:recovery-guide, errors must tell the agent what to do next.
STATEFUL SESSION MANAGEMENT ANTI-PATTERN: The server maintains session state in Redis and expects clients to track session_id across calls. This is a stateful protocol violation for MCP, which requires each request to be self-contained. Clients cannot reliably persist session IDs in hostile environments (e.g., browser-based agents). The design forces multi-step flows: create_session → start_chat_session → continue_chat_session, when a single stateless chat tool would be more robust.
PARAMETER DESCRIPTIONS MISSING OR MINIMAL: 'session_id' appears in multiple tools with minimal description ('The session ID to delete', 'The session ID to continue'). These descriptions lack format guidance, constraints, or examples of valid session_id format.
DESTRUCTIVE OPERATION WITHOUT CONFIRMATION: 'remove_session' is marked DESTRUCTIVE but shows no evidence of a confirmation pattern. Per pattern:confirmation-request, irreversible operations should support dry-run or require explicit confirmation to prevent agent mistakes.
OVERLAPPING TOOL FUNCTIONALITY: 'create_session' and 'start_chat_session' both appear to initiate sessions, but differ in signature. 'create_session' takes no input; 'start_chat_session' takes a message. This creates ambiguity: which tool does the LLM call first? Should they be merged or clearly distinguished by different names (e.g., 'create_empty_session' vs 'create_and_start_chat_session')?