2c:null 2d:["$","title",null,{"children":"An MCP Interface for the Dydra RDF Graph Store | James Anderson | Observable"}] 32:T6489,# An MCP Interface for the Dydra RDF Graph Store *2026-09-03*
*2026-09-14* A language model handed an unfamiliar RDF repository is in an awkward position. It can write SPARQL — that much it learned from the public web — but it cannot write *this* repository's SPARQL, because it does not know which classes exist, which predicates connect them, or whether the data sits in the default graph or in four named ones. So, it guesses. It invents `foaf:worksFor` where the data says `foaf:member`, queries the default graph and gets zero rows, and reports that the repository is empty. None of that is a query-language problem. It is a *comprehension* problem, and that comes before the first query. Dydra's MCP endpoint helps to solve it: it allows a model — or a person — to arrive at a repository knowing nothing, find out what is there in two calls, and convert that understanding into a query it can keep. This note introduces the endpoint, explores the concepts behind it, describes how the design compares with other graph and vector stores, and recalls how it came to look the way it does. ## What MCP is, in graph-store terms The [Model Context Protocol](https://modelcontextprotocol.io/) is a small JSON-RPC 2.0 convention for exposing a service to a model. It offers three kinds of thing, and each lands somewhere specific on an RDF store. **Tools** are operations the model may call. Two carry the whole surface: `query` executes one request in whichever notation you name — SPARQL query, SPARQL update, GraphQL, or score — while `survey` explores and makes records. Two rather than twenty, because a model choosing among twenty near-identical tools spends its attention on the menu instead of the question. `tools/list` offers thirteen more all the same, and they are shortcuts rather than liabilities: `sparql_select`, `sparql_update`, `sparql_describe`, `graphql_query`, `graphql_mutate`, `list_graphs`, and `orch_survey` through `orch_navigate`. Each is a thin rewrite onto `query` or `survey`, so it costs nothing to keep and cannot drift from the implementation it delegates to. A caller should use whichever fits: a single-purpose tool with a narrow schema is sometimes easier to invoke correctly than a general one whose first argument is a media type, and a model that has learned `sparql_select` should not have to unlearn it to reach the same engine. The two-tool surface is the one we document and the one that generalizes; the shortcuts are a convenience, not a deprecation. **Resources** are documents the model may read, and the important one is `rdf://vocabulary` — not a hand-written schema but a report generated from the data on request: the classes present with instance counts, the properties instances carry, and the domains and ranges they exhibit. *What the data does, not what an ontology declares*, as its own header puts it. Beside it, `rdf://types` and `rdf://graphs` for orientation, `score://grammar` and `score://operations` for the exploration language. **Prompts** are complete instructions the server writes for its own surface, naming its own resources: `explore-repository`, `write-sparql-query`, `explore-with-score`. The transport is deliberately plain: one `POST` per request, no handshake and no connection state. Each request carries its protocol version and capabilities in `params._meta`, and three headers repeat what the body says, so a mangled request fails loudly. ## Two calls to get started Here is the cold start, against a small test repository. There is no handshake, so the first request — `server/discover` — is simply a question about the server. It answers with `instructions`, guidance the server writes for whatever model is calling, including the sentence that saves the most wasted effort: > A repository loaded from quads keeps its data in named graphs, and the default graph is > not their union: a query that names no graph reads no named graph. Either name the graph, or > select over the union with `FROM `. Second, read the vocabulary — `resources/read rdf://vocabulary`: ```turtle # RDF vocabulary for test/test, derived from the data. # Classes, with instance counts. (schema classes elided here) foaf:Organization a rdfs:Class . # 3 instances foaf:Person a rdfs:Class . # 10 instances a rdfs:Class . # 3 instances # What each class carries, observed: # foaf:Organization: foaf:name (3) # foaf:Person: foaf:name (10), foaf:age (8), foaf:mbox (8), # foaf:member (9), foaf:topic_interest (10), foaf:knows (17) ``` That is the comprehension problem solved: ten people, three organizations, three topics, and — the part that makes a graph worth querying — `foaf:member` pointing from a Person to an Organization, `foaf:topic_interest` from a Person to a Topic. A question that crosses classes is now writable: ```sparql PREFIX foaf: SELECT ?person ?organization ?knows ?theirOrganization FROM WHERE { ?a a foaf:Person ; foaf:name ?person ; foaf:member ?oa ; foaf:knows ?b . ?b a foaf:Person ; foaf:name ?knows ; foaf:member ?ob . ?oa a foaf:Organization ; foaf:name ?organization . ?ob a foaf:Organization ; foaf:name ?theirOrganization . FILTER(?oa != ?ob) } ORDER BY ?person ?knows ``` ``` person organization knows theirOrganization ------------- ------------- ------------- ----------------- Alice Bergman Acme Research Carol Diaz Borealis Labs Bob Chen Acme Research Erin Fischer Borealis Labs Carol Diaz Borealis Labs Alice Bergman Acme Research … (8 rows) ``` Eight of seventeen acquaintances cross an organizational boundary. Two calls of orientation and one query, with nothing invented. ## How it got here The project did not start from score notation. It started at the end of September 2025 by exploring how the Dydra service could support typical MCP client apis. This led just to a simple server endpoint which provided just a SPARQL tool. From that point, the project sat dormant until March 2026 when it returned to a narrow question about media types and response content — how should an MCP client specify the media type of each request and response? This widened within hours: > *rather than just reassessing graphql, expand your perspective to the nature of access > languages in general … the aim is to make the access language circumstantial and lower > the access threshold as much as possible … First analyse the information exchange > requirements in general, then evolve an interaction form and language in response to > those requirements.* Two instructions are buried there. **Requirements before syntax** — do not begin from a grammar. And **the access language is circumstantial** — SPARQL is present because conformance demands it, not because it is the right surface for a language model. What followed arrived as constraints rather than features. **QNames** were chosen for being unambiguous and short at once — token efficiency was a constraint from the first week, not a later optimization. Provide the means to **materialize stages** of the exploration process as queries is why `materialize` is first-class and not a debugging aid. And asking how any of this works in a *new* domain — data, but no query history and no problem formulations — produced the vocabulary cache and bare-name resolution. This is one reason why score is a notation in its own right rather than a SPARQL dialect. The notation was specified in the first March week, its bare-name feature commissioned in the same breath as its BNF. Two days later, however, a small presentation bug led to another principal distinction. IRIs were printing as `<"https://example.com/…">`, and the correction was not about quoting: > *the purpose of iri instance is to handle the construction/deconstruction and serializing > in a manner which distinguishes them clearly from string terms … The benefit is, the > algebra can include iri instances directly and they are handled correctly by the query > processor.* **A term and a string are different objects**, and the notation must never blur them. That is why names became symbols rather than strings. Another decision from March: session export should carry definitions, not results. Those should be recreated on demand. **Derived state is not stored.** The persistence layer stores shapes and the service process recompiles algebra — so a stored exploration improves when the compiler does. The project sat untouched from mid-March to late August while the engine consolidated triple terms, wide term identifiers, temporal indices, and replication. Reopening it to carry score over MCP produced the tri-notation request model, one `survey` tool rather than one tool per operation, `save`/`load` withdrawn as graph-store concerns, and a user guide. Getting it conformant afterwards took four things, and the combination is reusable: - **A general reference.** The [Model Context Protocol specification](https://modelcontextprotocol.io) settles what a compliant server must do about framing, headers, versioning, error codes and result envelopes, so arguments about intended behaviour end at a document. - **A specific reference.** A requirements document restates that specification as numbered obligations for *this* server — seventy-odd, each marked MUST, SHOULD or MAY. Every regression check names the obligation it pins, so a failure reports which requirement broke rather than which assertion did. - **A grammar.** `score.bnf` is the notation's specification, written the same evening as the parser it describes. Reading the implementation against it is how `@order` and `@group` were caught emitting algebra the evaluator rejects — both had been returning zero rows in silence. - **A live endpoint**, so the loop is test, analyse the error, reimplement, repeat, against a running service rather than a mock. Sometimes that ran inside one model reflecting on its own output; sometimes as an exchange between two, one exercising the endpoint and reporting, the other reading the report and changing the implementation. An independent pass of that kind found fifteen distinct faults, now closed. ## Score, gently SPARQL is the right tool once you know the question. Score is for when you need to find that out. It began by asking the models themselves. Before any syntax existed we put the question to GPT and then to Claude: given a repository you have not seen, how would you *rather* hold a SPARQL query while still working out what to ask? The complaints converged. Triple patterns are an awkward unit to revise, because changing what you retrieve means editing variables in two places at once. Namespaces are a barrier before you know the data. And there is no way to say "the same query, one property further out" without rewriting it. Those complaints became the requirements, and the requirements became the notation: a description of *what they want back* rather than of the patterns that would fetch it, names that work before they know a namespace, and a form they can extend by one property without rewriting anything. Concretely it is JSON with three additions. - **An unquoted word is a name; a quoted string is data.** `{foaf:name: Alice}` sets the value to the *term* `Alice`, something to look up. `{foaf:name: "Alice"}` sets it to the *string* `"Alice"`. They are different objects and the notation distinguishes them, which is what makes it safe to resolve a whole request against the repository's vocabulary: only names are candidates, so a data value is never rewritten into somebody's namespace. Quote anything that is data. - **A bare name needs no namespace.** Write `Person` and `name` rather than `foaf:Person` and `foaf:name`; the server resolves them against the vocabulary it just built, by local part and then by `rdfs:label`, and *reports what it did*: ``` resolved: {Person: foaf:Person, name: foaf:name} ``` Read that line before trusting a result. Where a bare name matches two vocabularies the reply says so under `ambiguous`, and `"strict": true` makes the ambiguity an error rather than a guess. The feature exists for one reason: someone exploring an unfamiliar repository does not yet know its namespaces. - **A shape says what you want back.** This is the third addition and the one worth slowing down on, since it is the part a person must read rather than infer. A shape is an **array**, each element is one of two things: - a **property name** — a leaf. Retrieve that property's value. - a **single-key object**, `{property: [ … ]}` — a traversal. Follow that property to whatever it points at and apply the nested shape *there*. Traversals nest to any depth, so the array is really a small tree read outward from the entity you started at. Nothing else belongs there: a shape is not a pattern and not a filter. Nor is it a SHACL shape — SHACL describes what data *must* look like to be valid, a score shape what you *want returned*. Same word, opposite direction. The shape sits inside an object saying what it applies to and how: ``` { @type: foaf:Person, the class of the anchor entity @shape: [foaf:name, {foaf:member: [foaf:name]}], @anchor: { foaf:name: "Alice" }, constrain the anchor to one entity @limit: 5 } ``` `@type` and `@shape` are the two you always write. The others — `@anchor`, `@optional`, `@union`, `@order`, `@group`, `@distinct`, `@limit`, and `@define`/`@body`/`@apply`/`@export` for abstraction — are modifiers drawn from a fixed vocabulary that is never resolved against the repository, so an `@`-word cannot collide with a property of yours. Before your first `select`, keep in mind that **`@limit` has no default.** The compiler wraps the query in a slice only when you asked for one; with no `@limit` the shape compiles to no slice clause and the query returns every matching row. Nor is there a cap further down: the repository's response and solution limits are configurable but unset by default, MCP has no pagination, and a result is one JSON-RPC response. On the ten-person repository above that is invisible — on an unfamiliar large one, a bare `select` is the wrong first move. `catalog` and `profile` cost a count and a sample regardless of size, so the sound order is to catalog, profile, then select *with* a limit, and raise it once you know what to expect. Two properties of shapes are easy to miss. **A field is named for the predicate that produced it**, and a traversal composes: `foaf:name` at the top gives `foaf_name`, and `foaf:name` reached through `foaf:member` gives `foaf_member_foaf_name`. The namespace prefix is always part of the name, so `foaf:name` and `schema:name` can sit in one shape without either being renamed to make room for the other. And **order is still significant** — the position of a property decides which column its value lands in, and the same property may legitimately appear twice at different depths, which is what the path distinguishes. **A shape can have a hole.** This addition turns score from a way of writing a query into a way of keeping one. A hole is a `$`-name, and naming a shape that contains one gives you something to reuse: ``` op=define session=9f2c… { @define: members, @body: { @type: foaf:Person, @shape: [foaf:name, foaf:age], @anchor: { foaf:member: $org }, @export: { person: foaf:name, age: foaf:age } } } → {abstraction: "members", free: ["$org"], exports: ["person", "age"]} op=apply session=9f2c… { @apply: members, $org: } → {person: "Alice Bergman", age: 34} {person: "Bob Chen", age: 41} {person: "Dave Eriksen", age: 52} ``` Note what `@export` does: the fields are `person` and `age` rather than `foaf_name` and `foaf_age` — a name chosen for the caller rather than derived from the predicate. And binding *nothing* is not an error — the answer says what it still wants and keeps its place in the tree, so a partly bound abstraction can itself be named, which is what deriving one abstraction from another amounts to. A free name is never resolved against the vocabulary, so a hole can no more be mistaken for a term than a quoted string can. With that, exploration is four moves. Open a session first — the handle it returns is an ordinary argument, and it appears on every call after this one because nothing on the wire remembers it for you: ``` op=connect → {session: "9f2c…", repository: "test/test", vocabulary: {types: 5, prefixes: 21}, expires_after_minutes: 30} ``` Take a census — a `GROUP BY` you did not write — then profile one class for its properties, how many instances carry each, and a sample value: ``` op=catalog session=9f2c… { scope: types } → {type: foaf:Person, count: 10}, {type: foaf:Organization, count: 3}, … op=profile session=9f2c… foaf:Person → instance_count: 10 {predicate: foaf:name, count: 10, sample: "Alice Bergman"} {predicate: foaf:member, count: 9, sample: } {predicate: foaf:knows, count: 17, sample: } ``` Then select a shape — follow `foaf:member` and take the organization's *name*, not its IRI: ``` op=select session=9f2c… { @type: foaf:Person, @shape: [foaf:name, {foaf:member: [foaf:name]}], @limit: 5 } → {foaf_name: "Alice Bergman", foaf_member_foaf_name: "Acme Research"} {foaf_name: "Bob Chen", foaf_member_foaf_name: "Acme Research"} {foaf_name: "Carol Diaz", foaf_member_foaf_name: "Borealis Labs"} … (5 rows) ``` Each move is a node in a tree, so you can branch, name a node, navigate back to it, join two nodes, or walk a linking predicate into another class; `history` prints the tree. `expand` is the move the original complaint asked for — the same query, one property further out, without rewriting it. The exploration is an object you can inspect rather than conversational state buried in a transcript. And now the move the whole design is arranged around. Ask what that shape compiles to: ``` op=materialize session=9f2c… sparql → SELECT ?FOAF_NAME ?FOAF_MEMBER_FOAF_NAME FROM WHERE { ?S rdf:type foaf:Person . ?S foaf:name ?FOAF_NAME . ?S foaf:member ?FOAF_MEMBER . ?FOAF_MEMBER foaf:name ?FOAF_MEMBER_FOAF_NAME } OFFSET 0 LIMIT 5 ``` The variables carry the same names as the fields, because they are the same names: a variable is named for the path of predicates that reaches it. `?FOAF_MEMBER` is the traversal's link — it carries the join and is not projected, which is why no field is named for it. A query you can read is the whole point of materializing one. Hand that back to the `query` tool and it returns the same five rows. Nothing is lost in translation, because the shape was never a separate query language: it compiles to the engine's own algebra and serializes through the engine's own SPARQL writer. Score is a way of *arriving at* a query when you do not yet know enough to write one, and `materialize` is the exit — SPARQL that runs anywhere and depends on no session. That is why score should not feel threatening even though its intended caller is a model. Every decision an agent makes is recoverable as a query a person can read. ## How this compares We reviewed the field while considering feature-store support, and the comparison is instructive about architecture. (Vendor behaviour is as documented on 2026-09-15 by an LLM survey.) The clearest division is what the MCP layer actually is. Mostly it is an adaptation layer: | RDF database / MCP server | MCP tool set | |---|---| | **Generic baseline — `rareba/sparql-mcp`** | `sparql_query_tool` · `list_endpoints_tool` · `describe_resource_tool` · `list_classes_tool` · `list_predicates_tool` · `list_named_graphs_tool` · `sample_of_type_tool` · `get_prefixes_tool` · optional RDF parsing/serialization tools | | **AllegroGraph** — first-party `agraph-python` MCP server | `list_repositories` · `get_repository_info` · `get_namespaces` · `add_triples` · `get_shacl` · `sparql_select_query` · `sparql_graph_query` · `sparql_ask_query` · `sparql_update_query` · `list_freetext_indices` · `get_freetext_index_config` | | **Amazon Neptune** — first-party AWS Labs MCP server | `get_graph_schema` · `get_graph_status` · `run_gremlin_query` · `run_opencypher_query` | | **Virtuoso** — OpenLink `mcp-odbc-server` | `get_schemas` · `get_tables` · `describe_table` · `filter_table_names` · `query_database` · `execute_query` · `execute_query_md` · `spasql_query` · `sparql_query` · `virtuoso_support_ai` | | **Oracle Database / Oracle Graph** — first-party Oracle MCP surfaces | **SQLcl MCP:** `list-connections` · `connect` · `disconnect` · `run-sql` · `run-sqlcl` **ORDS MCP:** `database_list` · `schema_information` · `sql_run` **OCI Database Tools MCP:** `sql_run` · `schema_information` · `request_status` · `report_list` · `report_execute` · `report_sql` · user-defined SQL/PLSQL tools · Generative AI SQL Assistant tools | | **QLever** | No QLever-specific MCP tool set found. A generic SPARQL MCP server such as `rareba/sparql-mcp` can be placed in front of its SPARQL endpoint. | | **Oxigraph** — independent `mcp-server-oxigraph` | **Store:** `oxigraph_create_store` · `oxigraph_open_store` · `oxigraph_close_store` · `oxigraph_backup_store` · `oxigraph_restore_store` · `oxigraph_optimize_store` · `oxigraph_list_stores` **RDF:** `oxigraph_create_named_node` · `oxigraph_create_blank_node` · `oxigraph_create_literal` · `oxigraph_create_quad` · `oxigraph_add` · `oxigraph_add_many` · `oxigraph_remove` · `oxigraph_remove_many` · `oxigraph_clear` · `oxigraph_quads_for_pattern` **SPARQL:** `oxigraph_query` · `oxigraph_update` · `oxigraph_query_with_options` · `oxigraph_run_query` **Serialization:** `oxigraph_parse` · `oxigraph_serialize` · `oxigraph_import_file` · `oxigraph_export_graph` · `oxigraph_get_supported_formats` | | **Apache Jena / Fuseki** — independent `jena-mcp` | **Condensed/default:** `jena_admin` · `jena_graph` · `jena_sparql` **Verbose/optional:** `jena_backup` · `jena_compact` · `jena_create_dataset` · `jena_dataset_info` · `jena_delete_dataset` · `jena_delete_graph` · `jena_get_graph` · `jena_list_datasets` · `jena_list_tasks` · `jena_metrics` · `jena_ping` · `jena_post_graph` · `jena_put_graph` · `jena_query` · `jena_server_info` · `jena_set_dataset_state` · `jena_stats` · `jena_task_info` · `jena_update` | For AllegroGraph, a [Python server](https://github.com/franzinc/agraph-python/tree/master/src/franz/mcp) mediates access to an Allegrograph service through an MCP interface. It provides one exploration tool `get_shacl`, which returns "SHACL shapes describing the repository schema". [Neptune's interface](https://aws.amazon.com/about-aws/whats-new/2025/05/amazon-neptune-mcp-server/?utm_source=chatgpt.com) is internal, but leaves its RDF/SPARQL side out of it and exposes just the Neo4J datasets through openCypher/Gremlin queries. Oracle's graph store provides limited MCP support. The MCP interface tools are limited to SQL resource management and SQL queries. SPARQL operations on their graph store are available through their [SQL interface](https://docs.oracle.com/en/database/oracle/oracle-database/26/rdfrm/using-sem_apis-sparql_to_sql-function-query-semantic-data.html#GUID-D90AABC8-81CA-4212-B1A1-C03B818D46C6) only. None of them offer a **stateful semantic algebra** as the tool surface itself: an exploration that accumulates, composes, and compiles back to the query language. None of them expose historic data. Three goals fall out of the comparison : - **RDF identity should stay primary.** A retrieval result is an RDF term, so that the next step is ordinary graph navigation rather than a join in application code. - **Retrieval should compose with exploration.** A result can become a score node and then participate in `walk`, `join`, `shape`, or `materialize`. In the coverage matrix we built, "semantic graph composition after retrieval" is the row where conventional feature stores are simply absent. - **History is available.** Repository revisions can serve as the historical store, so point-in-time retrieval need not mean a second offline database. A note about status: the MCP support is to be released, but the feature-store and vector work in that review — a third `feature` tool, `nearest`, registered embedding spaces — is a *proposed* design. What ships today is the `query` and `survey` surface described above. ## What the project taught us Three threads run its whole length, and all three are about restraint. **Analyse the exchange, then choose the syntax.** Score is short, unambiguous and resolvable without prior knowledge because those were requirements before there was a grammar to argue about. **Keep the distinctions the data already makes.** A term is not a string; a name is not a value; a distance is not a similarity. Each blurred at least once, and each cost more to unblur than to keep. **Do not store what you can derive.** Shapes are the record and results are recomputed, which is why an exploration survives a compiler improvement instead of being invalidated by it. 33:[] 30:{"id":"46425b3c86791878","slug":"an-mcp-interface-for-the-dydra-rdf-graph-store","title":"An MCP Interface for the Dydra RDF Graph Store","thumbnail":"de5f0822a98d24a3555f9910429a83a371a66aee1e7a2901a702a82f939ee9da","access_level":"public","create_time":"$D2026-09-14T23:10:49.392Z","update_time":"$D2026-09-14T23:14:31.242Z","view_time":null,"first_public_time":"$D2026-09-14T23:18:46.564Z","has_unpublished_edits":null,"fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"b452fd69977f5701","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":"starter_2024","bio":"I am one of the developers for dydra.com."},"version":4,"publish_version":4,"role":null,"authored":false,"authors":[{"type":"individual","id":"987c90ad70c449c1","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":null,"bio":"I am one of the developers for dydra.com."}],"members":[{"type":"team","id":"b452fd69977f5701","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":"starter_2024","role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"lapsed":null,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"titling":"auto","title":"An MCP Interface for the Dydra RDF Graph Store","cells":[{"id":1,"value":"$32","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"}],"files":"$W33","stdlib":"2"}} 31:"$30:body"