Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This MCP server has severe definition quality issues across nearly all 17 tools. While tool names follow verb_noun conventions (get_*), descriptions are mostly generic boilerplate, parameter descriptions are absent or minimal, output schemas are not documented, and there is no visible input validation or error handling. The server appears to be a FastAPI wrapper around a health database with Azure AI agent integration, but the tool definitions lack the rigor expected for production LLM-driven agent interactions. Most tools return database records directly without pagination, composition hints, or chaining IDs documented. No tools declare what data they require to function or what happens on failure.
Tools (17)
get_bp_check_remindersread only38/100
Get BP check schedules from the database (MCP toolset tool)
get_bp_historyread only38/100
Get full blood pressure history with notes from the database (MCP toolset tool)
get_bp_statisticsread only38/100
Get statistical analysis (averages, counts) of blood pressure readings from the database (MCP toolset tool)
No documented output schemas for any data retrieval tool (16 of 17 tools). LLMs cannot infer what fields will be returned, forcing them to guess field names or make redundant calls. This violates the 'Document the output schema' critical check.
Tool descriptions are generic boilerplate: '...from the database (MCP toolset tool)'. These 35-character descriptions fail to answer WHEN to use the tool, what distinguishes it from similar tools, or what it returns. Baseline for A+ tools is 194 chars with clear context.
get_user_profile
Recommendations
Add detailed output schemas for all 16 data retrieval tools. Document the expected fields, types, and whether results are paginated. Example: get_bp_history should specify it returns {readings: [{date, systolic, diastolic, notes}], total_count, has_more}.
Rewrite tool descriptions to answer: WHAT does it do? WHEN should an LLM call it instead of a similar tool? WHAT does it return? Use 100-200 character descriptions with clear, context-specific language. Example: 'Retrieves all blood pressure readings for a user, including dates and notes. Use this for historical trend analysis. Returns paginated results with up to 50 readings per page.'
Add descriptive text to the 'user_id' parameter in all tools. Specify that it is a numeric database identifier (e.g., 'The numeric user ID from the user database, e.g., 12345').
Consolidate overlapping medication tools. Combine 'get_medication_reminders', 'get_pending_medication_reminders', 'get_recent_medication_activity', and 'get_medication_adherence' into 2-3 tools with clear purposes: (1) 'get_medication_schedule' for upcoming/pending reminders, (2) 'get_medication_history' for past activity and adherence stats. Add a 'filter' or 'include_stats' parameter to control what data is returned.
Consolidate appointment and reminder tools. Merge 'get_doctor_appointment_reminders' and 'get_upcoming_doctor_appointments' into one 'get_doctor_appointments' tool with an optional 'time_range' parameter (e.g., 'next_24h', 'next_7d', 'all').
Add pagination to all list-returning tools. Include 'limit' (default 20, max 100) and 'offset' parameters. Return total_count and has_more boolean in responses.
Score history
Overall score trend
↑ 25 points across a rubric change (v1 → v2)
33/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
33
2026-07-28+
v2
2026-03-09
F
8
-
v1
get_pending_bp_check_remindersread only38/100
Get pending BP checks from the database (MCP toolset tool)
get_pending_medication_remindersread only38/100
Get medications not yet taken from the database (MCP toolset tool)
get_pending_workout_remindersread only38/100
Get pending workouts from the database (MCP toolset tool)
get_recent_bp_readingsread only38/100
Get last 5 BP readings for trends analysis from the database (MCP toolset tool)
get_recent_medication_activityread only38/100
Get recent medication activity from the database (MCP toolset tool)
get_upcoming_doctor_appointmentsread only38/100
Get upcoming appointments from the database (MCP toolset tool)
get_upcoming_remindersread only38/100
Get all upcoming reminders (next 24 hours) from the database (MCP toolset tool)
get_user_profileread only38/100
Get complete user profile and health info from the database (MCP toolset tool)
get_workout_remindersread only38/100
Get all workout schedules from the database (MCP toolset tool)
Parameter 'user_id' lacks a description in the JSON schema. LLMs cannot determine whether to pass a numeric ID, email, username, or internal identifier. The rubric requires every parameter to have a non-empty description.
No pagination support visible. Tools like 'get_bp_history', 'get_medication_reminders', and 'get_upcoming_reminders' could return arbitrarily large result sets with no limit parameter or offset/cursor mechanism. Returning hundreds of records wastes tokens and degrades LLM reasoning.
No error handling or recovery guidance documented. If a user_id does not exist, what does the tool return? A 404? A null? An error message? Without clear error categorization (retryable, user-fixable, fatal), agents cannot recover from failures.
Tool composition and chaining IDs unclear. If an agent calls 'get_user_profile' and then 'get_bp_history' with the same user_id, the response should explicitly return the user_id so the agent can pass it forward. Without chaining IDs documented in output, agents may struggle to compose multi-step workflows.
Highly overlapping tools with no clear distinction. 'get_medication_reminders', 'get_pending_medication_reminders', 'get_recent_medication_activity', and 'get_medication_adherence' all operate on the same resource (medications). Names like '_reminders' vs '_activity' vs '_adherence' do not clearly convey the semantic difference. LLMs will conflate similar names and pick the wrong tool.
Similar redundancy with appointment and reminder tools. 'get_doctor_appointment_reminders' and 'get_upcoming_doctor_appointments' appear to serve the same purpose but with different names. The descriptions do not clarify when to call one vs the other.
No input validation constraints documented. The 'user_id' parameter accepts only integers, but the description does not specify a valid range (e.g., 1-1000000). Without explicit constraints, LLMs may pass invalid IDs or negative values.
Document error responses and recovery paths. For each tool, specify: (1) What happens if user_id is invalid? (2) What if no data exists? (3) Are errors retryable? Example error response: '{error: 'User not found', code: 'USER_NOT_FOUND', suggestion: 'Verify the user_id or call search_users() to find the correct ID.'}'
Add tool annotations (readOnlyHint: true for all these tools, since they are all READ_ONLY). This tells the LLM these tools are safe to call repeatedly without side effects.
Validate user_id as a positive integer in all tools. Return a clear error: 'Invalid user_id: must be a positive integer, received: X'.
Include all chaining IDs in responses. If get_user_profile returns a user object, ensure it includes user_id, so the LLM can pass it to get_bp_history without an extra lookup.