Loading ToolBench
An MCP server that integrates electronic health record databases and a large-scale heterogeneous knowledge graph for rapid clinical record query and fast biomedical knowledge inference
MedCP provides 4 well-named, read-only query tools with solid descriptions and clear safety restrictions. All tools start with action verbs (query_, get_) and have descriptions explaining WHAT they do, WHEN to use them, and what constraints apply (read-only SQL, no write operations blocked). Parameter descriptions are present and specific ('A read-only SQL SELECT query'). However, output schemas are not documented in the source code, the server returns results as structured JSON but does not explicitly document field names, types, or pagination behavior. Error handling is minimal (no recovery guidance for common failure modes like syntax errors or missing tables). Tool descriptions are well-above the 20-char minimum but lack explicit return type documentation. No input validation constraints are visible in parameter descriptions (e.g., max query length, timeout). Security is strong: all tools are read-only and credentials are injected server-side via environment variables (not exposed as parameters).
Retrieve the schema of the electronic health record (EHR) database. Returns table names, column definitions (name, type, nullable status), and primary/foreign key relationships.
Retrieve the schema of the biomedical knowledge graph (Neo4j or compatible). Returns node labels, relationship types, and property definitions.
Execute read-only SQL queries against the electronic health record (EHR) database. Supports SELECT queries only; INSERT, UPDATE, DELETE, and schema-altering operations are blocked. The EHR backend is pluggable and supports three SQL engines: mssql (Microsoft SQL Server), mysql (MySQL/MariaDB), and sqlite (SQLite).
Execute read-only Cypher queries against the biomedical knowledge graph (Neo4j or compatible). Write operations (MERGE, CREATE, SET, DELETE, etc.) are blocked. Returns result records as JSON.
Output schemas not documented. No explicit definition of return fields, types, pagination, or constraints. LLMs cannot plan downstream operations or extract required fields reliably.
query_clinical_records and query_knowledge_graph lack input validation constraints. Descriptions do not specify maximum query length, timeout, complexity limits, or error conditions (e.g., 'Query must be a valid SELECT statement, max 10,000 characters').
Error handling does not guide recovery. No documented error responses for common failures (SQL syntax error, connection timeout, table not found, resource exhaustion). Errors provide no actionable next steps for the LLM.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
query_clinical_records parameter 'query' and query_knowledge_graph parameter 'cypher_query' lack format constraints in descriptions. No mention of max length, allowed statement types, or character restrictions. Descriptions say 'read-only' but do not explain how that is enforced or what happens if a write statement is submitted.
query_knowledge_graph 'params' parameter description is minimal ('Optional query parameters'). Does not explain how to use it, what format key-value pairs must follow, or provide an example of substitution syntax.
No pagination guidance documented. For large result sets (thousands of clinical records or graph nodes), tools do not describe limits, offset/limit parameters, or next_cursor behavior. Result truncation and resumption are not documented.