Helvabase — Governed response dossiers

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

Annotations already flag this as a mutating, destructive, idempotent operation, so the description does not need to restate that. It adds non-obvious behavioral context: the tool only records an unreviewed metadata description, and file content/upload-related data must go through a separate transport. It could say more about the destructive side effect, but the annotations already surface that risk.

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

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

Two short sentences with no filler. The core action is front-loaded and the critical upload-transport constraint is stated immediately afterward.

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 with no output schema, the description leaves concrete side effects and return behavior unstated, and it does not name the upload transport tool. The rich schema and annotations make the tool usable, but the description alone is not fully self-sufficient.

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 low (33%), and the description only partially compensates: 'unreviewed' maps to the status=missing_review default, and 'version description' clarifies the version object is metadata-only. It does not explain evidenceId or the meaning of the other version fields, so the agent must rely on the schema for those.

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 action ('Record') on a specific resource ('unreviewed evidence version description'), and the phrase 'version description' plus 'unreviewed' distinguishes this from file-upload and evidence-creation tools. The purpose is clear even within a large sibling list.

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

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

The second sentence provides one useful exclusion: file upload, hashes, and storage references require the dedicated upload transport. However, it does not name a sibling tool or explicitly state when to choose this over create_evidence or upload-related alternatives, so usage conditions are mostly implied.

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

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

Annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true. The description adds meaningful behavioral context: it resets evidence review, cannot approve/promote, and requires review scope for change requests. This goes beyond the annotations and helps the agent understand side effects. It doesn't contradict annotations. The only gap is not explaining what 'resets evidence review' means in terms of data loss, but the description is still strong.

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, zero fluff. The first sentence states the core action, the second states critical exclusions, the third states a prerequisite. Every sentence earns its place 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?

For a mutation tool with no output schema, the description covers the key behavioral constraints: what it does, what it doesn't do, and a prerequisite. The nested answer object's semantics are mostly in the schema. It could mention what the response looks like or what 'resets evidence review' implies, but given the annotations and schema richness, this is nearly complete.

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%, with projectId and idempotencyKey having descriptions. The description itself doesn't add parameter-level detail beyond what the schema provides. The nested 'answer' object has enums and defaults in the schema, so the schema carries most of the semantic weight. The description's mention of 'draft answer or request changes' maps to the status/reviewStatus enums, but doesn't explain the relationship explicitly. Baseline 3 is appropriate.

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

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

The description states a specific action ('Save a draft answer or request changes') and clearly distinguishes what the tool cannot do ('cannot approve an answer or promote it to the answer library'). This is clear and differentiates from sibling tools like helvabase_apply_library_promotion or helvabase_confirm_review. However, it doesn't explicitly name a sibling alternative, so it loses a point for not being fully explicit about which sibling to use instead.

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

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

The description gives clear context: this tool is for saving drafts or requesting changes, and it explicitly states when NOT to use it (cannot approve or promote). It also notes that 'Requesting changes requires review scope,' which is a useful prerequisite. It doesn't name a specific alternative tool, but the exclusions are strong enough to guide an agent toward the right choice.

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

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

Annotations already declare read-only and idempotent, and the description adds meaningful behavioral detail: it excludes expired, retired, superseded, and contradicted knowledge, and labels the operation as deterministic. It also communicates that results are suggestions requiring adaptation and review, which is beyond what annotations provide.

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

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

Two front-loaded sentences with no filler: the first states the action, constraints, and bound; the second adds exclusions and the review caveat. Every phrase contributes to selection or correct invocation.

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?

Covers the core workflow: lookup, filtering criteria, determinism, and the need to adapt and review results. It lacks explicit return-format or sorting details, but for a bounded read-only lookup the available guidance is sufficiently complete.

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?

With only 33% schema description coverage, the description compensates by clarifying the limit semantics ('up to 20'), the scope role of projectId ('scope-compatible'), and the question's function ('current requirement'). It still doesn't explicitly describe defaults or phrasing requirements, but adds meaningful meaning beyond the bare schema.

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

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

States a specific verb ('Find'), a bounded result count ('up to 20'), and a clear resource ('reusable answers') with strong qualifying constraints ('current, explicitly approved and scope-compatible'). This distinguishes it from mutation or questionnaire-related siblings by describing a read-only suggestion lookup.

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 workflow context: use it to retrieve reusable answer candidates, adapt them to the current requirement, and then review them separately. It does not explicitly enumerate when to prefer sibling tools or state when-not-to-use cases, but the intended use is 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?

The annotations already signal mutating, destructive, and idempotent behavior, so the description only needs to add context beyond that. It contributes useful behavioral nuance: the tool verifies the existing actor-bound claim approval and current evidence, cannot convert an unconfirmed challenge into approval, and should be preceded by inspection if success is uncertain. It does not describe what is mutated or the response shape, but the main destructive and safety profile is adequately covered.

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, every one serves a role: framing the recovery scenario, naming the required matching values, and adding safety conditions. No filler or redundant restatement of the schema. The guidance is front-loaded with the most important constraint ('Recover after...') and then expands operationally.

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 specialized idempotent recovery tool with five required parameters, the description covers the core preconditions, the safety check, and the inability to confirm unconfirmed claims. It does not mention what the successful response looks like, and there is no output schema to rely on, but for a tool whose main purpose is to resume a known approval after a failure, the essential usage context is present.

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

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

Schema coverage is only 40% for five parameters, so the description should compensate for missing parameter explanations. It does help by mapping 'challenge ID' to confirmationId and 'original exact version' to the revision parameter. However, other parameters such as claimVersionId and projectId never receive complementary explanation, and idempotencyKey's guidance redundant near-fully lives in the schema. The contribution is useful 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 states a specific action: recover and apply an approval after a human confirmation succeeded but its application was interrupted. It also clarifies a key boundary (existing claim approval is required, an unconfirmed challenge cannot be approved), which differentiates this tool from confirm_business_claim_approval and related request/propose tools. It could be even more explicit in saying 'reapply the claim approval' directly, but the recovery context is precise enough.

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 tells the agent when to use the tool: after a human claim confirmation succeeded but application was interrupted. It also gives a clear safety rule: inspect the claim first if application may already have succeeded, and it warns that an unconfirmed challenge cannot be promoted to approval. It stops short of naming an exact sibling tool to use instead, but the guidance still strongly constrains the call 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?

Annotations already mark this as read-only-false, destructive, and idempotent; the description adds valuable context beyond that: it must be the authenticated administrator's exact choice, inferred selections are forbidden, and a changed snapshot invalidates the supplied revision. It does not detail the destructive impact of applying, but given annotation coverage the additional context is solid.

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

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

Three short sentences front-load the core action and then deliver the most important constraints: no inference, fresh selection on snapshot change, and no email or upload. Every sentence earns its place 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?

For a destructive, idempotent mutation with four required parameters and no output schema, the description covers the key prerequisites and exclusions. It would be more complete if it told the agent where selectionId and selectionRevision come from, but the review-then-apply workflow is reasonably inferable from the constraints given.

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%, with selectionId and selectionRevision undocumented in the schema; the description partially compensates by tying them to 'the exact library selection and revision' and warning that a changed snapshot requires a fresh selection. It still does not explain how to obtain these IDs or confirm the relationship between them and the current snapshot, so the added value is moderate.

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 'Apply the exact library selection and revision', a specific verb and resource, and clarifies it must be the admin-reviewed choice rather than an inferred one. This distinguishes the tool from siblings like helvabase_apply_library_promotion and the prepare/inspect/confirm dossier-library-access 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 gives clear behavioral conditions: never apply an inferred selection, and obtain a fresh selection when the snapshot changes. It also removes false prerequisites by stating no email code is needed and no upload is performed, though it does not name the exact sibling tools to use instead.

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

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

Annotations already signal mutation, destructiveness, idempotency, and open-world behavior. The description adds useful context about requiring an existing actor-bound promotion and current evidence, and clarifies that no new approval is inferred. However, it does not disclose what the destructive application actually changes or overwrites, which is a meaningful gap given destructiveHint=true.

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, no filler, with the core recovery scenario front-loaded. Each sentence adds distinct value: when to use, required identifiers/state, and a safety caution about checking for prior success.

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 nearly complete for a retry/recovery operation: it names the triggering condition, required inputs, prerequisites, and a key ambiguity to check before invoking. It could go further by describing what the agent should expect on success or conflict, but with no output schema and annotations already covering mutation/idempotency, the missing detail is not critical.

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?

With only 40% schema description coverage, the description compensates for the two most recovery-critical parameters: confirmationId is explained as the challenge ID, and revision is explained as the original exact revision. The other parameters are either already described in the schema (projectId, idempotencyKey) or reasonably self-evident from the field name (entryId), though entryId lacks explicit elaboration.

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 a specific recovery scenario: resuming a library promotion after a human confirmation succeeded but the application was interrupted. It distinguishes this tool from confirmation and request tools by anchoring it to the 'apply after confirmation' stage and using precise recovery language.

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 when to use the tool (recovery after interrupted application) and gives a strong prerequisite: use the confirmation challenge ID and original revision, and inspect the entry first if application may already have succeeded. It does not name sibling tools explicitly, but the when/when-not conditions are clear enough to route an agent 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?

The annotations already mark the tool as non-read-only, idempotent, and destructive; the description adds useful process context such as 'no server LLM', persistence of existing gates, and the boundary that original Office/PDF forms are not created or signed. However, it does not explicitly disclose what is destroyed or overwritten by reassembly beyond the word 'Reassemble', so the destructive effect is only implied.

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 main purpose in the first sentence and every subsequent sentence adds a distinct, non-redundant constraint: prerequisites, internal-content exclusion, gate rules, timing, and boundary with document-pack tools. 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 complex mutating tool with no output schema, the description covers many operational aspects (prerequisites, exclusions, gates, alternatives), which is strong. It is incomplete, though, on how the required revision parameters are obtained or what the tool returns after assembly, leaving an agent without the full picture needed to invoke it confidently.

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%, with expectedRevision and expectedDraftRevision lacking descriptive text. The description does not explain how to construct these objects or what payloadHash/outputJobId refer to; it only mentions 'dossier revision' in passing. It adds little semantic value beyond what the input schema already states.

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

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

