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

The description adds scope detail beyond the annotations (what the plan contains) and a sequencing constraint. But it never resolves the tension between 'Create ... risk register' and readOnlyHint=true — the agent cannot tell whether the plan is persisted as a new artifact or merely computed and returned, which matters for a tool whose annotations declare no mutation.

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-loaded with the primary action and followed by the artifacts produced and the ordering constraint. No filler; a little more length would have been justified for the parameter, but nothing present is wasted.

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

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

No output schema exists, so the description should carry more weight on what is returned and whether the plan is stored; it only lists section names. Combined with an undocumented required enum parameter, the definition is adequate for orientation but leaves real gaps before 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?

There is one required parameter, deployment_patterns, with 0% schema description coverage and no help in the description — the description never mentions deployment patterns or what the enum values mean. With a non-trivial enum of seven AI system types, the description is needed to compensate and 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?

Specific verb+resource: creates an audit plan and unverified risk register, and enumerates the artifacts produced (intake, source-scoped risks, control verification backlog). It implicitly separates itself from siblings like scope_risks and investigate_risk by being the plan-construction step, though it never names 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?

'after system classification' signals a prerequisite ordering, so an agent can infer this is the post-classify_system step. However, it does not explicitly name classify_system or state when to prefer scope_risks/propose_remediation instead, leaving selection guidance implied 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 read-only, closed-world, idempotent, non-destructive behavior. The description adds useful behavioral detail beyond annotations: unknown inputs trigger questions and multiple applicable patterns should be combined. It still does not describe the exact response shape, but it adds meaningful context.

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

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

Three short sentences, front-loaded with the entry-point instruction, then purpose, then unknown-case behavior. Every sentence earns its place with no redundant text.

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 seven-parameter classification tool with no output schema, the description covers the entry point, what is classified, and the special handling of unknown inputs. It leaves the exact output structure implicit, but the pattern/question language gives enough for an agent to invoke it.

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?

All seven parameters are optional yes/no/unknown enums with 100% schema description coverage, so the schema already carries parameter semantics. The description only says features are explicit and applicable patterns are combined; it adds no parameter-specific detail. Baseline 3 is 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?

The description leads with a specific action ('Start an AI security audit here') and states the resource/output ('Identify ML, GenAI and agentic deployment patterns from explicit system features'). The phrase 'Start ... here' positions it as the entry point relative to audit siblings such as build_audit_plan and investigate_risk.

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 gives a clear usage context: begin an AI security audit with this tool. It does not explicitly list when to use each sibling or when not to use this tool, so it falls short of 5, but the entry-point guidance is stronger than implied usage.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds some behavioral context by noting that evidence is caller-reported and that the tool distinguishes a possible risk from an independently verified failure, but it does not explain return format, limitations, or what the explanation is based on beyond the supplied evidence.

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 compact sentences and front-loads the core purpose before adding the risk-versus-failure distinction and language guidance. It is efficient, though the second sentence is somewhat abstract and could be more concrete about the tool's output.

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 more responsibility for explaining what the caller receives. It states that the tool prepares an explanation and guides the agent on language and risk/failure distinction, but it does not describe the return shape or how the explanation is structured, leaving a notable gap for a four-parameter generation tool.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It gives meaningful coverage for language (English or Brazilian Portuguese) and clarifies that risk and caller-reported evidence feed the explanation, but it does not explain the role or expected format of risk_id, observation, or evidence_refs beyond that high-level framing.

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 and resource: prepare an explanation of a risk plus caller-reported evidence, in English or Brazilian Portuguese. It also states a useful distinction between a possible risk and an independently verified failure, though it does not explicitly differentiate itself from sibling tools like investigate_risk or propose_remediation.

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 usage context is implied: this tool is for producing a user-facing explanation after a risk has been identified, and it guides the calling agent to explain the source mechanism in the user's language. However, there are no explicit when-to-use or when-not-to-use instructions relative to siblings such as investigate_risk or get_risk.

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 the safety profile is covered. The description adds real value by disclosing the returned content bundle (docs, mappings, verification criteria), but says nothing about not-found behavior, size of the documentation payload, or identifier validity.

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 payload list is compact and immediately useful.

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 naming the returned artifacts, which is the key unknown for a lookup tool. Remaining gaps (ID format, error behavior) are minor given annotation coverage but not zero.

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

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

