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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds a genuinely non-obvious caveat: the mapping is the project's own analysis, not an official NCA mapping. It does not elaborate on return structure or size, but against these annotations that is a minor gap.

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?

Four tight sentences, front-loaded with the general rule ('map in either direction at the subdomain level') before the per-framework branches. Every sentence carries unique information; the only mild redundancy is restating the return targets per branch.

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?

There is no output schema, so the description must convey what comes back, and it does name the returned content per direction (ISO/NIST references or ECC subdomains). It stops short of describing the shape of those results, which an agent doing programmatic json processing might still need to discover.

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 only 50% (id and framework have no schema descriptions), so the description carries real burden and does so: it defines the accepted framework values and the id format expected for each ('2-8', 'A.8.24', 'PR.DS'). The lang and response_format enum descriptions are left to the schema, which is fine.

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 (map) and resource (frameworks) with the precise granularity: 'subdomain level'. The description makes clear it is bidirectional and returns ISO 27001 / NIST CSF 2.0 cross-references, which distinguishes it from siblings like ecc_get_control or ecc_list_subdomains.

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 when-to-use detail per input: 'ecc' + subdomain code to go outward, 'iso27001' + reference, 'csf2' + category to go inward. Each branch is illustrated with a concrete example value ('2-8', 'A.8.24', 'PR.DS'), leaving nothing to 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, idempotentHint and non-destructive, so the safety profile is covered. The description adds the shape of what is returned (families, applicability, baseline) but says nothing about ordering, completeness, or how baseline status relates to the entities involved.

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 sentence with no filler, and the resource is front-loaded ahead of the purpose clause. Nothing is wasted, though it is arguably compressed enough to lose some detail.

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-required-parameter read-only listing with no output schema, the description adequately conveys what is returned and why. It could say more about the relationship between families and the baseline concept, but nothing essential to a correct call is missing.

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 100% and both parameters carry enum descriptions, so the schema fully documents lang and response_format. The description adds no parameter-level information, which is the expected baseline when the schema does the heavy lifting.

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?

Specific verb+resource: 'List the NCA control families', and it names the attributes returned (applicability, baseline). It does not explicitly differentiate itself from siblings like ecc_list_domains or ecc_overview, so an agent must infer the distinction from names 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?

The trailing clause 'to help decide which NCA controls apply to an entity' implies the usage context but states no explicit when-to-use, prerequisites, or alternatives to compare against. An agent gets a hint, not a routing rule.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-obvious context beyond that: summaries are the project's own paraphrasing and the authoritative text lives at a linked page, which tells the agent how much to trust the returned wording.

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

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

Two sentences, zero filler. The core action and returned fields are front-loaded, and the provenance caveat is placed at the end where it belongs.

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?

There is no output schema, so the description carries the burden of return-value disclosure, and it lists the returned fields and their provenance. It does not mention behavior on an unknown/malformed ID, which is the one remaining gap for a deterministic lookup 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 coverage is 100%, setting a baseline of 3. The description earns above that by documenting that the id accepts multiple equivalent formats (dashed, dotted, or unpunctuated), which the schema's single "1-5-1" example does not convey; lang and response_format remain schema-driven.

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?

Specific verb+resource ("Get a control by ID") plus an enumeration of exactly what comes back: summary, subdomain, domain, official page, and ISO 27001 / NIST CSF 2.0 mappings. The ID-format examples ("2-8-3", "2.8.3", "283") make it unmistakably a single-record lookup, distinguishable from ecc_search_controls.

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?

Usage is only implied: the agent must infer that this is the tool for when it already has a control ID. No when-not guidance and no explicit routing to the search/crosswalk siblings is given, so the discriminating condition is left to 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the shape of the returned content, with no notes on rate limits, pagination, or behavior of the lang option.

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 that says exactly what the tool returns, with no filler or redundancy. Nothing could be cut without losing information.

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

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

For a simple, parameterless-required read tool with full annotation coverage and no output schema, the description gives enough to call it correctly and know what comes back. It is only slightly short of ideal in not mentioning the lang/response_format effects on output.

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 100% and both parameters (lang, response_format) are documented in the schema with enums and defaults. The description adds no meaning beyond that, so the baseline 3 applies.

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 ('List') and resource ('the four ECC domains') and enumerates exactly what is returned: codes, names, and subdomain/control counts. This is clearly distinguishable from siblings like ecc_list_subdomains or ecc_families without opening any schema.

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?

Usage is implied by the purpose: an agent can infer this is the top-level enumerator for domains. However, the description never states when to use it versus alternatives such as ecc_overview, ecc_families, or ecc_list_subdomains, and gives no prerequisites or exclusions.

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 destructiveHint=false, so the safe-read profile is covered. The description usefully discloses the fixed result size (28 items) and returned fields, but says nothing about ordering, pagination, or caching 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?

Two short sentences, scope stated first, optional narrowing second. No filler or repetition of the title.

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 parameterless-safe listing tool with full schema coverage and no output schema, the description covers the essential return shape and the filter option. Only the relationship to the sibling list tools is left 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 100% and all three params are self-documented, so the baseline is 3. The description echoes the domain filter intent but adds no syntax or format detail beyond the 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?

States a specific verb (List), resource (ECC subdomains), and enumerates what each entry contains: codes, titles, objectives, control counts. The mention of limiting to one domain hints at the split with ecc_list_domains, but the contrast with that sibling is only 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?

The optional domain-filter sentence implies when to narrow the call, but nothing states when to prefer this over ecc_list_domains or ecc_families, and no prerequisites or exclusions are given.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds useful context on the payload contents (four domains, counts, sources), giving the agent a sense of what a summary returns beyond a bare lookup.

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

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

