Skip to main content
Glama

Formato de Conocimiento Abierto de la ONS

okf-ons es una capa de descubrimiento solo de metadatos para estadísticas públicas expuestas a través de los servicios de la Office for National Statistics. Está diseñado para ayudar a una persona o a un agente a encontrar el conjunto de datos exacto, ver alternativas fácilmente confundibles, comprender la evidencia de calidad estadística disponible y preparar un plan candidato no ejecutable que un servicio posterior debe validar en vivo y autorizar antes de la recuperación.

El proyecto separa deliberadamente cuatro tareas:

  1. El paquete OKF estático descubre y explica conjuntos de datos, versiones, dimensiones, procedencia, evidencia de estándares y alternativas.

  2. OKF Explorer reduce y compara un gran corpus estático sin un LLM ni un servicio de búsqueda alojado.

  3. El broker MCP local del repositorio da a los clientes de IA acceso limitado a los mismos metadatos congelados y prepara un plan de selección no ejecutable.

  4. Un servidor MCP de datos en vivo posterior ejecuta una consulta de ONS o Nomis solo después de que las opciones específicas del conjunto de datos requeridas estén completas.

El broker local no es el servidor de datos en vivo posterior: no realiza llamadas de red y no devuelve valores de observación. No se almacenan observaciones, claves de API ni datos privados en el paquete.

Núcleo de OKF 0.2 y extensiones de Explorer

El paquete verificado se dirige a Open Knowledge Format 0.2. Su núcleo portátil generado comienza en index.md, que declara okf_version: "0.2" y enlaza progresivamente a conceptos tipados para el catálogo, la instantánea congelada, los cuatro carriles de fuentes, el estado del proveedor, la gobernanza, los estándares y la selección de MCP.

Cada concepto usa generated y sources. No se reclama ningún evento verified: las comprobaciones automatizadas prueban la conformidad estructural y la integridad de la entrada congelada, no la revisión humana ni la verdad estadística. No se inventa ningún valor stale_after mientras la política de frescura gobernada permanezca indefinida. El estado del ciclo de vida es, por tanto, explícito y la ejecución en vivo continúa requiriendo la revalidación del proveedor.

El descriptor de corpus grande, JSON/YAML-LD, la búsqueda estática, las facetas, las relaciones, la federación, los catálogos de integridad y los paquetes de datos del proveedor siguen siendo extensiones aditivas de Explorer. Los nuevos conceptos también conservan los respaldos timestamp y # Citations de v0.1 para que los consumidores más antiguos puedan continuar con el descubrimiento de mejor esfuerzo mientras que los consumidores de v0.2 prefieren generated y sources.

Related MCP server: ONS + Nomis MCP server

Acceso y documentación

Estos son los puntos de entrada canónicos para el despliegue de Pages desde main. La versión de aplicación inmutable v0.2.0 es anterior a la migración de la especificación OKF 0.2 y permanece disponible como evidencia histórica de la versión.

Acceso en vivo y legible por máquina

Recurso

URL

Interfaz de descubrimiento humano

https://chris-page-gov.github.io/okf-ons/

Índice raíz de OKF 0.2

https://chris-page-gov.github.io/okf-ons/index.md

Índice de conceptos OKF

https://chris-page-gov.github.io/okf-ons/concepts/

Abrir este paquete directamente en OKF Explorer

https://chris-page-gov.github.io/okf-explorer/?bundle=https%3A%2F%2Fchris-page-gov.github.io%2Fokf-ons%2Fokf-explorer.json

OKF Explorer sin un paquete precargado

https://chris-page-gov.github.io/okf-explorer/

Descriptor del paquete OKF

https://chris-page-gov.github.io/okf-ons/okf-explorer.json

Paquete semántico JSON-LD

https://chris-page-gov.github.io/okf-ons/okf-bundle.jsonld

Paquete semántico YAML-LD

https://chris-page-gov.github.io/okf-ons/okf-bundle.yamlld

Contexto JSON-LD local fijado

https://chris-page-gov.github.io/okf-ons/context/okf-ons.jsonld

Manifiesto de datos y fragmentos

https://chris-page-gov.github.io/okf-ons/data/manifest.json

Índice de visión general

https://chris-page-gov.github.io/okf-ons/data/overview.json

Visión general del análisis

https://chris-page-gov.github.io/okf-ons/data/analysis/overview.json

Libro mayor de cobertura

