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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile. The description adds meaningful behavioral context beyond annotations: the mapping is 'this project's analysis, not an official mapping', which signals data trust and provenance. It also names the specific framework versions included, but does not cover return behavior or limitations like coverage 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?

The description is two sentences with no filler. The first sentence defines the mapping scope and the second provides a critical caveat. It is appropriately sized, though the first sentence is somewhat dense and could be more front-loaded with the action.

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 explaining return values. It states what data is included but does not describe the structure of the returned crosswalk (e.g., list of control IDs, titles, summaries) or pagination behavior. For a simple read-only lookup this is minimally adequate but leaves a 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 100%, so the schema already documents all three parameters including the id format example ('crb:5.6.1'), language enum, and response format. The description adds no additional parameter semantics beyond what the schema provides, which is the expected baseline when coverage is high.

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 specifies the exact resource (crosswalk) and scope (one CORF control area) by naming the frameworks included: ISO 27001 Annex A, PCI DSS v4.0.1, SWIFT CSCF v2026. It lacks an explicit action verb like 'returns' or 'maps', but the implied retrieval is clear. Sibling differentiation from corf_reverse_crosswalk is only implicit via the title and the phrase 'woven to one CORF control area'.

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 is provided on when to use this tool versus alternatives such as corf_reverse_crosswalk or corf_get_area. There is no mention of prerequisites, exclusions, or specific use cases. The description merely states what the tool contains.

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 and non-destructive, so the safety bar is covered. The description adds substantive context beyond that: it enumerates what payload comes back and clarifies that this is a summary and reference set, with the official text living at the linked page — a semantic distinction that matters.

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?

Front-loaded with the resource and scope, then one dense clause listing the returned fields, then a short pointer sentence. Slightly packed by the parenthetical examples, but every sentence 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 must carry the return contract, and it does list the summary, sub-domain/domain, control ids and official pages, plus crosswalk references. Missing only minor edges such as behavior when an id is unknown.

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%, so the baseline is 3, but the description adds real meaning to `id` by documenting accepted formats (namespaced, bare, and space-separated with the crb default). It does not extend the lang or response_format enums, which the schema already handles.

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+resource: retrieve ONE control area by id, with concrete id examples. The singular scope cleanly separates it from the plural sibling corf_list_areas without needing to name it.

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?

It implies usage through the id format examples ("crb:5.6.1", "5.6.1" defaults to crb, "tprm 10.1.1"), which is genuinely helpful for invocation. However it never states when to reach for this tool versus corf_search, corf_list_areas, or corf_list_framework, so routing guidance remains implied.

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, so the safety profile is covered. The description adds two pieces of real behavioral context – that results are paged and the exact filter-id shapes ('orb:6', 'crb:5.6') – but says nothing about ordering, paging limits, or what an empty result means.

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, front-loaded sentences with no filler: content, filters, paging. It is terse almost to a fault, but every sentence 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 correctly previews the return shape (own-words summary plus control counts) and covers filtering and paging for a simple read-only tool. Minor gaps are return ordering and the interaction between baseline/domain/subdomain filters, which an agent may have to infer.

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 71%, and the two undocumented parameters (domain, subdomain) are precisely the ones the description compensates for by giving concrete id formats ('orb:6', 'crb:5.6'). 'Paged' also maps to the offset/limit pair. lang and response_format remain schema-only, 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?

States a specific verb (list) and resource (control areas) and says what each item contains: an own-words summary and control counts. It is distinguishable from corf_list_domains / corf_list_subdomains, though it never explicitly names those siblings to sharpen the boundary.

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 usable filtering context ('Limit to a baseline, a domain id or a sub-domain id') which tells the agent how to narrow results, but it never says when to pick this over corf_list_domains, corf_list_subdomains or corf_get_area. Usage is implied rather than contrasted against alternatives.

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 covered. The description adds the return shape (three baselines with ids, titles, and counts) but says nothing about auth needs, pagination, ordering, or other behavioral traits. With annotations covering safety, this is an adequate but not rich addition.

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, tightly focused sentence with no filler. It front-loads the resource and specifies the returned metadata without repeating the title or wasting words.

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 usefully carries the expected return fields. However, it omits usage context relative to the many sibling list/search tools and does not explain how lang or response_format affect the output. It is adequate for a simple three-item list but leaves clear gaps.

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 both parameters (lang and response_format) are fully documented in the schema. The description does not mention either parameter, so no value is added beyond the structured fields; baseline 3 is appropriate 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?

The description names the specific resource (the three CORF baselines) and the exact metadata returned (ids, titles, and counts of domains, sub-domains, areas, controls). It lacks an explicit action verb and does not compare itself to sibling list tools, but the resource scope is clear enough to distinguish it from corf_list_domains, corf_list_areas, and corf_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?