Two tight sentences: the first enumerates the content, the second is a one-line routing cue. No filler and the key detail is 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 read-only, no-required-param overview tool with no output schema, the description adequately conveys scope and content. Nothing critical is missing, though a note on how it relates to the list/search siblings would make it fully self-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 100% and both parameters (lang, response_format) are fully documented with enum values, so the schema does the heavy lifting. The description adds nothing about language or output format selection, so the baseline of 3 applies.

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 resource (the ECC-2:2024 framework overview) and enumerates what it covers: the four domains, subdomain/control counts, and official sources. It is clearly distinct from listing or search siblings, though it doesn't name them directly.

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?

'Start here' gives clear positioning as the entry-point tool for the ECC family, which is real usage guidance relative to siblings like ecc_list_domains or ecc_search_controls. It does not spell out when NOT to use it or name alternatives explicitly.

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 destructiveHint=false, so the safety profile is covered elsewhere. The description adds only that filtering is optional and unspecified; it says nothing about result size, pagination, or how PDPL obligations relate to ECC controls in the output.

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

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

Two tight sentences with the core scope front-loaded and the filter caveat second. No filler, though the second sentence is vague enough ('by words') that it buys little.

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 three-parameter, read-only list tool with no output schema, the description covers what is listed and that filtering is optional, but it omits how results relate to the ECC and what markdown vs json output actually contains.

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 67%: lang and response_format are documented in the schema, but query has no schema description. The phrase 'Optionally filter by words' partially compensates for that gap by implying free-text matching, though it does not specify matching behavior or 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?

States a specific verb (List) and resource (core obligations from the Saudi PDPL) and frames them as sitting alongside the ECC, which separates it from the ECC-centric siblings like ecc_list_domains and ecc_get_control. It does not name a sibling explicitly or clarify overlap with ecc_crosswalk, but the scope is clear.

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 only usage hint is 'Optionally filter by words,' which addresses the query parameter rather than when to choose this tool over ecc_crosswalk or the other ECC tools. No prerequisites, exclusions, or alternative-routing guidance is given.

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 establish the safe read-only, idempotent, closed-world profile, so the description is free to add context: it names the expected input schema ("ecc-register/1"), sketches the input shape, and discloses that pagination applies specifically to the gap list rather than all output. That paging-scope detail is a genuine behavioral trait beyond the annotations, though return format specifics are left to the schema.

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 tightly packed sentence-plus-clause: the verb and target lead, the output inventory follows, and the paging constraint closes it. No filler, no restatement of the title, every phrase carries information.

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

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

With no output schema, the description carries the burden of describing returns and does so by enumerating the report's components; the nested 'assessment' object and all five parameters are documented in the schema. It is nearly complete, with only minor gaps around gap-list ordering ('prioritized' is asserted but not explained) and failure modes.

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 100%, so limit/offset/lang/response_format are self-documenting and the baseline is 3. The description earns above baseline by clarifying that paging is scoped to gaps, which tells the agent what limit/offset actually paginate over in this tool.

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 (evaluate) and resource (an assessment object saved by the web app) and enumerates the outputs generated: overall and per-domain readiness, maturity band, status counts, prioritized gap list. This clearly separates it from listing/lookup siblings like ecc_list_domains or ecc_get_control, though it never names an alternative explicitly.

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 context of use (you have an assessment object saved by the web app and want a readiness evaluation), and 'Paged over gaps' hints at large result sets. But there is no explicit when-to-use vs. when-not, no prerequisites, and no pointer to sibling tools for related needs, so guidance remains inferential.

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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds that results are paged and that summaries exist in English and Arabic, which is useful context, but says nothing about ordering, total counts, or how ID matching behaves.

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

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

Two short sentences with no filler, and the primary capability is front-loaded before the optional filter and paging notes. It is arguably too terse to fully orient the agent, which keeps it below a 5.

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 no output schema, the description still conveys the result domain (control summaries), the searchable dimensions, and paging. It falls short only on whether matching is fuzzy or exact and how results are ordered.

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 100% and all six parameters are self-documented (lang, limit, query, domain, offset, response_format), so the baseline is 3. The description restates lang/domain/paging without adding syntax, defaults, or constraints beyond the 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?

States a specific verb (Search) and resource (control summaries) and enumerates the searchable axes: language and ID, plus an optional domain filter. It clearly differs from the single-record sibling ecc_get_control, though it never names the alternative explicitly.

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?

'Optionally filter by domain code' and 'Paged' imply this is the browsing/query tool, but there is no statement of when to prefer it over ecc_get_control or ecc_list_domains, and no note that query may be left empty to list everything (that fact lives only in the schema). Usage is inferable rather than stated.

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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds that a provenance note distinguishing official text from project work is returned, which is modest extra context but not deep behavioral disclosure.

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 core action is stated first and the payload preview follows. Slightly long-tailed but efficient.

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

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

No output schema exists, but the description compensates by stating what is returned (sources with links plus a provenance note). For a simple zero-required-parameter lister with full annotation coverage, this is adequately complete.

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

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

Schema coverage is 100% and both parameters (lang, response_format) carry descriptions in the schema itself. The description mentions neither, so it adds nothing beyond the schema; baseline 3 applies.

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?

Specific verb+resource ('List the official sources this register is built on') and even previews the payload (links, provenance note). It is clearly distinct from siblings like ecc_get_control or ecc_crosswalk, though it does not explicitly name them.

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?

Usage is implied by the purpose — call it when you need to know the underlying official sources or check provenance — but there is no explicit when/when-not statement or alternative named. Minimum viable guidance.

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