https://chris-page-gov.github.io/okf-ons/data/coverage/ledger.json

Reconciliación entre fuentes

https://chris-page-gov.github.io/okf-ons/data/reconciliation/report.json

Metadatos de versión gobernada

https://chris-page-gov.github.io/okf-ons/data/governance/release.json

Conjunto de contexto vinculado a resúmenes

https://chris-page-gov.github.io/okf-ons/data/governance/context-set.json

Sumas de verificación

https://chris-page-gov.github.io/okf-ons/checksums.json

Manifiesto de búsqueda

https://chris-page-gov.github.io/okf-ons/data/search/manifest.json

Evaluación de estándares

https://chris-page-gov.github.io/okf-ons/data/standards/evaluation.json

Informe de conformidad OKF 0.2

https://chris-page-gov.github.io/okf-ons/data/standards/okf-v0.2.json

Evidencia SDMX

https://chris-page-gov.github.io/okf-ons/data/standards/sdmx.json

Informe de evaluación

https://chris-page-gov.github.io/okf-ons/data/evaluation/report.json

Índice de enlaces MCP

https://chris-page-gov.github.io/okf-ons/data/ons/mcp-bindings.json

Índice espacial

https://chris-page-gov.github.io/okf-ons/data/ons/spatial-index.json

Guía de demostración en vivo

https://chris-page-gov.github.io/okf-ons/demo-guide.html

Declaración de accesibilidad

https://chris-page-gov.github.io/okf-ons/accessibility.html

Los fragmentos subordinados de conjuntos de datos, recursos, búsqueda y opciones de selección se descubren a través de los manifiestos de datos y búsqueda anteriores; sus rutas generadas no son puntos de entrada estables independientes.

Repositorios, versión y procedencia

Mapa de documentación

OKF Explorer puede cargar el paquete hoy mediante el enlace directo anterior. Se recomienda una actualización separada del registro y la presentación de Explorer para que el paquete se sugiera sin pegar su URL y los nuevos campos de autoridad, derechos y gobernanza se muestren como interfaz de primera clase en lugar de solo en JSON sin procesar.

Soporte de SDMX

El paquete registra SDMX 3.1 (ISO 17369), asigna siete campos canónicos de OKF a conceptos de SDMX y conserva la agencia, el identificador, la versión, el orden de dimensiones, los roles de componentes y las referencias a listas de códigos de SDMX del carril de Nomis. Las selecciones de Nomis también conservan opciones limitadas de etiquetas de código FREQ y extensiones estrictas de TIME disponibles cuando esa evidencia es utilizable. FREQ es la frecuencia estadística/de referencia, no la cadencia de publicación, y las anotaciones de revisión de períodos de TIME no son el estado de revisión del conjunto de datos. Todas las demás dimensiones requeridas aún necesitan validación y selección en vivo; la ejecución en vivo completada utiliza nomis_query de MCP-Geo.

El paquete no es en sí mismo un mensaje SDMX. Se serializa como JSON-LD utilizando términos de DCAT 3, SKOS, PROV-O y RDF Data Cube, sin espacio de nombres SDMX en su contexto. El data/standards/sdmx.json generado informa el mapeo exacto y los recuentos de evidencia de Nomis sin afirmar conformidad o certificación ascendente.

Demostrador del lunes

El demostrador previo al hackathon está congelado para que la presentación del lunes pueda usar una instantánea reproducible y revisable en lugar de adquisiciones en vivo cambiantes. Publica:

  • un libro mayor de fuentes y cobertura que hace explícita la incompletitud;

  • una instantánea de metadatos congelada de 5,097 registros de la API de datos de ONS (337), Nomis (1,617), ONS Open Geography (3,035) y ONS Explore Local Statistics (108);

  • roles calificados de productor de fuente, operador de servicio, publicador de paquete y autoridad semántica, con no respaldo explícito;

  • búsqueda determinista y publicaciones de filtros de primera clase;

  • relaciones de alternativa/contraste respaldadas por evidencia;

  • conciliación exacta de códigos de tabla del Censo entre la API de datos de ONS y Nomis;

  • evidencia de calidad estadística y estándares sin afirmaciones de garantía falsas;

  • un contrato de plan de selección de MCP; y

  • un informe reproducible de evaluación de recuperación y calidad de metadatos.

