Agents Should Consult, Not Guess

An LLM agent working against your data platform always has an opinion about your schema. The only question is whether that opinion comes from a stale paste buried in a prompt — or from the system that actually governs what your data means. We built the CoreModels MCP server so agents can ask instead of assume.

The failure mode: confident structure, invented meaning

Anyone who has wired a language model into a data workflow has watched this happen. An analyst asks an agent to draft a query. The agent's only knowledge of the warehouse is a schema dump somebody pasted into a system prompt six weeks ago. Since then a column was renamed, a status field gained a new allowed value, and a table was split in two. The agent doesn't know any of that. It produces fluent, plausible SQL against a database that no longer exists — and when the real schema doesn't match, it doesn't stop. It guesses. It invents a column name that sounds right. It assumes status means what status usually means.

Retrieval alone doesn't fix this. RAG finds documents about your schema — wiki pages, old data dictionaries, README fragments — and those drift just as badly as the pasted prompt. What an agent needs is not a description of the structure written by someone at some point. It needs the structure itself, live, with its meaning attached.

That is what the governed graph in CoreModels is: types, elements, taxonomies of allowed values, relationships, and ontology bindings, maintained as the single authoritative account of what the data means. The MCP server is how agents get to it.

A live surface instead of a stale paste

CoreModels exposes the governed graph through a Model Context Protocol (MCP) server — the open standard that lets Claude, ChatGPT, and any other MCP-capable client call tools over HTTP. The public endpoint lives at /mcp on your CoreModels host (for example, https://go.coremodels.io/mcp — replace with your CoreModels host) and is protected by OAuth. Connecting is deliberately unexciting: add the URL as a connector, sign in, done. Dynamic client registration means there is no client id to pre-provision; a spec-compliant client discovers the authorization server and completes the flow on its own.

Once connected, the agent stops guessing and starts consulting:

• Orientation. list_projects and get_project_summary tell the agent what exists — the types, elements, and taxonomies in a project, by name and id. get_mixins_and_relation_groups gives it the full project schema, and search_nodes finds the specific node it needs. No more inventing table names: the agent looks them up.
• Schema in whatever shape the task needs. The same governed model exports on demand as JSON Schema, Avro, LinkML, SQL DDL, OWL, ShEx, or JSON-LD — one tool per format, generated live from the graph at the moment of the call. An agent writing a validator asks for JSON Schema; an agent reasoning about ontology structure asks for OWL; an agent scaffolding a pipeline asks for Avro or SQL. Nothing is copied around, so nothing goes stale.
• Validation, not vibes. validate_json checks a document against the project's stored JSON Schema. Instead of the agent asserting that a payload "looks right," it can prove it — or surface exactly which rule failed.
• Schema transformation. transform_schema runs a stateless schema-to-schema transformation through the mapping engine — hand it a schema in one format, name a target format, and get back the result plus a replayable plan and a ledger of everything that didn't survive the trip. The agent doesn't improvise a conversion; it delegates to a deterministic engine and reports what the engine reported.
• Reality checks against the estate. audit_vendor_project compares vendor artifacts — a dbt manifest, a warehouse information schema — against the governed model and reports coverage, drift, and conformance findings. An agent asked "is production still in line with the contract?" has an actual answer, down to the field that drifted.
• Grounded vocabulary. suggest_ontology_terms searches the public EMBL-EBI Ontology Lookup Service and returns ranked candidate terms — from ontologies like EFO or MONDO — for a schema node or label. The agent's semantic suggestions come from curated ontologies, not from whatever the model half-remembers.

Read-only by default, honest about writes

Handing an agent tools is easy. Handing it only the tools it should have is the part that matters, and we refuse to blur it.

The public /mcp endpoint serves read-only tools exclusively. Write tools — creating and updating nodes, importing vendor estates, binding ontology terms — live on a separate admin endpoint, /mcp-admin, and the separation is not cosmetic: regardless of which endpoint a token arrived through, write tools require Editor or Admin membership on the specific project. Every tool also declares its nature up front — a read-only hint, plus annotations for whether it is destructive, idempotent, or reaches the open internet — so a well-behaved client knows what it is holding before it calls anything.

The ontology tools show the philosophy at its sharpest. suggest_ontology_terms is advisory only: it searches, it ranks, and its response says in so many words that nothing was written. Actually binding a term to a node — making it part of governed meaning — is a separate, explicit, admin-gated act through bind_ontology_term, which writes exactly one binding and nothing else. An agent can research meaning all day; changing meaning stays a deliberate human-directed decision. We think that boundary is precisely where agent autonomy should stop, and we built the tool surface to enforce it rather than just recommend it.

Honesty as a feature

Every export and transformation in CoreModels carries a lossiness ledger: a structured record of what could not be expressed in the target and what was done about it. Export a model with a controlled value list to PostgreSQL DDL and you don't silently get a plain VARCHAR — you get the column plus a record explaining that Postgres has no inline enum, so the allowed-value constraint is not enforced in that output. Even the OWL export carries its lossiness as comments at the top of the file, so the caveats travel with the artifact.

This matters more for agents than it ever did for humans. A person reading an export might sense that something was approximated. An agent won't — it builds confidently on whatever it receives. Give it a silent approximation and the error compounds downstream; give it an explicit lossiness record and it can account for the gap, flag it, or choose a different format. A transformation that reports success is telling you it ran, not that nothing changed — and the ledger is where the difference lives. The same discipline applies when AI helps with the transformation itself: an AI-proposed schema mapping passes exactly the same validation gate as a human-authored one. Nothing gets waved through because a model was confident.

The meaning layer is the durable asset

Models will keep churning. Agent frameworks will keep churning faster. What persists underneath is the meaning layer: the governed graph of what your data is, which values are allowed, how datasets relate, and which ontology terms your fields actually denote. Because ontology bindings ride the same carrier every export reads, an agent pulling LinkML or OWL today inherits the same precise semantics a different agent will inherit next year — that this field is a datetime, that this status has exactly these governed values, that this diagnosis element maps to a specific term IRI rather than a plausible-sounding synonym.

That is the trade we're offering. Instead of feeding each new agent another stale paste and hoping, you maintain one governed source of meaning — and every MCP-capable agent, present and future, consults it live, within honest boundaries, with the losses on the record.

Ready to connect an agent? The CoreModels docs and quickstarts walk through adding the /mcp connector and making your first grounded call.