The description names a specific action ('Assemble') and a specific resource ('all mapped buyer-facing text fields into the existing sourced draft workflow'), plus a distinctive constraint ('without a server LLM'). It explicitly contrasts itself with document-pack tools by saying it does not create or sign original Office/PDF forms, which differentiates it from siblings like produce_document and export_document_pack.

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 a clear precondition ('Requires complete section coverage'), exclusion criteria ('Internal knowledge, opportunity notes without buyer audience, strategy and audit stay internal'), and timing ('Reassemble after any dossier revision before final review'). It also names the alternative family ('use document-pack tools with exact original targets') when the task is creating or signing original forms, making the when/when-not decision 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with an explicit guarantee: 'This read cannot change policy.' It also adds domain behavior by explaining server-required prerequisites. This goes beyond the annotations by clarifying the policy-inspection semantics without contradicting any hint.

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 provides prerequisite context, and the third explicitly guarantees non-mutation. Every sentence earns its place 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 single-parameter read-only inspection tool, the description is complete. It names the inspected resource, the server-required prerequisites, and the read-only guarantee. The absence of an output schema is not a major gap because the tool's purpose is to expose BID steps and the annotations already cover safety behavior.

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

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

The input schema covers the only parameter, projectId, at 100% with a clear description. The tool description adds no additional parameter semantics, which is acceptable because the schema already documents what projectId means and its constraints. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Inspect this dossier's server-required BID steps.' It clearly says this is a read operation and differentiates itself from mutation siblings like helvabase_request_bid_decision and helvabase_confirm_bid_decision by stating 'This read cannot change policy.' The agent immediately knows what the tool does and what it is not.

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 concrete when-to-use context: new dossiers must have qualification, an exact human bid decision, and a current clear control report before final review or submission. This tells the agent when inspecting BID steps is relevant. It does not explicitly name alternatives or exclusions, but the workflow context is strong enough.

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

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

The description adds useful behavioral context beyond annotations: 'Deterministic' and 'tied to the original analysis revision' clarify idempotency and revision binding, while 'human review remains required' signals a safety check. These traits are not present in the annotations, which only indicate destructive/idempotent hints. The description complements rather than contradicts the annotations.

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

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

The description is exceptionally concise—two sentences with no filler. It front-loads the primary action and quickly covers key characteristics (determinism, revision binding, human review). Every word contributes meaning, making it easy to parse quickly.

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 a nested pricing object, three required parameters, and no output schema, the description is too thin. It does not explain how to structure the pricing data, what 'approved claims' maps to (likely selectedClaimVersionIds), or when to call this versus related review tools. The annotations provide some safety context but not enough to allow correct invocation without further schema inspection.

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% (two of three parameters have descriptions), yet the description does little to clarify the parameters, especially the complex 'pricing' object. It mentions 'pasted prices' which hints at pricingText, but does not explain the structure or required fields. The idempotencyKey is described in the schema but not reinforced. The description adds minimal semantic value 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 clearly states the action ('Prefill a review artifact') and its sources ('from the current analysis, pasted prices and approved claims'). It also adds distinguishing characteristics ('Deterministic and tied to the original analysis revision') that set it apart from vague alternatives. This is specific and unambiguous, effectively differentiating it from the many 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or alternatives, leaving the agent to infer context from the name and action alone. The note about human review being required is a behavioral constraint, not a usage guideline.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description adds the clarification that it 'Does not call a model or approve final delivery', which is additional behavioral context beyond annotations. However, it does not elaborate on the destructive nature (what gets overwritten) or idempotency semantics. Given the annotations, the bar is lower, and the description provides some extra clarity but not comprehensive 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 two sentences with no fluff. The first sentence defines the core purpose, and the second adds important constraints. It is front-loaded and every word serves a purpose. No redundancy or 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 tool has 3 parameters, no output schema, and annotations present. The description mentions the prerequisite ('ready autofill artifact') and clarifies what it doesn't do. It doesn't describe the return value or post-assembly steps, but since there is no output schema, that is not required. It could mention that the draft is not final or that it requires a valid current analysis, but overall it is sufficiently complete for an agent 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%: projectId and idempotencyKey have good descriptions, but title lacks any description. The tool description does not mention any parameters or compensate for the undocumented title parameter. Since coverage is below 80%, the description should add meaning for uncovered params but does not, leaving title's purpose 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?

The description states a specific action: 'Assemble a commercial deck review draft from a ready autofill artifact'. It also clarifies what it does not do ('Does not call a model or approve final delivery'), distinguishing it from related tools like build_autofill or submit_draft. The verb 'assemble' and the resource 'commercial deck review draft' give precise meaning.

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

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

The description implies usage after an autofill artifact is ready ('from a ready autofill artifact'), indicating it should be used after build_autofill. It also notes it does not approve final delivery, hinting that confirmation/submission tools are separate. However, it does not explicitly name alternatives or say when not to use it, so it lacks explicit exclusions, leaving room for improvement.

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?

Beyond the annotations, the description adds two concrete behavioral guarantees: it preserves the original analysis revision and never calls a drafting model. This is useful and does not contradict destructiveHint=true, since the operation may still overwrite an existing matrix while leaving the analysis revision intact.

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

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

Two tight sentences with no filler; the core purpose is front-loaded and the two behavioral caveats are packed into the second sentence without burying the main point.

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 and schema are adequate for a basic call, but with no output schema the return behavior is unstated, and the destructiveHint=true annotation leaves whether an existing matrix is overwritten to inference. It also does not explain how the optional CSV/TSV maps to matrixText or how selectedClaimVersionIds interacts with the dossier analysis.

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%: projectId and idempotencyKey are documented, while the nested matrix object is not described at the property level. The description hints that matrixText can hold pasted CSV/TSV content, but it does not explain title, sourceFileName, or selectedClaimVersionIds beyond their schema constraints.

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

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

The description states a specific action ('Build') on a specific resource ('review matrix') with clear inputs ('current dossier analysis and optional pasted CSV/TSV'). This distinguishes it from read-oriented siblings like read_compliance_matrix and change-request tools such as request_matrix_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 first sentence makes the context explicit: use this when constructing a matrix from the current dossier analysis, optionally incorporating pasted CSV/TSV data. It does not name alternatives or exclusions, but the build-vs-read distinction is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'Read' is consistent. It adds some context about returned fields and the historical nature of versions, but it does not disclose error conditions, authorization needs, or any constraints around the version history.

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 no filler. The action and resource are front-loaded, and each sentence adds distinct value: what is read and how history behaves.

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

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

For a simple read tool with two required parameters and strong read-only annotations, the description is mostly complete: it identifies the resource, output facets, and history semantics. It leaves the exact meaning of 'blockers' and how to obtain claimVersionId implicit, but those gaps are minor for this operation.

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?

projectId is well described in the schema, but claimVersionId has no schema description. The description only indirectly identifies claimVersionId via 'exact version,' providing modest additional meaning. With 50% schema coverage, the description does not fully compensate for the undocumented 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?

Uses the specific action 'Read' with a clear resource: 'an exact version proposed through the controlled claim workflow.' It also lists what is returned (proof, scope, validity, blockers) and the closing phrase 'Historical versions remain history' differentiates it from a current-claim reader like read_business_claim.

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

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

The description clearly implies this is for reading a specific historical version within the controlled claim workflow, and 'Historical versions remain history' signals it is not for current claim data. It does not explicitly name the alternative read_business_claim or state when-not-to-use, but the context is clear enough.

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?

Beyond the read-only annotation, the description discloses that the read never grants access or creates a collection, that a collection auto-selects only when exactly one is writable, and that ingestion is separate. These are meaningful behavioral traits not already encoded in the annotations or 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?

The description is compact: a clear lead sentence states the primary purpose, followed by two terse sentences explaining selection behavior and the tool's read-only constraints. There is no filler or redundancy, 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?

For a simple one-parameter read tool without an output schema, the description covers purpose, selection semantics, side-effect boundaries, and how ingestion relates. It does not describe the response format, but given the low complexity and rich annotations, this is a minor omission.

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

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

The input schema already fully documents the single projectId parameter, including its pattern and meaning, with schema description coverage at 100%. The tool description adds no material parameter semantics beyond referencing 'this dossier,' so it relies on the schema and warrants the baseline 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: 'List the existing business-library collections this dossier can write to,' immediately establishing what the tool does and its scope. It also distinguishes itself from siblings by tying the operation to a dossier's writable collections rather than generic library lists.

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

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

The description gives clear guidance on when to use the tool: to list collections a dossier can write to and select one authorized by the responsible person. It explicitly excludes access-granting and collection creation, though it does not name alternative sibling tools; the situational boundaries are still clear.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context about the state-dependent behavior and the boundary of what cancellation can accomplish. It explains the business rule that prevents cancelling dispatched imports, which annotations do not convey. Minor missing detail: no description of what occurs on a successful cancellation, but the key behavioral constraints are 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?

Two sentences with front-loaded action and condition. No fluff. Each sentence earns its place by providing the key rule and the exclusion. Highly concise and structured for quick comprehension.

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 simplicity of the operation and presence of annotations and schema descriptions, the description covers the essential decision logic: what can be cancelled and what cannot. It doesn't explain how to determine dispatch status or describe return values, but no output schema exists and those details are likely in related tools. Slightly more detail about the cancellation effect would elevate it, but it's adequately complete for an agent to make a safe first call.

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%, with projectId and idempotencyKey already documented in the schema. However, importId has no schema description. The tool description does not compensate for this gap, nor does it add any parameter-specific meaning. Baseline is moderate because the schema covers most parameters, but the description could have at least clarified that importId identifies the specific upload to cancel.

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 ('Cancel') and resource ('source upload'), with a clear precondition ('only if it has not been dispatched'). It goes beyond simply restating the tool name and effectively distinguishes this cancellation flow from the reconciliation path.

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: only if the upload has not been dispatched. It also states when not to use and what to do instead: uncertain or dispatched imports must be reconciled and cannot be released by cancellation. This gives clear routing guidance even without naming a specific sibling 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?

Annotations already signal a non-read-only, idempotent, destructive mutation, and the description adds substantial behavior beyond that: zero-based character spans, persistence semantics, the irreversible adoption of prior fields and section targets, the need for a fresh clear report on draft changes, and the explicit statement that checks remain bounded and never confer human approval. No contradiction with the annotations.

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

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

The description is five dense sentences with no filler, and it is front-loaded: purpose first, then critical semantics, then lifecycle constraints and boundary conditions. Every sentence carries load-bearing 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?

This is a complex five-parameter mutation with nested objects and no output schema, so the description carries a heavy burden. It covers purpose, location semantics, and lifecycle well, but it never states the response/return shape or how to populate `revision` beyond referring to the 'exact current draft'. It is adequate for tool selection but not fully self-sufficient for a correct first invocation.

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

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

