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. The description adds valuable behavioral detail beyond annotations: matching is case-insensitive, ignores punctuation, and the framework filter is optional. This meaningfully helps an agent predict results without contradicting the annotations.

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

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

The description is front-loaded with the core purpose, then provides concrete examples and behavioral caveats. Every sentence adds value: the examples disambiguate key formats, and the matching rules prevent incorrect expectations. It is appropriately sized for a tool with two parameters and nuanced matching behavior.

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

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

Given the output schema already covers return shape, the description does not need to explain return values. It covers the tool's purpose, supported key formats, normalization behavior, optional framework restriction, and points to the authoritative list. For this complexity level, nothing essential 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?

The input schema offers only generic titles ('Key', 'Framework') with 0% schema description coverage, so the description must carry the semantic burden. It fully compensates by explaining that 'key' is an external reference identifier with concrete examples and that 'framework' restricts results to a framework name from list_reference_frameworks. Both parameters are meaningfully clarified.

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 'Reverse crosswalk' and immediately states the exact resource ('AIGF risks and controls') and action ('find ... that cite an external reference'). The examples clarify the input format and the phrase 'reverse crosswalk' distinguishes it from mapping tools like map_control_to_external.

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 clear context for when to use the tool: when you need to find risks/controls by an external reference. It also directs the user to list_reference_frameworks for valid framework names. However, it does not explicitly mention exclusions or contrast itself with search_framework or map_control_to_external, so it stops short of a perfect 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context about what the response contains (risks, related controls, crosswalk references) and that include_sections=false yields a compact record, which is meaningful beyond the annotations.

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

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

Two concise, information-dense sentences. The main purpose and id formats are front-loaded, followed by the optional flag guidance. No wasted 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?

Given the rich annotations, an output schema, and only two parameters, the description covers everything an agent needs to select and invoke the tool correctly. It explains the lookup key, the response contents, and the compaction option.

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%, but the description fully compensates: it explains the id parameter with concrete accepted formats and explains the behavior of include_sections. This adds substantial meaning beyond the bare 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 states a specific verb and resource: get one AIGF control by id, and enumerates the included related data (risks, related controls, crosswalk references). The accepted id examples also help distinguish this from sibling list/map tools.

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 clearly implies use when retrieving a single control by id, and gives guidance on include_sections for compactness. However, it does not explicitly contrast with sibling tools like list_controls or find_by_external_reference, so the when-not-to-use context 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 the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context by explaining that the response includes mitigating controls, related risks, and external references, and that include_sections=false returns a compact record without full 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?

Two tight sentences: the first covers the core action and output contents, the second covers the optional flag. No filler, and the most important usage 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?

With a rich output schema present, annotations covering safety/idempotence, and clear explanation of id formats and the include_sections toggle, nothing essential is missing for an agent to invoke the tool 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?

Schema descriptions are absent (0% coverage), but the description compensates fully by documenting the id parameter's accepted forms (AIR-SEC-010, ri-10, 10, title) and the effect of include_sections. This gives an agent concrete grounding for both 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 ('Get') and resource ('one AIGF risk by id'), and it clarifies the identifier formats accepted. This differentiates it from siblings like list_risks (which returns many) and get_control (which targets controls rather than risks).

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 'by id' wording makes clear this is for retrieving a single known risk, and the mention of title/ID formats helps an agent know when it has a valid lookup key. It does not explicitly name alternatives or list when-not-to-use conditions, so it stops short of full routing 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 mark the call as read-only, idempotent, and non-destructive. The description adds useful behavioral context: it returns IDs intended as input for get_control and explains that 'mitigations' is AIGF's name for controls, which helps an agent interpret downstream data. No contradiction with annotations.

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

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

