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

With no annotations provided, the description carries full burden and does so well: it discloses that missing_mapping adds coverage while spurious_mapping removes it, that changes are batched as one version per affected control, that validation is per-item, and that partial batches still apply valid items.

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 a clear one-sentence summary, then uses compact paragraphs to add essential behavioral detail and usage workflow. Every sentence contributes information, with no 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?

For a mutating batch tool with no annotations, the description covers core effects, validation behavior, and prerequisite workflow. The presence of an output schema reduces the need to describe return values. Minor missing context is the meaning of server_version, but overall the description is sufficient for correct usage.

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%, so the baseline is 3; the description adds value beyond the schema by explaining the behavioral meaning of each item kind and by advising how to filter coverage rows before constructing the items array. The only gap is server_version, which remains undocumented.

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 action ('Accept a set of coverage divergences'), the resource ('coverage divergences'), and the batch scope ('as mapping changes, in one batch'). It also differentiates the semantics of the two item kinds, making the tool's specific role unmistakable.

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 explicit sequencing guidance: read rows first with get_verdict_divergence, optionally filter by p_covers, then pass items here. It does not explicitly contrast with sibling dismiss_verdict_divergences, but the prerequisite workflow is clear 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?

With no annotations provided, the description carries the full burden — and it delivers richly. It discloses side effects (creates a new version), gating behavior (LLM-gated against re-add of soft-deleted assets), the three possible outcomes with their response signatures (normal create, auto-restore with revived CO tombstones, similar-verdict rejection), and explicit failure modes (503 and 502 with retry guidance). This is exceptional behavioral disclosure for an unannotated mutation tool.

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 long but well-structured and front-loaded: the core purpose leads, then the authoring contract, then outcomes, then errors. Bold headers, bulleted outcome lists, and bold inline flags make it scannable. Every section adds distinct information rather than padding, though it borders on being dense enough to skim past details.

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 this is a complex, LLM-gated mutation tool with an output schema, the description is complete: it covers the accepted shapes, the contract for a good asset, the three possible returns, and the failure modes. Nothing an agent needs to invoke it correctly — including what happens after invoking — is missing.

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

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

Schema coverage is high (86%), so the schema already documents most parameters. The description adds genuine meaning beyond it: it explains that description feeds the factor-reasoning prompt, that component_ids is the canonical architecture-to-code bridge and multi-component is right for multi-instance assets, and it frames the authoring contract for name. It does not elaborate on server_version or notes, but those are self-evident, so the description compensates where it matters.

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 — 'Add a new asset to a threat model' — and immediately distinguishes its effect by noting 'Creates a new version.' The description sets this apart from sibling tools like edit_asset (which overrides post-create) and add_component/add_attacker by naming the precise resource being added. An agent can tell this from its siblings without opening their schemas.

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 names edit_asset as the alternative for post-create overrides, and create_co_disposition for recording non-applicability — giving clear routing advice. The component_ids paragraph also explains when multi-component is the right shape. However, it does not explicitly contrast with add_component or add_attacker (the other 'add_*' family members), so sibling differentiation is incomplete.

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?

No annotations are provided, so the description carries the full burden. It discloses the mutation side effect, the attestation/mitigation lifecycle, deterministic class-3 evidence behavior, wildcard defaults, and precedence rules. This is strong behavioral context, though it does not cover operational concerns like permissions or reversibility.

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 action and side effect, then organizes the advanced exclusion predicate behavior into a focused section. It is fairly long, but the content earns its place given the tool's complexity and 11 parameters.

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 complex tool with no annotations, an output schema, and high schema coverage, the description covers the essential operational context: side effects, matching behavior, defaults, precedence, and a concrete use case. It does not spell out every assumption lifecycle step, but the schema and output schema cover the structured details.

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 91%, setting a high baseline. The description adds meaningful semantics beyond the schema: it explains that any subset of exclusion_* fields can be passed, unspecified fields default to wildcard, exclusion_co_ids takes precedence, and the predicate feeds deterministic composer evidence. This exceeds the baseline.

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: "Add an assumption." and clearly states the side effect "Creates a new model version." This distinguishes add_assumption from related operations like edit_assumption without relying on the title alone.

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

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

The description gives a concrete, decision-relevant scenario: use this to resolve a CO with an "indeterminate" composer verdict by setting exclusion_co_ids. It provides clear context for when the exclusion_* predicate mechanism is appropriate, though it does not explicitly name alternatives or state when not to use the tool.

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?

With no annotations present, the description carries the full transparency burden and does so thoroughly. It discloses that the call creates a new version, that the backend LLM-reasons the factor decomposition, that three outcomes mirror add_asset, that 503/502 errors can occur, and that surface_extent is recorded as an attested operator statement.

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 long but information-dense, with important constraints front-loaded and clearly separated. It loses a point for some redundancy, such as mentioning the add_asset mirror twice, and for an extended rationale about for-all obligations that could be tighter.

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 create operation with backend reasoning, side effects, error conditions, and an attestation parameter, the description covers all the non-obvious context an agent needs. It explains versioning, alternative routing, failure modes, the capability contract, and the special surface_extent workflow, while output format is covered by the output schema.

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 high at 88%, but the description still adds significant meaning beyond the schema. It defines the capability authoring contract with a concrete pattern and quality_warning consequence, and it explains surface_extent's create-time restriction and attestation semantics in ways the schema 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?

Opens with a specific verb and resource: "Add a new attacker to a threat model." It also distinguishes itself from the sibling edit_attacker by noting that post-create factor overrides and surface narrowing happen there, and it names add_asset as its semantic mirror.

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 explicit when-to-use guidance: use this tool to create an attacker, and use edit_attacker afterward to override factors or narrow surface_extent. It also tells the caller that only "whole" is declarable at create time and that narrowing belongs on a later edit, which prevents a common misuse.

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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the tool's relationship to generation (must be called after generate_threat_model), the meaning of empty repo_url, and the permanent external-dependency marker behavior of component_unbound findings. It doesn't explicitly state side effects like whether it overwrites existing components or requires specific permissions, but the disclosed context is substantial.

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 moderately long but every sentence earns its place. It front-loads the core purpose, then provides essential context about components, generation ordering, and the repo_url/trust boundary semantics. The structure is logical, though the final warning about client code could be seen as slightly tangential.

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 tool's complexity (6 params, output schema present, many siblings), the description is quite complete. It covers the tool's role, when to use it, key parameter semantics, and common pitfalls. It doesn't describe the return value, but an output schema exists, so that's not required. It could mention prerequisites like needing a valid model_id, but that's likely implied by the schema.

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 83%, so the schema already documents most parameters well. The description adds meaning beyond the schema by explaining the semantic distinction between speculative and external components (empty repo_url) and how trust_boundary_ids drive reach decisions. It doesn't add detail for every parameter, but the schema covers them adequately.

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: 'Add a component to a threat model.' It goes beyond a simple definition by explaining what components are, how they relate to trust boundaries and repos, and how they drive the reachability composer. This distinguishes it from sibling tools like edit_component and add_trust_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 description provides explicit usage guidance: 'Generation reads no components, so add or edit them after generate_threat_model, not before.' It also explains when a component with empty repo_url is speculative vs external, and explicitly warns against a common mistake ('Binding by "some client code touches it" is wrong'). This is strong, actionable 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?