With schema description coverage around 40%, the description compensates for some gaps by explaining expectedReportRevision ('Echo ... null initially') and locations ('zero-based character spans of persisted text'). However, the `revision` object, `fields[].source`/`marker`, and the mapping between the `field` enum values and the mentioned check categories remain undocumented, so compensation is only partial.

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: 'Persist checks against the exact current draft and explicit text spans' for support gaps, repeated commercial values, and validity dates. It also references helvabase_draft_checks as the source of expectedReportRevision, helping distinguish this write-side operation from the related read-side 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 clear situational context: expectedReportRevision must be echoed from helvabase_draft_checks, and lifecycle constraints are explicit ('Once adopted... cannot be omitted', 'a changed draft needs a fresh clear report'). It stops short of a full 5 because it does not enumerate alternative tools or explicit when-not-to-use cases.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'authorized workspace' scoping, which is useful context beyond the annotations. However, it doesn't disclose pagination behavior, whether resolved contradictions are included by default, or what the response shape looks like—though the includeResolved parameter partially covers that.

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

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

One sentence, front-loaded with the verb and resource, and it includes the workspace scoping. It is concise and readable, though it could have added a brief note about the includeResolved parameter without becoming verbose.

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

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

For a read-only list tool with four self-explanatory parameters and no output schema, the description is adequate but not complete. It doesn't mention pagination defaults, the resolved-filtering behavior, or what fields the returned contradictions contain. An agent could call it correctly, but it would have to rely on the schema and parameter names for full understanding.

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

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

Schema description coverage is 0%, so the description carries the burden, but it only mentions 'a claim' and 'the authorized workspace,' which maps to claimId but not to limit, offset, or includeResolved. The parameter names and defaults in the schema are self-explanatory, but the description adds no meaning beyond what the schema already shows. Baseline 3 is appropriate given the schema is fairly clear.

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 ('Inspect') and resource ('recorded contradictions for a claim'), and scopes it to 'the authorized workspace.' It clearly distinguishes from mutation tools like helvabase_resolve_contradiction, though it doesn't explicitly name that 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 implies a read-only inspection use case and the workspace scoping is stated, but it doesn't explicitly say when to use this over alternatives like helvabase_resolve_contradiction or helvabase_read_business_claim. The context is clear enough for an agent to infer usage, but exclusions are not stated.

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

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

Beyond the annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false), the description adds valuable behavioral detail: it never contacts Helvabase, writes a new file (locally), and separates byte return from human approval. It also instructs hash verification. These specifics give the agent a clear picture of side effects and operational constraints that annotations alone do not capture.

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 yet informative, front-loading the core purpose in the first sentence and then layering essential usage details. Each sentence adds value: precondition (after reading assignment), behavior (preserves profile, writes new file, never contacts Helvabase), workflow (separate operations), and security (verify hash). No wasted words, and structure is logical.

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

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

For a parameterless tool with no output schema, the description is complete: it explains what is returned (executor, hash, format), how to use it (through file tools after reading assignment), and any caveats (verify hash, separate operations). It also covers prerequisites and security steps, leaving nothing crucial missing for an agent to call it correctly.

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

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

With zero parameters, the description does not need to explain parameter meanings. The baseline score of 4 is appropriate because the tool has no inputs and the description focuses on outputs and usage. It does not redundantly describe parameters, but it could have briefly mentioned that no arguments are required, though that is already implied by 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 clearly states the tool's function: to retrieve an optional standalone local file executor along with its SHA-256 hash and task format. It uses a specific verb ('Get') and names the resource, distinguishing it from the many sibling tools focused on other operations. It leaves little ambiguity about what the agent can expect to obtain.

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 contextual guidance on when to use this tool: after reading the assignment and through the customer assistant's file tools. It also mandates verifying the download hash before execution. However, it does not explicitly mention alternatives or situations where this tool should not be used, leaving room for the agent to infer the exclusion 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?

The description goes beyond annotations by explaining the one-time nature of the code, the strict binding to the original context/actor, and the fact that gaps are preserved and final contents are not approved. This complements the destructive/idempotent hints rather than repeating them. No contradiction with readOnlyHint=false or destructiveHint=true.

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

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

Three short sentences, front-loaded with the main action, followed by security constraints and a consequence clause. Every sentence adds information; 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?

For a 4-parameter mutation with a nested object and no output schema, the description covers purpose, authorization, rejection conditions, and outcome boundaries. It doesn't describe return values or detailed error cases, but the annotations and schema cover idempotency and retry behavior.

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 gives meaningful operational meaning to 'code' (one-time, reviewer-supplied, never retrieve) and implies constraints on challengeId/actor. However, it does not explain decisionRevision's outputJobId/payloadHash or how to obtain them, and schema coverage is only 25%, so it only partially compensates.

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 ('Confirm'), a precise resource ('exact proposed bid decision'), and the mechanism (one-time code from reviewer). It is clearly distinct from sibling tools like request_bid_decision or confirm_review, and the closing clause clarifies it does not approve final contents.

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 conditions use on a reviewer-supplied one-time code and instructs the agent never to retrieve it. It also gives rejection criteria (changed context/qualification, other actors, old codes), which tells the agent when not to invoke. It doesn't name an alternative tool explicitly, but the context is clear enough.

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

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

Annotations already declare destructive, idempotent, not read-only behavior, so the description doesn't need to restate those. It adds meaningful context: it rechecks 'proof and current versions' and that a changed statement/proof cannot reuse the decision, which gives the agent a guard against blind confirmation. This goes beyond what the annotations say.

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

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

The description is short and front-loaded, covering the main action, required constraint, rechecks, and exclusion in four sentences. It earns its place with no filler, though it could be slightly tighter if it directly named the sibling to disambiguate 'apply' but the brevity remains effective.

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?

This is a destructive, idempotent mutation with six required parameters, no output schema, and sparse parameter semantics. The description gives the core decision logic but does not mention what happens on success/failure, what is destroyed, or how to relate the parameters to the workflow. Because of the tool's nontriviality, more explanation around expected outcomes and exact call prerequisites would be needed for full completeness.

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

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

Only two of six parameters have schema descriptions (33% coverage), so the description should compensate. It adds meaning to 'code' by saying it is the reviewer-supplied value and hints that 'current versions' relate to the versioning parameters, but it does not explain claimVersionId, revision, or challengeId in enough detail for an agent to confidently map them without outside knowledge.

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 very specific verb and resource: 'Approve the exact sourced business claim'—with a strong qualifier distinguishing the approval from library/dossier approval. It also embeds the key constraint that only the reviewer-supplied code may be used, which uniquely separates it from other approval-related siblings and gives an agent a precise mental model.

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

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

The description clearly says the code must come 'explicitly supplied by its reviewer,' implying this is the confirmation step after a reviewer provides code. It also says that if proof or current versions change, the decision cannot be reused, and explicitly separates this from library/dossier approval. It doesn't, however, name the 'apply' sibling to distinguish them beyond the separation from library/dossier.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds behavioral context: 'Edits invalidate affected approvals and the assembled draft' – this explains a side effect of edits on the review state, which is not covered by annotations. It also warns against retrieving emails or inventing codes, which are operational cautions. This goes beyond the annotations and helps the agent understand consequences.

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

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

The description is two sentences, front-loading the core purpose first and adding cautions second. Every sentence contributes: the first states what it does, the second provides behavioral caveats. It is concise without unnecessary fluff, though it could add more detail on parameters if space allowed.

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?

This is a complex operation with 7 required parameters, nested objects, and no output schema. The description provides only the purpose and a couple of cautions; it does not explain the meaning of key parameters (expectedRevision, fieldIds, includeDefinition, challengeId) or how the code should be obtained and validated. Given the complexity and low schema coverage, the description is insufficient for an agent to correctly invoke the tool without further 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 only 29% (only projectId and idempotencyKey have descriptions in the schema). The tool description does not explain any parameters, not even the 'code' mentioned in the purpose, nor expectedRevision, fieldIds, includeDefinition, or challengeId. With such low coverage, the description should compensate but fails to do so, leaving agents to guess the meaning and relationships of the required parameters.

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

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

The description states a specific action ('Confirm an exact contribution review') with a clear resource ('contribution review') and a distinctive mechanism ('code supplied by the authenticated human reviewer'). It distinguishes itself from other confirm_* tools by specifying 'contribution review' and 'exact', though it does not explicitly name alternatives. The purpose is unambiguous and not a tautology.

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

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

