MCP Server for Biosanarcall IPS medical appointment scheduling, patient management, and healthcare service lookup. Provides tools for patient search, appointment scheduling, waiting list management, and reference data access (EPS, specialties, CUPS codes).
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server registers 29 tools covering a healthcare call center appointment system. Strengths: all tools have names starting with action verbs (search_, get_, list_, schedule_, cancel_, etc.), all have descriptions, and schemas are visible with parameter types. Significant weaknesses: descriptions are mostly short (10-50 chars) and lack WHEN/WHY/context; parameter descriptions are minimal or missing specifics about formats, constraints, and error recovery; output schemas are NOT documented in the code; error handling lacks actionable guidance. The server exhibits basic structure but falls well short of production quality. Average per-tool score: 52 across 29 tools.
Descriptions are too short (median ~35 chars) and lack context. Most say WHAT without explaining WHEN to use or WHY. Examples: 'List all active EPS' (31 chars), 'Get CUPS procedure code information' (35 chars). Baseline for A-grade tools is 50-200 chars with explicit WHEN/WHY guidance.
Output schemas are NOT documented. No tool in the source code shows what fields are returned, what structure the response follows, or what IDs/references are included for chaining. This forces LLMs to guess and prevents planning of downstream calls.
Expand all descriptions to 50-200 characters, following the pattern: '[ACTION]. Use when [WHEN]. Returns [STRUCTURE]. Requires [PREREQUISITES].' Example: 'Schedule an appointment for a patient. Use when patient has been searched and availability slots are visible. Returns appointment_id and confirmation details. Requires patient_id and valid availability_id.'
Document output schemas for all tools. Add a 'Returns' section to each description or create a separate schema document showing field names, types, and whether they can be chained to downstream tools. Example for getPatientAppointments: 'Returns array of {appointment_id, patient_id, specialty_name, scheduled_date, status}. Use appointment_id with cancelAppointment.'
Add detailed parameter descriptions for all inputs. Include format (YYYY-MM-DD), constraints (min 1 - max 100), enums (with meaning: Urgente=highest priority, Alta=high, Normal=standard, Baja=low), and lookup hints. Example: 'priority_level: One of Urgente (emergency, <4hrs), Alta (same-day preferred), Normal (within week), Baja (flexible). Required.'
Add error recovery guidance to all write operations. Example for scheduleAppointment: 'On failure, possible errors: Patient not found (try searchPatient first), No slots available (call getAvailableAppointments to suggest alternatives), Appointment conflict (call getPatientAppointments to check existing bookings).'
Implement dry-run mode for destructive operations (cancelAppointment, cancelarCitasVencidas, reassignWaitingListAppointments). Add 'dry_run: boolean' parameter defaulting to false. Example: 'dry_run=true returns what would be cancelled without modifying database, enabling confirmation workflows.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 7 points across a rubric change (v1 → v2)
47/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
47
<=2025-11-25
v2
2026-03-09
D
54
-
v1
read only
source verified
57/100
Get authorized locations for a patient based on their EPS
Parameter descriptions are sparse or missing specificity. Examples: 'zone_id' has no description of what zones are or how to find them; 'priority_level' and other enums lack explanation of what each value means in the healthcare context (Urgente vs Alta); 'reason' for scheduleAppointment says 'Appointment reason/complaint' but no format or length constraints.
Non-English tool names ('cancelarCitasVencidas', 'actualizarPhone') reduce discoverability and confuse LLMs trained primarily on English corpora. Tool naming should follow English verb_noun convention.
No error handling guidance. Tools like scheduleAppointment, cancelAppointment, and registerPatientSimple can fail in many ways (patient not found, no slots, permission denied, data conflict) but no description mentions recovery steps or actionable error messages. LLMs have no idea what to do on failure.
No confirmation or dry-run support for destructive operations. cancelAppointment, cancelarCitasVencidas, and reassignWaitingListAppointments modify state irreversibly. No mention of dry-run mode or confirmation step to prevent accidents.
Duplicate/overlapping tools with unclear differences. addToWaitingList and addToWaitingListDirect appear to do the same thing; getWaitingListPosition and getPatientWaitingList have unclear distinction. LLMs waste reasoning on choosing between similar tools.
Some parameters accept ID, name, or alternative lookups but descriptions do not clarify which is preferred or how lookup will resolve conflicts. Examples: getAvailableAppointments accepts both specialty_id and specialty_name; getAvailableTimeSlots accepts availability_id. If both are passed, which takes precedence? How are collisions handled?
No pagination or result limits documented. Tools like searchCups, searchCupsByName, getPatientAppointments, and listActiveEPS do not specify max results or provide pagination guidance. Large datasets could exhaust context windows.
Consolidate duplicate waiting list tools. Merge addToWaitingList and addToWaitingListDirect into one tool with clear documentation. Merge getWaitingListPosition and getPatientWaitingList by documenting what each returns (position=int, list=array of entries).
Clarify precedence when multiple lookup parameters are provided. Example for getAvailableAppointments: 'If both specialty_id and specialty_name are provided, specialty_id takes precedence. If neither is provided, returns appointments across all specialties.'
Add pagination to list and search tools. Implement 'limit' (default 20, max 100) and 'offset' (default 0) or 'cursor' parameters. Example: 'searchCups(cups_code, limit=50, offset=0) returns {results: [], total_count: 1234, has_more: true}'.
Add tool annotations for read-only, destructive, and idempotent hints if supported by MCP transport. Mark scheduleAppointment, cancelAppointment, and cancelarCitasVencidas as destructive. Mark searchPatient, listZones as read-only.