Schema coverage is 0% and the single parameter is undocumented, but the description's phrase 'one DASF control' at least signals that control_id is a DASF control identifier. It still does not explain the expected ID format or where the agent should obtain valid IDs.

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 ('Read') and resource ('one DASF control') and enumerates the payload (platform documentation, source mappings, verification criteria), so the agent knows exactly what a call yields. It does not name a sibling to contrast with, though get_risk/get_reference are close enough that differentiation would have helped.

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?

'Read one' implies a single-ID lookup, but there is no statement of when to prefer this over get_reference, get_risk, or search_knowledge, and no prerequisites (e.g., where a control_id comes from) 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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context that it remains available even in MCP hosts without resource support, but it does not describe return format, invalid-name behavior, or other operational details.

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 short and front-loaded, with the core purpose in the first sentence and a useful availability note second. The first sentence is somewhat dense, but it avoids wasted text.

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 read-only reference lookup with robust annotations, the description is adequate to convey the general purpose. However, with no output schema and incomplete coverage of the enum values, it leaves gaps around exactly which references are available and what is returned.

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 lone 'name' parameter has an enum of 13 values with 0% schema description coverage, so the description must carry the semantic load. It names several content categories that map to some enum values, but leaves others like index, toolkit, agent-security, finding-template, and skill-sources unexplained and does not explicitly map labels to enum values.

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 read operation and names the resource categories it retrieves, such as wiki method, glossary, source caveats, and audit skill material. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like search_knowledge, get_risk, or get_control.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to choose this tool over search_knowledge or the get_risk/get_control siblings. The only usage-adjacent note is that it works in MCP hosts without resource support, which is not a selection guideline.

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 that this is a safe, read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context by specifying that the result includes impacts, deployment applicability, mappings, and the official source row, beyond what the annotations 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 filler. Every phrase contributes to stating the action and the returned content.

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 one-parameter read tool with rich annotations and no output schema, the description usefully enumerates what is returned. The remaining gaps are the undocumented risk_id format and the lack of guidance on choosing this tool over investigate_risk.

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

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

The schema has zero description coverage for the sole risk_id parameter, so the description must compensate. It implies that risk_id selects one complete DASF risk, but it does not describe the expected ID format, source, or examples, leaving some semantic gaps.

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

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

The description names a specific verb (Read) and resource (one complete DASF risk) and enumerates the payload components, so the operation is clear. It does not distinguish this from sibling tools such as investigate_risk or scope_risks, which creates ambiguity about when this direct fetch is preferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use get_risk versus investigate_risk, search_knowledge, or other sibling tools. The single-record fetch is implied by the wording and required risk_id, but the agent is left to infer the selection criteria.

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 that the tool is read-only, idempotent, non-destructive, and closed-world. The description adds meaningful behavioral context by explicitly stating that it does not scan or execute tests, which helps set expectations for an 'investigate' tool. It does not, however, describe output format or permission requirements 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?

The description is two sentences with no wasted text. The primary purpose is front-loaded, and the exclusion sentence is short and useful. It is appropriately sized for a simple one-parameter tool.

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

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

The description lists the topics covered by the guidance, which partially compensates for the lack of an output schema. However, it does not explain how risk_id is obtained or formatted, does not define 'DASF,' and does not clarify how this tool relates to siblings such as get_risk or scope_risks. It is adequate but has 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?