It provides no when-to-use guidance, no exclusions, and no mention of alternative sibling tools such as corf_list_domains or corf_list_framework. The agent must infer usage entirely from the tool name and description.

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 this a read-only, idempotent, non-destructive, closed-world operation, so safety is covered. The description adds modest behavioral value by fixing the result size at 27 domains and naming the returned fields, but says nothing about ordering, pagination, or what counts represent.

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 compact sentences, front-loaded with the resource and result cardinality, then the optional filter. There is no filler and nothing that fails to earn its place.

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 correctly compensates by listing the returned fields, and the simple zero-required-parameter shape is fully documented by the schema. Only minor gaps remain, such as result ordering and how counts are scoped.

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 parameters are enum-documented, so the schema carries the semantics. The description's only parameter contribution is restating that baseline is an optional single-value filter, which adds nothing 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?

The description names the resource precisely (the 27 CORF domains) and enumerates the returned attributes (baseline, reference number, title, counts), which lets an agent separate it from siblings like corf_list_subdomains, corf_list_areas and corf_list_baselines. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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 limited to one baseline" implies the filtering use case, but there is no statement of when to reach for this tool versus corf_list_baselines or corf_list_areas, and no exclusions or prerequisites. 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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description usefully adds that results include per-control mapped-area counts and mandatory/advisory flags, but says nothing about result size, pagination, or ordering.

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 leads with the resource and then supplies per-framework detail. Dense but every clause carries selection-relevant information; the count enumerations are borderline but helpful for anticipating output size.

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 does the work of describing the returned item shape (controls plus mapped-area counts, status flags). It omits sorting/pagination and any note on how the three framework variants differ structurally, but the essentials for a correct call are present.

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%, with framework left as a bare enum. The description compensates by mapping iso/pci/swift to their real-world frameworks (ISO 27001:2022 Annex A, PCI DSS v4.0.1, SWIFT CSCF v2026) and by noting the entity counts per framework. lang and response_format are already documented in 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+resource (list framework contents) and enumerates exactly what each framework returns, including control counts and whether SWIFT status is mandatory/advisory. The scope is clear enough to separate it from sibling list_* tools, 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?

No statement of when to choose this over corf_list_baselines, corf_list_domains, or corf_search. The agent must infer that this is the top-level enumeration tool from the name and description alone.

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, and closed-world, so safety is covered. The description adds only the finite cardinality (93) and the composition of each entry; it says nothing about ordering, paging, or what a filtered miss returns. Modest additive value.

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 tightly written sentences with zero redundancy: the payload is stated first and the optional filtering constraint second. Nothing is padded or restated.

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-output-schema list tool the description names the returned fields and the filtering options, and annotations cover the safety profile. Ordering/pagination behavior is the only unaddressed aspect, a minor 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 coverage is 100%, so all four parameters including the lang/response_format enums are already documented. The description repeats the domain id format ('crb:5') and baseline filtering that the schema supplies, adding no semantic detail beyond it. 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 resource (the 93 CORF sub-domains) and enumerates exactly what each record carries: domain, title, official page, and area/control counts. This clearly separates it from corf_list_domains and corf_list_areas, which have no such count fields.

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 notes the listing can be limited to one baseline or one domain id, which implies the filtering use case, but it never states when to choose this tool over corf_list_domains or corf_list_baselines. Usage is implied rather than instructed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the scope of what the summary aggregates, which is genuinely useful context, but says nothing about caching, size of payload, or refresh 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?

Two compact sentences that front-load the content inventory, with a short imperative cue at the end. No filler, though the trailing 'Start here.' could be folded into the first sentence rather than standing alone.

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, so the description carries the burden of describing the return value, and it does so by listing the aggregated sections. For a zero-required-parameter overview tool this is nearly complete, with only the exact shape/size of the response left unspecified.

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 enums (lang, response_format) carry their own descriptions and defaults, so the schema does the heavy lifting. The description adds no additional meaning about either parameter, making the baseline 3 appropriate.

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?

