Loading ToolBench
A Flask-based web application for blind users to navigate using AI-powered features including real-time video analysis for detecting tactile paving paths, voice commands, map navigation, family contact management, and multi-modal AI settings (cloud or local Ollama)
This server exhibits pervasive structural deficiencies across naming, descriptions, and schema completeness. While 20 tools are declared, nearly all lack proper MCP-style registration, parameter schemas are incomplete or missing entirely, and descriptions are often generic or absent. The codebase shows a Flask web application with routes but no evidence of MCP tool registration, introspection, or protocol implementation. Tools appear to be inferred from route handlers rather than explicitly defined as MCP resources.
Unified chat interface that routes user messages to different agents based on intent: settings, map navigation, family messages, or general conversation
Add a new family contact for the current user
Reset user password using email verification code
Get available AI model presets (cloud providers, default Ollama endpoint) and their metadata
Get current user's AI configuration (cloud or local Ollama) with masked API keys for security
Get the system's available voice list for text-to-speech
Retrieve the current user's settings
No MCP tool registration visible. Tools are inferred from Flask route handlers (routes/main.py, routes/auth.py, etc.) but no explicit MCP tool definitions, schemas, or server-side introspection. Code shows @main_bp.route decorators, not tool registration.
Missing or incomplete parameter descriptions. Many tools have schemas with properties but no descriptions for individual parameters. E.g., login has 'username' and 'password' params with descriptions in the rubric assessment, but the actual Flask code (app.py, routes/auth.py) does not show explicit schema definitions with per-parameter documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Get detailed information about the current user including username, email, phone, creation date, and last login
Get the current user's list of family contacts
User login with username and password
User logout - clears session
Probe a local Ollama endpoint to check if it's online and list available models
User registration with username, password, email, and verification code
Delete a family contact by ID
Send a message from family member to blind user with voice announcement
Send an email verification code for registration or password reset
Convert audio file to text using STT (Speech-To-Text) with optional stutter correction
Test voice settings by playing a sample text with specified voice speed and volume
Update current user's AI configuration (deployment type and local Ollama settings)
Update user settings such as voice speed, voice volume, user mode, gender, name, age, and encourage functionality
Generic or missing tool descriptions.
No output schemas documented. The rubric requires documenting return types for all tools. Source code shows Flask jsonify() returns but no formal specification of response structure, field types, or pagination. This forces LLMs to guess what fields are returned.
Weak error handling and recovery guidance. Code shows basic try-except with generic error messages ('保存设置失败: {str(e)}', 'Failed: {str(e)}'). No error categorization (retryable vs fatal), no recovery hints, no validation of input constraints. LLM cannot determine next action on failure.
Credentials exposed in authentication flow. login, register, forget_password accept 'password' and 'confirm_password' as parameters. While this is standard web practice, MCP tools should use server-side secret injection. If logs capture request bodies, passwords appear in agent traces.
No tool annotations. The spec (2026-07-28) rewards toolAnnotations with readOnlyHint, destructiveHint, and idempotentHint. The server declares risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but these are not present in the actual MCP tool definitions, no annotations visible in code.
Parameter naming and typing gaps. Tools like 'update_settings' accept arbitrary string enums (voice_speed: '慢'|'中等'|'快') without formal enum constraints in the schema. Chinese characters in enum values are valid but descriptions lack English equivalents, LLM may struggle to reason about or select correct values.
No pagination for list tools. list_family_contacts returns all contacts with no limit, offset, or pagination fields. If a user has hundreds of contacts, the response bloats the context window. Per the rubric, list tools must support page/offset and limit.
No multi-round-trip request (MRTR) support for confirmation. Destructive tools like remove_family_contact lack a dry-run or confirm step. An agent could delete critical contacts without user approval. MRTR with result 'input_required' would enable confirmation patterns.