ensmcp

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.