CEDAR Now Has MCP Servers: Build a Template by Describing It

Good metadata is still made by hand. Someone reads a dataset, its data dictionary, a protocol, and a paper, then transcribes what they learned into a structured form, choosing a standardized term for each value. It is slow work, and it is exactly the kind of reading and restructuring that a large language model does well.

A language model on its own, though, is not the right tool for the final step. Ask one to write a metadata template and it will cheerfully invent field names, guess ontology identifiers that do not resolve, and emit something that looks like CEDAR but does not validate. The reasoning is useful. The unaided output is not trustworthy.

The Model Context Protocol (MCP) closes that gap. An MCP server hands a model a set of real tools backed by real services. We have built four of them, one per task, and a language model orchestrates them:

The BioPortal term server searches BioPortal and resolves names to real ontology classes and ontologies, each with a resolvable IRI.
The CEDAR artifact server builds, validates, and renders CEDAR templates and instances as YAML.
The CEDAR embeddable-editor server renders a template or an instance as a form in your browser, so you can see what the YAML actually produces.
The CEDAR REST server uploads and manages artifacts on a CEDAR server, so you can keep and share what you built.

The division of labor is the point. The model supplies the judgment: which fields a template needs, which vocabularies fit them, and which shape of constraint each field should take. The servers supply the ground truth: real IRIs from BioPortal, a schema and an instance the CEDAR validator accepts, and a faithful rendering of both. Neither half is enough alone. The model without the servers invents identifiers; the servers without the model have nothing to assemble.

In practice you describe what you want and the servers do the rest. One sentence starts it:

Build a CEDAR template called “Tissue Sample”. Give it two plain text fields, Sample ID (required) and Lab ID. Then add three fields constrained to ontology terms: Cell Type, allowing any term from the Cell Ontology; Organ, allowing any organ from Uberon; and Assay Type, allowing three specific assays: histopathology, imaging, and microscopy.

The model looks each term up instead of guessing it. Organ in Uberon comes back as UBERON_0000062 and histopathology assay in OBI as OBI_0002564, both resolvable. It then assembles the template on the artifact server, which validates the artifact as it is built, and returns compact CEDAR YAML:

type: template
name: Tissue Sample
children:
- key: sample-id
  type: text-field
  name: Sample ID
  configuration:
    required: true
- key: organ
  type: controlled-term-field
  name: Organ
  datatype: iri
  values:
  - type: branch
    ontologyName: Uber Anatomy Ontology
    acronym: UBERON
    termLabel: organ
    iri: http://purl.obolibrary.org/obo/UBERON_0000062
    maxDepth: 0

From there the embeddable-editor server renders the template as the CEDAR form it describes, opened read-only in your browser, so you can check the design before saving anything. Filling an instance works the same way: you name the values in plain language, and the instance stores hepatocyte as CL_0000182 rather than as the loose word, so the value means the same thing to every reader and every program that encounters it. The REST server uploads the result to a CEDAR account when you want to keep and share it.

Because the workflow is a conversation over reusable tools rather than a one-off script, the same method retargets to any study. Change the description of what you want, keep the approach, and the servers keep the output honest.

The CEDAR MCPs Tutorial walks the whole example end to end, from the first sentence to a filled instance, and its appendix shows how to register the four servers with an MCP-capable client such as Claude Desktop or Claude Code.

You might also like