An MCP server for assisting with BioCypher workflows, providing tools for adapter creation, schema validation, and project management.
BioCypher MCP has solid foundational definition quality with clear, domain-specific tool names and mostly complete descriptions. However, there are consistent gaps in parameter descriptions, input validation details, and output schema documentation. All 10 tools start with action verbs (get_, check_, validate_) which is excellent for LLM parsing. Tool descriptions are reasonable length (60-150 chars typically) and explain PURPOSE well. The critical weakness is that parameter descriptions are often generic or missing constraint details (e.g., 'The phase number (1-5)' lacks description of what happens with invalid phases). Output schemas are not explicitly documented, forcing LLMs to infer response structure. Error handling is minimal, no guidance on recovery paths or categorization of error types. The server is fundamentally sound but needs parametric rigor and output documentation to reach B-grade quality.
Check if a BioCypher project exists at the given path.
Provides detailed information about the adapter creation workflow.
Main entry point tool that provides information about available BioCypher workflows.
Get instructions for creating a BioCypher project using cookiecutter.
Get decision guidance based on data characteristics.
Get all implementation patterns or a specific pattern type.
Provides detailed guidance for a specific phase of the adapter creation workflow.
Output schemas not documented. Tools like get_available_workflows, get_adapter_creation_workflow, and 7 others lack explicit return type schemas. LLMs must infer response structure by trial-and-error, risking misinterpretation of nested objects, array structure, and field types.
Parameter descriptions lack constraint details. For example, get_phase_guidance has parameter 'phase_number' with description 'The phase number (1-5) to get guidance for' but does not specify: (a) what error is returned for invalid phases (0, 6, -1, 3.5), (b) whether phases are 0-indexed or 1-indexed, (c) any dependency on prior steps. This forces LLMs to guess and retry on errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Guidance on resource management and caching
Guidance on BioCypher schema configuration
Validate a BioCypher schema_config.yaml (raw YAML content) against the official schema rules.
Minimal error handling and recovery guidance. The validate_schema_config tool may fail on invalid YAML or schema mismatches, but tool description provides no guidance on 'what to do if validation fails' or 'how to fix common schema errors'. Error responses should include actionable recovery steps, not just raw validation failure messages.
get_decision_guidance parameter 'data_characteristics' has complex nested object schema with 6 optional boolean flags and 1 optional string. Description says 'Data characteristics object containing structure type, relationship info, and temporal data flags' but does not explain: (a) which combinations are valid, (b) what happens if all flags are false or null, (c) how the tool chooses between conflicting characteristics. LLMs need dependency mapping.
No pagination or limit controls on list/discovery tools. Tools like get_available_workflows, get_implementation_patterns (without filter), and get_adapter_creation_workflow may return unbounded results. Best practice is to cap results at 20-50 items and offer offset/limit parameters. Current implementation risks context window exhaustion.
check_project_exists has default parameter 'project_path' defaulting to '.' but description does not explain: (a) does '.' mean current working directory of the server or the agent?, (b) are relative paths resolved from the server root or the agent's context?, (c) what happens if a path is outside the allowed directory tree?. Path handling is a security vector, undocumented defaults invite traversal attacks.