El ID de instantánea inmutable monday-2026-07-17-r2 extiende la congelación del viernes 17 de julio con la proyección de metadatos de ELS fijada. El sufijo r2 evita que el corpus expandido reutilice la identidad de instantánea original v0.1; "monday" es el nombre del demostrador, no una afirmación de que el 17 de julio fuera lunes.

El carril de Explore Local Statistics es una proyección determinista y de lista permitida del submódulo de aplicación fijado. Lleva 108 indicadores seleccionados por ONS de 24 productores atribuidos, explica 12 entradas de manifiesto no publicadas, conserva 46 alias históricos válidos y elimina valores de observación, matrices de estado, dominios de valores, binarios y geometría. Es un dispositivo de desarrollo más que una afirmación de que la API interna de ELS es un contrato de ejecución público estable. Su commitAsOf de Git verificado se mantiene separado del tiempo de adquisición; la fijación congelada no inventa una marca de tiempo de recuperación que no se registró.

El paquete también publica un paquete de datos de proveedor que hace visible la distinción entre instantánea de ELS y en vivo sin debilitar la reproducibilidad. La instantánea gobernada permanece fijada a 795eaf2 del 17 de julio de 2026. Una referencia ascendente revisada por separado en d5f0ac9 registra una diferencia de ejemplo conocida: el precio promedio de la vivienda termina en abril de 2026 en la instantánea y en mayo de 2026 en la referencia revisada. Esa referencia se verificó por última vez el 23 de julio de 2026, es explícitamente externa y no es una validación en vivo. Su comparación es un ejemplo revisado no exhaustivo, no una afirmación de que los 108 indicadores se compararon. El descriptor aplica un hash al manifiesto del proveedor y el manifiesto aplica un hash al paquete, por lo que la revisión con fecha no se puede reemplazar bajo el mismo ID de instantánea sin fallar las comprobaciones de integridad de Explorer. Consulte el contrato de paquetes de datos de proveedor.

Este paquete experimental es publicado de forma independiente por el proyecto OKF ONS. La atribución de fuente no implica respaldo por parte de ONS u otro productor.

Compilación

Se requiere Python 3.11 o posterior. Se requiere un clon recursivo porque los archivos fuente normales de GitHub no contienen el submódulo ELS fijado. El ZIP del paquete de lanzamiento enlazado anteriormente es el artefacto de publicación autocontenido.

okf.publication.json registra el contrato v1 del método de publicación del repositorio: familias de fuentes congeladas, límites de autoría y generación, planos de dependencia, declaraciones de comandos revisadas, sincronización de documentación y destino de Pages. Las cadenas de comandos en el contrato son declaraciones no confiables y deben verificarse contra esta guía antes de su uso. Valide las rutas locales, las referencias cruzadas y el grafo de planos acíclico con:

python scripts/check_publication_contract.py

Los cambios en rutas controladas de fuente, generador, aplicación o flujo de trabajo deben actualizar la documentación relevante y CHANGELOG.md en el mismo cambio. Las rutas desconocidas fallan de forma cerrada y las actualizaciones de dependencias no tienen exención general.

El flujo de trabajo de Pages compila el directorio ignorado bundle/ una vez, luego valida, ensambla y sube esos mismos bytes del espacio de trabajo. Una compilación previa limpia con --check no es posible porque no se rastrea una línea base de paquete generada. Introducir una línea base inmutable separada o un artefacto de lanzamiento es la opción futura registrada; el flujo de trabajo no realiza una segunda compilación idéntica solo para comparar el resultado consigo mismo.

Para reproducir v0.2.0 desde su instantánea congelada verificada:

git clone --recurse-submodules --branch v0.2.0 \
  https://github.com/chris-page-gov/okf-ons.git
cd okf-ons
python scripts/project_els_snapshot.py \
  --submodule-dir vendor/explore-local-statistics-app \
  --output output/ons-explore-local-statistics.json
cmp output/ons-explore-local-statistics.json \
  source/demo-snapshot/ons-explore-local-statistics.json
python scripts/build_bundle.py \
  --snapshot-dir source/demo-snapshot \
  --output bundle
python scripts/build_bundle.py \
  --snapshot-dir source/demo-snapshot \
  --output bundle \
  --check
python scripts/check_okf_v02.py bundle