With no annotations provided, the description carries the full burden and it deliberately discloses 'Mutating.' to signal side effects. It further clarifies a non-obvious behavioral nuance: evidence does not affect a control's implementation status. It stops short of covering dupicate-attachment behavior, permissions, or reversibility beyond pointing to remove_evidence, but the mutation disclosure plus semantic caveat is solid for a simple attach operation.

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 terse sentences with zero waste: the action is front-loaded, 'Mutating.' is a compact side-effect flag, and the semantic caveat plus sibling routing each earn their place. The paragraph break after the first sentence aids scannability.

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 straightforward mutation tool with an output schema present, the description plus schema cover the essentials: what it does, that it mutates, how it relates to status, and how to undo it. The only notable gap is the required server_version parameter having no description in either schema or description, and no statement about duplicate-attachment behavior, but these are minor against an otherwise complete definition.

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 83% (all parameters except server_version are documented), so the schema carries most of the parameter weight. The description adds marginal value by reinforcing the 'metadata-only' nature of the item and the type list already in the schema. It does not elaborate on server_version or label requirements, but the baseline 3 is appropriate given high schema coverage.

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 ('attach'), names the resource ('auxiliary evidence item... to a control'), and enumerates the item types (doc, link, artifact reference). It also differentiates from siblings by clarifying that evidence is not an assertion and naming remove_evidence as the inverse, so an agent can distinguish it from add_assumption or submit_assertions.

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: evidence is contextual metadata and does not count toward implementation status, with 'only assertions prove controls' serving as an implicit when-not signal. It explicitly points to remove_evidence for detaching. It does not name the exact alternative tool for proving controls (e.g., submit_assertions), but the guidance is strong enough to route correctly.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is mutating, that it records only the status the caller claims, that it does not run or verify anything, that CI verification happens separately, and that manually-added tests survive regeneration/refresh.

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?

Every sentence earns its place: purpose, mutation flag, routing to alternatives, and the no-verification caveat. It is dense but not bloated, and the most important 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?

The description plus the rich schema cover purpose, alternatives, side effects, and the existence of an output schema means return values need no explanation. The only gap is that the required server_version parameter is undocumented in both the tool description and the input schema, which an agent may need to fill 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 description coverage is high (83%), so the schema already documents most parameters; the description adds little parameter-specific meaning beyond reaffirming one-or-more objective mapping and the status-as-claim behavior. The required server_version parameter remains unexplained in both the description and 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: 'hand-author a single functional test and map it to one or more objectives.' It also names what the tool is not — generation and bulk import — which clearly distinguishes it from nearby siblings such as generate_functional_objectives and import_functional_tests.

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 explicit when-to-use guidance: use only to register an extra test that generation did not produce, use import_functional_tests for bulk-registering existing tests, and attach verification evidence via submit_functional_test_assertions. This leaves no ambiguity about when to choose this tool over 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?

With no annotations present, the description carries the full behavioral burden and does so well. It states the operation is mutating, clarifies that the model is linked without moving or copying, notes that the model remains independently editable, and discloses per-kind return behavior and an API limitation regarding system member removal.

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 organized with a clear purpose sentence, a short behavioral note, and a structured list for kind values. Every sentence adds useful information, and the removal caveat is placed as a closing note without bloating the main explanation.

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 mutating tool with four required parameters and no annotations, the description covers prerequisites, kind-specific behavior, return expectations, and the key limitation around removal. The output schema handles return structure, so the description is complete enough for an agent to decide when and how to call this 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?

The schema already describes kind, group_id, and model_id, but the description adds valuable meaning: the semantic difference between 'tag' and 'system', the implications of overlapping tag membership, and distinct return payloads. The server_version parameter remains undocumented in both schema and description, preventing a higher score.

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: 'Add a threat model to a group as a member,' which clearly identifies the operation. It further distinguishes itself from the sibling remove_model_from_group and explains the tag vs. system semantics, making the tool's purpose unambiguous.

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 explicitly explains when to use each kind ('tag' vs. 'system'), states prerequisites (both entities must already exist), and flags an important usage boundary: member removal is tag-only and points to remove_model_from_group. This gives the agent clear, actionable guidance on when this tool is appropriate and when it is not.

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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Creates a new model version,' which is vague and does not explain side effects such as versioning implications, reversibility, permission requirements, or what happens to existing boundaries. The description fails to disclose any meaningful behavioral traits.

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 extremely concise, consisting of two short sentences. It is front-loaded with the primary action and avoids redundancy. While it is arguably under-specified, it is efficiently structured with 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?