Two short sentences provide the action, alternate vocabulary, filter semantics, and the return/next-step hint with no filler. All information 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 list tool with an output schema and safe annotations, the description covers purpose, filters, and downstream usage. It does not enumerate possible status values, but the schema leaves status as an open string and the search_status sibling can handle discovery; this is 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 0%, so the description must carry parameter meaning. It does for the two significant filters: it defines PREV and DET and says status is a filter. Page and page_size are left to their self-explanatory names/defaults, which is acceptable for a list endpoint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description begins with a specific action and resource ('List AIGF controls') and clarifies the framework's alternate terminology ('the framework calls them mitigations'), so there is no ambiguity about what is being listed. It also distinguishes itself from siblings like get_control (single item) and list_risks (different resource).

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 conveys when to use the tool: to list/filter controls by type or status, and to obtain IDs for a follow-up get_control call. It does not explicitly contrast with alternative list/search sibling tools, but the workflow hint is clear enough to route an agent.

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, so the safety profile is covered. The description adds meaningful behavioral context by specifying the scope ('crosswalks to') and the aggregation details (entry counts, risk/control citations), which is useful beyond the annotations alone.

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 states the verb, resource, and output details with no wasted words. Every part of the description contributes to an agent's understanding of the 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?

For a no-parameter list operation with rich annotations and an output schema, the description is complete: it says what is listed and what summary information is returned. Nothing essential is missing 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 there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description appropriately adds scope and output granularity without needing to explain any arguments.

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 ('List') and a clear resource ('external reference frameworks the AIGF crosswalks to'), and it specifies the output shape: entry counts plus risk/control citation counts. This clearly distinguishes it from siblings like search_framework, find_by_external_reference, and list_risks/list_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?

The description implies the tool is for enumerating reference frameworks and their citation counts, rather than searching or mapping. However, it does not explicitly state when to prefer this tool over siblings like search_framework or find_by_external_reference, leaving the routing decision mostly 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 destructiveHint, so the safety profile is covered. The description adds value by explaining the return shape ('Returns ids you can pass to get_risk') and the filter behavior, which goes beyond the structured annotations.

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

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

Two sentences, no filler, and the core purpose is front-loaded. Every sentence adds useful information, and the tool is immediately understandable.

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 an output schema present and annotations covering side-effect safety, the description provides the key missing context: how to filter and how to chain results into get_risk. Minor gaps remain around pagination and status values, but defaults and output schema cover part of that.

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 explains the meaningful values for 'type' (RC, OP, SEC) and mentions 'document status', but it does not clarify page/page_size behavior or enumerate possible status values. Partial compensation, not full.

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 action ('List'), a clear resource ('AIGF risks'), and the available filters. It also distinguishes itself from get_risk by explicitly noting that it returns ids to pass to get_risk, making the tool's role in a workflow 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 description gives clear usage context by explaining this tool is for listing/filtering risks and that its ids feed into get_risk. It does not explicitly exclude alternatives like list_controls, but the resource and filter details make the intended use reasonably unambiguous.

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 establish that this is read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful scope context (supported frameworks and optional restriction), but it does not disclose behavior around unknown control IDs or empty mapping results; the output schema helps cover return shape.

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 front-load the verb and object, then give the framework list and the optional restriction in a single clause. There is 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?

Given the output schema, annotations, and sibling context, the description is nearly complete for tool selection and invocation. It names the framework set, explains the optional filter, and points to the relevant sibling for framework discovery; the only notable gap is the under-specified id parameter.

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 explains the frameworks parameter well by tying it to named frameworks and list_reference_frameworks, but the required id parameter is only implied as 'one control' with no stated source or format.

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 ('Crosswalk') and resource ('one control') and enumerates the target external frameworks, making the tool's scope immediately clear. It is easily distinguished from siblings like map_risks_to_controls and find_by_external_reference, which address different mapping directions.

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 clearly communicates the intended use case—mapping a single control to external frameworks—and points to list_reference_frameworks for valid framework names. It does not explicitly state when to prefer alternative tools such as find_by_external_reference, so it lacks formal 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?

The description goes beyond the readOnly/idempotent annotations by disclosing important behavior: controls are ordered by coverage count, control_type restricts results, uncovered risks are reported, and unresolved inputs are surfaced. This gives the agent accurate expectations for the tool's output and edge-case handling.

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 carries operational value: input modes, limits, union semantics, ordering, filtering, and reporting behavior. It is front-loaded with the core purpose and avoids filler or repetition.

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 5-parameter tool with no required parameters and an output schema present, the description covers all relevant invocation semantics, constraints, and result-shaping behavior. An agent can correctly decide how to call this tool for single, multi-query, id-based, and filtered mapping scenarios.

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%, but the description compensates fully: it explains risk_ids (up to 25), free-text query behavior (top k matching risks), up to 5 queries with unioned results, control_type as PREV or DET, and k as the match count. Every parameter's role is described beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Map risks to the controls that mitigate them.' It clearly distinguishes the tool from sibling list/get/search tools by focusing on the mapping relationship and the combination of risks-to-controls coverage 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?