La campaña de enriquecimiento de metadatos también incluye la instantánea sucesora inmutable metadata-enrichment-2026-07-21-r6. En relación con la instantánea v0.2.0, r3 actualiza el catálogo limitado de la API de datos de ONS, r4 agrega resúmenes compactos de Nomis limitados solo a metadatos, y r5 agrega solo la proyección de dimensiones revisada de cada URL de versión más reciente congelada de ONS. r6 sigue las referencias exactas de listas de códigos FREQ y TIME en la cohorte congelada de Nomis de r5 y conserva solo metadatos de etiquetas de código y anotaciones explícitas de estado de revisión de períodos. Los sobres de fuente de la API de datos de ONS, Explore Local Statistics y Open Geography en r6 son byte-idénticos a r5. Recompile y perfile r6 sin acceso a la red:

python scripts/build_bundle.py \
  --snapshot-dir source/metadata-enrichment-2026-07-21-r6 \
  --output bundle
python scripts/build_bundle.py \
  --snapshot-dir source/metadata-enrichment-2026-07-21-r6 \
  --output bundle \
  --check
python scripts/profile_metadata_gaps.py \
  --bundle bundle \
  --output evaluation/metadata-completeness/current.json

Las URL en vivo de Pages y Explorer anteriores aún sirven la versión gobernada v0.2.0. La instantánea de campaña r6 está verificada como evidencia de campaña gobernada pero sigue siendo un candidato de lanzamiento no implementado hasta que los metadatos de lanzamiento y la instantánea seleccionada por Pages se cambien deliberadamente.

El historial de lotes medido, las definiciones de métricas, los tiempos y los perfiles legibles por máquina están enlazados desde la campaña de enriquecimiento de metadatos, incluida la auditoría de detención.

Para un clon existente, ejecute git submodule update --init --recursive antes del proyector. Para adquirir una instantánea futura, mantenga la caché sin procesar fuera del repositorio, use --mode refresh y elija una nueva identidad inmutable—nunca sobrescriba una instantánea existente. Para actualizar solo el catálogo de ONS mientras se conservan los otros sobres de fuente validados:

python scripts/acquire_snapshot.py \
  --cache-dir /path/to/raw-cache \
  --output-dir source \
  --snapshot-id NEW_UNIQUE_SNAPSHOT_ID \
  --base-snapshot source/metadata-enrichment-2026-07-21-r4 \
  --source ons-data-api \
  --mode refresh \
  --page-size 1000 \
  --maximum-pages 1 \
  --require-complete

Para reproducir o actualizar los resúmenes compactos limitados de Nomis, use la instantánea r3 validada previa al enriquecimiento como base: los sobres de reemplazo están vinculados por digest a esa cohorte exacta y las instantáneas de enriquecimiento no se encadenan como bases de adquisición. Primero adquiera en un sobre de reemplazo externo, luego componga ese sobre sobre r3. El script de adquisición deriva de forma independiente su cohorte de la fuente congelada de Nomis y no publica respuestas sin procesar ni rutas de caché:

python scripts/acquire_nomis_overviews.py \
  --snapshot-dir source/metadata-enrichment-2026-07-21-r3 \
  --cache-dir /path/to/raw-cache \
  --output /path/to/nomis-overviews.json \
  --limit 1617 \
  --mode refresh \
  --request-interval 0.2
python scripts/acquire_snapshot.py \
  --cache-dir /path/to/raw-cache \
  --output-dir source \
  --snapshot-id NEW_UNIQUE_SNAPSHOT_ID \
  --base-snapshot source/metadata-enrichment-2026-07-21-r3 \
  --replacement-acquisition /path/to/nomis-overviews.json \
  --require-complete

Para reproducir o actualizar la proyección de dimensiones de la versión más reciente limitada de ONS, use r4 como base validada previa al enriquecimiento. La adquisición sigue solo los 337 valores exactos de links.latest_version.href congelados en r4, almacena solo la proyección de lista permitida en una caché externa y no obtiene observaciones, opciones de dimensiones, listas de códigos ni descargas:

python scripts/acquire_ons_version_metadata.py \
  --snapshot-dir source/metadata-enrichment-2026-07-21-r4 \
  --cache-dir /path/to/external-cache \
  --output /path/to/ons-version-metadata.json \
  --limit 337 \
  --mode refresh \
  --request-interval 0.5
python scripts/acquire_snapshot.py \
  --cache-dir /path/to/external-cache \
  --output-dir source \
  --snapshot-id NEW_UNIQUE_SNAPSHOT_ID \
  --base-snapshot source/metadata-enrichment-2026-07-21-r4 \
  --replacement-acquisition /path/to/ons-version-metadata.json \
  --require-complete

