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 description need not repeat safety traits. It adds behavioral context by explaining what the tool returns (DoD asset categories with treatment details, plus CUI categories that commonly surprise contractors) and the significance of scope decisions on cost. This goes beyond annotations without contradicting them.

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 three sentences, each serving a distinct purpose: (1) the core function, (2) the return value, and (3) when to use it. It is front-loaded with the primary action, avoids redundancy, and includes only one contextual sentence about cost implications, which adds urgency rather than fluff. Every sentence earns 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 two parameters, full schema coverage, and no output schema, the description carries the burden of explaining what the tool returns. It does so by enumerating the asset categories and CUI categories, which is sufficient for an agent to select and invoke the tool. It could be more explicit about the output structure (e.g., whether it's a list or detailed report), but the missing details are not critical for correct invocation, so this is slightly above the baseline.

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 baseline is 3. The description adds semantic value for the include_cui_categories parameter by noting 'the CUI categories that most often pull a defense contractor into scope unexpectedly,' which enriches the schema's phrase 'traps that hide them.' It does not discuss the level parameter further, but the schema already adequately describes it, including the Level 1 nuance.

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

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

The description clearly states the tool's function: 'Work out which assets fall inside a CMMC assessment boundary, and what each category obliges.' It uses a specific verb ('work out') and resource ('CMMC assessment boundary'), and distinguishes itself from siblings like determine_cmmc_level by focusing on asset scope rather than level determination. The description also enumerates the returned asset categories, making the purpose concrete.

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

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

The description provides explicit usage contexts: 'Call this when someone asks what is in scope, how to reduce assessment cost, whether an enclave helps, or whether a specific system counts.' This is clear and actionable, though it does not explicitly mention alternatives or when-not-to-use. The guidance is sufficient for an agent to decide when this tool is appropriate, so it earns a 4 rather than a 5.

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