For a tool with 6 parameters, an output schema, and a complex domain (trust boundaries in threat models), the description is insufficient. It does not clearly explain the model versioning behavior, any prerequisites, or the effect on the overall model. It also fails to reference the rich parameter semantics that the schema provides, leaving the agent without a clear operational picture.

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 provides detailed descriptions for 5 of 6 parameters (83% coverage), so the description is not required to explain parameters. The description adds no additional meaning beyond what the schema already offers, earning the baseline score for high schema coverage.

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 verb 'Add' and resource 'trust boundary', making the primary purpose obvious. However, it does not differentiate from the sibling edit_trust_boundary beyond the verb difference, and the added 'Creates a new model version' is ambiguous about whether that is a side effect or a separate action. Purpose is clear but not fully distinct.

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 edit_trust_boundary or other model-modifying tools. The description does not mention prerequisites, the distinction between adding vs editing boundaries, or any context that would help an agent decide between 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that the operation mutates state, soft-deletes an entity, bumps the model version, emits an activity event, and may return 400 if the candidate is stale. This gives an agent a realistic picture of side effects and failure modes before calling the tool.

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 systematically covers effects, workflow, tier differentiation, error handling, and side effects in a logical order. Every sentence carries useful information; there is no filler or redundancy. It is appropriately sized for a mutation tool with this level of complexity.

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 presence of an output schema and a complex mutation with concurrency implications, the description is remarkably complete. It explains preconditions (use after listing candidates), the tier rules, server-side re-validation and 400 handling, and success effects (version bump, activity event). No critical behavioral aspect needed for correct invocation appears to be 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 schema already covers 5 of 6 parameters with descriptions, putting the baseline at 3. The description adds meaning beyond the schema by explaining the behavior of confirm_heuristic (heuristic-tier refused without it) and implying that server_version acts as an optimistic concurrency token during re-validation. However, server_version itself remains undocumented in both schema and description, so the added meaning is strong but not 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 description clearly states the verb 'Apply' and the specific resource 'certain-tier reconciliation candidate', and explains exactly what the operation does: soft-deletes the descendant's duplicate and makes the inherited entity canonical. It also distinguishes itself from sibling reconciliation tools by noting that certain-tier candidates apply directly while heuristic-tier candidates require the confirm_heuristic flag. This is specific and unambiguous.

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 explicitly says to use this after surveying candidates via list_reconciliation_candidates, providing clear sequencing. It also describes the alternative path for heuristic-tier candidates, which require operator review and the confirm_heuristic flag, and notes that they are refused server-side without it. This gives an agent actionable guidance on when to invoke this tool versus other reconciliation actions.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains atomic all-or-nothing commit, mapping-only semantics, preservation of status/evidence/assertions, and the orphan guard evaluated on the final state. This is exemplary transparency for a mutation tool.

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 detailed but every sentence earns its place. It front-loads the core purpose, then adds necessary transaction and constraint details without repetition or fluff. The structure is well organized for a complex 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 fully addresses the tool's complexity: atomicity, operation types, orphan guard behavior, and mapping-only effects. An output schema exists, so return values are covered elsewhere. The only minor gap is server_version, which is neither described in the schema nor the description.

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%, so most parameter meaning is already provided by the schema. The description adds valuable context about operation behaviors but does not significantly elaborate on individual parameter semantics beyond what the schema already includes. server_version remains undocumented, but the high schema coverage keeps this at baseline.

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: 'Apply a batch of control operations atomically as ONE transaction.' It clearly distinguishes this batch tool from single-operation siblings like remap_control and delete_control by emphasizing atomic, multi-operation changes.

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 explicitly states when to use it: to reorganize controls in one step, such as deduplication, 'instead of many separate calls.' It does not explicitly name alternative tools or exclude single-operation cases, but the context is clear enough for an agent to choose correctly.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the operation mutates state, commits previewed changes, records justification in the audit trail, does not enforce the preview-then-apply norm itself, and documents all relevant error statuses (404, 409, 400, 422). This gives the agent a strong model of side effects and failure modes.

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 well-structured and front-loaded: purpose first, then workflow/audit context, then the critical safety warning, then error semantics. Each sentence adds relevant operational value and none feel redundant.

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 fully covers the safety-critical workflow, audit implications, and error handling, and an output schema exists so return-value documentation is not required. The only notable gap is server_version, which remains unexplained, preventing a perfect score.

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 description adds useful meaning for finding_id and justification by tying them to error codes and audit-trail behavior, but server_version has no schema description and the description does not clarify its purpose or format. With only 67% schema coverage and no description of server_version, the parameter semantics are only partially compensated.

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 action ('Apply the remediation for a finding'), explicitly states it mutates state, and distinguishes itself from preview_finding_remediation by describing this as the follow-up commit step. An agent can immediately tell what this tool does and how it differs from its preview sibling.

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 an explicit, direct usage rule: DO NOT call this without first calling preview_finding_remediation and showing the operator the diff. It also defines the agent's responsibility to obtain explicit operator confirmation, making the when-to-use and workflow 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states the tool is read-only, makes no LLM calls, performs no mutation, and is deterministic. It also describes what the assessment computes and returns, including summary counts and progressive metrics. This goes well beyond the structured schema and gives the agent a confident mental model of the tool's behavior.

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

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

The description is well-structured and front-loaded: purpose first, behavioral safety second, output summary third, alternative routing fourth, and a practical usage tip last. Every sentence adds value and there is no redundant text repeating schema fields.

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 is largely complete given the output schema exists and covers return values. It explains purpose, safety, result semantics, and the alternative tool. The only notable gap is that server_version is a required parameter with no schema description and no explanatory mention in the description, which is a small but real completeness gap for a required input.

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 83%, so the schema already documents five of six parameters well. The description adds useful context for summary_only and reinforces the allowed status values. However, it does not help with server_version, the one parameter lacking schema documentation, and it adds no deeper semantics for limit, offset, or model_id beyond what the schema already provides.

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: 'Run the deterministic assurance assessment over a threat model.' It clearly explains what the tool evaluates and returns, and distinguishes itself from check_control_gaps by naming that sibling explicitly. An agent can tell exactly what assess_model does and what it does not do.

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 explicit routing guidance: for LLM-based reasoning about which control objectives are under-covered and what controls to add, use check_control_gaps instead. It also explains when to use summary_only=True. This is clear when-to-use and when-not-to-use guidance, not just implied context.

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?

With no annotations, the description carries the full burden and does so well: it flags the operation as 'Mutating,' states both variants are 'mechanical / non-AI-gated,' and discloses the only validation rule. It also explains downstream effects like visibility to coding agents and boundary context flowing into reachability derivation.

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 core action and mutation flag are front-loaded, and the two variants are organized in clean bullets. Every sentence earns its place, with concrete examples and domain rationale that support correct invocation rather than padding.

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?

Since an output schema exists, return-value documentation is not required. The description covers both target types, appropriate use cases, replacement semantics, unscoping via empty string, and validation rules, making it complete enough for an agent to call 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 coverage is already high at 83%, and the description still adds meaningful value for target_type, target_id, and component_ids with examples, empty-string behavior, and multi-instance asset guidance. It leaves server_version undocumented in both schema and description, which prevents a 5.

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: 'Replace an asset's or a control's component scope.' The two target_type variants are fully spelled out with examples, so an agent can distinguish this from siblings like add_component or edit_component.

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 explicit 'Use when' scenarios for the control variant: wiring an unscoped control, adding a second component to a cross-cutting control, and correcting a wrong assignment. It explains the asset variant's purpose for reachability, but it does not name when-not-to-use conditions or alternative sibling tools.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the platform verifies each association before accepting it and returns declined mappings under 'rejected_mappings'. This is useful behavioral context, though it does not cover side effects or idempotency.

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 concise sentences, each earning its place: what it does, when to use it, and what behavior to expect. 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 tool with four required parameters and an output schema, the description provides essential operational context, usage timing, and behavior. It does not explain 'server_version', but the output schema and remaining context make the tool sufficiently usable.

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 75%, so the schema already documents most parameters. The description adds some context about the association intent and the rejection behavior, but it does not compensate for the undocumented 'server_version' parameter or add deeper meaning to the parameter 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?