Para reproducir o actualizar la proyección de listas de códigos FREQ/TIME limitada de Nomis, use r5 como base exacta. La adquisición sigue 3,234 referencias de listas de códigos congeladas solo de metadatos secuencialmente, conserva resultados fallidos explícitos en el denominador y almacena solo su proyección de lista permitida en una caché externa versionada:

python scripts/acquire_nomis_codelists.py \
  --snapshot-dir source/metadata-enrichment-2026-07-21-r5 \
  --cache-dir /path/to/external-cache \
  --output /path/to/nomis-codelists.json \
  --limit 1617 \
  --mode refresh \
  --request-interval 0.2
python scripts/acquire_snapshot.py \
  --cache-dir /path/to/external-cache \
  --output-dir source \
  --snapshot-id NEW_UNIQUE_SNAPSHOT_ID \
  --base-snapshot source/metadata-enrichment-2026-07-21-r5 \
  --replacement-acquisition /path/to/nomis-codelists.json \
  --require-complete

Para una actualización completa de fuentes registradas, primero produzca la proyección local fijada de ELS, luego adquiera todos los carriles HTTP e inclúyala:

python scripts/project_els_snapshot.py \
  --submodule-dir vendor/explore-local-statistics-app \
  --output /path/to/els-projection.json
python scripts/acquire_snapshot.py \
  --cache-dir /path/to/raw-cache \
  --output-dir /path/to/public-snapshots \
  --snapshot-id NEW_UNIQUE_SNAPSHOT_ID \
  --mode refresh \
  --projected-acquisition /path/to/els-projection.json \
  --require-complete

La adquisición es reanudable y externa. bundle/ es determinista a partir de una instantánea congelada validada.

El resumen del hackathon de ONS que se puede enviar explica el paquete de trabajo, la ruta de demostración y las preguntas para ONS. Consulte también el registro de estándares, método de evaluación y alcance y denominador.

Investigación y evaluación de acceso a IA

El repositorio conserva y fija mediante SHA-256 las pruebas del 18 de julio de 2026 de Claude Desktop Cowork, Google Antigravity CLI y Microsoft 365 Copilot Researcher en research/. Solo se publican derivados DOCX públicos, revisados técnicamente y saneados. Los paquetes originales de Office se retienen fuera de Git y se identifican únicamente por sus hashes de origen fijados. Las observaciones normalizadas mantienen separados los derivados públicos, la identidad declarada en la sesión, la verificación posterior y nuestras interpretaciones.

El caso de estudio ahora siembra un banco de pruebas neutral respecto al proveedor y seguro para accesorios:

python3 scripts/ai_client_harness.py validate
python3 scripts/ai_client_harness.py validate-research
python3 scripts/ai_client_harness.py clients --initial-only
python3 scripts/ai_client_harness.py probe-clients
python3 scripts/ai_client_harness.py tasks

El banco de pruebas define brazos OKF, web abierta y API sin procesar; ocho tareas de humo de desarrollo; seis personas específicas de ONS y ocho recorridos; un registro de diez incidencias observadas; una respuesta estructurada común; evaluación independiente vinculada a la respuesta; puntuación determinista de componentes; separación entre lo impuesto y lo autodeclarado; y resultados de preparación separados para que un cliente bloqueado no se puntúe como respuesta incorrecta. La CI no realiza llamadas en vivo, autenticadas ni de pago a modelos.

Un broker MCP de solo metadatos, sin dependencias, ahora expone herramientas deterministas de descriptor, búsqueda, registro exacto, comparación, plan MCP de solo lectura y envío de respuestas. Antigravity CLI (agy) puede cargarlo desde el .agents/mcp_config.json con ámbito de repositorio. Esa configuración se añadió después de la prueba conservada de Antigravity; no se reivindica ninguna ejecución nueva de modelo de pago o en vivo. El broker usa el corpus congelado, no realiza ninguna llamada de red, no almacena credenciales y no devuelve valores de observación.

Mapa de conexión de sistemas de IA

