ensmcp 是一个 MCP（模型上下文协议）服务器，将 ENS Navegable（RD 311/2022附件II）的安全措施提供给 Claude Desktop、Claude Code 及任何其他 MCP 客户端使用。它是一个独立服务器，与 CCN、CCN-CERT 或 CNI 无隶属关系，也未获得其支持或维护。
数据以快照形式随包分发，因此服务器可即时响应并离线运行。默认模式为 offline：不启动 Chrome 也不访问网络。--check-updates 用于检查官方来源而不替换快照，--live 可临时采用实时数据。
除附件II外，还集成了 CCN-STIC 808 指南（RD 311/2022版）的验证问卷：每项措施的审计问题、对RD条款的核查以及审计员可能要求的文件证据。
特性 | 描述 |
基于 stdio 的 MCP 服务器 | 可集成到 Claude Desktop、Claude Code 及其他 MCP 客户端 |
离线运行 | 完整语料以快照形式随包分发 |
确定性快照 | 默认模式始终提供打包的语料 |
显式检查 |
|
适用性矩阵 | 计算规范性基础，用于准备适用性声明 |
CCN-STIC 808 审计 | 审计大纲、基本要求、RD条款及文件证据 |
Related MCP server: Swiss Law Local Search
Tool | Args | 描述 |
| — | 附件II的类别及其分组（ |
|
| 按类别、安全维度或级别筛选的措施。 |
|
| 按精确代码获取单项措施（例如 |
|
| 在代码、标题、描述和RD文本中进行全文搜索（忽略大小写和重音符号）。 |
Tool | Args | 描述 |
|
| 准备DdA的规范性基础矩阵：对每个维度进行评级（ |
| 与DdA相同 | 系统的审计大纲：适用的措施及其累积的验证问题，以及最低要求的成熟度级别。 |
|
| CCN-STIC 808原始问卷，按措施或按区间，并标注基本要求。 |
| — | 对RD条款的审计核查（正式DdA、分类、INES等）。 |
|
| 审计员可能要求的文件，按措施分类。 |
Tool | Args | 描述 |
| — | 立即检查官方网站，若数据有变更则更新。 |
| — | 当前所提供数据的来源和新鲜度。 |
每项措施包含两段文本，两者缺一不可：norm_text 是 RD 311/2022 的条文（该措施要求什么），description 是 CCN-STIC 808 的问卷（审计员询问什么）。强化措施与其要求的级别及RD条文配对出现：
{
"code": "mp.s.4",
"title": "Protección frente a denegación de servicio",
"description": "Categoría Media 1.1 ¿Se ha planificado y dotado al sistema de capacidad suficiente ...?",
"norm_text": "Se establecerán medidas preventivas frente a ataques de denegación de servicio ...",
"category_code": "mp.s",
"dimensions": ["disponibilidad"],
"levels": ["medio", "alto"],
"reinforcements": [
{ "code": "R1", "level": "alto", "alternative": false, "text": "R1-Detección y reacción. ..." }
],
"raw_levels": { "bajo": "n.a.", "medio": "aplica", "alto": "+ R1" }
}alternative 区分强制性强化措施（+ R1 + R2）和可替代性强化措施（+ [R1 o R2]，满足其中任意一项即可）：混淆两者会改变需要实施的内容。
ENS 并非为整个系统指定一个级别：而是每个维度一个级别。对每个维度进行评级后，工具返回该系统必须满足的要求：
{
"categoria_sistema": "alta",
"measures": [
{ "code": "op.acc.5", "title": "Mecanismo de autenticación (usuarios externos)",
"required_level": "alto",
"required_reinforcements": [
{ "code": "R2", "alternative": true, "text": "R2-..." },
{ "code": "R5", "alternative": false, "text": "R5-..." }
] }
]
}规则出自 RD 311/2022：系统类别为所评级别中的最高者（附件I第4节），标记为「类别」的措施按系统类别执行，保护维度的措施按该维度的级别执行，未评级的维度将排除仅保护该维度的措施。
如果DdA回答的是*「我需要实施什么？」，那么 alcance_auditoria 回答的是「审计员会问我什么？」*。它针对每项适用措施，返回累积到其要求级别的验证要求，以及指南要求的最低成熟度级别：
类别 | 最低成熟度级别 |
基础 | L2 — 可复现，但凭直觉 |
中等 | L3 — 已定义流程 |
高级 | L4 — 已管理且可度量 |
这个细节很重要：ENS Navegable 标注为「基础/中等/高级类别」的区间，根据 CCN-STIC 808 §5 是累积性的——「基础类别」意味着对所有类别都适用，而非仅适用于基础系统。中等类别系统需要回答基础和中等的全部问题。对于一个 C=高、I=中、D=低、A=中、T=中的系统，实际大纲是 382 个问题（其中136个为基本要求，不满足将阻止认证），而非其区间的73个。
requisitos_articulos 和 evidencias_auditoria 覆盖审计的另一半：对RD条款的核查（DdA是否存在并已签署、系统是否已正式分类、是否向INES报告等）以及指南建议的365项文件证据。这些数据来自 CCN-STIC 808；ENS Navegable 不发布这些内容。
src/ensmcp/data/anexo_ii.json — ENS Navegable 的语料（措施、RD文本、问卷、按级别的适用性），从官方网站抓取。每次查询都是内存中的查找。
src/ensmcp/data/guia_808.json — 从 CCN-STIC 808 指南中提取的数据及其归属信息（指南本身不重新分发）。snapshot_status 指示其来源版本。
重新生成快照：
python scripts/build_snapshot.py服务器默认不启动 Chrome 也不使用网络。要显式检查变更：
ensmcp --offline
ensmcp --check-updates
ensmcp --live也可以通过 ENSMCP_MODE=offline|check-updates|live 进行配置。
Python 3.12-3.14
仅更新快照时（refresh_live_page、启动检查、scripts/build_snapshot.py）还需要：
已安装 Google Chrome
一个显示器（无显示器的服务器上需要 xvfb）
从 PyPI 使用服务器：
pip install ensmcp
ensmcp --offline启用实时检查：
pip install "ensmcp[live]"
ensmcp --check-updatesgit clone https://github.com/seifreed/ensmcp.git
cd ensmcp
python3 -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r pylock.toml # versiones exactas, verificadas por hash
pip install -e . --no-deps # el propio paquete, sin re-resolver
patchright install chromium在全新安装的 Linux 上可能还需要：
patchright install-deps chromiumpyproject.toml 是唯一声明依赖的地方；pylock.toml 是根据它生成的产物（PEP 751），将所有依赖——运行时和开发依赖一起——固定到精确版本和哈希，并带有 Windows、Linux 和 macOS 的 x64 和 ARM 标记。要更新依赖，请编辑 pyproject.toml 中的范围并重新生成：
uv pip compile pyproject.toml --all-extras --universal --python-version 3.12 \
--format pylock.toml -o pylock.tomlpython -m ensmcp在 MCP 客户端（例如 Claude Desktop / Claude Code）中配置，指向虚拟环境的解释器：
{
"mcpServers": {
"ensmcp": { "command": "ensmcp", "args": ["--offline"] }
}
}无需其他配置：查询直接从包中的快照响应。
对于合规性决策，以 BOE、技术安全指令、现行官方指南以及相应审计或认证机构的判断为准。
手动检查：
npx @modelcontextprotocol/inspector venv/bin/python -m ensmcp欢迎贡献。
Fork 本仓库
创建你的功能分支（git checkout -b feature/nueva-funcionalidad）
提交你的更改（git commit -m 'Añade nueva funcionalidad'）
推送分支（git push origin feature/nueva-funcionalidad）
打开 Pull Request
请确保所有质量和安全门禁在发送 PR 前无错误无警告地通过。
如果这个项目对你有用，你可以支持它的发展：
Marc Rivero López | @seifreed
El temario de auditoría de un sistema: qué le van a preguntar.
Mismos argumentos que declaracion_aplicabilidad — el nivel de cada
dimensión, u omitida si el sistema no la valora.
Devuelve sólo las medidas que le aplican y, por cada una, los requisitos de verificación exigibles acumulados: los de "Categoría Básica" se exigen a todas las categorías, los de "Media" a MEDIA y ALTA, y los de "Alta" sólo a ALTA (CCN-STIC 808 §5). Un sistema medio responde los de básica y los de media.
nivel_madurez_requerido es el mínimo CMM que el auditor exige a cada
medida según la categoría (CCN-STIC 808 §6), con su code y su
name: BÁSICA → L2 "Reproducible, pero intuitivo", MEDIA → L3
"Proceso definido", ALTA → L4 "Gestionado y medible". essential marca los
requisitos cuyo incumplimiento hace que la medida entera cuente como no
implantada.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| compact | No | ||
| integridad | No | ||
| autenticidad | No | ||
| trazabilidad | No | ||
| measure_codes | No | ||
| disponibilidad | No | ||
| confidencialidad | No | ||
| include_evidence | No | ||
| include_norm_text | No | ||
| include_questions | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: the category-based accumulation rules (Básica applies to all, Media to MEDIA/ALTA, Alta only to ALTA, CCN-STIC 808 §5), the meaning of `nivel_madurez_requerido`, and the `essential` flag semantics. This enriches what the raw annotations convey. No contradiction with annotations — the compute/read behavior described matches readOnlyHint=true.
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 dense but every sentence earns its place: purpose, input contract, accumulation rules, maturity levels, and the `essential` flag semantics. It is front-loaded with the purpose statement and organized in logical paragraphs. It is somewhat long and technical (CCN-STIC references, CMM level names), but the complexity of the domain justifies the length.
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 an output schema exists (so return values need not be spelled out) and 12 parameters, the description covers the core semantics thoroughly: dimension inputs, accumulation behavior, maturity requirements, and essential flags. The only real gap is the output-formatting/pagination parameters (limit, cursor, compact, include_*) left unexplained, but those are largely self-evident from their names. It is complete enough for an agent to call the tool correctly for its primary purpose.
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 description coverage is 0%, so the description carries the burden of explaining parameters. It does map the key semantic inputs — the dimension levels (integridad, autenticidad, disponibilidad, confidencialidad, trazabilidad) and their 'omitted if not valued' behavior — and explains output fields like `nivel_madurez_requerido` and `essential`. However, it never mentions `limit`, `cursor`, `compact`, `include_evidence`, `include_norm_text`, or `include_questions`, leaving 6 of 12 parameters undocumented in both schema and description. It compensates only partially for the coverage gap.
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 opening line states a specific purpose — the audit syllabus of a system, i.e., what will be asked — and the description makes clear it returns applicable measures with their accumulated verification requirements. It provides a concrete resource and verb. However, it does not differentiate itself from close siblings like `requisitos_auditoria` or `evidencias_auditoria`, which an agent could easily confuse with this tool, so it stops short of a 5.
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?
Gives explicit calling context: takes the same arguments as `declaracion_aplicabilidad` (dimension level per dimension, or omitted if not valued), explaining the input semantics needed to invoke it correctly. It also states the accumulation logic clearly. It does not, however, state when NOT to use this tool versus its siblings, so the guidance is strong on how but weaker on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea y persiste una DdA completa para un sistema o subsistema.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | ||
| record_id | Yes | ||
| subsystem_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, covering the safety profile. The description adds only 'persiste', confirming a write; it does not disclose the non-idempotent consequence (duplicate DdAs on repeat calls) or any auth/permission requirements, leaving real behavioral gaps.
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?
A single efficient sentence with the action verb front-loaded and no filler. It is appropriately terse, though terseness here borders on under-specification given the schema complexity.
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?
This is a creation tool over a deeply nested, 10-def schema with 0% description coverage; an output schema exists so return values need not be explained, but the description omits the structure of the required 'profile' object, the meaning of record_id, and subsystem nesting. For this complexity the definition is thin.
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 description coverage is 0%, so the schema itself documents none of record_id, profile, or subsystem_id. The description supplies no parameter meaning whatsoever, not even what record_id references or how subsystem_id relates to profile.subsystems, so it fails to compensate for the coverage gap.
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?
States a specific verb pair (creates and persists) and a resource (a complete DdA), scoped to a system or subsystem. However, the acronym 'DdA' is never expanded and no sibling is referenced, so an agent must infer how this differs from get_dda or update_dda_measure_status.
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 clause 'para un sistema o subsistema' hints at scope, but there is no guidance on when to create vs. update an existing DdA, no prerequisites (e.g., must a record_id already exist), and no mention of alternatives despite a crowded sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Medidas y refuerzos exigibles a un sistema, para su DdA.
Cada dimensión toma "bajo", "medio" o "alto" — el nivel al que está valorada en ese sistema (Anexo I). Se acepta "basico" por compatibilidad y se omite si el sistema no la valora. Hay que valorar al menos una.
Devuelve la categoría del sistema (el mayor de esos niveles) y, por
cada medida exigible, el nivel al que se le exige y los refuerzos de
ese nivel. Un refuerzo con alternative: true es una opción entre
varias: basta implantar uno de los marcados así en ese nivel.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| compact | No | ||
| integridad | No | ||
| autenticidad | No | ||
| trazabilidad | No | ||
| measure_codes | No | ||
| disponibilidad | No | ||
| confidencialidad | No | ||
| include_norm_text | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, and the description's 'Devuelve' is consistent with those — no contradiction. Beyond annotations, the description adds valuable behavioral context: accepted dimension values ('bajo'/'medio'/'alto', with 'basico' tolerated for compatibility), the rule that at least one dimension must be valued, omission when a dimension is not valued, the category being the highest level, and the semantics of `alternative: true` reinforcements (only one needed). This meaningfully exceeds what the annotations signal.
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 front-loads the purpose in the first line and uses line breaks to separate the recurrence of the input rules, output contract, and alternative-reinforcement semantics. Each sentence earns its place; there is minimal filler. The phrasing 'se omite si el sistema no la valora' is slightly unwieldy but not bloated. It is efficient for the amount of rule context it conveys.
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?
For a tool with 10 parameters and 0% schema coverage, the description covers the core dimension semantics and the output shape (category, required measures, reinforcement levels, alternative behavior), and an output schema exists to reduce the return-value burden. However, it does not address pagination (limit/cursor), the behavior or filtering effect of measure_codes, the meaning of compact, or what include_norm_text toggles. These gaps leave an agent uncertain about controlling output scope for a complex tool.
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 description coverage is 0%, so the description carries the burden. It usefully explains the five dimension parameters (integridad, autenticidad, trazabilidad, disponibilidad, confidencialidad) by specifying their value vocabulary and rules. However, the remaining five parameters — limit, cursor, compact, measure_codes, and include_norm_text — are left unexplained beyond their names; measure_codes as an output filter and compact/include_norm_text as format controls are not described. The compensation for the schema gap is partial.
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 states a clear, specific function: compute measures and reinforcements required of a system for its DdA (Declaración de Aplicabilidad), returning the system category and per-measure required levels. The verb 'Devuelve' plus the resource (system applicability) makes the purpose understandable. It does not explicitly name a sibling to distinguish from, but the computation-based nature is evidently distinct from listing tools like list_measures and search_measures.
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 the use case — querying required measures for a system given its dimension security levels — but gives no explicit when-to-use vs alternatives, no exclusions, and no mention of sibling tools (list_measures, get_measure, search_measures, snapshot_status). An agent must infer that this tool aggregates applicability from dimension levels rather than listing static measures. There is 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.
Evalúa un perfil completo y sus subsistemas contra el Anexo II.
Los máximos se calculan con las dimensiones del sistema, sus activos de información y sus servicios. Cada resultado conserva la justificación y el origen que llevó a ese nivel. Los subsistemas pueden heredar esos máximos o evaluarse de forma aislada.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and closed-world, so safety is covered. The description adds genuinely useful domain behavior: maxima derive from system dimensions/assets/services, results carry justification and origin, and subsystems may inherit maxima or be evaluated in isolation. It does not disclose output shape or error/validation behavior.
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?
Three short sentences, front-loaded with the action, no filler. Slightly abstract phrasing but well-bounded.
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?
The tool takes one deeply nested, undocumented object and has an output schema (so return values needn't be explained), yet the description leaves key input fields (scope, compliance_profiles, active_compliance_profile) and constraint relationships unclear. The inheritance note is the main added value; more is needed for a single complex structured argument.
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?
There is a single parameter (profile) and schema description coverage is 0%, so the schema is title-only. The description hints at the profile structure (dimensions, information assets, services, subsystems) and inheritance semantics, but does not explain the critical fields an agent must populate (scope, active_compliance_profile, compliance_profiles).
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 verb 'Evalúa' with resource 'un perfil completo y sus subsistemas' against 'Anexo II' gives a recognizable purpose, but it is vague about what the evaluation produces and does not differentiate from siblings like declaracion_aplicabilidad or explain_applicability, which also touch applicability/assessment semantics.
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 when-to-use, when-not-to-use, or alternative routing guidance. The sentence about subsystems inheriting vs. isolated evaluation is behavioral, not a usage rule for the agent choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Qué documentación puede pedir el auditor, por medida.
code: una medida concreta, p. ej. "org.1". Omitido, todas. Un código que no sea una medida del Anexo II es un error.
Responde a "¿qué papeles preparo?", que es el trabajo de las
semanas previas a la auditoría. Se une por measure_code con lo que
devuelven alcance_auditoria y declaracion_aplicabilidad.
Fuente: CCN-STIC 808 §6.2, no el ENS Navegable.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds beyond annotations: the error behavior for a non-Annex II code, the join key (measure_code) linking it to sibling outputs, and the authoritative source. This gives the agent behavioral detail the annotations do not include.
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 compact and front-loaded: purpose first, then parameter semantics, then use-case and source context. It is dense but every sentence earns its place. Slightly run-on in the parameter section, but no filler words or 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?
The tool has an output schema, so return values don't need explanation. The description covers the selection semantics, error case, join relationship with sibling tools, and source authority. The only minor gap is no explicit indication of pagination or result limits, but for a single-parameter lookup tool this is sufficient.
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 coverage is 0% and the only parameter is a bare 'code' field with anyOf string/null. The description fully compensates: it explains the format with a concrete example ('org.1'), the omission semantics ('Omitido, todas'), and the error condition for invalid codes. This is complete, actionable parameter documentation.
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 opens with a clear statement of what the tool returns: the documentation an auditor can request, per measure. It grounds the resource precisely (Annex II measures) and hints at differentiation from siblings via the source note ('no el ENS Navegable') and the join relationship with alcance_auditoria and declaracion_aplicabilidad. It slightly misses full sibling differentiation but the verb+resource+scope is unambiguous.
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 explicitly names the question it answers ('¿qué papeles preparo?') and places it in the pre-audit preparation phase. It also signals the source (CCN-STIC 808 §6.2, not the ENS Navegable), which helps an agent route to the correct data lineage. It does not state explicit when-not-to-use cases, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explica por qué una medida aplica, no aplica o fue forzada por un perfil.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| profile | Yes | ||
| subsystem_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-open-world operation. The description adds that the output is an explanation of applicability status (applies, does not apply, forced), which is useful behavioral context beyond the annotations, but it does not describe permissions, scope, or limitations.
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 front-loaded sentence with no wasted words. It is concise, though its brevity contributes to the under-specification captured in other dimensions.
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?
The tool takes a complex nested profile object and has 0% schema description coverage, yet the description is only one sentence. Although an output schema exists, the description does little to help an agent understand required inputs, optional subsystem scoping, or how to construct the profile.
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 description coverage is 0%, so the description must compensate, but it only loosely maps 'una medida' to code and 'un perfil' to profile. It gives no meaning, format, or role for subsystem_id and does not explain the complex SystemProfile input.
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 names a specific action and target: it explains why a measure applies, does not apply, or was forced by a profile. It is clear enough to distinguish from generic measure lookup, but it does not name or contrast with siblings such as declaracion_aplicabilidad or evaluate_system_profile.
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?
There is no explicit guidance about when to use this tool versus alternatives, nor any when-not condition. The description only states what the tool does, leaving the agent to infer usage from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exporta una DdA como JSON, CSV, Markdown, XLSX, ODS o DOCX en base64.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | ||
| output_format | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral detail beyond the structured fields: the payload is returned base64-encoded, which tells the agent to expect an encoded blob rather than plain text.
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?
A single front-loaded sentence with no filler; the format list and encoding detail are packed into one clause without 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?
An output schema exists, so return-structure documentation is unnecessary, and the base64 note covers the one surprising aspect of the response. For a two-parameter, enum-driven export tool this is nearly complete, with only record_id provenance left implicit.
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 description coverage is 0%, so the description must carry parameter meaning; it enumerates the six valid output_format values, which compensates partially. However, record_id is left undefined (no hint about identifier format or provenance from list_dda/get_dda).
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?
States a specific verb ("Exporta") and resource ("una DdA") plus the full set of output formats, which distinguishes it from the read-oriented siblings like get_dda. The sibling set is not referenced by name, so the differentiation is implicit rather than explicit.
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 guidance on when to choose export_dda over get_dda or list_dda, and no stated prerequisites (e.g. whether the DdA must exist or be finalized). The agent must infer the use case purely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene una DdA persistida con todas sus medidas y evidencias.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context about what is returned (all measures and evidences), but does not explain error behavior, permissions, or what happens if the record is absent.
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, front-loaded sentence with no wasted words. It is efficient, though very short, leaving substantial detail to structured fields.
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?
An output schema exists, so return value details need not be in the description, and annotations cover safety. However, the lone parameter is undocumented in both schema and description, and there is no usage guidance, leaving meaningful gaps for an agent.
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 description coverage is 0%, so the description should compensate, but it never explains what record_id represents or its format. The only hint comes from the phrase "DdA persistida," which minimally implies an identifier for a specific persisted DdA.
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 states a specific verb ("Obtiene") and resource ("DdA persistida") with an explicit scope of included data ("todas sus medidas y evidencias"). It does not explicitly distinguish itself from the sibling list_dda, but the singular persisted DdA makes the retrieval-by-identifier intent inferable.
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?
There is no explicit statement of when to use this tool versus alternatives such as list_dda or get_measure. Usage is only weakly implied by the retrieval verb and the required record_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene una medida de seguridad por su código exacto, p. ej. "org.1".
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the description needn't restate safety. The description adds the exact-code matching constraint, which is mildly useful, but says nothing beyond annotations about error behavior or scope.
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?
A single compact sentence, front-loaded with the verb and resource. The example 'org.1' adds concrete value without bloat.
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?
Output schema exists so return values needn't be explained. But with 0% parameter schema coverage and no sibling differentiation among many similar list/search tools, the description is only minimally complete for correct tool selection.
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 coverage is 0% and the single 'code' parameter has no schema description. The description clarifies that the code must be exact (e.g. 'org.1'), which compensates somewhat, but lacks format or validation details. For 1 param with no schema description, this is a modest addition.
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?
States a specific verb (obtiene) and resource (medida de seguridad) retrieved by exact code. However, it does not distinguish this from sibling tools like search_measures, list_measures, or get_dda, leaving ambiguity about when exact-code lookup is appropriate versus search.
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 guidance on when to use this tool versus alternatives such as search_measures or list_measures. The 'código exacto' phrase hints at exact-match retrieval but doesn't contrast with siblings or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todas las categorías del Anexo II (org, op.pl, mp.if, ...).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds minimal context about the category examples, but does not disclose other behavioral traits (e.g., return format, pagination, errors). Since annotations cover the key behavioral aspects, a 3 is appropriate.
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, concise sentence that gets straight to the purpose with no filler. It is appropriately sized and front-loaded.
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?
For a zero-parameter tool with an output schema present, the description is complete. It clearly states what the tool lists and provides examples, leaving no ambiguity for an agent to call it correctly.
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 tool has zero parameters, so the schema already fully covers this aspect. The baseline for 0 params is 4, and the description adds nothing beyond the schema, which is acceptable.
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 lists all categories of Annex II, with specific examples (org, op.pl, mp.if). It uses an explicit verb (list) and resource (categories), distinguishing it from sibling tools focused on measures or other entities.
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 does not provide explicit guidance on when to use this tool versus alternatives. It only describes what it does, without mentioning exclusions or alternative tools. The purpose is clear, but there is no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los crosswalks externos, su procedencia, cobertura y vigencia.
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description usefully discloses the returned facets (provenance, coverage, validity), but says nothing about the active/inactive default behavior implied by the single parameter.
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?
A single compact sentence, front-loaded with the verb and resource. Nothing is wasted, though it is arguably too terse for the behavioral details it omits.
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?
An output schema exists, so return values need not be explained, and the annotations carry the safety profile. What is missing is the routing context against 'query_crosswalk' and the semantics of include_inactive, which for a simple list tool is a modest but real gap.
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 description coverage is 0% and the only parameter, include_inactive, is never mentioned in the description. Its self-descriptive name and false default mitigate somewhat, but the description does not compensate for the coverage gap by explaining what inactive packs mean or when to include them.
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?
States a specific verb ('Lista') and resource ('crosswalks externos'), plus the attributes returned (procedencia, cobertura, vigencia). It is clear what the tool does, but it never distinguishes itself from the sibling 'query_crosswalk', leaving the boundary between listing and querying implicit.
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?
There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative 'query_crosswalk'. The agent must infer that this is an enumeration tool versus a lookup tool on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las DdA persistidas y el recuento de sus estados.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world. The description adds that the result includes a per-status count, which is useful aggregate context beyond what annotations convey. No pagination, ordering, or volume caveats are mentioned.
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?
One compact, front-loaded sentence. No filler, no repetition of the tool name.
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?
Output schema exists, so return-value detail is not required. But for a list tool among many siblings, the absence of any usage guidance or differentiation leaves a real gap.
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?
Zero parameters, so baseline 4 applies. No parameter meaning needs to be conveyed.
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?
States a clear verb ('Lista') and resource ('DdA persistidas') plus what is counted ('recuento de sus estados'), which is more than a tautology. However, it is in Spanish while sibling names are English (create_dda, get_dda, update_dda_measure_status) — mixing languages weakens discoverability. It doesn't explicitly differentiate from get_dda or create_dda.
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 indication of when to use this instead of get_dda, export_dda, or list_measures. With 18 siblings, some routing signal is essential; the description offers none.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista medidas de seguridad con filtros opcionales.
category_code: código de categoría o grupo, p. ej. "mp.if" o "mp". Uno que no sea una categoría del Anexo II es un error: todas las categorías tienen medidas, así que una lista vacía sólo podía significar que el argumento no era una categoría. dimension: "confidencialidad", "integridad", "disponibilidad", "autenticidad" o "trazabilidad". level: "bajo", "medio" o "alto". Se acepta "basico" por compatibilidad.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| cursor | No | ||
| compact | No | ||
| dimension | No | ||
| category_code | No | ||
| include_norm_text | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true and openWorldHint=false, which the description does not contradict. Beyond that, the description adds real behavioral value: it discloses that an invalid category_code is an error, that an empty result can only mean an invalid category (since every Annex II category has measures), and that level accepts 'basico' as a compatibility alias.
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 definition front-loads the one-line purpose before the parameter breakdown, and each parameter note earns its place with concrete values and examples. It is somewhat long for a listing tool, but the organization is logical and there is no filler.
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 7 parameters, 0% schema coverage, and an output schema that covers return values, the description explains the three filtering dimensions in depth but omits the pagination and output-format controls. An agent calling with limit/cursor would have no documentation of how pagination behaves, which is a meaningful gap for a list tool with plausible large result sets.
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, and it does well for three of seven parameters: category_code gets concrete examples ('mp.if' or 'mp') plus error semantics, dimension gets all five allowed values, and level gets its values plus the 'basico' alias. But limit, cursor, compact and include_norm_text are left unexplained; their names are partially self-evident but the pagination semantics (limit units, cursor mechanics) are not documented.
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 opening sentence 'Lista medidas de seguridad con filtros opcionales' states a specific verb (listar), a concrete resource (seguridad/security measures), and the filtering behavior, which lets an agent tell it apart from list_categories and get_measure. It doesn't explicitly contrast with search_measures, so it falls just short of full 5 differentiation, but the core purpose is unambiguous.
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 gives no guidance on when to use this tool versus its siblings search_measures or get_measure, and states no exclusions. The filter parameter notes imply a use case (filtered listing), but nothing tells an agent why to choose list_measures over search_measures when a broad or fuzzy search is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta un crosswalk por medida ENS o referencia del otro marco.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| pack_id | Yes | ||
| ens_code | No | ||
| include_inactive | No | ||
| external_reference | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered. Beyond that the description adds nothing: it does not explain pagination behavior implied by limit/cursor, what 'inactive' records mean for include_inactive, or how results are shaped.
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?
A single front-loaded sentence with no padding, which is structurally clean. But the brevity here reads as under-specification rather than effective conciseness for a six-parameter tool.
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?
With 6 parameters, an output schema present, and safety already covered by annotations, the description still omits usage context, required-parameter emphasis, and pagination semantics. It is too thin for an agent to invoke this correctly on first attempt.
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 description coverage is 0% across 6 parameters, so the description must carry the load. It only loosely maps to two of them ('medida ENS' ~ ens_code, 'referencia del otro marco' ~ external_reference) and says nothing about the required pack_id, limit, cursor, or include_inactive.
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?
States a specific verb and resource ('Consulta un crosswalk') plus the filter axes ('medida ENS', 'referencia del otro marco'), so an agent can tell it retrieves crosswalk mappings. However, it does not clarify what a 'crosswalk' is or how it differs from measure-lookup siblings like get_measure or search_measures, leaving scope only partially pinned down.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is not told when to prefer query_crosswalk over list_measures or search_measures, nor that pack_id is mandatory context for every call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprobaciones de auditoría sobre el articulado del RD 311/2022.
Una auditoría verifica el articulado además del Anexo II, y esta es esa mitad: las preguntas documentales y de gobierno (Declaración de Aplicabilidad firmada, categorización, INES, perfiles...) por las que suele empezar el auditor.
evidence son los documentos que la guía propone que pida.
Fuente: CCN-STIC 808 §6.1, no el ENS Navegable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only, non-mutating safety profile is covered — and the description is consistent with it (no contradiction). The description adds value by explaining the documentary/governance nature of the checks and citing the source (CCN-STIC 808 §6.1). However, it discloses nothing about response behavior, pagination, or filtering; the fact that an output schema exists lowers the burden, keeping this at a solid 3.
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 front-loaded with the core purpose in the first sentence, then builds context across three short paragraphs. Every sentence contributes something (scope, the audit-half distinction, evidence meaning, source attribution). It is slightly more verbose than strictly necessary for a zero-parameter tool, but nothing is wasted.
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?
For a no-parameter, read-only tool with an output schema and safety annotations, the description covers the essential ground: what the tool checks, how it splits from the Anexo II audit, what `evidence` refers to, and the governing source standard. The main remaining gap is not explicitly tying this tool to its sibling requisitos_auditoria / evidencias_auditoria, but that is a minor omission for a passive, parameterless tool.
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 tool has 0 parameters and the schema coverage is trivially 100% (empty properties object), so there is nothing for the description to document. Per the rubric, 0 params warrants a baseline of 4. The description appropriately spends no time on parameter syntax.
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 states a specific resource ('articulado del RD 311/2022') and a specific kind of operation ('Comprobaciones de auditoría'). It distinguishes its scope from the Anexo II half of the audit, which separates it from related tools. However, it never explicitly names a sibling tool, so an agent must infer the differentiation from the 'esta es esa mitad' framing rather than being told which tool does the other half.
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 gives solid contextual guidance: it explains that an audit verifies both the articles and Annex II, positions this tool as one half, and notes this is where the auditor typically starts ('por las que suele empezar el auditor'). It also clarifies the evidence concept. But it stops short of explicit when-to-use/when-not-to-use instructions or naming alternatives like requisitos_auditoria or evidencias_auditoria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preguntas del cuestionario de auditoría (CCN-STIC 808), en bruto.
code: una medida concreta, p. ej. "org.1". Omitido, devuelve el
cuestionario entero. Un código que no sea una medida del Anexo II
es un error, no una lista vacía: hay medidas cuyo cuestionario está
legítimamente vacío en un tramo, y las dos cosas no pueden
contestarse igual.
level: "basica", "media" o "alta" — las categorías oficiales del sistema.
tools. Filtra por la sección en que la guía imprime el
requisito ("Categoría Básica", "Media" y "Alta" respectivamente),
que NO es el temario de un sistema de esa categoría: los requisitos
son acumulativos y los de "Categoría Básica" se exigen a todas.
Para el temario real de un sistema usa alcance_auditoria.
Cada elemento trae essential: si uno esencial no se cumple, el auditor
considera la medida entera como no implantada. Ojo con code dentro de
una medida — es la etiqueta que imprime el sitio y se repite (hay cinco
"1.1" distintos en op.acc.5); lo que identifica un requisito es
position.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| level | No | ||
| limit | No | ||
| cursor | No | ||
| essential_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds substantial non-obvious behavioral details: invalid codes cause an error (not an empty list), the `essential` flag determines measure failure, and `code` within a measure is not unique (five '1.1' exist in op.acc.5) while `position` is the true identifier. This goes far beyond the annotations and prepares the agent for real edge cases.
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 well-structured with bolded parameter names and front-loaded purpose. It is longer than minimal but earns its length by explaining tricky semantics. A minor typo ('tools.' mid-sentence) and a slightly meandering level explanation cost it a perfect score, but it remains appropriately sized for the complexity.
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?
The tool has 5 parameters, 0% schema coverage, and an output schema. While the description covers `code` and `level` thoroughly, it omits `limit`, `cursor`, and `essential_only` entirely. It also doesn't describe the overall return format or pagination behavior. For a tool with this complexity, the description is not complete enough to ensure correct invocation without additional 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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains `code` (measure example, error semantics) and `level` (official categories, section vs syllabus), but provides no explanation for `limit`, `cursor`, or `essential_only`. These three parameters remain undocumented, leaving a significant gap in the agent's ability to use them correctly.
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 purpose: 'Preguntas del cuestionario de auditoría (CCN-STIC 808), en bruto.' It specifies the verb (devuelve/returns), the resource (audit questionnaire), and the raw nature. It also distinguishes itself from sibling `alcance_auditoria` by explicitly pointing to it as the correct tool for the actual system syllabus, making the purpose unambiguous.
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 explicit when-to-use guidance: it warns that `level` filters by the guide's section, not the system's syllabus, and says 'Para el temario real de un sistema usa `alcance_auditoria`.' This directly routes the agent to the correct sibling and clarifies the subtle distinction, covering both when to use this tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca medidas por texto: código, título, cuestionario, redacción del RD.
Mira el code, el title, la description (el cuestionario de la
CCN-STIC 808), el norm_text (lo que exige el RD 311/2022) y el text
de cada refuerzo. Ignora mayúsculas y tildes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| compact | No | ||
| include_norm_text | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat that. It adds useful behavioral detail: it searches specific named fields and ignores case and accents. This goes beyond the annotations and helps the agent predict search behavior without over-explaining. A minor gap is the lack of any mention of result ordering or pagination, but given the annotation coverage, this is acceptable.
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 concise and front-loaded with the main purpose. It uses two short paragraphs, the first stating the action, the second detailing the fields and the case-insensitivity. There is no fluff, though slightly more structure (e.g., separating the parameter notes) would improve readability. Still, it is appropriately sized.
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?
The description explains the search scope and case handling, which covers the core behavior. However, it omits any explanation of the optional parameters (limit, cursor, compact, include_norm_text) and does not mention pagination behavior. Given that an output schema exists, return values are not needed, but the parameter semantics are an important gap. Overall, it is adequate but not fully 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?
The schema description coverage is 0%, so the description must compensate by explaining parameters. However, it only implicitly covers `query` and never mentions `limit`, `cursor`, `compact`, or `include_norm_text`. The agent may not know what `compact` does or whether `include_norm_text` affects the search scope. This is a significant gap for a tool with five parameters.
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 states a specific verb ('Busca' = search) and resource ('medidas' = measures), and enumerates the specific fields searched (code, title, description, norm_text, text). This clearly distinguishes it from sibling tools like list_measures (which lists) and get_measure (which retrieves a single record). The purpose is unambiguous and actionable.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The use case is implied by the verb 'search' and the field list, but there is no direct guidance on when to choose this over list_measures or get_measure. It is adequate but relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el origen y la frescura de los datos servidos.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that the tool reports data origin and freshness, which is meaningful context, but does not disclose anything about caching, snapshot identity, or timing behavior beyond that.
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?
A single short sentence with no filler or redundancy. It is front-loaded and easy to parse, though it could have included a routing hint without becoming bloated.
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?
An output schema exists, so return values need not be explained in the description. However, for a tool whose purpose depends on distinguishing it from many similarly named siblings, the description is thin and provides no operational context such as when the snapshot is generated or what freshness means for the caller.
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 tool takes zero parameters, so no parameter documentation is needed. The schema and description are consistent, and the baseline for a no-param tool is a 4.
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 names a specific resource (data origin and freshness) but the verb is vague ('Devuelve') and it doesn't distinguish this tool from any of the 18 sibling tools. An agent could not confidently route to snapshot_status versus get_measure or list_data_packs based on this text alone.
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?
There is no when-to-use guidance, no when-not-to-use, and no named alternatives. The description merely states what is returned without indicating the conditions that should trigger calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Actualiza estado, responsable, evidencias, excepciones y fechas de una medida.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| owner | No | ||
| record_id | Yes | ||
| review_date | No | ||
| target_date | No | ||
| justification | No | ||
| exclusion_reason | No | ||
| evidence_references | No | ||
| compensatory_measures | No | ||
| implementation_status | Yes | ||
| surveillance_measures | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that this is a non-read-only, non-idempotent mutation (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds a list of updateable fields, which is useful context beyond annotations, but it does not describe permissions, side effects, validation rules, or concurrency behavior. With annotations covering the safety profile, this is adequate but limited.
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 front-loaded sentence with no filler. It immediately states the action and the fields affected. Though terse, conciseness is not the source of its gaps.
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?
With 11 parameters at 0% schema description coverage and a mutation operation, the description is not complete enough for confident invocation. Output schema and annotations reduce some burden, but the description leaves required identifiers, optional fields, and update semantics largely unexplained.
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 description coverage is 0% and there are 11 parameters, so the description must compensate. It names several update targets (estado, responsable, evidencias, excepciones, fechas), but omits key required identifiers such as record_id and code, and does not explain justification, surveillance_measures, compensatory_measures, or date formats/constraints. It adds some meaning but falls well short for an 11-parameter 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?
The description uses a specific verb ('Actualiza') and resource ('una medida'), and lists several updateable fields: status, owner, evidence, exceptions, and dates. It is clear what the tool does. It does not explicitly differentiate itself from sibling tools, but the purpose is still evident.
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 only implies that this tool is used for updating a measure. It provides no when-to-use guidance, no exclusions, and no alternatives such as create_dda or get_measure. The agent must infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2create_ddaevaluate_system_profileexplain_applicabilityexport_ddaget_ddaget_measure4 fields changedOutput schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "title": "Result"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / titlePrevious value: -"get_measureOutput"New value: +"get_measureDictOutput"list_data_packslist_ddaquery_crosswalkupdate_dda_measure_statusv0.1.1alcance_auditoriadeclaracion_aplicabilidadevidencias_auditoriaget_measurelist_categorieslist_measuresrequisitos_articulosrequisitos_auditoriasearch_measuressnapshot_statusScored across 19 tools
Most tools target clearly distinct resources, and the descriptions carefully delineate siblings like declaracion_aplicabilidad (applicability/DdA), alcance_auditoria (audit syllabus), evaluate_system_profile (profile scoring), and explain_applicability (per-measure reasoning). There is still residual overlap among these four applicability/audit-oriented tools since some share identical arguments, which could invite misselection.
The English tools follow a fairly consistent verb_noun pattern (get_measure, list_measures, create_dda, update_dda_measure_status), but five tools use Spanish noun phrases (declaracion_aplicabilidad, alcance_auditoria, evidencias_auditoria, requisitos_articulos, requisitos_auditoria), breaking the pattern. The set remains readable but mixes two conventions.
At 19 tools the surface is somewhat heavy but each tool maps to a plausible ENS task (measure lookup, DdA lifecycle, audit requirements, crosswalks, data freshness). No obvious redundancy that inflates the count artificially, though a few audit/query tools sit close together.
DdA lifecycle is well covered (create, get, list, update status, export) plus measure retrieval, search, crosswalks, and multiple audit-requirement views. Minor gaps exist—no delete_dda and no measure-level editing—but agents can work around them.
Offline methodology engine for authorized penetration testing, CTF, and security research.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
CVE, KEV, EPSS, SBOM and advisory lookups; per-CVE exposure from Shodan data (© Shodan). Keyless.