The description gives clear guidance on when to use each input mode and specifically calls out the multi-query use case for 'both X and Y' questions. It does not explicitly name alternative sibling tools or state when not to use this tool, but the usage context is strongly implied and actionable.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context beyond that — and it does, explaining that the risks/controls ordering is a 'stable partition of the original relevance-ranked results, not a new relevance score.' That is a genuine behavioral disclosure about ranking semantics that the annotations and schema do not convey.

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 paragraphs, the core capability front-loaded in the first line and the ranking caveat second. No filler, no restatement of the tool name, and every clause carries information an agent would otherwise have to guess.

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 no explanation, and annotations cover the safety profile. Still, for a three-parameter search tool the description leaves the result-count parameter undefined and gives no sense of corpus size or result limits, so an agent could call it correctly but not optimally.

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 does explain the non-obvious 'scope' semantics well (unscoped vs. explicit precedence, mixed results for both), but 'k' is never mentioned and the query format/limits are left unstated, so compensation is partial rather than complete.

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 first sentence states a specific verb and resource pair ('Search risks and controls') plus what comes back ('matching sections and citable source URIs'). It implicitly separates itself from get_risk/list_risks by being a search, but never names or contrasts those siblings explicitly, so an agent must infer 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?

The second paragraph gives real conditional guidance ('for an unscoped question clearly asking for risks or for controls', 'questions asking for both kinds stay mixed', 'explicit scope always wins'), which helps an agent decide how to rank. However, it never addresses when to choose this tool over list_risks, list_controls, or search_status, so tool-selection guidance is only 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 cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context by explaining that the tool reports not just the mode but the underlying reason, with concrete examples like missing 'semantic' extra or model load failure. This goes beyond the annotation metadata without contradicting it.

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 written sentence that front-loads the core purpose and then provides useful explanatory detail and concrete examples. There is no redundancy or 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?

For a parameterless, read-only status tool with an output schema available, the description is comprehensive enough. It tells the agent what the tool reports, why it matters, and what kind of reasons might appear, leaving no critical gap for correct invocation.

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, and the description does not need to explain parameter behavior. It still adds semantic value by describing what the status output is about, satisfying the baseline for parameterless tools.

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 ('Report') and identifies the exact resource and concern: search_framework's active retrieval mode, including whether it is BM25-only or hybrid and why. This clearly distinguishes it from sibling tools like search_framework, which performs searches, and server_info, which reports general server state.

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 clearly implies the tool is for diagnosing search_framework's retrieval configuration, and the read-only annotations reinforce when it is safe to call. However, it does not explicitly name alternatives or conditions when another tool should be used instead, so it stops short of full routing 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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by listing the exact informational dimensions returned (version, provenance, counts, latency, policy), but does not disclose any additional behavioral traits such as whether the information is cached, whether the call itself may be slow due to latency measurement, or how policy is represented. With annotations present, 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 sentence that front-loads the core action and then provides a compact, informative list of the six content areas. There is no filler, repetition, or extraneous context.

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, read-only informational tool with an output schema, the description covers the essential purpose and content scope. It could be slightly more explicit about what 'exposed counts' and 'policy' mean, but the presence of an output schema compensates for any ambiguity about return structure. Overall, it is adequate and complete for this low-complexity 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 zero parameters and the schema is empty, so parameter semantics are trivially satisfied. Per the baseline for 0-parameter tools, the description need not compensate for missing parameter documentation. It also avoids inventing unnecessary 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 uses a specific verb ('Describe') and a clear resource ('this server'), then enumerates the dimensions it covers: standard version, upstream provenance, exposed counts, latency, and policy. This clearly distinguishes it from the sibling risk/control tools, which concern controls, risks, and frameworks rather than server metadata.

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?

Although there is no explicit 'when to use' statement, the context is clear: this is the only server-info tool among siblings that all address risk/control/framework operations. An agent can infer it should be used when server metadata is needed. It lacks an explicit exclusion or alternative, but the sibling set makes the use case unambiguous.

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