okf-ons
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:
El paquete OKF estático descubre y explica conjuntos de datos, versiones, dimensiones, procedencia, evidencia de estándares y alternativas.
OKF Explorer reduce y compara un gran corpus estático sin un LLM ni un servicio de búsqueda alojado.
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.
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
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
Repositorio OKF-ONS, todas las versiones de GitHub, y versión v0.2.0
Descargas inmutables de v0.2.0: ZIP del paquete y resumen SHA-256
Registro de fuentes, metadatos de publicación OKF, manifiesto de instantánea de versión, manifiesto de instantánea de enriquecimiento actual, y registro de cambios de la versión
Mapa de documentación
Producto y demostración: guía de demostración, contrato de producto, resumen del hackathon de ONS, y declaración de accesibilidad
Operación del repositorio: guía del repositorio, política de seguridad, registro de cambios de versiones, y flujo de trabajo de publicación de CI; el fragmento de cambio para clientes de IA se conserva como historial previo al lanzamiento
Metadatos y garantía: modelo de metadatos, alcance y denominador, y registro de estándares, además de la campaña cronometrada de enriquecimiento de metadatos y la transferencia de la campaña de OKF Explorer, con la auditoría de detención legible por máquina
Acceso MCP e IA: contrato de selección de MCP, despliegue de clientes MCP, y propuesta de acceso de agentes y evaluación
Evaluación: método de evaluación, análisis de prueba entre clientes, y el estudio legible por máquina, registro de clientes, tareas, resultados esperados, personas y recorridos, registro de incidencias, y consultas de oro
Investigación y comunicaciones: registro de investigación, manifiesto de evidencia de investigación, manifiesto de arquitectura, prompt de investigación de IA gobernada, informe de arquitectura de IA gobernada, y borrador de publicación
Registros de investigación de clientes de IA con fecha: traza de acceso de Claude Desktop, informe de Antigravity, y análisis posterior de Antigravity
Resultados de investigación portátiles: DOCX de traza de Claude, DOCX de informe de acceso a M365, DOCX de investigación de alojamiento de M365, presentación de IA gobernada, presentación de IA empresarial, y el visual de puente de descubrimiento
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.pyLos 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 bundleLa 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.jsonLas 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-completePara 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-completePara 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-completePara 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-completePara 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-completeLa 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 tasksEl 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 toolsokf.compareCompare exact ONS metadata recordsARead-onlyIdempotent
Return evidence-backed field contrasts for two to five exact records. Never asserts statistical equivalence.
| Name | Required | Description | Default |
|---|---|---|---|
| record_ids | Yes |
TDQS
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.
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.
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.
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.
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.
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 answerARead-onlyIdempotent
Validate and return a deterministic, non-persisted evaluation envelope. Accepts visible answers, evidence and caveats, never hidden reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | ||
| task_id | Yes | ||
| evidence | Yes | ||
| mcp_plan | No | ||
| contrasts | No | ||
| caveat_ids | Yes | ||
| confidence | Yes | ||
| alternatives | Yes | ||
| substitution | No | ||
| chosen_record_id | Yes | ||
| considered_record_ids | Yes |
TDQS
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.
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.
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.
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.
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.
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 recordARead-onlyIdempotent
Resolve an exact stable ID, native ID, route or declared evaluation alias and return the complete frozen metadata record.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
TDQS
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.
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.
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.
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.
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.
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 planBRead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | ||
| audience | No | ||
| arguments | No | ||
| record_id | Yes | ||
| expires_at | No |
TDQS
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.
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.
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.
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.
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.
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.
4 tool updates
v0.2.0- First observed
okf_eval.submit_answer - First observed
okf.compare - First observed
okf.get_record - First observed
okf.prepare_mcp_plan
TDQS
Scored across 4 tools
Each tool targets a distinct operation: record retrieval, comparison, plan preparation, and answer submission. No functional overlap exists.
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).
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.
Missing fundamental operations such as creating, updating, listing, or searching records. The tool set feels incomplete for the implied workflow.
Maintenance
Related MCP Connectors
UK Office for National Statistics dataset catalogue + Beta JSON API
Search, sample and query open reproducible datasets published as immutable Parquet with schemas.
Search and query 1,500+ OECD statistical datasets via SDMX. Keyless.
Curated gateway to snapshot-versioned Canadian public data services with source provenance.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables querying UK Office for National Statistics datasets and their editions through natural language, with no authentication required.203 npmMIT
- AlicenseAqualityDmaintenanceProvides 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.18MIT
- AlicenseAqualityDmaintenanceEnables users to discover and recommend Korea public datasets by describing their project idea, searching a static catalog of 96,056 datasets without API calls.715MIT
- AlicenseNot gradedqualityBmaintenanceProvides access to DataCite DOIs for research datasets, enabling searching and retrieval of dataset metadata.485 npmMIT