States a specific operation: associating a functional test with one or more functional objectives. It names the related sibling tool suggest_functional_test_mappings, which helps distinguish this tool from other mapping-related 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?

Gives explicit usage timing: 'Use this after suggest_functional_test_mappings, or to hand-map a test to the objectives it covers.' This clearly explains when the tool is appropriate, though it does not enumerate exclusions or 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?

With no annotations provided, the description carries the behavioral burden. It clearly states that edges are draft, run LLM validation, carry no credit until separately confirmed, and returns {created, failed}. This is solid behavioral disclosure, though it doesn't cover failure semantics or side effects in depth.

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 concise, front-loaded with the main action, and each sentence adds critical information: input shape, relationship to proposal, draft/validation behavior, credit semantics, and return value. No redundant 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 tool with four parameters and an output schema, the description covers the essential input semantics, the draft nature, the validation behavior, and the return shape. It lacks some detail about error cases or prerequisites, but the references to propose_attach_foundation and separate confirmation provide enough workflow context.

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 75%, so the schema already explains most parameters. The description adds valuable detail for 'selections' by showing its expected structure and relationship to propose_attach_foundation, but it adds little meaning for model_id, foundation_model_id, or server_version 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 states a specific verb and resource: it creates draft delegation edges for selected (objective, control) pairs. It also references the sibling propose_attach_foundation, placing this tool in context as operating on a confirmed subset of that proposal, which distinguishes it from related attach/propose operations.

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: selections are typically the operator-confirmed subset of propose_attach_foundation. This implies the tool is used after proposal and before final confirmation, but it does not explicitly state when not to use it or directly compare it to alternatives such as confirm_reliance.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is mutating, runs as a background job, waits for completion, returns results, requires PRO tier, and only maps existing controls. This is strong transparency for a complex asynchronous write operation.

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 action and constraint, followed by concise behavioral details and then sibling differentiation. Every sentence contributes useful information with minimal jargon or redundancy.

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?

Despite the tool's complexity — async, mutating, tier-gated, with multiple sibling tools — the description covers what it does, how it behaves, its scope limitations, and its relationship to alternatives. The presence of an output schema means return-value detail is not required here. This is a complete and actionable description.

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%, so the schema already documents model_id, control_id, and framework_id. The description adds context about 'existing controls' and 'never adds or excludes entities,' which indirectly clarifies scope, but it does not add meaningful per-parameter semantics beyond the schema, especially for server_version.

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 and resource: 'LLM-map a model's existing controls to a framework's requirements.' It clearly distinguishes itself from siblings by naming map_control_to_requirement and auto_remediate_compliance and explaining how auto_map_controls differs from both.

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?

Explicit usage placement is provided: it 'sits between' the manual single-mapping tool and the full auto-remediation loop. It also states exactly what it does not do — it never adds or excludes entities — so an agent can decide when to prefer it over 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?

With no annotations, the description carries the full burden and delivers exceptionally. It discloses the restore-candidate LLM gate shared with add_asset, the side effect of reinstating stable IDs along with CO tombstones and tied controls, fail-closed behavior when the gate is unavailable, per-entry skip reasons, response field distinctions (restored vs newly added), and automatic convergence.

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 long but information-dense, with purpose and prerequisite front-loaded before the phase breakdown. The phase-3 paragraph is the most verbose section, yet nearly every clause carries operational significance for a tool with this side-effect complexity. Minor tightening of the restore-candidate explanation would be possible without losing value.

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 complex mutation tool with zero annotations, the description covers prerequisites, the full operational loop, side effects on soft-deleted entities, failure modes, concurrency behavior, and trigger conditions. The output schema covers return values, so the response-field explanation is bonus. The one real gap is server_version, a required parameter whose meaning appears nowhere in the schema or description.

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%: model_id and framework_id are documented in the schema, and the description adds contextual meaning by tying framework to the remediation target and noting that model changes justify re-triggering. However, server_version is a required parameter with no schema description and no description-side compensation, leaving its semantics entirely unknown.

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 opening sentence states a specific verb and scope: "Automatically close compliance gaps for a framework." The three-phase loop then concretely defines what 'close' means (map controls, exclude non-applicable requirements, apply new assets/attackers), which clearly differentiates it from mapping-only siblings like auto_map_controls and check_control_gaps.

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 invocation context: it runs automatically when a framework is selected, can be manually re-triggered when the model changes, and requires PRO tier. However, it never explicitly names alternatives or states when not to use this tool (e.g., when only control mapping is needed versus full remediation with asset/attacker creation), leaving some routing inference to the 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?

With no annotations provided, the description carries the full burden, and it does so well: it explicitly states the tool is read-only, does not mutate the model, runs as a polled background job, and uses LLM reasoning. These are meaningful behavioral traits beyond what the schema alone reveals.

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 compact and front-loaded: the first sentence states the core purpose, the second covers behavior, and the final paragraph distinguishes the tool from its sibling. No sentence 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?

The description covers purpose, behavior, async execution, and the key alternative, and an output schema exists to cover return values. The main gap is the unexplained server_version parameter, and the description does not mention how to obtain or poll the background job's result.

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

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

Schema coverage is only 50%: model_id has a description but server_version does not. The description adds no parameter-level guidance at all, leaving server_version's meaning and format unexplained. It does not compensate for the low schema coverage.

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 specific verbs ('Analyze', 'surface') tied to a clear resource: control coverage and control objectives lacking sufficient controls. It also explicitly differentiates itself from assess_model, making its purpose unmistakable.

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 explicit guidance: used to decide what controls to add, while assess_model is used to score the current state. It also contrasts its LLM-based reasoning with assess_model's deterministic computation, so an agent can choose correctly between the two.

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?

With no annotations present, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only, has no side effects, and describes what the returned subset contains (conditions with no objective, failing objectives, objectives with no passing test). This is meaningful behavioral context beyond the bare function name.

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 compact and front-loaded: it leads with the action, states the read-only nature, explains the return value, and then provides routing guidance. Every sentence adds value, with no redundant 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?

The description is largely complete for a read-only filtering tool: it explains purpose, scope, return behavior, and the sibling alternative, while the output schema covers return structure. The main gap is that server_version is left undocumented, so the agent may not know what value to provide for that required 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 only 50%, and the description does not compensate for the undocumented server_version parameter. model_id is explained in the schema, but server_version has no description and no additional meaning is provided in the tool description.

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 ('Get') with a defined resource ('actionable functional gaps for a model') and clearly distinguishes the returned subset from the full coverage report. It also explicitly contrasts itself with the sibling get_functional_coverage, so an agent can differentiate the two without opening schemas.

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 states exactly when to use this tool: to decide what to implement or fix next. It also names the alternative, get_functional_coverage, and explains that the alternative should be used when the complete coverage matrix and all states are needed.

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?

