Loading ToolBench
A Model Context Protocol (MCP) server for interacting with the CEDAR (Center for Expanded Data Annotation and Retrieval) metadata repository.
cedar-mcp provides 6 well-named, domain-specific tools for CEDAR metadata repository and BioPortal ontology access. Tool names follow verb_noun convention (get_*, search_*, list_) and are descriptive. Descriptions are substantive (150-250 chars typical) and explain WHEN and HOW to use each tool. All tools have input parameters with type declarations and descriptions. However, OUTPUT SCHEMAS are not documented in the visible source, the code does not show what fields are returned by each tool, only that data is 'cleaned' and 'transformed'. Parameter descriptions are generally good but some lack constraint details (e.g., ontology_acronym accepts any string, no enum of valid acronyms). Error handling is minimal, no explicit guidance on recovery or categorization. Security is reasonable (API keys injected via environment variables, not parameters), but no audit logging or permission gating visible. All tools are READ_ONLY (safe for retry), reducing some concern. Tool composition is sound, tools chain naturally (template → instances → ontology terms). No tool does multiple unrelated things. However, the lack of visible output documentation and absence of result limits/pagination details reduce confidence.
Get a template from the CEDAR repository. The template is fetched in CEDAR's compact YAML rendering, which is a far cheaper way to read a template than the JSON-LD form: it leaves out provenance and other bookkeeping keys, so it costs fewer tokens. A field restricted to an ontology branch reports that branch rather than the values it allows. Use expand_branches to list those values, bearing in mind that each branch costs one BioPortal lookup and a template can easily have twenty of them.
Get the hierarchical structure of a class in an ontology from BioPortal. Provides the full class hierarchy showing parent and child relationships.
Get template instances that belong to the input template ID with pagination support. This tool searches for instances of a given template and fetches their complete content in paginated chunks to avoid token limit issues.
List all child terms directly under an ontology branch. Returns the terms one level directly under a branch root. Results are cached to avoid repeated BioPortal lookups during template authoring.
Search for terms within a specific ontology branch using BioPortal. Searches only within a branch subtree. For searches across the entire ontology, use search_ontology_terms instead.
Output schemas not documented in visible source code. Tool returns are described informally ('cleaned', 'transformed') but no explicit field-level documentation of response structure. LLMs cannot reliably plan downstream tool calls without knowing what fields to expect.
Parameter 'ontology_acronym' (used in 4 tools) accepts free-form strings with no enum constraint or valid-value documentation. Should declare: enum of supported acronyms (NCIT, CHEBI, HRAVS, etc.) or provide a discovery tool. LLMs currently guess at valid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Search for terms in a specific ontology using BioPortal. Searches across all terms in an entire ontology. For branch-specific searches, use search_ontology_branch_terms instead.
No explicit result limits or pagination documentation. get_instances_based_on_template accepts 'limit' (1-100) but other tools (search_ontology_terms, search_ontology_branch_terms) have no documented limit on returned results. BioPortal searches can return hundreds of terms, uncapped results blow LLM context window.
Error handling is generic and lacks recovery guidance. Code checks for 'error' in responses but does not categorize errors as retryable/user-fixable/fatal or provide actionable next steps ('If ontology not found, try search_ontologies()' etc.). LLMs cannot self-correct.
No audit logging visible. Tools that call external APIs (BioPortal, CEDAR) should log who called what, with parameters and timestamp, for compliance and debugging. Current code has no logging instrumentation.