The description implies when to use it: when a human reviewer has supplied a code to confirm a contribution review. It also gives a caution ('Do not retrieve the human's email or invent a code'), which guides appropriate use. However, it does not state when NOT to use this tool or mention alternative tools (e.g., helvabase_confirm_review for generic reviews). This leaves some 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?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds meaningful context: it records a confirmation, depends on a code, and that changes invalidate the request – that's a non-obvious failure mode. It also discloses an operational constraint (never read mailbox). This goes beyond the annotations without contradicting them, providing useful behavioral insight.

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 fluff. The core action is front-loaded, and each sentence adds critical information: what it does, how to get the code (do's/don'ts), and conditions for validity. Efficient and well-structured.

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 4 required parameters (including a nested object), no output schema, and light annotations, the description covers the essential purpose and constraints but omits details like what payloadHash represents, what outputJobId points to, and what 'deterministic blockers' specifically are. It is adequate for a basic call but not fully complete for a complex mutation tool.

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

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

Schema description coverage is only 25% (only idempotencyKey has a description). The tool description partially compensates: it explains the 'code' parameter ('the code the reviewer supplies') and implies 'arbitrationRevision' corresponds to the proposed interpretation. However, it does not clarify challengeId or the nested outputJobId/payloadHash structure, leaving significant gaps. The description adds some semantic value but not enough to fully offset 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 states a specific verb and resource: 'Record the authenticated reviewer's email confirmation for the exact proposed interpretation.' It clearly identifies the action (recording a confirmation) and the object (a proposed interpretation), and distinguishes this tool from its sibling 'request_control_arbitration' by its confirmatory nature. It is unambiguous and specific, earning a full score.

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 operational guidance: 'Use only the code the reviewer supplies after inspecting the questions. Never read their mailbox or provide their code.' It also conditions validity with 'Changes to the report, source context or draft invalidate the request; deterministic blockers remain.' While it does not explicitly name alternatives (e.g., request_control_arbitration), it clearly implies the confirmation context and provides clear do's and don'ts. The absence of explicit 'when not to use' keeps it from a 5.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds the important note that 'Changes invalidate the receipt', which aligns with idempotency and clarifies that modifications void the operation. However, it does not explain what constitutes a 'receipt' or what happens on success/failure, and it does not mention permission or prerequisite 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 concise, with two sentences that front-load the purpose and add a critical constraint. Every word earns its place, and it avoids redundancy. However, it is almost too terse, omitting necessary details for a mutation with five 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?

With five required parameters, a nested object, no output schema, and minimal parameter descriptions, the description leaves significant gaps. It does not explain the revision structure, the challengeId meaning, or how the code is obtained, and it lacks failure handling or return value expectations. The invalidation note is helpful but insufficient for a complete calling 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 only 20% (only idempotencyKey has a description). The description mentions 'code' implicitly but does not explain the role of itemId, revision, challengeId, or code beyond the vague reference. It provides almost no added meaning for the parameters, forcing the agent to rely entirely on the schema for parameter semantics.

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 the action ('Record one file review') with a specific constraint ('using the code explicitly provided by the reviewer') and clarifies what it does not do ('No inferred approval, signature or buyer submission'). It is clear about the core purpose but does not differentiate from sibling confirm_* tools like confirm_review or confirm_contribution_review beyond the word 'file'.

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 use this tool versus alternatives. The description does not mention a paired request tool (e.g., request_document_review) or any context for selecting it. The only hint is 'using the code explicitly provided by the reviewer', which implies a specific workflow but does not explicitly state when to choose this over other confirm 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?

The description provides substantial behavioral context beyond the annotations. It details invalidation conditions, atomicity of permissions/code consumption/audit, revocation effects on cached receipts and authenticated downloads, and a clear exclusion (does not alter direct workspace memberships). This goes well beyond the simple readOnlyHint/destructiveHint/idempotentHint annotations, giving the agent a precise mental model of side effects.

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 and front-loaded. The core purpose is stated in the first sentence, followed by three sentences of high-value constraints and side effects. There is no filler; every sentence adds distinct information about invalidation, atomicity, revocation, and scope.

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 behavioral aspects well, but it is incomplete for an agent to correctly invoke the tool. It does not explain the relationship to the request step (request_dossier_access_confirmation), what 'preview' refers to, or the meaning of proposalId and challengeId. Since there is no output schema and schema coverage is low, the description should carry more weight for parameter context, which it does not.

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 20% (only idempotencyKey is described). The description mentions the 'code' as the one supplied by the human, and 'revisions' as an invalidation factor, but does not clarify proposalId, challengeId, or revision semantics. With low schema coverage, the description fails to compensate by explaining what each parameter represents, leaving the agent to infer meaning from names alone.

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

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

The description states a specific action: 'Apply precisely the preview confirmed by the human using only the code THEY supplied.' It clearly indicates this tool applies a human-confirmed access grant based on a code. It also includes a scope limitation ('This does not alter direct Snipara workspace memberships') that helps differentiate from some siblings, though it does not explicitly name 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 implies this is the confirmation step after a human preview, and notes conditions under which the code is invalid (changed memberships, permissions, revisions, expired codes). However, it never explicitly states when to use this tool versus alternatives like request_dossier_access_confirmation or apply_dossier_library_access. The guidance is implied rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context beyond these: it requires an exact code supplied by the reviewer, warns that stale revisions fail, and states that no approval is inferred from conversation. This is meaningful additional behavioral disclosure about the confirmation mechanism and failure conditions.

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, each earning its place. The first sentence states the action and its critical requirement (exact code). The second sentence states a failure condition. The third sentence states a critical exclusion. No wasted words, and the most important operational 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?

For a confirmation tool with 6 required parameters, the description covers the key operational context: what code to use, that stale revisions fail, and that approval isn't inferred. The annotations cover idempotency and destructive behavior. The description doesn't explain the exact relationship between 'revision' and 'code' parameters, but the core usage context is adequately covered. An output schema is absent, but for a confirmation action the description's coverage is reasonable.

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 33%, with descriptions present for projectId and idempotencyKey. The description itself doesn't explain the 'code' parameter's format or meaning beyond 'code explicitly supplied by the reviewer', which is useful but minimal. The 'revision' parameter's purpose (identifying the exact version to approve) is implied by 'Stale answer/proof revisions fail' but not explicitly documented. The description adds some semantic value but doesn't fully compensate for the 67% of parameters lacking schema descriptions.

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 ('Approve') and resource ('this exact reusable answer'), and clarifies the scope ('using only the code explicitly supplied by the reviewer'). It distinguishes itself from the sibling 'helvabase_apply_library_promotion' by emphasizing confirmation with a code, though it doesn't explicitly name that sibling. The phrase 'Stale answer/proof revisions fail' adds a clear constraint that helps an agent understand the tool's purpose.

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

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

The description gives clear context for when to use this tool: after reading the complete promotion and receiving a code from the reviewer. It also states what not to do ('No approval is inferred from the conversation'), which is an explicit exclusion. However, it doesn't explicitly name alternative tools like 'helvabase_apply_library_promotion' or 'helvabase_request_library_promotion', so the when-not-to-use guidance is implied rather than 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?

Annotations indicate destructiveHint=true and readOnlyHint=false, so the agent is warned that this is a mutating operationhol, but the description adds crucial context: it explicitly states it does not sign or submit to the buyer. This provides clarity on the side effects of the operation beyond the annotations. However, it doesn't disclose what happens after confirmation (e.g., does it persist data?) or any irreversible effects, leaving some behavioral questions unanswered.

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

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

The description is two short sentences. The first sentence states the action and requirement, the second warns against misuse. Every word is purposeful, no fluff. The critical warning is front-loaded and 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 tool's complexity (7 required params, nested objects), the description is highly effective in conveying the core purpose and the most critical constraint (the code). It does not detail the document structure, but the schema provides that, and the description's focus on the 'exact complete pack' hints at the need for completeness. The lack of output schema is not an issue as the description clarifies the action's non-signing side effect. Overall, it covers the essential decision-making information.

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 extremely low (14%), with only idempotencyKey having a description. The description itself does not explain individual parameters, but it emphasizes the critical meaning of 'code' – that it must come from the final reviewer and not be reused from other contexts – which is essential for correct usage. Given the low coverageional overload, the description compensates by highlighting the most error-prone parameter. However, it doesn't explain the 'documents' array structure or 'selection' semantics, which might be inferred from siblings but are not explicitly addressed.

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 ('Confirm'), the resource ('exact complete pack'), and the required authorization ('final reviewer's explicitly supplied code'). It explicitly distinguishes itself from the sibling 'helvabase_confirm_plan_agreement' by noting it is not a plan agreement and from 'helvabase_confirm_review' by stating it does not sign or submit. This clearly separates it from similar confirmation 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 provides explicit guidance: 'Never reuse a plan-agreement or individual-file code' – this tells the agent when NOT to use this tool. It also implicitly implies it should only be used when the final reviewer has supplied a code. The exclusion of signing/submitting clarifies that this step is for internal confirmation, not for finalization, which helps the agent decide between this and other confirmation steps.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds important behavioral context: that this is a one-time code, the conditions for failure, and that it is not final approval. However, it does not clarify the destructive nature (what is destroyed) or that idempotency is supported even though the idempotencyKey parameter hints at it.

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

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

The description is just two sentences, front-loaded with the core action and constraints narrowed to the essential rules. Every sentence adds value 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?

For a complex confirmation tool with nested objects, no output schema, and only 20% parameter coverage, the description covers the core usage and failure conditions. It does not explicitly tie parameters together, but the overall context of plan agreement is sufficient. Slight gap in explaining why idempotency matters despite the annotation.

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 20% (only idempotencyKey has a description). The main description explains the code is one-time and tied to the exact plan, which adds meaning to the code, revision, selection, and challengeId. It doesn't detail each parameter, but the high-level description plus the idempotencyKey description partially compensate.

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 confirms a production agreement using a one-time code, and explicitly distinguishes it from final content approval or signature. It is specific with verb, resource, and mechanism, and stands apart from sibling confirm tools by focusing on plan agreement.

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 conditions for use (only with explicitly supplied code after reviewing this exact plan) and explicitly states what fails (changed plans, other actors, expired codes, replays). It does not name a specific alternative tool, but the pair with request_plan_agreement is implied.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the agent knows this is a mutating, idempotent operation. The description adds valuable context: it records email-confirmed authorization (not a legal signature), and that old revisions, changed sources, expired codes, and replays are rejected. This goes beyond what annotations provide and clarifies the safety and validity constraints without contradicting the annotations.

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

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

The description is three sentences with no wasted words. It front-loads the primary action and then provides critical constraints and context. Each sentence earns its place: the first states what the tool does, the second warns against unethical code acquisition, and the third clarifies rejection conditions and the non-legal nature. It is appropriately sized for the tool's 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?

For a tool with four required parameters, a nested object, and no output schema, the description covers the essential aspects: the purpose, the code source, rejection conditions, and the non-legal nature. It does not explain the 'challengeId' parameter, which could be a session or challenge identifier, but given the schema also lacks a description, this gap is not entirely the description's fault. Overall, it provides enough context for an agent to understand the tool's role and constraints.

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 25% (only idempotencyKey has a description). The description adds meaning to two parameters: 'code' (one-time code supplied by reviewer) and 'revision' (exact revision). However, it does not explain 'challengeId' at all, which remains ambiguous. While it partially compensates for the low coverage, it leaves one parameter unexplained, so it does not fully bridge the 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 clearly states the action (record confirmation), the object (reviewer's explicit confirmation), and the specific mechanism (one-time code supplied by the reviewer). It also distinguishes this from sibling tools by specifying 'review' and 'this exact revision', which differentiates it from other confirm_* tools like confirm_contribution_review or confirm_document_review.

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

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

The description gives clear context on when to use the tool: after the reviewer inspects the exact revision, and it explicitly prohibits inventing, searching for, or reading the code from the mailbox. It also mentions rejection conditions (old revisions, changed sources, expired codes, replays), which help the agent understand when not to use it. However, it does not explicitly name alternative tools or provide an explicit 'when-not-to-use' statement beyond the rejection criteria.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds meaningful behavioral context: it refuses overwriting existing work, preserves immutable history, requires approved source references, and clarifies that assistant submissions never claim human authorship. It also mentions revision protection and idempotency through the expectedRevision parameter. These go beyond the annotations and give the agent concrete expectations about mutation 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 six sentences, each carrying meaningful content: purpose, prefill behavior, authorship constraints, attachment requirements, dependency resolution, and immutability. It's front-loaded with the core purpose. The sentences are dense but not bloated. Could be slightly more concise, but every sentence adds value for correct usage.

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 (nested changes array, expectedRevision object, 4 params, 50% schema coverage, no output schema), the description covers the critical usage constraints: prefill vs replace, overwrite refusal, immutable history, source ID requirements, and dependency resolution. It doesn't explicitly state what the return value is, but since there's no output schema and the focus is on mutation behavior, this is acceptable. The description is sufficient for an agent to understand the mutation's semantics and constraints.

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%: projectId and idempotencyKey have descriptions in the schema, but expectedRevision and changes do not. The description adds value by explaining the overall semantics: prefill vs replace intent, revision protection, and immutable history, which clarifies the purpose of expectedRevision. However, it doesn't explicitly explain the structure of 'changes' array items beyond what's in the schema, but the description's context about provenance and source markers helps interpret evidenceRefs and intent. The description partially compensates for the missing schema descriptions.

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 'Save' with the resource 'field contributions' and elaborates on the mechanism: provenance, source markers, comment and revision protection. It also distinguishes this from generic save operations by mentioning prefill/overwrite refusal semantics. It clearly differentiates from siblings like helvabase_assemble_contributions or helvabase_confirm_contribution_review by focusing on saving field-level contributions with specific constraints.

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 to use this tool: 'Use prefill for empty fields; it refuses overwriting existing work.' It also states that 'Assistant submissions never claim human authorship or approval' and 'Attachments must reference an approved source ID.' However, it doesn't explicitly name alternative tools or state when NOT to use this tool in favor of a sibling. It implies usage context (when contributing to a dossier) but lacks explicit exclusions or alternative references.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond annotations: new dossiers receive a server-required BID policy, and returned IDs must be reused. It also warns about required steps before final review/submission. This is meaningful behavioral disclosure that complements the annotations.

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

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

Three sentences, all informative. The core purpose is front-loaded, followed by the BID policy constraint and the ID reuse instruction. No wasted words, though the BID policy sentence is dense and could be clearer.

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 creation tool with no output schema, the description covers the key behavioral requirements: BID policy, ID reuse, and next-step inspection. It doesn't describe the return value shape, but the 'Returned IDs must be reused' implies an ID is returned. Given the tool's complexity and the lack of output schema, this is reasonably complete, though it could mention what the response contains.

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 25% (only idempotencyKey has a description). The description doesn't explain the 'name', 'slug', or 'description' parameters beyond what the schema provides. The idempotencyKey guidance in the schema is already detailed, and the description's 'Returned IDs must be reused' is about the response, not parameters. With low coverage, the description could have compensated but doesn't.

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: 'Create a current RFP/client dossier in this workspace.' This clearly distinguishes it from sibling tools like helvabase_list_dossiers or helvabase_contribute_dossier. However, it doesn't explicitly name a sibling alternative, so it doesn't fully earn a 5.

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

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

The description provides clear context: it's for creating a new dossier, and it directs the agent to inspect helvabase_bid_policy for missing steps. It doesn't explicitly state when not to use this tool or name alternatives, but the 'inspect helvabase_bid_policy' instruction gives actionable routing guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, indicating a write operation. The description adds that it does not upload or certify, which clarifies scope but does not elaborate on side effects, idempotency behavior (though the schema's idempotencyKey description covers this), or what happens to existing data. It adds some value beyond annotations but is not rich.

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

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

The description is two sentences: the first states the core action and the optional version, the second states a key exclusion. It is front-loaded with the most important information and contains 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 creation tool with nested objects, no output schema, and only partial parameter descriptions, the description is insufficient. It does not explain the return value or what the agent should expect after registration, nor does it clarify what 'unreviewed version description' means in practice. It also fails to reference the sibling tool for adding versions to existing evidence, leaving the agent without full 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 only 50%: only the idempotencyKey parameter has a description, while the nested 'evidence' object (containing title, proofType, version, etc.) is undocumented. The description mentions 'optionally with an unreviewed version description' but does not explain the required fields or the structure of the version object. The agent must rely entirely on the schema, and the description fails to compensate for the missing parameter semantics.

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 clear verb ('Register') and resource ('evidence record'), and immediately distinguishes the tool from file upload or certification. It conveys that this creates a new evidence entry, differentiating it from sibling tools like helvabase_add_evidence_version which operate on existing records.

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 exclusionary guidance ('Does not upload or certify a file') but no explicit when-to-use or when-not-to-use recommendations. It does not mention alternatives like helvabase_add_evidence_version for adding a version to existing evidence, nor does it explain conditions for using this tool over others. The guidance is limited to stating non-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?

Annotations already carry idempotentHint=true and destructiveHint=true, so the bar for description disclosure is lower. The description adds useful boundary context by listing operations it does not perform. However, for a mutation tool flagged destructive, it does not mention that creating a questionnaire may overwrite an existing one or require idempotency-key reuse, which the annotation set only partially signals.

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 filler. The primary action and its limit are front-loaded, and the second sentence efficiently enumerates exclusions that clarify the tool's boundary. Every clause 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 tool with three required params, nested objects, a destructive hint, and no output schema, the description is adequate but thin: it clarifies scope and input kind but stays silent on return values, failure modes, and the destructive implications flagged by annotations. The idempotencyKey description in the schema relieves some of this burden, but the overall definition leaves the agent inferring a fair amount.

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% (projectId and idempotencyKey have descriptions; the questionnaire object's property itself lacks a summary, though its nested fields are well documented). The description adds the 'client-supplied' framing and the 100-question cap, which mirrors the schema's maxItems. It adds modest semantic value but does not compensate for the missing top-level questionnaire 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 ('Create'), a resource ('questions for a dossier'), and a concrete limit ('up to 100'), then distinguishes itself by spelling out what it does NOT do: import a workbook, attest signatures, or approve answers. This clearly separates it from siblings like helvabase_upload_sources, helvabase_answer_questionnaire, and helvabase_apply_business_claim_approval without the agent needing to open 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 clear exclusions (no workbook import, no attestation, no approval) and implies the intended input ('client-supplied questions'), but it never names alternative tools or states the conditions under which an agent should pick this tool over related ones. The when-to-use is only implied, not 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?

The description provides extensive behavioral rules beyond the annotations: preserve original files, reference source IDs, distinguish document kind from role, scope supersession to clauses/lots, keep company knowledge internal, model internal fields, retain stable IDs and existing contributions, never infer extraction or approval, and require review for new definitions. This fully discloses how the tool behaves, complementing the annotations (write, idempotent, destructive) without contradiction.

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 appropriately structured: it opens with the main purpose and then lists behavioral imperatives in a logical order. Each clause adds distinct meaning without redundancy. For a tool with this complexity, the length is justified; it is not bloated but efficient in conveying many rules.

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 parameters, nested objects, many fields), the description covers all critical behavioral aspects: preservation, source referencing, kind/role distinction, supersession scope, confidentiality, field modeling, ID stability, inference limitations, review requirements, and integration with submit_analysis. No output schema exists, but for a mutation tool this is acceptable. The description is comprehensive for an agent to correctly invoke it.

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

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

Schema coverage is only 33%, and many nested fields lack descriptions. The description compensates by explaining the meaning of key concepts like kind vs. role, scoping supersession, internal fields, and binding buyer text fields to responseOutline. It clarifies how to structure the definition and the roles of revision parameters (analysisRevision, contextRevision) implicitly. While not every parameter is detailed, the description adds substantial semantic value.

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 purpose: 'Define this specific dossier from the current analysis.' It specifies the resource (dossier workspace) and action (define) with context, and distinguishes from generic 'create' or 'contribute' tools by emphasizing it works from the current analysis. The detailed behavioral constraints further clarify its scope.

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

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

The description implies when to use it (when defining a dossier from analysis) but does not explicitly compare with sibling tools like create_dossier or contribute_dossier. It states a new definition or context requires review, which hints at conditions, but lacks clear 'use X instead' guidance. This leaves some ambiguity for an agent selecting among many related 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds that unsupported features remain explicit blockers, and that existing response forms must be filled on copies—both useful behavioral nuances beyond the safety profile. No contradiction with annotations.

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

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

Three sentences, concise and front-loaded with the primary purpose. The second sentence about response forms is slightly tangential but still relevant. No waste, though the order 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 read-only, zero-parameter tool with no output schema, the description covers the key usage point (read limits before production) and adds blockers context. It doesn't describe return format, but for a simple capabilities check this is acceptable.

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

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

The tool has 0 parameters, so the schema is trivially 100% covered. The description doesn't need to explain parameters. Baseline 4 is appropriate; nothing is missing.

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 a specific verb and resource: 'Read the actual multi-document rollout limits.' It also gives a clear purpose: to check limits before promising file production. This distinguishes it from sibling tools that deal with production, export, or other document 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?

It explicitly says 'before promising file production,' which is a clear usage context. It doesn't name alternatives, but it implies this is a pre-check tool. The instruction about filling forms on copies is more behavioral than usage guidance, but the timing cue is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Reads existing rights only; no grant or upload.' It adds useful context about the concrete scope—available libraries and current selection—and the intended audience. It does not contradict the annotations, and no hidden side effects are implied.

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

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

The description is two short, purposeful sentences. The core behavior is front-loaded, and the read-only qualifier is placed immediately after. There is no filler, redundant phrasing, or 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?

For a single-parameter, read-only tool, the description covers invocation context, safety behavior, and the high-level informational result. There is no output schema, but the description clearly states what the caller should see: available business libraries and the current selection. Minor gaps are the lack of explicit output structure and non-differentiation from the inspect sibling, but they are not critical for basic selection and invocation.

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

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

There is only one parameter, projectId, and the schema description is complete and practical: it is a Helvabase project/mapping ID returned by list or create dossier, never a local path. The tool description itself adds no parameter information, but the schema already provides full meaning, so the baseline of 3 applies.

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

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

The description clearly identifies a read-only query ('Show') over two related resources: available business libraries and the dossier's current selection. It also states that it 'Reads existing rights only; no grant or upload,' which separates it from apply/upload operations. However, it does not explicitly distinguish itself from the similarly named 'inspect_dossier_library_access' sibling, so it does not fully disambiguate within the sibling family.

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: this is for a workspace administrator to view the current selection and available libraries. The phrase 'Reads existing rights only; no grant or upload' is an explicit when-not-to-use for modifications. It does not name an alternative tool, so the agent must infer which sibling handles grant/upload operations.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a meaningful behavioral note: 'No human approval is conferred', which is not in annotations and clarifies a limitation. This is useful context beyond what structured fields provide.

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

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

The description is two sentences with no redundancy. The core action and subject are front-loaded, and the additional note about obsolescence and approval is concise. Every word adds value without 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?

For a simple read tool with one parameter and no output schema, the description sufficiently conveys what is returned (report, revision, mappings) and the crucial caveat about approval. It does not detail return format or error scenarios, but given the tool's simplicity, this is a minor gap. The description is complete enough for an agent to call it correctly.

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

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

The input schema fully documents projectId with format, length, and a clear description, so schema coverage is 100%. The tool description does not add any parameter-specific meaning; it focuses on the action, not the parameter. Given the high schema coverage, a baseline score 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 clearly states a specific action (read) on a specific resource (latest stored business check report) and includes details about revision and field mappings. It distinguishes this tool from generic read tools by specifying it retrieves the latest report and its mappings, 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 implies a usage context with 'An obsolete report requires rechecking', suggesting when this tool might be insufficient, but does not explicitly guide when to use this tool versus alternatives like helvabase_check_draft or other read tools. No exclusions or alternative tool names are provided, leaving the choice somewhat to inference.

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

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

Annotations already signal read-only, idempotent, non-destructive behavior. The description adds meaningful transparency beyond that by stating suggestions 'never assign work or grant access' and that the agent must 'cite the actual question source and obtain the responsible person's decision before creating an assignment.' It also explains the synonomy behavior for legal/juridique/recht. No contradiction with annotations.

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

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

Three sentences with no fluff. The main action is front-loaded, and the remaining sentences efficiently cover edge cases and safety boundaries. 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 two-parameter tool with no output schema, the description gives enough context to call it correctly: the candidate source, the matching requirement, synonym handling, unassigned cases, and the no-assignment guarantee. It could be more explicit about the exact shape of the returned suggestions, but the core behavior is sufficiently covered.

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%, with projectId documented but requiredExpertise not. The description compensates by explaining expertise semantics: 'Legal/juridique/recht are the same expertise' and that 'Empty, unknown or ambiguous requirements remain unassigned.' This adds meaningful value beyond the raw schema for the undocumented parameter, though it does not provide concrete value examples.

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: 'Suggest current workspace members matching every required expertise for an accessible dossier.' This is clear and unambiguous, and the added boundary 'Suggestions never assign work or grant access' helps distinguish it from assignment-like tools. However, it does not explicitly differentiate from sibling suggestion tools such as helvabase_answer_suggestions or helvabase_propose_document_plan.

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

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

The description implies the use case: when you need member suggestions for required expertise in an accessible dossier. It also warns that empty, unknown, or ambiguous requirements remain unassigned, which gives some operational context. But it does not explicitly state when to prefer this tool over alternatives or when not to use it.

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

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

The description adds meaningful behavioral context beyond the annotations: it states that the download rechecks evidence, revisions, access and expiry, and that it does not auto-submit to buyers. Annotations already indicate destructiveHint and idempotentHint, and the description does not contradict them. It provides some added value but not extensive detail.

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 and front-loaded with the main purpose. Each sentence adds distinct value: purpose, prerequisites, download recheck behavior, and no auto-submission. No fluff or redundant restatement of the tool name.

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

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

For a tool with six required parameters, nested objects, and no output schema, the description is insufficient. It lacks guidance on parameter construction, how to obtain the resulting ZIP, or any details about return values. An agent would struggle to invoke this correctly without additional context from other tools or prior knowledge.

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 17% (only idempotencyKey has a description). The description does not explain any of the six required parameters, including the nested objects (documents, selection, planRevision) and confirmation IDs. With such low coverage, the description should compensate but does not, leaving agents uncertain about how to construct valid arguments.

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

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

The description states a specific action: exporting exact approved file versions and a hash manifest as a ZIP. This clearly identifies the resource and format, and distinguishes it from siblings like helvabase_export_dossier or helvabase_export_requirement_coverage by focusing on exact approved versions. However, it does not explicitly name those alternatives, so it stops short of a 5.

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

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

The description provides prerequisites (requires current file reviews and final pack confirmation) and notes that there is no automatic buyer submission, giving context for when to use it. It does not explicitly state when not to use it or name alternative tools, so guidance is present but not 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?

Annotations declare idempotentHint=true and destructiveHint=true, and the description does not contradict them. It adds useful context—the draft is immutable, review copies are marked unapproved with findings in Word comments and a visible appendix, and submission has no override. However, it does not address the destructiveHint implications or what happens to an existing DOCX, so it adds moderate but not rich behavioral context beyond the annotations.

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

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

Three sentences with the core purpose front-loaded, followed by the edition distinction. It is efficient and well-ordered, though the first sentence could arguably merge the locale instruction more tightly. 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 a nested revision object, no output schema, and destructive/idempotent annotations, the description conveys the key constraints (immutability, review/submission distinction, no override, locale behavior). It does not describe the returned DOCX or failure modes, but it is sufficiently complete for an agent to invoke it correctly with the schema filling the remaining 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 coverage is 50%, with locale and idempotencyKey already described in the schema. The description mirrors the locale guidance ('Set locale to the draft language (en/fr/de)') and clarifies edition semantics (review vs submission), adding some value. It does not, however, explain the revision object (outputJobId/payloadHash) or the idempotencyKey pattern beyond what the schema already states, so it only partially compensates 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 states a specific verb ('Build a professional DOCX') and a precise resource ('the exact immutable draft'), and contrasts review vs submission editions. This clearly differentiates it from siblings like helvabase_export_document_pack and helvabase_produce_document, which the name alone would not distinguish.

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 tells the agent to set locale to the draft language and explains when the submission edition applies ('still requires current source validation and reviewer confirmation; no override is accepted'). It gives clear context on the two editions but stops short of naming explicit alternatives or stating when not to use this 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the output is 'bounded' (implying size limits), it is a review artifact, and it includes 'source extraction issues'. It also clarifies the output is base64 bytes, which is a behavioral detail beyond the schema. No contradiction with annotations.

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

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

Two sentences with no filler. The core action and output format are front-loaded, and the review-artifact caveat is placed immediately after. 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 single-parameter read-only export tool with rich annotations and no output schema, the description is nearly complete. It explains what the output is, how to handle it, and what it includes. The only minor gap is that it doesn't describe the workbook's structure or how the base64 bytes should be decoded, but the instruction to use client tools mitigates that.

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

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

Schema description coverage is 100%, so the schema already documents the only parameter (projectId) with a clear description. The tool description doesn't add parameter-level detail beyond the schema, but it does reinforce that projectId is a Helvabase project/mapping ID. Baseline 3 is appropriate because the schema carries the parameter semantics fully.

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 ('Return'), a specific resource ('current traceability matrix'), and a specific format ('bounded XLSX review workbook (base64 bytes)'). It also distinguishes itself from approval/submission exports, which helps differentiate it from sibling export tools like helvabase_export_dossier and helvabase_export_document_pack.

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

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

The description clearly indicates this is a review artifact and explicitly says it is 'never an approval or a submission export', which tells the agent when not to use it. It also instructs to save and open it using client tools. However, it doesn't explicitly name alternative tools or provide a when-to-use vs. when-not-to-use comparison beyond the approval/submission distinction.

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

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description confirms the non-writing behavior, which is consistent with the annotations. However, 'Unknown remains unresolved' is ambiguous about what happens when the receipt is unknown (error vs. null return), and the description adds little behavioral context beyond what annotations provide. No contradiction with annotations.

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

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

The description is short and front-loaded with the purpose, which is good. But the second sentence 'Unknown remains unresolved; this never writes access' is cryptic and wastes the opportunity to explain behavior clearly. The phrase adds confusion rather than value, so the conciseness is not well spent.

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?

This is an inspection tool with three required parameters and no output schema, so the description carries a heavy burden. It does not explain what the access receipt contains, what happens in unknown states, or the meaning of the parameters. The 'Unknown remains unresolved' clause leaves critical behavior unexplained, making the description incomplete for an agent to call this confidently.

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 low at 33% — only projectId has a description in the schema; selectionId and selectionRevision have none. The tool description mentions no parameters at all, so it fails to compensate for the schema gap. An agent is left to infer the meaning of selectionRevision's 64-char hex pattern from the schema alone, which is inadequate.

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 ('inspect') and resource ('stored library selection's original access receipt'), making the primary purpose clear. It also differentiates from siblings by declaring 'this never writes access', which distinguishes it from apply_dossier_library_access and retry_dossier_library_access. However, the phrase 'Unknown remains unresolved' is cryptic and adds confusion rather than clarifying behavior.

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?

'This never writes access' provides implicit guidance that this is a read-only inspection tool, not the tool to apply or retry access. However, it never names alternatives explicitly, such as retry_dossier_library_access when access is failing, nor states when this tool should be preferred over other inspect/read siblings. The guidance is implied rather than 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?

Annotations already declare this as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds the scope ('actual stored original') and a behavioral requirement to preserve exact returned values, which is useful but does not disclose additional behavior like response format or edge-case handling.

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

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

Three short sentences, front-loaded with the core action. Every sentence earns its place, and there is no redundant repetition of the schema or annotations.

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

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

With no output schema, the description should explain what 'supported editable targets', 'locations', and 'expectedText' actually are, but it does not. The instructions assume domain knowledge that the agent may not have, and the tool's role relative to related read tools is left underspecified.

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%: projectId has a meaningful explanation, but fileId has none beyond format constraints. The description does not clarify either parameter or explain the relationship between the returned 'locations'/'expectedText' and the inputs, leaving a real semantic 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 clearly states the verb ('Inspect') and resource ('supported editable targets in the actual stored original'), making the core purpose recognizable. However, it doesn't explicitly differentiate from the many sibling read/inspect tools, so the agent must infer why this one is 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?

The description gives post-call handling instructions ('Preserve returned locations and expectedText exactly') but provides no guidance on when to choose this tool over alternatives such as helvabase_read_original_page or helvabase_read_source_original. There are no explicit when-to-use or when-not-to-use conditions.

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

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

Annotations already mark the operation read-only and idempotent. The description adds meaningful context: jobs are durable, and failed or interrupted mutations will not be automatically replayed. This tells the agent to expect persistence and manual inspection rather than automatic retries.

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

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

Two short sentences, front-loaded with the main purpose and followed by a useful caveat. Every clause earns its place and there is no redundant restating of the tool name.

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

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

For a read-only tool with only two optional parameters this is minimally adequate, but with no output schema the description does not explain the return shape, job statuses, or how limit/jobId shape the result. The failure caveat is organizationally relevant but does not fill those 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 0% and the description mentions neither jobId nor limit, so it does not compensate for the schema gap. The schema's field names and constraints carry the only semantics, and the description adds no guidance on how to filter or page.

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: 'Read durable processing/result jobs' and scopes it to the authorized workspace. It is clear, but it does not explicitly distinguish this from sibling read_* tools or say what qualifies as a 'job'.

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

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

Usage is implied by the read semantics and the caveat that failed/interrupted mutations are not automatically replayed, which hints that this tool is how you inspect job outcomes. There is no explicit when-to-use statement, alternative routing, or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about governed information and the group-vs-claimed-claim distinction, but does not disclose additional behavioral traits such as pagination or result completeness. This is acceptable given annotation coverage, so a mid-score is appropriate.

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

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

The description is appropriately sized: three sentences, each carrying distinct meaning. The core action is front-loaded, followed by entity clarification and downstream usage. No redundant phrases 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 simple list operation with annotations covering the read-only safety profile, the description is mostly adequate. However, it references a parameter (knowledgeAssetId) that is not in the schema and does not explain expected return values or result ordering. The domain clarification adds value, but the knowledgeAssetId discrepancy leaves a gap in completeness.

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 33%, and the description does not explain any of the actual parameters (projectId, limit, offset). It mentions 'knowledgeAssetId' which is not present in the input schema, creating potential confusion about this tool's parameter surface. With low schema coverage, the description should compensate but 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?

The description uses a specific verb-resource pair, 'List existing groups of governed company information,' which clearly identifies the operation and scope. It also distinguishes the resource type by stating 'A group is not an approved claim,' helping to disambiguate from sibling claim-related tools even without naming them.

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

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

The description provides concrete context on how the tool's results are used: 'Use its ID for a proposal, or omit knowledgeAssetId to create a group from the reviewed evidence.' This gives an agent actionable guidance on when the returned IDs matter and how they relate to downstream proposal/creation actions, though it does not explicitly enumerate alternative listing 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that source validity, owner, scope, and contradictions are checked live, and that includeHistory returns non-approved history with blockers. This provides behavioral detail beyond the annotations.

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

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

Three concise sentences, front-loaded with the core purpose. Every sentence adds value, and there is no fluff. The structure is efficient and readable.

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 core purpose and the includeHistory nuance, but lacks explanations for entryId, question, and limit. An agent may not know how to use these parameters correctly. However, the tool is read-only and annotations cover safety, so it's not severely incomplete, but still has 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 only 20% (only projectId has a description). The description explains includeHistory's behavior but not limit, entryId, or question. With low coverage, the description should compensate more; it only partially does.

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

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

States a specific verb 'find', resource 'current approved reusable answers', and scope 'for this dossier'. It also notes live checks for validity, owner, scope, and contradictions. It doesn't explicitly name sibling tools, but the purpose is clear enough to distinguish from many 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?

Provides guidance on the includeHistory parameter, explaining that it exposes non-eligible history with blockers and never as approved truth, plus a warning that reuse requires adaptation and fresh review. However, it doesn't mention alternatives like helvabase_library_source or helvabase_reuse_library_entry, so no explicit when-to-use vs 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety properties. It adds useful behavioral context beyond annotations by warning that a dossier approval should not be treated as approval of reusable knowledge. This is an extra domain rule that helps the agent behave correctly, though the description still does not say anything about pagination, return shape, or what a 'revision' contains in practice.

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

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

The description is two sentences with no fluff. The first sentence leads with the action and the exact when-to-use context; the second sentence is a useful caution. Both sentences carry meaningful weight, and the structure is appropriately front-loaded.

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

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

For a simple read tool with two required parameters and full annotation coverage, the description supplies enough context to know why the tool exists and approximately when to call it. It is incomplete in two material ways: answerId semantics are missing, and the description never states what the tool returns (e.g., whether it includes full answer text, timestamps, authorship, or the archival revision). Given no output schema, these omissions leave room for agent error.

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?

With 50% schema description coverage, answerId is entirely undocumented in the schema, and the description also fails to clarify its meaning or relationship to projectId. The phrase 'questionnaire answer' gives a weak clue that answerId identifies an answer, but projectId is only explained inside the schema and the description does not help map the two parameters. For low coverage, the description should compensate, and it 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?

The description states a specific action and object: 'Read the exact questionnaire answer and its revision.' It also ties the reading to the downstream goal of proposing reusable knowledge or adapting a suggestion, which distinguishes its purpose from many sibling read tools. It is not a full 5 because the tool name 'library_source' is not explicitly reconciled with the object being read, and the actual return value is not made explicit.

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 timing guidance: use this before proposing reusable knowledge or adapting a suggestion. It also gives a domain caveat with 'A dossier approval never approves reusable knowledge,' which prevents a common misuse. It does not explicitly name alternative tools or provide a full when-not-to-use list, so it stops short of 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered. The description adds genuinely new behavioral context beyond the annotations: revisions are immutable, and changing a file or draft invalidates previous file and pack approvals. This immutability/invalidation semantic is valuable and not present in the structured fields. No contradiction with annotations.

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

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

Two sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds a consequential detail (expectedVersion reuse and invalidation). Efficient and well-ordered, though it could afford a brief parameter note given the schema gap.

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 has a nested parameter with no schema description, no output schema, and sits in a complex domain of revisions and approvals. The description explains the tool's purpose and a key side-effect but leaves the sole required parameter entirely unexplained and does not hint at the response shape. For a one-parameter call this is inadequate completeness.

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

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

Schema description coverage is 0%, so the schema provides no documentation for the planRevision parameter or its nested fields. With such low coverage, the description carries the full burden to explain the parameter, but it never mentions planRevision, outputJobId, or payloadHash at all. This is a significant gap for an agent trying to construct a valid call.

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 ('List') and resource ('current per-item immutable revisions'), making the purpose clear. It adds a domain detail (reuse as expectedVersion) that helps an agent understand what the list is for. It doesn't explicitly differentiate from siblings, but the revision-listing purpose is distinctive enough in this large family.

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 implicit usage guidance: revisions should be reused as expectedVersion, and it warns that editing a file/draft invalidates prior approvals. This helps an agent decide when the returned value matters. However, it does not name alternatives or state when NOT to use this tool, leaving the selection decision largely to inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds the useful scoping behavior that only dossiers in the currently authorized workspace are returned, which is context beyond the annotations but not rich behavioral detail like pagination or ordering.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it is appropriately sized for a tool with no 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 zero-parameter, read-only list operation, the description is nearly complete. It tells the agent what action is performed and on what scope. The lack of an output schema is acceptable given the simple intent, though a note about the returned list format would push it to a 5.

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

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

There are zero parameters and schema coverage is 100%, so the input schema fully defines the invocation. The description correctly adds nothing about parameters. With no parameters to document, a baseline of 4 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 specific verb ('List') and resource ('dossiers'), and adds a clear scope ('currently authorized workspace'). This cleanly distinguishes it from sibling tools like helvabase_create_dossier, helvabase_read_dossier_access, or helvabase_contribute_dossier, which have different actions.

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

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

The description gives no guidance on when to use this tool versus alternatives, such as when to use helvabase_workspace or helvabase_read_dossier_access for related information. There is no mention of exclusions, prerequisites, or scenarios that favor this 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description needn't repeat those. It adds useful context by noting that this tool returns 'current versions' and that file transfer/approval are separate operations, which informs the agent about the tool's scope beyond the annotations.

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

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

The description is two concise sentences with no fluff. The main purpose is front-loaded, and the usage caveat is efficiently placed in the second sentence. Every word 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 simple list tool with no output schema and annotations covering safety, this description provides everything an agent needs: what it does, what it returns (evidence records with current versions), and what it does not cover (file transfer/approval). Pagination is self-evident from the schema. Nothing essential is missing.

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

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

Schema coverage is 0%, so the description must compensate for parameter meaning. However, the parameters (limit and offset) are standard pagination controls with clear defaults and ranges in the schema. The description does not mention them, but they are self-explanatory given the schema. The description adds no extra value here, but the schema itself is sufficient.

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 'List evidence records and current versions' with a specific verb and resource, distinguishing it from other list tools like helvabase_list_dossiers or helvabase_list_document_versions. The phrase 'current versions' adds precision and helps differentiate from other evidence-related 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 explicitly states that 'File transfer and evidence approval are separate operations,' which tells the agent this tool is not for those tasks and guides it toward appropriate siblings. This is a clear when-not-to-use directive that prevents 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds a useful caveat that readiness is not final approval, and the 'Inspect' framing aligns with the read-only annotation. But it provides no additional depth such as what the returned state means or how readiness is determined.

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

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

Two short sentences, with the core action and scope front-loaded and the clarifying caveat placed at the end. No repetitive filler or schema-restating 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?

The complexity is low, and the tool has complete schema coverage and strong safety annotations. However, there is no output schema, and the description does not explain what the inspection outcome looks like, so an agent must still guess at the return format and interpretation of 'readiness'.

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

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

There is one parameter and schema coverage is 100%: the input schema already contains a detailed description of projectId, including its source and what it is not. The tool description does not need to add parameter detail, so the baseline score 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 uses a concrete verb ('Inspect') and names the resource/scope: evidence readiness, questionnaire gaps, and team work for the dossier. The extra sentence clarifies the tool does not finalize approval, though it does not explicitly differentiate it from closely related sibling tools like check_draft or next_actions.

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

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

The description implies the tool is used when an agent needs a readiness inspection and explicitly warns it is not final document approval. However, it does not state when to prefer this tool over read/check siblings, nor does it provide concrete conditions 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?

The description discloses the return content ('who should act and an exact work-item revision') and the scoped nature ('bounded work queue'). It complements the annotations (readOnlyHint, idempotentHint) by adding behavioral detail about the output and scope, without contradicting them.

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

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

The description is two sentences, front-loading the core purpose and then the scoping constraint. No wasted words; every sentence adds 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?

The description adequately covers the purpose, the return type, and the scope. With annotations protecting read-only and idempotency, and a simple parameter set, the description is reasonably complete, though it doesn't mention pagination or format details of the 'work-item revision'.

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% (projectId has a description, limit does not). The tool description adds no information about either parameter, so the agent is left without guidance for the limit parameter. The description does not compensate for the schema 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 clearly states the tool's function: it reads dossier blockers before deadlines and assigned work, returning who should act and a work-item revision. It explicitly distinguishes itself from sibling tools by clarifying it is a bounded work queue, not an approval, notification scheduler, or RFP coverage declaration.

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 guidance on what the tool is for and what it is not, but it does not name specific alternative tools or give explicit when-to-use/when-not-to-use conditions beyond the negations. It is clear enough for an agent to infer usage 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat that it is safe to call. It adds useful context about status semantics (sent vs delivered) and the operational review requirement for 'uncertain'. However, it doesn't describe what happens when the tool is called (e.g., return format, pagination), but given annotations cover safety, a 3 is fair.

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

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

The description is two sentences long and front-loads the core purpose. The status definitions are tightly packed with the key warning about 'uncertain'. No wasted words, though the second sentence could be considered slightly dense.

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 (1 parameter, no output schema), and the description covers the essential status semantics and a critical caveat. Missing details like return format or how to interpret 'read or approved' are minor, but given that the description could be slightly richer, a 3 is appropriate.

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

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

Schema coverage is 0%, so the description carries the burden for the single parameter 'limit'. However, the description does not mention 'limit' at all, so the agent must infer its meaning from the schema. Since the schema has a default and min/max, the description adds no value beyond existing schema details, but the schema is self-explanatory for limit. A 3 is appropriate because the description doesn't compensate but the schema is sufficient.

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 tool as reading notification status, specifying the resource ('notification history') and scope ('your own'). It distinguishes it from sibling tools like notification_settings by focusing on status rather than preferences. However, it doesn't explicitly name the sibling tools that might be confused, so a 4 is appropriate.

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 on when to use this tool (to check sent/delivered status) and includes an exclusion for the 'uncertain' status, explicitly stating not to retry with a new key. While it doesn't mention alternatives like notification_settings as a contrast, the guidance for the 'uncertain' case is valuable.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description adds genuinely non-obvious behavior: reminders run without an open LLM session and never approve a dossier or send a bid to a buyer. This is valuable side-effect context beyond what annotations provide.

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

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

Three short sentences with the core purpose front-loaded and the safety context following. Every sentence earns its place; there is no filler or redundant restatement of the tool name.

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

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

For a zero-parameter read-only tool, this is nearly complete. The only minor gap is that it does not describe the exact return shape, but with no output schema and such a well-scoped read target, the agent has enough to call it correctly.

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

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

With zero parameters, the schema covers everything and the baseline is 4. The description adds no parameter-level detail, which is acceptable here, and it hints at the response scope by listing preferences, rules, and engine activation.

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 the specific verb 'Read' and names three concrete resources: reminder preferences, workspace rules, and actual engine activation. This clearly differentiates it from sibling set_* tools and immediately tells the agent what the tool returns.

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 read-only wording clearly signals the inspection use case, and with zero parameters there is no invocation ambiguity. However, it does not explicitly name set_notification_preferences or set_notification_rules as the alternatives for modification, so it stops short of full sibling routing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context by warning that legacy imports may include test data and that unverified imports are not verified live opportunities, which is not captured in the annotations.

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

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

Two concise sentences with no filler. The core purpose is front-loaded, and the data quality caveat is placed in the second sentence without bloating the description.

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

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

For a simple read operation with one optional parameter, the description is largely complete and includes an important data quality warning. It could be slightly more explicit about how this relates to searching or profiling opportunities, but nothing critical is missing for basic invocation.

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

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

The only parameter, 'limit', is fully specified in the schema with type, default, minimum, and maximum, so the description does not need to add much. However, schema description coverage is 0% and the description does not mention 'limit' at all, though its meaning is self-evident from 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 uses a specific verb and resource ('Read stored opportunity matches'), clearly stating what the tool does. It differentiates somewhat by saying 'stored' matches, implying persistence, but it does not explicitly distinguish itself from siblings like helvabase_search_opportunities or helvabase_opportunity_profiles.

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

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

No guidance is provided on when to use this tool versus alternatives such as helvabase_search_opportunities or helvabase_opportunity_profiles. The data quality caveat about legacy imports is useful but does not help an agent decide between this and other opportunity-related 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds operational details beyond annotations: it explicitly states 'No model call or profile persistence,' which clarifies side effects and computational behavior. This is valuable context for an agent deciding whether to invoke this 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 a two-sentence, front-loaded summary with no fluff. The primary action is stated first, and the operational qualifiers are concise. Every word adds value, making it highly efficient.

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

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

For a simple read-only tool with only two parameters and no output schema, the description provides the core purpose and some behavioral context, but it lacks detail on the limit parameter, what 'watch profiles' consist of, and the exact nature of the output. The description is adequate but not fully complete, given the absence of an output schema and parameter explanations.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It indirectly covers derivePreview through 'optionally deriving an unsaved deterministic proposal,' but it does not mention the limit parameter at all. This leaves a significant gap for a low-coverage schema, making the description insufficient for parameter understanding.

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 action (read) and the resource (saved watch profiles), and mentions an optional derivation (unsaved deterministic proposal) which distinguishes it from save_opportunity_profile and search_opportunities. It is specific and unambiguous, though 'watch profiles' could be clearer, the name disambiguates.

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

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

The description implies usage (reading saved profiles and optionally deriving a preview) but does not explicitly state when to use this tool over related siblings like helvabase_save_opportunity_profile or helvabase_search_opportunities. No exclusions or alternative suggestions are provided, leaving the selection to the agent's inference.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior, so the description only needs to add context. It adds dossier scoping and buyer-feedback content, but it does not mention pagination behavior, response shape, or the open-world nature of the data beyond what the annotations already signal.

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

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

A single focused sentence with the key verb and resource front-loaded and no filler. It is terse, but the brevity is not a structural flaw; every word contributes.

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

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

For a simple read operation with robust safety annotations, this is minimally viable. However, with no output schema, no pagination explanation, and no sibling differentiation, the agent is left to infer several details about what will be returned and why this tool is the right choice.

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 33%, with limit and offset lacking descriptions entirely. The phrase 'this dossier' loosely maps to projectId, but the description does nothing to explain limit/offset pagination semantics, failing to 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 states a specific verb ('Read') and a clear resource ('recorded outcomes and buyer feedback') scoped to a dossier. It adds useful specificity beyond the bare name 'outcomes' and is readily distinguished from write-oriented siblings like helvabase_record_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?

There is no explicit guidance on when to use this tool versus alternatives, and no mention of the obvious counterpart helvabase_record_outcome. The read verb implies the general usage context, but the description does not state when-not-to-use or how it relates to the many other read_* 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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds non-obvious behavior: the download endpoint re-checks access and revision gates, and the tool does not approve, send, or submit. These side-effect disclosures are genuinely useful and do not contradict any annotation.

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

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

Three short sentences with no filler: the core purpose comes first, followed by the review-copy caveat and the explicit non-behaviors. Every sentence contributes a distinct, useful 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 one-parameter tool with strong annotations and no output schema, the description explains what is returned (an authenticated link), the precondition, the access/revision re-check, and what the tool does not do. Failure cases and link expiration are not covered, but nothing essential for invoking 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?

The only parameter, jobId, is never explicitly explained in the description; 'existing generated file' implies it references a prior generation job but does not directly connect the term. With 0% schema description coverage, the description should have compensated more explicitly. The parameter's self-evident name keeps this from being lower.

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 the exact deliverable — an authenticated link — and the resource, an existing generated file. It explicitly negates approve/send/submit behavior, which helps separate this tool from export/produce siblings. The review-copies-only clause further narrows scope.

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

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

It clearly says this tool is for obtaining download links for already-generated files and explicitly warns against using it to approve, send, or submit. It also flags historical dossiers and presentations as review copies only. However, it names no alternative sibling tool, so routing guidance stops just short of 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?

Annotations already indicate readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds value beyond these by clarifying that despite the destructive hint, 'this does not create or approve a file,' which is a key behavioral distinction. It also states 'Returned values and targets are authoritative,' giving insight into the return behavior. It does not contradict annotations and adds useful context about prerequisites and limitations, though it does not fully describe side effects.

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 sized but includes an instruction-like sentence ('Read all assignment/original pages, fill a copy and submit actual bytes') that is ambiguous as to whether it describes the tool's behavior or gives agent workflow guidance. This adds confusion rather than value. The core purpose is front-loaded, but the extra sentence could be removed or clarified. Overall it is not overly verbose but has some unnecessary 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?

With 15 parameters, nested objects, no output schema, and only 7% schema coverage, the description is far from complete. It does not explain the structure of the returned values ('Returned values and targets are authoritative' gives no details), does not describe how to construct the complex nested objects, and does not clarify the distinction between planRevision, draftRevision, adaptiveRevision, expectedVersion, and expectedAssignment. An agent would need substantial additional knowledge to correctly invoke this tool.

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

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

Schema description coverage is only 7%, so the description must compensate for the many undocumented parameters. The description only provides meaning for expectedAssignment ('Use expectedAssignment=null for the first assignment') and vaguely references plan/draft/adaptive revisions through the prerequisite phrase. The other 15 parameters, including complex nested objects like selection, pdfTargets, docxTargets, xlsxTargets, consistencyFacts, and the revision objects, remain unexplained in the description. This is insufficient given 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 states a specific verb and resource: 'Prepare a version-bound assignment for filling an original with the customer's own file tools, or attaching it unchanged.' It distinguishes itself from the actual submission (submit_client_file) by explicitly stating 'this does not create or approve a file,' clarifying it is a preparation step. The purpose is clear, though the later instruction 'Read all assignment/original pages, fill a copy and submit actual bytes' introduces ambiguity about whether the tool itself does this or the agent does it afterward.

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

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

It provides prerequisites ('Requires enabled managed files, exact-plan agreement and all existing source/draft/adaptive approval gates') and a specific parameter hint ('Use expectedAssignment=null for the first assignment'). It implies the actual file creation/submission is done elsewhere ('this does not create or approve a file'), and lists a limitation ('Unsupported arbitrary Office rewrites or PDF overlays remain blocked'). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already signal that this is a mutating, destructive, idempotent operation. The description adds useful context (retrieves documents, persists a revision, not server prose) but does not disclose what 'persist a reusable context revision' entails for existing revisions (e.g., overwrite, create new version, side effects). It does not contradict annotations, but it misses an opportunity to elaborate on the destructive behavior the annotations hint at.

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

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

The description is three sentences, each earning its place: the core action, the clarification about what it returns, and the next-step pointer. It is front-loaded with the primary purpose and contains 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 complexity (5 parameters, no output schema) and the presence of annotations, the description gives a clear high-level duty and directs the agent to the next step. However, it omits important context: the exact nature of the persisted 'revision', whether it replaces or creates revisions, and any prerequisites (e.g., dossier must exist). These gaps matter for a mutating tool with destructiveHint=true.

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 40% (projectId and idempotencyKey have descriptions; query, title, and maxTokens do not). The description provides no parameter information whatsoever, so it fails to compensate for the schema's low coverage. An agent is left without clarity on the meaning of key inputs like 'query' or the effect of 'maxTokens'.

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

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

The description states a specific action ('Retrieve sourced business context for a dossier') and a distinct secondary action ('persist a reusable context revision'). It explicitly distinguishes the tool's behavior from related ones by noting 'This retrieves documents, not server-generated prose.' It also names the sibling tool to call next, making its role in the workflow 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 provides a sequencing hint ('Next call helvabase_read_context') but does not explicitly state when to use this tool over alternatives such as helvabase_prepare_client_file or helvabase_prepare_document_analysis. There are no exclusions or conditional pathways, so usage context is only implied.

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