Names a concrete operation and resource (a summary of the CBK Cyber and Operational Resilience Framework v1.0) and enumerates what the summary contains: three baselines, counts of domains/sub-domains/control areas/controls, crosswalk targets, and source. Sibling differentiation is only implied by 'Start here' rather than by naming the corf_list_* tools it precedes.

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 an explicit entry-point cue that positions this tool ahead of the listing/search siblings in the workflow. There is no explicit when-not-to-use statement or named alternative, so it stops short of a 5.

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, destructiveHint=false and closed-world scope, so safety is covered. The description adds genuine behavioral context beyond that: unknown ids and invalid values are silently ignored (graceful degradation), and it discloses what the output contains. It does not mention rate limits or output size limits, keeping it below a 5.

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 dense sentences that front-load the action and input, then the return value, then the error-tolerance rule. No filler and nothing repeated from the schema or annotations.

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 return-value burden and does so (overall and per-baseline readiness, maturity averages, applicability counts, largest gaps). Input, output and edge-case handling are all covered; only deeper detail such as output-size behavior relative to limit/offset is 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 100%, so lang/limit/offset/response_format are already documented and the baseline is 3. The description goes beyond the schema by detailing the required `assessment` object's internal shape (schema "sadu/1", maturity 1-5, applicability, notes), which the schema only labels as "The exported assessment object."

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 gives a specific verb ("Score") plus the exact resource and its origin ("an assessment exported from the Sadu web app"), and enumerates the input shape it expects (status per control, maturity, applicability, notes). This clearly separates it from the corf_list_*/corf_get_*/corf_search siblings, which enumerate or fetch rather than score an assessment.

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 input requirement: you have an exported Sadu assessment and want a readiness score. However, there is no explicit when-to-use guidance, no distinction from corf_overview (which may also summarize), and no stated prerequisites or exclusions. Adequate but with a clear gap.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact — that the cross-framework results are derived indirectly through the CORF hub rather than direct pairwise mappings — but says nothing about coverage limits, missing mappings, or latency.

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 sentence, front-loaded with the starting point and input formats, then the output. No filler or redundant restatement 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?

With no output schema, the description correctly spends its words on return semantics — mapped CORF areas plus the other two frameworks' statements — so an agent knows what it will get back. It stops short of describing the shape of that output (grouping, field names, markdown vs json rendering differences).

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 75% and the enum values are self-describing, so the schema carries most of the load. The description adds real meaning by showing the expected reference format for each framework ('A.5.19' for ISO, '8.4' for PCI, '2.9' for SWIFT), which the schema's generic 'Reference id in that framework' does not.

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: given a framework reference (ISO/PCI/SWIFT), return the mapped CORF areas plus the other two frameworks' statements. The examples ('A.5.19', '8.4', '2.9') make the operation concrete. It implies the inverse direction of the sibling corf_crosswalk but never names it, so sibling differentiation is left to inference.

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 opening 'Start from an ISO 27001 control...' clearly establishes the entry-point condition that selects this tool over a forward crosswalk, and the parenthetical '(derived through the CORF hub)' signals it is a lookup rather than a raw mapping. No explicit when-not or named alternative is given, so it falls short of a 5.

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 semantics, so the safety profile is fully covered. The description adds the searchable-field scope, language handling, and paging behavior, which is real value, but it says nothing about result shape or ordering beyond paging.

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, front-loaded sentences with no filler; the core capability leads. The clipped fragments ('Optionally limited to one baseline', 'Paged.') are terse but cost no clarity.

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 should ideally hint at what results contain (matching areas, total counts, paging fields), which it does not. Annotations and the schema cover safety and inputs, so an agent can call it correctly, but the return side is left entirely 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 100%, so every parameter including enums and defaults is already documented in the schema. The description only mirrors query/lang/baseline/limit without adding syntax, matching rules, or default behavior beyond what the schema states. 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 (search) and resource (control areas) plus the searchable fields (id, title, summary) and languages. It is clearly distinguishable from list-style siblings, though it never names them or explains why one would search rather than list.

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?

Implies usage ('optionally limited to one baseline', 'paged') but gives no explicit when-to-use versus corf_list_areas or corf_get_area, and no statement of prerequisites or exclusions. The context is inferable but not spelled out.

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 covered. The description adds useful content transparency by specifying exactly what is returned, including the provenance note and count discrepancy, but it does not explain output format, pagination, or any other behavioral details beyond what annotations and schema already provide.

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 appropriately sized for the tool, though its noun-phrase structure lacks an explicit action verb that would make it more immediately clear as an instruction.

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 a simple read-only tool with two fully described parameters, rich annotations, and no output schema, the description is nearly complete: it specifies the returned content and a notable detail. It does not address return format or language behavior, but those are handled by the schema parameters.

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) have enum descriptions and defaults. The description adds no parameter-level information, so the baseline of 3 is appropriate when the schema fully documents the inputs.

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 identifies the specific resource and content: official sources, what each was used for, and a provenance note with the CBK count discrepancy. It lacks an explicit verb such as 'returns' or 'lists', and it does not differentiate itself from sibling tools like corf_overview, so it falls 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?

There is no guidance on when to use this tool versus alternatives. The description does not state conditions, prerequisites, or which sibling tool to prefer for source/provenance information. Usage is only implied by the resource content.

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