Loading ToolBench
A Flask-based REST API backend for health data management that processes natural language queries and returns MCP tool requests and operation manuals. Provides endpoints for user profile management, health metrics tracking, and intelligent assistant capabilities.
This MCP server exposes 2 tools with basic Flask resource handlers. Both tools have descriptions and parameter schemas, but critical gaps exist: parameter descriptions lack specificity, output schemas are undocumented, error handling is minimal, and the natural language processing logic in the assistant endpoint is a significant architectural issue that conflates LLM-style tool invocation with backend API routing. The server implements HTTP transport correctly but demonstrates poor separation of concerns.
Update user personal information including name, age, height, weight, gender, and blood pressure readings. Extracts parameters from natural language queries and returns an MCP tool request.
Query and display blood pressure trend data for a specified date range. Supports date range extraction from natural language queries including relative time expressions like 'past week' or 'past month'.
No documented output schemas. Tools lack response structure documentation. LLMs cannot plan downstream operations or extract required fields without knowing what the tool returns.
Parameter descriptions are vague and lack constraints. 'User's full name' and 'Start date in YYYY-MM-DD format' provide format hints but omit validation rules, length limits, required characters, and edge cases.
Architectural violation: The AssistantResource and AssistantAskResource endpoints perform natural language processing inside the backend. This conflates user-facing NLP (LLM's job) with MCP tool definitions. The server should expose clean tool endpoints; NLP logic should live in the agent/LLM layer, not in the tool server.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error handling is minimal. PUT /user and GET /health_data endpoints return generic JSON errors. No guidance for recovery (e.g. 'Invalid date format. Use YYYY-MM-DD'), no classification (retryable vs fatal), no suggestions for self-correction.
bloodPressure parameter in edit_profile is an object with nested properties but lacks explicit constraints. Are systolic and diastolic required when bloodPressure is present? What are valid ranges (0-300 mmHg)? Can they be null? No guidance.
No pagination or result limits documented. The view_blood_pressure tool queries health data by date range but provides no limit, offset, or pagination guidance. A query spanning years could return thousands of records, blowing context windows.
Tool naming: 'edit_profile' is acceptable but could be more specific. 'update_user_profile' or 'update_health_profile' would clarify scope.
Parameter type safety: The 'gender' parameter accepts a string with description '(male or female)' but no enum constraint. LLMs will pass invalid values like 'Male' (capitalized), 'man', 'woman', '性别未知', etc. Enums prevent hallucination.
Idempotency not documented. Is calling edit_profile twice with the same data safe? Does it overwrite or merge? For health tracking, idempotence matters, agents retry on network failures, and duplicate records could corrupt medical data.
Missing scope/permission declarations. Neither tool declares what permissions they require (e.g. 'read:health', 'write:health'). An agent invoking edit_profile should know it modifies data; audit trails cannot be built without explicit scope.