La guía de despliegue de MCP es la guía canónica de configuración y estado para cada superficie de IA en el registro de evaluación. Distingue cuatro capas de acceso y despliegue:

  • Acceso a paquete estático: cualquier cliente HTTP permitido puede leer el descriptor y el JSON de Pages, pero la captación nativa difiere según el host.

  • MCP local de metadatos: los clientes de línea de comandos y de escritorio que admiten MCP stdio local pueden iniciar scripts/okf_ons_mcp.py. La configuración de espacio de trabajo AGY confirmada es la única configuración de cliente con ámbito de repositorio; la guía ofrece las rutas separadas de Codex, Claude, Gemini, VS Code/Copilot e Inspector sin tratar la instalación como una prueba exitosa.

  • MCP remoto de metadatos planificado: las aplicaciones personalizadas de ChatGPT necesitan un endpoint remoto compatible o una ruta de túnel; Claude Research, Cowork de sesión remota y Microsoft 365 Copilot Researcher necesitan un endpoint remoto autenticado. Cowork local de escritorio puede usar MCP local, sujeto a la política del dispositivo. Este repositorio no despliega ni un endpoint remoto ni un túnel. La ruta del conector federado de M365 está documentada, pero no se ha creado ni habilitado para un inquilino.

  • MCP en vivo descendente: una vez completada la selección, una integración separada de ONS o Nomis puede ejecutar el plan. El broker del repositorio deliberadamente nunca lo hace.

El client-profiles.json legible por máquina es el registro completo de clientes de 16 perfiles; study.json fija el diseño de la evaluación. Los públicos tasks.json, personas-and-journeys.json y issue-register.json mantienen las tareas, los usuarios, los recorridos, los fallos observados y las correcciones en sincronía con ese diseño.

Consulte el análisis de pruebas entre clientes para ver la evidencia, la matriz de incidencias/correcciones, las personas, el protocolo de eficiencia y los paquetes de trabajo priorizados.

Qué significa «todo»

El repositorio puede describirse a sí mismo como cobertura de todos los metadatos públicos de ONS solo cuando cada fuente dentro del alcance en source/source-register.json tiene un denominador medido y el libro de cobertura generado informa unexplained_omissions = 0.

Las celdas de observación, los microdatos seguros y las cargas útiles binarias duplicadas quedan intencionadamente fuera del alcance. Consulte alcance y denominador.

Licencia

El código tiene licencia MIT. Los metadatos de origen siguen sujetos a su licencia ascendente declarada, a menudo la Open Government Licence v3.0. El paquete no hace ninguna reivindicación de licencia general: los derechos de registro ELS permanecen como not-evaluated pendientes de revisión fuente por fuente, y los registros generados conservan la evidencia de fuente y derechos disponible.

Available Tools

4 tools
okf.compareCompare exact ONS metadata recordsA
Read-onlyIdempotent

Return evidence-backed field contrasts for two to five exact records. Never asserts statistical equivalence.

NameRequiredDescriptionDefault
record_idsYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the behavioral caveat 'Never asserts statistical equivalence,' which goes beyond annotations. However, it does not disclose error handling or behavior with missing records.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the primary action front-loaded. Every sentence adds value, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and rich annotations, the description is adequate but could be more complete by explaining the output format or providing an example. Parameter explanation is minimal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It adds the context of 'two to five exact records' reinforcing minItems/maxItems constraints but does not explain the format or meaning of the record_ids strings beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares exact ONS metadata records by returning field contrasts. It specifies the range (2-5 records) and differentiates from siblings like okf.get_record which retrieves a single record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for comparing two to five exact records but does not explicitly state when to use this tool versus alternatives like okf.get_record. It provides no when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

okf_eval.submit_answerNormalise an AI evaluation answerA
Read-onlyIdempotent

Validate and return a deterministic, non-persisted evaluation envelope. Accepts visible answers, evidence and caveats, never hidden reasoning.

NameRequiredDescriptionDefault
answerYes
task_idYes
evidenceYes
mcp_planNo
contrastsNo
caveat_idsYes
confidenceYes
alternativesYes
substitutionNo
chosen_record_idYes
considered_record_idsYes

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context beyond annotations: it specifies the tool is non-persisted, deterministic, and never accepts hidden reasoning. Annotations already mark it as readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description reinforces and elaborates on these traits, providing useful behavioral clarity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that effectively front-loads the core purpose (validate, deterministic, non-persisted) and lists accepted inputs. Every phrase adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, 8 required, no output schema, nested objects), the description is insufficient. It does not explain the structure of the return envelope, the meaning of required parameters, or how inputs like task_id, chosen_record_id, and considered_record_ids should be used. The absence of output schema makes this gap more critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries full responsibility for explaining parameters, but it only mentions 'visible answers, evidence and caveats,' corresponding to answer, evidence, caveat_ids. Eleven parameters exist, including key ones like task_id, chosen_record_id, considered_record_ids, alternatives, mcp_plan, contrasts, substitution, confidence, all unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Validate and return a deterministic, non-persisted evaluation envelope.' It specifies what it accepts (visible answers, evidence, caveats) and excludes (hidden reasoning), distinguishing it from siblings like okf.get_record, okf.compare, and okf.prepare_mcp_plan, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when or when not to use this tool versus alternatives. No explicit context for usage, prerequisites, or exclusions are mentioned, leaving the agent to infer when submit_answer is appropriate given the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

