Why OMCP Exists
For an LLM like Claude to make use of Ontology data, copy-pasting text in on an ad hoc basis only gets you so far. OMCP (Ontology Model Context Protocol) builds on MCP (Model Context Protocol) — the open-source protocol Anthropic released — to hand an Ontology’s objects and relationships to Claude as structured context.
Where typical RAG (retrieval-augmented generation) retrieves documents by vector similarity, an Ontology already has explicit relationships defined — “A is a subtype of B,” “C is linked to D.” Passing those relationships through via MCP as-is lets Claude reason from more precise grounding.
The Basic Structure of MCP
MCP is a client-server architecture.
- MCP host: the application that actually talks to the LLM — Claude Desktop, or the Developer Console, for example.
- MCP server: the entity that controls an actual data source — an Ontology database, files, whatever it may be — and exposes the tools and resources Claude can use.
In other words, MCP is a standardized “channel through which Claude reaches the Ontology,” not the Ontology itself — and OMCP is that channel shaped specifically for Ontology data.
Setup Steps
- Prepare an OMCP server: set up a server with Ontology query capability. For example, define one tool that looks up a given node’s relationships, and have it query the Ontology store internally and return the result.
- Configure Claude Desktop: register the locally configured OMCP server in Claude Desktop’s config file (
claude_desktop_config.json), specifying both the server launch command and the environment variables (URL, credentials, etc.) needed to reach the Ontology store. - Verify the connection in the Developer Console: to reach your local OMCP server from the web-based Developer Console (Workbench), you need to expose the server at an externally reachable address and switch it to communicate over SSE (Server-Sent Events).
- Sync tools and test: once you register the MCP endpoint in the Developer Console, Claude automatically recognizes the tools the server exposes. Ask an actual question about an Ontology relationship and confirm Claude calls the tool and returns the correct result.
Common Mistakes
- Leaving credentials in plaintext in the config file: writing your Ontology store’s connection details (URL, account, password) directly into the config file risks exposure. It’s safer to use environment variables or a dedicated secrets-management approach.
- Testing locally only, and skipping external-exposure setup: when a connection that worked fine in Claude Desktop doesn’t work in the (web) Developer Console, it’s almost always because the local server was never exposed at an externally reachable address.
- Writing tool descriptions carelessly: Claude decides when to call a tool based on its description. A vague description means it either fails to call the tool when it should, or calls it when it shouldn’t.
Next Steps
Once the connection is in place, the next post picks up from here and covers actually analyzing Ontology data in a personal AIP Developer account using this structure.