MCP server for managing Singapore health facilities map state, facility class filters, and map view settings via a FastAPI backend with Redis state management
This server has significant definition quality issues across multiple dimensions. While tool names are appropriately action-verb-based (get_, list_, set_, reset_, check_), descriptions are present but lack strategic depth for agent selection. Critical gaps: (1) Parameters almost entirely lack descriptions, even required parameters like 'fclasses' in set_facility_filters and 'latitude'/'longitude'/'zoom' in set_map_view have minimal or absent guidance. (2) No output schemas are documented anywhere, forcing LLMs to guess what fields are returned. (3) Error handling descriptions are absent, tools do not guide recovery or explain failure modes. (4) Several tool descriptions are extremely brief (e.g., 'Reset the app to its default state.' at 36 chars, borderline acceptable but lacks WHEN to use it). (5) The set_facility_filters tool description says 'Rejects unknown values' but provides no guidance on what valid values are or how to discover them, an LLM would have to call list_facility_classes first, which should be documented. (6) Parameter enums are attempted dynamically in list_tools() for set_facility_filters, but this is not visible in the schema definitions provided in the spec, and the fallback for missing enums is bare strings with no constraint. Baseline comparison: A+ tools average 194 chars for descriptions and 72 chars per param annotation, this server averages ~35 chars for tool descriptions and has near-zero param annotations.
Check if the API server and Redis are healthy.
Get the current state of the Streamlit app including selected filters and map view
List all available facility class names (fclasses) from the dataset
Reset the app to its default state.
Set which facility classes are visible on the map. Rejects unknown values.
Set the map center location (lat/lon) and zoom level.
NO OUTPUT SCHEMAS DOCUMENTED. All 6 tools lack documented return schemas, forcing LLMs to guess what fields are returned. This violates pattern:tool and pattern:response-shaper, breaking downstream tool chaining and context extraction.
PARAMETER DESCRIPTIONS NEARLY ABSENT. 4 of 6 tools have no parameter descriptions (or minimal ones). set_map_view has descriptions but lacks numeric constraints (lat/lon ranges, precision). set_facility_filters mentions 'Rejects unknown values' but does not guide how to discover valid values. Violates pattern:tool-description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
MISSING CONSTRAINT DOCUMENTATION. set_map_view 'zoom' parameter has range (1-20) documented in description, but 'latitude' and 'longitude' lack WGS84 bounds (-90..+90 and -180..+180). No minimum/maximum JSON Schema fields visible. Violates pattern:constrained-input.
GENERIC TOOL DESCRIPTIONS LACK STRATEGIC CONTEXT. Descriptions do not answer: WHEN should the LLM call this tool instead of alternatives? What are the prerequisites? What happens on failure? E.g., 'Get the current state' does not explain that it requires API running, or what fields (selected_fclasses, map_center, zoom_level) are expected. Violates pattern:tool-description guideline.
NO ERROR HANDLING GUIDANCE. Tool descriptions do not explain what errors can occur, how to interpret them, or what recovery steps are available. E.g., set_facility_filters says 'Rejects unknown values' but provides no guidance on how to discover valid values or retry. Violates pattern:recovery-guide.
PARAMETER ENUM INJECTION IS CODE-LEVEL, NOT SCHEMA-VISIBLE. set_facility_filters attempts to inject 'enum' constraints in list_tools() based on dynamic API response, but this is not reflected in the static schema definition provided. Fallback case has bare string type with no constraint. This breaks schema portability and leaves LLMs uncertain about valid values. Violates pattern:constrained-input.
MISSING DEPENDENCY DOCUMENTATION. set_facility_filters should explicitly state in its description: 'Call list_facility_classes first to discover valid facility class names.' Currently an LLM must infer this relationship. Violates pattern:tool-description guideline on dependency hints.