okf.get_recordHydrate one exact ONS metadata recordA
Read-onlyIdempotent

Resolve an exact stable ID, native ID, route or declared evaluation alias and return the complete frozen metadata record.

NameRequiredDescriptionDefault
identifierYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and idempotentHint. Description adds 'frozen' to indicate immutability but does not disclose error behavior (e.g., what happens if identifier not found). Minimal additional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded with action and resource. All words carry meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description does not explain return structure beyond 'complete frozen metadata record'. Lacks details on pagination, error responses, or data format. Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no description for 'identifier' (0% coverage). Description compensates by listing acceptable identifier types: 'exact stable ID, native ID, route or declared evaluation alias', which adds meaningful context beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Resolve' and lists exact resource types (stable ID, native ID, route, alias) and output ('complete frozen metadata record'). Clearly distinguishes from sibling tools like okf.compare or okf_eval.submit_answer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the purpose implies single-record retrieval, it does not state when not to use it or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

okf.prepare_mcp_planPrepare a non-executing MCP selection planB
Read-onlyIdempotent

Bind the exact frozen identity and snapshot digest to its inspection/query tools, audience, purpose and caller-declared expiry. Preserve unresolved dimensions and reject credential fields. Never authorises or executes a query.

NameRequiredDescriptionDefault
purposeNo
audienceNo
argumentsNo
record_idYes
expires_atNo

TDQS

B3.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by stating it preserves unresolved dimensions, rejects credential fields, and never authorizes or executes, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief (two sentences) but the first sentence is dense with jargon, making it less clear. It lacks a clear breakdown of what the tool does in simpler terms.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, no output schema, nested objects), the description lacks details on the return value or how the plan is used afterward. It does not cover what the output contains, leaving the agent with insufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description refers to 'audience, purpose and caller-declared expiry,' linking to three parameters, but does not explain 'arguments,' 'record_id,' or their semantics. With 0% schema coverage, the description should provide more parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it binds a frozen identity and snapshot digest to tools, audience, purpose, and expiry, and emphasizes it never executes. The title 'Prepare a non-executing MCP selection plan' reinforces this. However, jargon like 'frozen identity' and 'snapshot digest' may not be universally understood, slightly reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it should be used for preparing a plan without execution ('Never authorises or executes a query') and mentions preserving unresolved dimensions and rejecting credentials. It does not explicitly contrast with siblings like okf.get_record or okf_eval.submit_answer, but the distinct roles are inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.2.0
    • First observedokf_eval.submit_answer
    • First observedokf.compare
    • First observedokf.get_record
    • First observedokf.prepare_mcp_plan

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct operation: record retrieval, comparison, plan preparation, and answer submission. No functional overlap exists.

Naming Consistency3/5

Names mix dot notation (okf.get_record) and underscore (okf_eval.submit_answer), with inconsistent prefixes (okf vs okf_eval) and verb forms (compare vs prepare_mcp_plan).

Tool Count3/5

4 tools is on the lower side but may be appropriate for a narrow domain. However, the descriptions suggest a more complex system that could benefit from additional tools.

Completeness2/5

Missing fundamental operations such as creating, updating, listing, or searching records. The tool set feels incomplete for the implied workflow.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables querying UK Office for National Statistics datasets and their editions through natural language, with no authentication required.
    203 npm
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Provides access to UK economic, social, and labour-market statistics via the ONS beta and Nomis APIs, enabling discovery and retrieval of time series, datasets, and census data.
    18
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables users to discover and recommend Korea public datasets by describing their project idea, searching a static catalog of 96,056 datasets without API calls.
    7
    15
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides access to DataCite DOIs for research datasets, enabling searching and retrieval of dataset metadata.
    485 npm
    MIT