The schema has one required parameter, risk_id, with 0% description coverage. The description only implicitly maps 'a DASF risk' to risk_id and provides no format, source, or usage guidance for the parameter. This leaves the agent with little beyond the parameter name and schema constraints.

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 that the tool provides guidance for investigating a DASF risk and enumerates the covered areas: trust boundary, failure hypothesis, evidence requests, bounded tests, and per-control acceptance criteria. It also clarifies that it does not scan or execute tests, which distinguishes it from an execution tool, though it does not explicitly contrast with sibling tools like get_risk.

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 'Learn how to investigate a DASF risk,' suggesting the tool is for retrieving investigative methodology rather than performing the investigation. The negative constraint 'Does not scan or execute tests' provides one exclusion, but there is no explicit guidance on when to use this versus get_risk, scope_risks, or other siblings.

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 the safety profile is covered structurally. The description still earns credit by reinforcing 'No changes are applied' and adding the downstream workflow expectation (select against evidence, assign owners/rollback).

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 action front-loaded and no filler. The second sentence is dense, packing three separate directives (no-apply, evidence selection, ownership/rollback) into one clause chain, but nothing is wasted.

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

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

For a single-parameter read-only tool with annotations covering safety, the description is adequate but leaves real gaps: what a 'proposal' contains, what 'retest criteria' means, and what the response looks like with no output schema to explain returns.

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?

Only one parameter exists and schema description coverage is 0%, so the description is the sole source of meaning. 'Selected risk IDs' confirms the parameter's intent but adds nothing about the 1-10 item limit or the string constraints already 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 and object: 'Propose control changes and retest criteria for selected risk IDs.' That is concrete enough to separate it from mutating siblings like build_audit_plan or investigate_risk, 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 changes are applied; select proposals against actual evidence and assign owners/rollback' implies this is a review/drafting step that feeds a human decision, but it never says when to choose this over investigating or planning, and no prerequisites are 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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing output content ('source citations and unspecified applicability') and the internal dedup step, though 'unspecified applicability' remains vague.

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 tight sentences, front-loaded with the operation and followed by the output note and the scope caveat. Every sentence carries information; density is slightly hurt by unexplained shorthand.

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, and the description compensates by naming what is returned. Annotations plus description cover the safety profile, inputs, and output at a level sufficient to invoke correctly; only the domain jargon ('DASF', 'Yes cells') leaves a small residual 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 compensate. It does convey meaningful semantics—each deployment pattern contributes 'Yes' cells that are unioned, with duplicates in linked controls collapsed—but it never explains the seven enum values or the minItems/maxItems constraint on deployment_patterns.

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 (filter) and resource (DASF risks) and explains the operation: union of deployment-pattern 'Yes' cells followed by deduplication of linked controls. It's distinguishable from siblings like investigate_risk or get_risk, though the terms 'DASF' and 'Yes cells' are unexplained jargon that a fresh agent may not parse.

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?

'After classification' gives explicit sequencing relative to classify_system, and the closing line 'This is scoping, not a vulnerability finding' excludes misuse in place of investigate_risk. No explicit negative routing to a named sibling, but the when-to-use and when-not conditions are clear.

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 settled. The description adds genuinely non-structured behavior: results are paginated, source-backed, and matched literally rather than semantically, which warns the agent off natural-language queries. It omits ranking/relevance behavior and what happens when nothing matches.

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

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

Three short sentences, front-loaded with capability, then results shape, then the alternative tool, then a caveat. Every clause carries information; nothing is 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 4-parameter search tool with a full annotation set and no output schema, this covers capability, likely result shape (paginated, source-backed), and the escalation path. The remaining gap is per-parameter guidance, especially the kind filter, which leaves a little inference to the agent.

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

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

Schema coverage is 0%, so the description carries the burden. It explains the query parameter well (literal words, IDs, framework mappings) and hints at pagination, but says nothing about the kind enum (risk/control/all), limit bounds, or offset semantics. Partial compensation only.

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 (find) and resource (DASF risks and controls) plus the matching mode (literal words, IDs, source framework mapping), which sharply distinguishes this from detail-fetching siblings. An agent can tell what this does without opening the 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?

Explicitly routes to get_risk/get_control for details, which is the key boundary an agent needs. The note about translating natural-language terms to source English clarifies the search mode. It does not address other siblings (scope_risks, investigate_risk, explain_finding), so the routing picture is only partially covered.

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