Record metadata

type: "Research"
title: "MCP access and OKF bundle discovery"
description: "Design for bounded machine access to OKF bundles and a digest-bound registry rather than an unbounded meta-bundle."
tags: [okf, mcp, discovery, registry, grounding]
language: en-GB
generated: { by: "process:okf-evolution-review", at: "2026-08-17T00:00:00Z" }
status: stable

MCP access and OKF bundle discovery

The prototype MCP server in mcp/okf_mcp_server.py exposes a local bundle by read-only JSON-RPC. Its bounded operations are:

list bundles and report identity/digest;
search records with deterministic lexical ranking;
fetch one exact record;
follow explicit relationships;
assemble a byte-limited context pack; and
expose provenance and source links already present in the record.

It does not execute commands declared by a bundle, fetch arbitrary URLs, resolve arbitrary remote JSON-LD contexts or invent semantic edges. The server is deliberately dependency-light so its retrieval behaviour can be tested independently from a particular MCP SDK. A production adapter should expose the same core through the client-supported MCP revision, authentication and transport.

Prompt and link compared with MCP

Direct prompt and bundle link	MCP retrieval
Lowest integration cost and already useful in Microsoft 365 Copilot.	Explicit query, limits, identity, digest and structured results.
Client decides how to crawl, index, rank and truncate.	Data owner can test deterministic retrieval and context budgets.
Fewer moving parts and familiar permissions where the content already lives.	More code, hosting, authentication, monitoring and client compatibility work.
Harder to observe why a near-neighbour won.	Ranking and returned evidence can be logged and compared.
Good default for small, stable and already indexed collections.	Better when bundles are numerous, large, sharded or require governed traversal.

The responsible sequence is to benchmark the simple route first, then add MCP only when its measurable retrieval, control or observability benefit exceeds its operational cost.

Discovery structure

The recommended control plane is a small catalogue registry, inspired by DCAT but specialised for OKF delivery. Each entry should carry:

stable bundle IRI and human title;
current version, OKF core version and optional profile IRIs;
descriptor and human landing-page URLs;
media types and supported projections;
publisher, licence, access class and jurisdiction;
themes, spatial/temporal coverage and languages;
issued, modified, observed and stale-after times;
record/relationship counts and sharding capabilities;
immutable snapshot digest and signature/attestation references; and
health, deprecation, replacement and compatibility information.

This is best treated as a registry/control-plane dataset. It may itself be published as a small OKF bundle to gain human navigation and provenance, but the narrative meta-bundle must not become the authority for the child content. The digest-bound child descriptors remain authoritative. Registries can federate, and duplicate entries are reconciled by stable bundle identity and snapshot digest rather than title matching.

Discovery flow

A client discovers one trusted registry by configuration or organisation policy.
It filters entries by theme, jurisdiction, access and freshness without loading child bundles.
It verifies the selected descriptor and immutable snapshot digest.
It selects a supported access path: static files, shards, MCP or a domain API.
It retrieves bounded evidence and retains the registry and child identities in the answer receipt.

This keeps discovery cheap and makes authority visible. Crawling every bundle or creating one enormous “bundle of bundles” would recreate the scale problem that progressive disclosure was intended to solve.