With no annotations, the description carries the full burden, and it delivers: grounding constraints, re-validation before persistence, skip-if-already-tagged behavior, force semantics, the summary shape, and a 404 failure condition.

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 compact and front-loaded with the core purpose, and each subsequent clause adds distinct behavioral information without redundancy.

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 covers return summary, idempotence, and errors, and an output schema exists, so the main gap is the unexplained required 'server_version' parameter. It is otherwise sufficiently complete for a tool of this complexity.

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% and the missing description is for the required 'server_version' parameter. The description reinforces 'force' and 'model_id' but adds no meaning for 'server_version', so the agent still cannot tell what value to supply.

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 names a specific verb ('Classify'), a concrete resource (a model's control objectives), and the target catalog, which makes the tool's job unmistakable and distinguishes it from sibling reads like get_cwe_catalog and get_model_cwe_tags.

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 makes clear this is the tool to use when classifying against the CWE catalog, and the skip/force behavior implies idempotent reclassification. However, it never explicitly states when not to use it or names an alternative for retrieving catalog IDs or existing tags.

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?

With no annotations, the description carries the full burden. It discloses that the operation is mutating, updates the checklist, and rejects unrecognized step_id values without changing state. This is strong behavioral disclosure, though it stops short of discussing permissions, idempotency on already-completed steps, or side effects beyond the checklist.

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 compact and front-loaded, with the core purpose stated in the first sentence. The subsequent sentences provide actionable usage guidance and an important failure behavior without 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?

The description covers purpose, mutation semantics, call timing, and invalid-input behavior, and an output schema exists to document return values. However, the required server_version parameter is left entirely unexplained, which is a meaningful gap for an agent trying 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?

The schema describes step_id and its allowed values, but server_version has no schema description and the tool description does not explain it either. With only 50% schema coverage, the description should compensate for the undocumented required parameter, but it never mentions server_version at all.

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 specific action ('Mark one onboarding setup step as done') and the resource it affects (workspace onboarding checklist). It also explicitly identifies the operation as mutating, which distinguishes it from read-only sibling tools like get_setup_status.

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 explicit when-to-use guidance: call after performing the actual setup action. It also instructs the agent to check get_setup_status first to avoid re-marking completed steps, providing a clear workflow and an alternative tool reference.

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?

With no annotations, the description carries the full behavioral burden. It discloses refusal semantics, the 'never silently credited' guarantee, and the return value. However, 'mode mismatch' is undefined, and it does not state what happens on failure beyond refusal.

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 sentences with no filler. The main action is first, followed by refusal conditions and the return value. Every sentence adds useful 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?

The tool is simple and has an output schema, so the description need not explain return shape. But the required server_version parameter is completely undocumented in both the schema and the description, and 'mode mismatch' is unexplained. An agent could struggle to invoke this 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 coverage is 67%; edge_id and accept_partial_as_relied_upon are described, but server_version has no schema description and the description does not clarify it. The description's 'partial result is refused' adds some meaning to the partial-coverage parameter, but the undocumented required parameter remains a gap.

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 precise verb and resource: 'Promote a draft reliance edge to active,' and adds the gate context 'credit-soundness gate.' This clearly distinguishes it from reliance lifecycle siblings like create_reliance, list_reliance, and delete_reliance.

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 a clear precondition: use this only when LLM validation returned 'valid'; partial results or mode mismatches are refused. It does not explicitly name alternative tools or say 'use X instead,' but the activation context is clear enough for correct selection.

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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses the side effect on control-level linkage, removal of the assumption from assumption_groups, dropping of empty groups, reverting of controls to not_implemented, and clarifies that underlying assumptions are not deleted.

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 primary action and use case, followed by a compact and well-organized side-effect disclosure. Every sentence adds meaningful information; there is no filler or redundancy.

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 mutation tool with complex side effects and an output schema present, the description covers the main behavior, the triggering condition, the affected entities, and the non-destructive aspect. An agent has enough context to invoke 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?

Schema description coverage is 67%; model_id and assumption_id are minimally described but server_version has no schema description and is also absent from the tool description. The description reinforces the role of assumption_id through its behavioral text but adds no parameter-level meaning and completely ignores the undocumented required server_version parameter.

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 uses a specific verb and resource: 'Convert a violated or retired assumption to controls.' It clearly distinguishes this from sibling tools like add_assumption/edit_assumption and regenerate_controls by stating the conversion action and the control-generation outcome.

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 states when to use the tool: 'Use when an assumption is no longer valid and the system owner needs to implement controls instead.' It gives a clear condition but does not explicitly name alternative tools or exclusion cases, so it falls just 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does this thoroughly: the objective remains in the matrix, no controls are generated, no coverage gap is raised, and the claim expires at review_by. This goes far beyond what the schema alone communicates.

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 claim and then structured into clear behavioral, temporal, and alternative-usage sections. It is longer than strictly necessary, but the length is justified by the nuance of the tool and the need to prevent confusion with create_risk_acceptance.

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 6 required parameters, no annotations, and an existing output schema, the description covers the tool's semantics, side effects, timing constraints, and sibling distinctions thoroughly. An agent has enough information to decide when to call it and what the call will do.

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 high at 83%, so the baseline is already solid. The description adds meaningful semantics beyond the schema, especially for review_by: it is 'not a formality,' the claim stops applying on that date, and the date should be realistic for re-checking. It also reinforces that owner is the accountable party.

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: 'Record that a control objective DOES NOT APPLY to this system.' It also explicitly distinguishes this from create_risk_acceptance by defining the type of claim being made, so an agent can tell the tools apart without needing to compare schemas.

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 explicit routing guidance: use create_risk_acceptance when the objective DOES apply and the risk is carried deliberately, and use neither tool when an objective is merely unaddressed rather than inapplicable. It also explains the operational consequences of using this tool, giving clear context for when it is appropriate.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It openly states the operation is mutating, explains uniqueness constraints, documents that passing model_ids for system groups raises an error, and describes what is returned for each kind.

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 well-structured with a front-loaded summary followed by focused bullet-style explanations. Every sentence adds meaningful context, and the format makes the tag/system distinction easy to parse.

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 lack of annotations and the tool's branching behavior between tag and system kinds, the description is complete: it covers creation rules, error conditions, follow-up actions, and return values. The existence of an output schema reduces the need to describe the full response shape.

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 80%, and the description adds significant meaning to the kind and model_ids parameters: it explains valid values, semantics, seeding rules, and constraints. However, server_version is undocumented in both the schema and the description, so the description does not fully cover every parameter.

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 creates a group, specifies the two kinds (tag and system), and describes what each kind means. It distinguishes this creation tool from related operations like add_model_to_group by explaining seeding and post-creation member addition.

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 when-to-use guidance by separating tag versus system behavior, states that system groups cannot be seeded at creation, and directs users to add_model_to_group for adding members later. This gives an agent a clear decision path.

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?

No annotations are provided, so the description carries the full burden, and it delivers well. It explicitly says 'Mutating: persists a proposal record,' clarifies that raising a proposal does not decide it, states that 'Design changes are never applied automatically,' and directs polling 'list_proposals' for the outcome. This is strong behavioral disclosure for a mutation tool.

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 usage triggers, then the mutation warning, then the workflow context. Although it is longer than average, every sentence earns its place, and the second paragraph clarifies the decision workflow rather than padding.

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 tool complexity, missing annotations, and an output schema being present, the description is largely complete: it covers purpose, trigger conditions, side effects, decision workflow, and follow-up. A small gap is that the initially stated trigger conditions emphasize removal ('should lose a component' and 'removed by design') even though the schema supports broader design-change payloads, but the opening 'change of scope or design' mitigates this.

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 high at 83%, so the baseline is 3 even without parameter detail in the tool description. The description does not add parameter-level semantics, but the schema already explains 'kind', 'payload', 'evidence', 'model_id', and 'rationale'. The only undocumented parameter, 'server_version', is left to inference but is not a major burden.

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 object ('Raise a proposal to change a model's scope or design') and immediately distinguishes itself from direct model editing. It even names the sibling tools it interacts with ('decide_proposal', 'list_proposals', 'get_design_leverage'), so an agent can tell exactly what this tool is and is not for.

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 explicit when-to-use guidance: 'Call this when the code or your analysis says the model should gain or lose a component, or that an attacker position or asset should be removed by design.' It also states a key exclusion ('do not edit the model directly for those changes') and delegates decision and outcome-checking to 'decide_proposal' and 'list_proposals'.

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?

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses that the edge enters draft state, runs LLM semantic validation, carries no credit until confirmed, only receives credit when validation returned 'valid', and returns the created edge. This is strong transparency for a creation tool.

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 well-structured and scannable: a front-loaded purpose, a clear two-mode breakdown using backticks and dashes, and no filler sentences. Every sentence contributes either a mode rule, a prerequisite, or a lifecycle fact.

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 complex 7-parameter, two-mode creation tool, the description covers the essential context: mode semantics, conditional parameter usage, workspace scoping, lifecycle behavior, and the return value. It is only slightly incomplete because the required server_version parameter is unexplained and error/idempotency behavior is not addressed.

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 description adds meaningful parameter semantics by mapping modes to conditional parameters: delegated -> source_objective_id, relied_upon -> source_control_id. It also clarifies provider_control_id as the 'credit terminus' and adds a workspace-constraint meaning for provider_model_id. However, the required server_version parameter remains undocumented in both the schema and the description.

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 ('Declare') and a clear resource ('cross-model dependency'), then immediately explains the core concept: this model relies on a provider control. The lifecycle note (draft -> confirm_reliance) also helps distinguish this tool from siblings like list_reliance, confirm_reliance, and delete_reliance.

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 two modes are explicitly defined with conditions for choosing each: delegated means no local implementation and requires source_objective_id; relied_upon means the model has its own control and requires source_control_id. It also states the workspace-scoping prerequisite and the required follow-up step through confirm_reliance, giving concrete when-to-use 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?

With no annotations provided, the description carries the full burden and discharges it well: it discloses the lifecycle ('reads as active until it expires or is revoked'), the record contents (owner, justification, review deadline), and the triage effect (surfaced as accepted, not unaddressed). This adds real behavioral context beyond the bare mutation implied by 'create'. It stops short of covering permissions or revocation mechanics, which keeps it at a 4.

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 paragraphs, front-loaded with the core purpose in the first sentence. Each subsequent sentence contributes a distinct fact — usage condition, lifecycle, triage effect — rather than restating schema fields. It is longer than a minimal definition but 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?

For a mutation tool with six required parameters and zero annotations, the description covers purpose, when to use it, record contents, lifecycle, and downstream visibility; the output schema relieves it of explaining return values. The remaining gaps — who is authorized to accept and what server_version should contain — are minor against the strong selection and invocation guidance.

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 83%, which is high, so the baseline is 3; the description adds collective framing by naming owner, justification, and review deadline as the components of an acceptance and linking review_by to expiry. It does not add per-parameter detail beyond the schema and leaves server_version unexplained, so it does not fully close that gap.

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 — 'Record that an operator explicitly ACCEPTS the residual risk on a control objective instead of mitigating it' — and self-identifies as 'the write counterpart to list_risk_acceptances', which separates it from the read sibling. The behavior is unambiguous and goes well beyond a paraphrase of the title.

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 an explicit trigger condition ('Use when a control objective's residual risk is a deliberate, documented decision rather than an unaddressed gap') and tells the agent to prefer this over leaving accepted risk implicit, citing auditability and the forced review deadline. It names the read counterpart but does not name an alternative tool for the unaddressed-gap case, so the when-not is implied rather than fully explicit.

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses mutation side effects, authorization requirements, HTTP 403 refusal behavior, creation of a decision_request, and the escalation_id. It even warns that this is a judgment call, which is useful context for the agent.

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 compact and front-loaded with the core action, followed by policy, mutation, and failure handling. Every sentence adds information, and there is no filler or repetition of schema details.

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 definition covers purpose, permission precondition, side effects, error behavior, escalation semantics, and follow-up actions. Since an output schema exists, not detailing the return value is acceptable. The agent has enough context to invoke this tool correctly and handle refusals gracefully.

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 80%, so the schema already documents most parameters. The description adds high-level meaning to decision and proposal_id through context like "Accept or reject a proposal," but it does not add details beyond the schema for note, model_id, or server_version. The baseline of 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 opens with a specific verb and resource: "Accept or reject a proposal." It further clarifies the effect with "Mutating: closes the proposal and applies an accepted change," which clearly distinguishes this mutation tool from read-only proposal and work-order siblings.

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 an explicit precondition: "Call this only when the workspace's delegation policy names this decision for this agent at the proposal's tier." It also tells the agent exactly what to do on refusal: report the escalation_id, poll list_proposals, and continue other work, including "Do not retry a refusal."

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly labels the operation as 'Mutating' and states that it 'records this model as a foundation and stores its advertised controls,' plus the downstream consequence that other models can then delegate. It also adds an important semantic rule: capabilities always advertise controls, never objectives. It does not cover permissions or reversibility, but the core behavior is clearly disclosed.

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 well organized: a one-line purpose, a concise mutation/effect paragraph, and an example-backed parameter explanation. Every sentence earns its place, and the most important semantic constraint 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?

The description is largely complete for a mutating tool with an output schema: it explains the mutation, the relationship to delegation, the meaning of provides entries, and the foundation concept. The only notable gap is that the required server_version parameter is left entirely unexplained in both the schema and description, which an agent may need 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 coverage is 75%, so the schema already documents model_id, provides, and visibility, while server_version has no description. The tool description adds real value for the provides parameter by giving a concrete example object and clarifying that each entry advertises one of this model's controls. It also emphasizes that capability entries represent proven controls, not objectives, which prevents misuse.

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, action-oriented statement: 'Mark a model as a shared foundation that advertises providable controls.' It clearly identifies the resource (a model), the operation (declaring/recording it as a foundation), and the purpose (advertising controls). It also distinguishes itself from related sibling tools by referencing propose_attach_foundation and attach_foundation as the follow-up delegation steps.

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 explains that declaring a foundation enables other models to delegate to it, and explicitly points to propose_attach_foundation and attach_foundation for that downstream step. It also clarifies what kind of model qualifies as a foundation via the shared-service examples. It does not explicitly state when not to use the tool, but the cross-tool guidance is strong.

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?

With no annotations provided, the description carries the full disclosure burden and meets it thoroughly. It states the operation is mutating and destructive, that deletion is permanent and not soft-delete, that sufficiency contribution is dropped, that verification is not re-run, and that inherited assertions cannot be removed here.

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 earns its place: the destructive behavior, the side-effect caveat, the intended use cases, the sibling alternatives, and the ownership limitation. The most important warning about permanent deletion is front-loaded in the first sentence.

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 destructive mutation tool with no annotations, the description is complete. It covers use cases, side effects, behavioral nuances, and routing to alternatives, while the output schema handles return-value expectations.

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 80%, so the baseline is 3. The description adds contextual meaning about control versus assumption targets and the ownership restriction, but it does not materially expand on the individual parameters beyond what the schema already says.

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: 'Permanently delete a single assertion from a control or assumption.' It also clarifies scope (own assertions only) and distinguishes itself from related operations by naming submit_assertions and list_assertions as alternatives.

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 explicitly says when to use the tool: to retract erroneous claims or assertions flagged as misaligned by get_verification_report. It also names the add and inspect alternatives and states an important exclusion: inherited assertions must be managed on their source model.

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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states that the operation is destructive/mutating, that it is a soft delete rather than a permanent erase, and that it can block with HTTP 409 under a specific coverage condition. This is substantial and goes well beyond a generic description, though it stops short of covering permissions or reversibility 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 compact and front-loaded: the first sentence states the core action, the second clarifies destructiveness, and the third explains the blocking condition and required remedy. Every sentence contributes necessary operational information with no 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?

Given the tool's moderate complexity and the presence of an output schema, the description covers the essential operational context: what the operation does, its side effects, and the key failure mode. It does not explain server_version semantics or mention any other restrictions, but the core invocation context is sufficiently complete for an agent to use 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 description coverage is 75%, so the schema already documents most parameters. The description adds context about the justification being optional and about the 409 condition, but it does not add meaningful detail for model_id, control_id, or server_version beyond what the schema provides. This is adequate given the high schema coverage.

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: 'Soft-delete a security control,' which immediately distinguishes this from other control-related tools. It also clarifies the semantic nuance ('retired, not permanently erased'), removing ambiguity about the lifecycle impact. This clearly separates it from hard-delete or update operations.

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 clear context for when the tool will succeed or fail, including the HTTP 409 blocking condition and the prerequisite to add a replacement control or refine the threat model. It does not explicitly name alternative sibling tools or state when not to use the tool, but the practical guidance is strong enough to guide invocation correctly.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that member models are not affected, deletion applies only to the grouping wrapper, and systems cannot be deleted through this API. This is meaningful context beyond the tool name.

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 compact and front-loaded with the core action. There is slight redundancy in stating twice that member models are unaffected, but overall it is well-structured and avoids unnecessary detail.

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

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

The description covers the essential operational context for a delete tool: what gets deleted, what does not get deleted, and an explicit unsupported use case. An output schema exists, so return value details are not required. The main omission is the purpose of server_version.

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

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

Schema coverage is only 50% because server_version has no description. The description adds useful meaning to tag_id by explaining tags are 'overlapping, semantics-free grouping,' but it never explains what server_version is or how it should be supplied. The description does not fully compensate for the missing schema detail.

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: 'Delete a tag group' with a clear scoping statement that only the grouping is removed, not member models. It also distinguishes itself from other delete_* siblings by emphasizing that deletion is supported for TAGS ONLY.

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 an explicit when-not-to-use signal: 'Deletion is supported for TAGS ONLY — systems have no delete endpoint on this API.' This prevents misuse on systems, though it does not name a specific alternative tool for system deletion.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses that the operation is destructive, immediate, and permanently removes the edge; explains downstream effects on consumer coverage/posture; clarifies that either model's own controls are unaffected; and states the return value. This is exemplary transparency for a mutating tool.

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 action and destructive nature, then expands into side effects, return value, and usage guidance. Each paragraph serves a distinct purpose with no filler or repetition, and the formatting makes the critical warnings immediately visible.

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 destructive operation, the description thoroughly covers behavior, side effects, return value, and how to obtain the required edge_id. The only meaningful gap is the undocumented server_version parameter, which prevents a perfect score.

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

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

Schema coverage is only 50%; server_version is a required parameter but has no schema description and is not mentioned in the tool description. The description does add useful context for edge_id by saying to find it via list_reliance, but it leaves server_version completely unexplained, so the description does not compensate for the coverage gap.

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 precise verb and resource: 'Delete a cross-model reliance / delegation edge.' It clearly distinguishes this tool from related sibling operations like create_reliance, confirm_reliance, and list_reliance by focusing on removal and stating destructive permanence.

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 explicitly instructs the agent to use list_reliance to find edge_id first, and states that there is no toggle to pause an edge—deletion is the only removal path. This provides clear when-to-use and prerequisite guidance, plus an explicit exclusion for a potential alternative action.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the operation is destructive, permanent, and mutating; enumerates exactly what is removed; explains downstream effects on reliance edges and consumer posture; and documents the return value. This is exemplary transparency.

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 most critical fact ('Destructive and permanent'), then gives a concise but complete list of side effects, followed by usable guidance and the return shape. Every sentence earns its place; no filler or redundant restating of the 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?

The description is highly complete for a destructive operation: it covers permanence, affected data, indirect effects on other models, a backup path, and the response. The only notable gap is the unexplained required server_version parameter, which weakens end-to-end invocability.

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 50%: model_id is described, but the required server_version parameter has no description and no enum or format guidance. The tool description adds nothing about either parameter, so an agent cannot confidently determine what server_version should be.

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: 'Delete a threat model and all associated data.' It sharply distinguishes this from sibling deletion tools by emphasizing the permanent, cascade-deleting scope, so an agent can tell it apart from delete_control, delete_assertion, delete_group, or remove_entity.

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 operational guidance: confirm intent before calling and export an archive if a copy is needed. It does not explicitly enumerate when not to use this tool versus nearby siblings, but the destructive scope and backup advice effectively frame when it is appropriate.

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?

With no annotations provided, the description carries the full burden and does well: it discloses that dismissal is keyed to the current verdict input hash, that dismissals auto-clear when underlying control or objective changes, and that the model itself is not modified. This goes well beyond a generic 'dismiss' statement, though it does not cover auth/permission requirements.

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 dense sentences with no filler. The core purpose and key constraint ('WITHOUT changing the model') are front-loaded, and the hash-keyed auto-clear behavior is explained in one well-placed sentence.

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 no annotations and moderate complexity, the description covers what the tool does, when to use it, its non-destructive character, and the important auto-clearing behavior. The provided input schema covers parameter structure and an output schema exists, so return-value explanation is not needed. A small gap is the lack of explicit alternative-tool routing when the structural model is wrong.

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 about 75%: items, reason, and model_id are described, though server_version is not. The description adds useful framing about coverage vs group_sufficiency row kinds, but it does not materially explain parameter formats or semantics beyond what the schema already provides, so a baseline of 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 states a precise verb and resource: 'Dismiss a set of divergences' and clarifies the semantic meaning ('the structural model was right, the LLM was not'). It also explicitly scopes the tool to coverage and group_sufficiency rows and emphasizes that the model is not changed, which helps distinguish it from model-modifying sibling 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?

The description gives clear usage context: use for rows that have been reviewed and judged not valid, and for the specific case where the structural model is correct. It does not explicitly name alternative tools or state when not to use this tool, but the guidance is strong enough to orient 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?

With no annotations, the description carries full behavioral burden and satisfies it: it discloses LLM gating on identity-bearing fields, the rejected-edit response shape, that nothing is saved on rejection, server derivation of impact, audit-trail capture, and specific 503/502/400 error conditions. This is far beyond a generic 'edit' statement.

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 long but earns its length for a 16-parameter mutation tool: it is front-loaded with the core behavior, then uses bold labels, bullets, and error summaries to make the constraints scannable. There is no filler or repeated schema 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?

Given the tool's complexity, the presence of an output schema, and no annotations, the description covers all decision-relevant behavior: partial-update semantics, LLM gating, audit trail, soft-delete handling, and error conditions. An agent has enough context to invoke it correctly without opening sibling definitions.

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?

Despite 94% schema coverage, the description adds grouping semantics the schema alone does not convey: identity-bearing fields vs factor/notes fields, the no-status-field caveat, the requirement to send change_reason with factor fields, and the impossibility of setting impact directly. It clarifies the relationship between change_reason and the factor/rating 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 opening sentence 'Edit an existing asset. Only provided fields changed' states a specific verb and resource with scope, and the rest clarifies it updates rather than creates (contrasting with add_asset). It is clearly distinct from sibling edit tools for other entity types.

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 explicit routing and preconditions: soft-deleted assets require restore_entity first, rating changes require setting factor values plus change_reason, there is no status field to set, and rejected edits must be handled by soft-delete + add-new. It names alternatives (add_asset, restore_entity) and the conditions that select them.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose one meaningful side effect — editing creates a new model version — which is valuable versioning context that the schema does not state. However, it omits other behavioral traits like the predicate-rewriting semantics and the mutual exclusivity between clear_exclusion and exclusion_* params, both of which remain buried in the schema.

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

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

Two sentences with zero wasted words; the primary operation is front-loaded and the versioning side effect follows immediately. It is efficiently structured, though for a 12-parameter tool arguably under-specified rather than optimally sized.

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 rich 92%-covered schema and the presence of an output schema carry most of the load, so an agent that reads the schema can likely invoke this tool correctly. However, the description alone offers no when-to-use guidance and does not explain the versioned workflow implied by the required server_version param. Adequate but with 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 92%, so the baseline of 3 applies; the schema thoroughly documents the exclusion_* rewrite behavior, defaults, and mutual exclusivity. The description contributes no parameter-level meaning, and notably it does not clarify the one required param without a schema description (server_version), which is a minor missed opportunity.

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?

"Edit an assumption" is a specific verb-plus-resource statement that clearly identifies the operation and, by verb choice alone, distinguishes it from the sibling add_assumption. The second sentence, "Creates a new model version," adds precision about what an edit entails, though the description never explicitly contrasts it with sibling 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?

No guidance is given on when to edit an assumption versus adding one (add_assumption) or converting assumptions to controls (convert_assumption_to_controls). There are no prerequisites, exclusions, or contextual cues beyond the bare operation itself, leaving the agent to infer applicability.

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?

With no annotations, the description carries full behavioral burden and does so thoroughly: patch semantics, LLM gating, server-derived likelihood, quality_warning on contract violations, specific HTTP error conditions, and surface_extent attestation with forking and refusal rules. This goes far beyond a generic 'edit' description.

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 essential edit semantics and dense with useful detail; no filler sentences. The surface_extent paragraph is long and intricate, but it encodes necessary refusal and forking semantics, so it earns its place despite being heavy.

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 17-parameter mutation tool with no annotations and an output schema present, the description covers all non-obvious behavior: patch semantics, gating, error responses, audit trail requirements, and attestation constraints. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 94%, but the description adds critical meaning beyond it: capability must name operations performable from the position, likelihood is server-derived and cannot be set directly, change_reason triggers and error conditions, and surface_extent attestation has deep structural consequences. Without this, several parameters would be ambiguous.

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?

First sentence, 'Edit an existing attacker. Only provided fields changed,' names the exact verb/resource and clarifies patch semantics. It is unambiguously distinct from sibling creation/editing tools and even references add_attacker for the authoring contract.

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?

Provides clear operational context: edits an existing attacker, only supplied fields change, identity fields are LLM-gated, and change_reason is required for factor/surface_extent edits. It does not explicitly contrast with alternatives like add_attacker or edit_asset, but its scope is unmistakable and the 'see add_attacker' pointer helps.

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