Loading ToolBench
MCP server for BioOntology API access - search ontologies, annotate text, and explore biological concepts
The BioOntology MCP server demonstrates good foundational definition quality with clear tool naming, comprehensive parameter schemas, and consistent descriptions. All 8 tools follow verb_noun naming conventions and include structured input parameters with type definitions. However, there are notable gaps in output schema documentation, error handling guidance, and description depth. Parameter descriptions are present but often generic (e.g., 'The search query string (required)'), lacking the constraint details and context hints that would optimize LLM tool selection. Output schemas are not explicitly documented, responses are inferred from BioOntology API but never formally described in the tool definitions. Error handling is minimal; tools rely on HTTP status codes rather than providing recovery guidance. The server handles read-only operations safely but would benefit from more sophisticated error classifications and descriptive guidance for the LLM.
Annotate natural language text with ontology concepts and find biomedical entities
Retrieve usage analytics and statistics for ontologies
Retrieve detailed information about a specific class/concept in an ontology
Retrieve detailed information about a specific ontology
Recommend suitable ontologies based on text input or ontology identifiers
Search and discover ontologies in the BioOntology repository
No output schema documentation. Tool responses are inferred from API but never formally described to the LLM. This forces the LLM to guess at response structure and risks misinterpretation of returned fields.
Parameter descriptions lack constraint details and context. E.g., 'The search query string (required)' does not explain what constitutes a valid query, whether regex is supported, or when to use which optional parameters. Descriptions should follow the pattern: 'What it does. How to format it. When to use it.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for properties and metadata across ontologies
Search for ontology terms and classes by keyword
No pagination result structure documented. search_terms, search_properties, and search_ontologies accept page/pagesize but do not document what the response includes (total count, has_more, next_cursor). This is critical for multi-page iteration.
Error handling is minimal. No recovery guidance in error responses. E.g., if search_terms returns 404 (ontology not found), the tool does not suggest calling search_ontologies() first. This forces the LLM to discover recovery paths on its own.
Parameter dependency relationships not documented. E.g., recommend_ontologies has input_type and output_type that constrain behavior, but the description does not explain which combinations are valid or what the defaults imply. wc, wa, wd, ws are weights (0-1) but their interaction is unexplained.
No result limits documented or enforced. search_terms, search_properties, and search_ontologies could return large result sets. Descriptions should state maximum results returned even with pagesize=500, or cap returned items at a reasonable default (20-50).
annotate_text has 13 optional boolean/string parameters but no guidance on which combinations are recommended. E.g., should expand_semantic_types_hierarchy always be used with expand_class_hierarchy? When is whole_word_only useful? The tool description does not guide the LLM toward effective invocations.