Red by Big Red Cloud

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

With no annotations provided, the description carries full burden and does a thorough job. It discloses that a routeToken is not permission to post, that preview-before-posting and confirmWrite still apply, and that the counterparty must be explicitly confirmed in the current conversation. These are critical behavioral constraints beyond basic input 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 dense but every sentence earns its place: purpose, batch limit, route token workflow, confirmation requirements, and counterparty constraint. It is well-structured and front-loaded with the core purpose before the process details.

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

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

For a transactional batch tool with no annotations and no output schema, the description fully covers the prerequisite workflow (routeToken acquisition), the constraints on token usage, and the confirmation gates. It adequately contextualizes the complexity of 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 coverage is 100%, so baseline is 3. However, the description adds meaningful context for routeToken (routing permission only, do not invent) and confirmCounterpartyExplicit (must be explicitly stated by user, not inferred), which goes beyond the schema descriptions. The max 20 items is also reinforced.

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 'Processes a batch of BRC cash payments' with a specific verb and resource, and adds the batch size limit (max 20). This also distinguishes it from single-item tools like brc_create_cash_payment and other batch tools (e.g., brc_batch_cash_receipts).

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 workflow guidance: call brc_route_request first, retain the returned routeToken, and pass it on the final transactional call. It also specifies when confirmCounterpartyExplicit must be true. It does not explicitly state alternatives or when not to use this tool, but the batch nature and prerequisites are clearly 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?

With no annotations provided, the description carries the full burden and discloses critical behavior: routeToken is not permission, preview-before-posting and confirmWrite/confirmDelete still apply, and confirmCounterpartyExplicit must be based on explicit confirmation in the current conversation. It also warns against inventing placeholder tokens.

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 its core purpose and is information-dense, but the routeToken guidance is somewhat repetitive across multiple sentences. Every sentence still contributes safety-relevant or workflow-relevant 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?

Despite having 8 parameters and no output schema, the description covers the essential routeToken lifecycle, confirmation prerequisites, batch limits, and posting safeguards. This gives an agent enough context to invoke this transactional batch tool correctly.

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

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

The input schema covers 100% of parameters with detailed descriptions, including routeToken and confirm flags. The description reinforces the routeToken workflow and counterparty confirmation, but it adds little new parameter-level meaning beyond what the schema already provides.

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

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

The description opens with 'Processes a batch of BRC cash receipts,' clearly naming the verb, resource, and batch scope. It also states the 20-item maximum, which helps distinguish it from single-item tools like brc_create_cash_receipt and other batch tools.

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

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

It provides explicit workflow guidance: call brc_route_request first, retain the routeToken, pass the same token, and only call this tool on the final permitted transactional call. It does not explicitly name alternatives or state 'when not to use,' so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: requires routeToken, routeToken is not permission to post, preview-before-posting and confirmWrite/confirmDelete still apply, and a 20-item batch limit. This is useful, actionable context beyond what the schema provides, though it still doesn't state the exact nature of the operation (create/update/delete).

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 compact paragraph with a clear front-loaded statement ('Processes a batch of customers') followed by essential workflow instructions. Each sentence serves a purpose: batch limit, routeToken requirement, sequence, and confirmation caveat. No wasted words 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?

Given the complexity of the routeToken workflow and 7 parameters, the description covers the critical context: the prerequisite call to brc_route_request, token retention, and confirmation requirements. However, it does not fully explain what 'processes' means (create/update/delete) or describe expected return values, though no output schema exists. It's adequate but with a small gap around the specific action semantics.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it restates the max 20 items and mentions routeToken requirements, which are already in the schema. It does not elaborate on priceBasis, confirmWrite, or confirmCrAnalysisCategory beyond their schema descriptions, so it adds only marginal 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 states 'Processes a batch of customers' which identifies the resource (customers) and indicates a batch operation. It distinguishes from sibling batch tools by entity type, though the verb 'processes' is somewhat vague and does not specify whether it creates, updates, or deletes customers. The mention of 'final permitted transactional tool call' implies a write operation but lacks exact action clarity.

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 workflow instructions: call brc_route_request first, retain the routeToken, pass it on this call, never invent a placeholder, and remember that the token does not bypass preview/confirmation. It does not explicitly compare with alternative tools (e.g., create_customer for single operations), but the context is clear that this is a batch transactional tool requiring prior 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?

With no annotations, the description carries the full burden and does well: it reveals this is a transactional write operation requiring routing permission and explicit confirmations, and it warns against bypassing preview-before-posting. It doesn't describe return behavior or specific side effects beyond posting, but the safety workflow is clearly disclosed.

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

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

Four sentences, each devoted to a distinct requirement: purpose and limit, routeToken workflow, no-placeholder rule, and confirmation requirements. Dense but not bloated; all information is actionable and non-redundant.

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

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

Covers purpose, limits, prerequisites, routing workflow, and confirmation rules—critical for a transactional tool with no output schema. Minor gaps remain: it doesn't define what a 'BRC payment' item consists of or state what a successful response indicates, but the schema and sibling tools help fill that 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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds workflow context for routeToken and confirmCounterpartyExplicit but doesn't clarify any parameter semantics beyond what the schema already provides (e.g., maxItems is duplicated, item structure is not expanded).

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 'Processes a batch of BRC payments,' which uses a specific verb and resource, clearly distinguishing it from sibling batch tools like brc_batch_cash_payments or brc_batch_purchases. The rest of the description adds operational context without obscuring the core 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?

Provides explicit usage instructions: 'Call brc_route_request first,' 'Retain the returned routeToken... and pass the same token,' and 'Never invent a placeholder token.' It also warns that a routeToken is not permission to post and that confirmWrite/confirmDelete still apply, giving clear exclusions and sequencing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the prerequisite routeToken workflow, warns against placeholder tokens, and explicitly states that preview-before-posting and confirmWrite/confirmDelete still apply, which is important operational behavior. It does not, however, describe what the batch processing actually does to products or any 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 appropriately sized, with the first sentence stating the core purpose and subsequent sentences delivering actionable workflow and guardrails. Each sentence earns its place: the 20-item limit, the routeToken requirement, the sequencing instructions, the 'never invent a placeholder' warning, and the reminder about preview/confirmation. It is front-loaded, efficient, and free of redundancy.

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

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

The description covers the token workflow and batch size limit but leaves significant contextual gaps. It does not explain what a 'batch of products' entails (e.g., what fields each item object should contain), especially since the schema defines items only as 'object' with no internal structure. The output is also unspecified, and there is no output schema. Given the tool's complexity, the description is adequate but not 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 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it references routeToken and confirmWrite but does not elaborate on them more than the schema already does. The description's workflow guidance indirectly supports the routeToken parameter but does not add new semantic detail for any parameter.

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

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

The description opens with 'Processes a batch of products,' which uses a specific verb and resource, distinguishing it from other batch tools like brc_batch_customers or brc_batch_purchases. However, it does not specify whether the processing involves create, update, or delete actions, leaving the exact operation type implied rather than 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 explicit workflow instructions: call brc_route_request first, retain the returned routeToken through lookup/preview/confirmation, and pass it on the final transactional call. It also provides critical exclusions like 'Never invent a placeholder token' and clarifies that a routeToken is not permission to post, making usage guidance exceptionally clear.

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

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

With no annotations, the description carries the full burden. It discloses that routeToken is not permission to post, that preview-before-posting and confirmWrite still apply, and that counterparty confirmation is required. This goes beyond the schema. It does not mention failure modes or exact write side effects, but the disclosed constraints are substantial.

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

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

The description is a single coherent paragraph where every sentence contributes essential workflow or constraint information. It avoids fluff and 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?

The description covers the key workflow prerequisites and safety constraints: routeToken lifecycle, batch limit, and explicit counterparty confirmation. It does not explain return values (no output schema exists), and it omits some parameters like priceBasis, but the schema covers those. Given the tool's transactional complexity, the contextual coverage is strong.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces routeToken and confirmCounterpartyExplicit but does not add meaning beyond what the schema already provides. The workflow context (call brc_route_request first) is already present in the routeToken schema field.

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 'Processes a batch of purchases' which identifies the resource (purchases) and implies a batch operation, distinguishing it from sibling batch tools like brc_batch_sales_invoices or single purchase tools. The verb 'Processes' is somewhat generic but combined with 'batch of purchases' it is clear 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?

The description gives explicit operational guidance: call brc_route_request first, retain the returned routeToken, never invent a placeholder token, and set confirmCounterpartyExplicit only after explicit user confirmation. It does not explicitly name alternative tools or when not to use this tool, but the clear prerequisites and workflow context earn a 4.

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

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

With no annotations provided, the description carries the full burden. It discloses critical behavioral traits: the tool does not post immediately (preview-before-posting and confirmWrite/confirmDelete apply), token safety rules, and the explicit-confirmation requirement for counterparty. This goes well beyond what the schema alone provides.

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 dense paragraph of about 100 words. Every sentence contributes useful information (max items, workflow, token rules, confirmation requirements). It's not as tight as a two-sentence example, but for the complexity of this routed transactional tool, it is appropriately concise and front-loaded with the core purpose.

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 8 parameters, no annotations, and no output schema, the description covers prerequisites, token handling, and confirmation requirements thoroughly. The main gap is that it never states what 'processing' actually does (e.g., create quotes, update quotes) or what the tool returns on success. However, the routeToken workflow implies the action is predetermined, so 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 schema already has 100% parameter coverage, so baseline is 3. The description adds meaningful semantics around routeToken (the full lifecycle and prohibition on placeholders) and reinforces confirmCounterpartyExplicit. It doesn't add detail for every parameter, but the routeToken context is significant, raising it above baseline.

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

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

The description opens with 'Processes a batch of quotes,' a specific verb and resource that clearly distinguishes this tool from single-quote tools and other batch tools (e.g., brc_batch_sales_invoices). The subsequent context about the routeToken workflow further pins down its role as a transactional batch operation.

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 explicit step-by-step guidance: call brc_route_request first, retain the routeToken through lookup/preview/confirmation, pass the same token on the final transactional call, and never invent a placeholder. It also clarifies that routeToken is not permission to post and that confirmCounterpartyExplicit is required. This is far more than minimal and directly tells agents when and how to use the tool.

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

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

With no annotations provided, the description carries full disclosure burden. It reveals runtime blocking of productId 0/1, a 20-item batch limit, that routeToken is not permission to post, and that confirmWrite/confirmDelete still apply. This is exceptionally transparent about the tool's guardrails and safety 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 a single dense paragraph, but every sentence addresses a critical constraint or prerequisite. There is no filler or repetition of schema content. While it could be broken into structured bullets for readability, the length is justified by the tool's complexity and each 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 batch transactional tool with no output schema, the description is remarkably complete. It covers prerequisites (routeToken, counterparty confirmation), constraints (productId validity, 20-item limit), safety (preview-before-posting, confirmWrite), and fallback guidance (ask user, use service line). Nothing essential for correct invocation 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the significance of productId placeholders (0/1 blocked), the workflow for routeToken (must be retained and reused), and the strict confirmation requirement for counterparties. These enrich parameter understanding beyond the schema's basic 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 opens with a specific verb and resource: 'Processes a batch of sales credit notes.' This clearly identifies the tool's function and the 'batch' qualifier distinguishes it from singleton siblings like brc_create_sales_credit_note. The scope is 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 explicit when-to-use and workflow guidance: call brc_list_products first for product lines, call brc_route_request first to obtain a routeToken, and require confirmCounterpartyExplicit after explicit user confirmation. It also names alternative actions (creating/selecting a product or using a service line) and emphasizes when not to invent placeholders.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the 20-item limit, that routeToken is not permission to post, that preview-before-posting and confirmWrite/confirmDelete still apply, and that confirmCounterpartyExplicit is required after explicit user confirmation. It also warns against inventing placeholder tokens, providing substantial 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 a single paragraph of about 150 words. Every sentence contributes critical information about routing, confirmations, and batch limits. While it could be structured with bullets for readability, it is not verbose or redundant.

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

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

Given the complexity (8 parameters, no output schema, no annotations), the description covers the essential operational workflow: routing prerequisites, confirmation requirements, and batch limits. It does not explain return values (since no output schema exists) or define 'sales entries' relative to siblings, but it is sufficiently complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema for key parameters: it explains the routeToken workflow (call brc_route_request first, retain through lookup/preview/confirmation) and clarifies the confirmCounterpartyExplicit requirement (only after explicit user naming in the current conversation). This adds value beyond the 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 tool 'Processes a batch of sales entries', providing a specific verb and resource. It does not explicitly differentiate from sibling tools like brc_batch_sales_invoices or brc_batch_sales_credit_notes, but the name and batch context make the primary function clear.

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

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

The description provides clear usage context by requiring brc_route_request first and explaining the workflow (routeToken, preview, confirmation). It does not explicitly name alternative tools for single entries, but the batch workflow and prerequisites are well described.

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

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

With no annotations, the description carries the full burden and does so extensively. It discloses placeholder blocking (productId 0/1), VAT category validation, priceBasis handling, note default behavior, deliveryTo inclusion rules, routeToken not being posting permission, and the need for explicit counterparty confirmation. This goes far beyond typical descriptions.

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 dense paragraph with notable redundancy (e.g., productId 0/1 blocking is mentioned twice, 'preview-before-posting and posting' appears multiple times). While every sentence adds valuable content, the lack of bullet points or structure hurts scannability and it is longer than necessary.

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 thoroughly covers safety checks, routing, confirmations, and limits, but it does not describe the expected return value or response format (no output schema). Additionally, the 'items' array has an open schema (additionalProperties), and the description only clarifies note and deliveryTo, leaving other item fields unspecified. For a complex batch tool, this is a notable gap.

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

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

Although the schema already documents all 8 parameters, the description adds significant meaning: note defaults to customer name, deliveryTo is only included when explicitly provided, confirmCrAnalysisCategory is batch-level, routeToken is not permission, and confirmCounterpartyExplicit requires an explicit user statement. These nuances are not inferable from the schema 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 opens with 'Processes a batch of sales invoices,' which clearly identifies the verb, resource, and batch scope. It distinguishes itself from sibling batch tools (e.g., batch purchases, batch sales credit notes) and from single-invoice tools by the batch context.

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 explicit preconditions: call brc_route_request first, use brc_list_products for valid product IDs, and require user confirmations (confirmCrAnalysisCategory, confirmCounterpartyExplicit). It also warns against inventing tokens or reusing counterparties. However, it does not explicitly state when to choose this batch tool over the single-invoice brc_create_sales_invoice, leaving that comparison 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?

With no annotations, the description carries the transparency burden. It discloses the routeToken requirement, warns that a token is not permission, and states that preview-before-posting and confirmWrite/confirmDelete still apply. Yet it does not disclose the document-processing behavior implied by the schema, and its mention of confirmDelete does not correspond to any parameter in the schema, leaving gaps in behavioral understanding.

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 dense paragraph of five sentences, front-loading the purpose and then explaining the routing workflow. While there is minimal wasted wording, the density combined with the misleading resource and the irrelevant confirmDelete mention reduce its structural quality.

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 batch operation with 7 parameters, no output schema, and routing/confirmation requirements, the description is incomplete. It does not explain what an item in the batch must contain, what 'processes' means (create/update/delete), or what the success/failure response looks like. It also fails to reconcile the contradiction between 'sales reps' in the description and 'sales invoice/credit note items' in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some meaning for routeToken (never invent a placeholder, routing permission only) and reinforces confirmWrite, but it does not clarify the structure of the items array or the sales-document-specific parameters (priceBasis, confirmCrAnalysisCategory), and the reference to confirmDelete is absent 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 states 'Processes a batch of sales reps,' which names a specific verb and resource. However, the input schema's parameters (e.g., priceBasis 'Applies to every sales invoice/credit note item in this batch' and confirmCrAnalysisCategory 'Applies to every sales document item in this batch') indicate the actual operation is sales document processing, not sales rep processing. This mismatch makes the purpose misleading.

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 routing workflow instructions: call brc_route_request first, retain and pass the routeToken on the final transactional call, never invent a placeholder token, and respect preview-before-posting with confirmWrite/confirmDelete. However, it offers no guidance on when to use this tool versus sibling batch tools like brc_batch_sales_invoices, and the guidance is attached to an incorrectly described resource, making it unreliable.

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

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

With no annotations provided, the description carries the safety burden. It discloses that routeToken is not permission to post, that preview-before-posting and confirmWrite/confirmDelete still apply, and that actions are gated behind confirmation. It could add more about side effects or return behavior, but the core transactional safety is addressed.

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 and front-loads the core action ('Processes a batch of suppliers'). It contains no wasted words and each sentence contributes to the workflow understanding, though it slightly repeats schema content about confirmWrite.

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

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

Despite strong schema coverage, the description fails to define the structure of each supplier item in the 'items' array—the schema only says objects with additionalProperties allowed. It also does not explain what 'processes' actually does (create/update/delete), leaving the agent uncertain about payload construction and expected behavior. This is a significant gap for a complex batch tool.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds valuable context beyond the schema by explaining the routeToken lifecycle (retain across steps, never invent) and confirming that confirmWrite/confirmDelete apply. It does not detail item structure, but that is more a completeness issue than 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 'Processes a batch of suppliers,' which identifies the resource (suppliers) and batch aspect, but 'processes' is ambiguous about whether it creates, updates, or deletes supplier records. It does not clearly distinguish itself from brc_create_supplier or brc_update_supplier, relying on the batch prefix to imply multi-record handling.

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 workflow guidance: call brc_route_request first, retain the returned routeToken through lookup/preview/confirmation, and pass the same token on the final transactional call. It also warns against inventing placeholder tokens and clarifies that a routeToken does not bypass confirmation, though it does not explicitly name alternatives for single vs batch 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?

Mentions returning warnings, and the 'check' nature implies no side effects. However, without annotations, it could explicitly state read-only behavior or prerequisites.

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 plus an alternative reference, every word contributes. No 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?

Given the simplicity of a check tool with no output schema, the description adequately covers return value (warnings), usage context, and differentiation from sibling.

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 covers 100% of parameters, and the description adds context (e.g., enumerates allowed workflows with explanatory note). The connectionRef parameter has a lengthy explanation 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 tool checks BRC company processing settings before VAT-sensitive or payment-terms-sensitive workflows, and explicitly distinguishes from the sibling brc_company_readiness_check by specifying a different 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?

Provides explicit guidance: use before creating/changing records for a single workflow, and name the alternative tool for overall readiness checks.

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

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

No annotations are present, so the description must fully disclose behavioral traits. It mentions clearing credentials from memory but does not specify side effects, such as what happens to active sessions or whether the action is reversible. The description is too brief to be transparent.

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

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

The description is a single sentence, which is concise, but it sacrifices completeness. It could be expanded to include important details without being overly 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 destructive operation that clears all API keys, the description is insufficient. It does not explain the return value (e.g., success message or error), nor does it cover potential impacts or confirmations. The single parameter is well-described, but the overall context of use is lacking.

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 100%, with the parameter connectionRef described in detail within the schema. The tool description adds no extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description clearly states it clears all connection credentials for all company contexts from MCP server memory, which defines the verb and resource. However, it does not distinguish from the sibling tool brc_clear_company_api_key (singular), so it lacks sibling differentiation.

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 like brc_clear_company_api_key or brc_clear_audit_log. There is no mention of prerequisites or context for usage.

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

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

No annotations provided, so description carries full burden. It explains the two-step confirmation flow, preview behavior, and that Red waits for confirmation. However, it does not explicitly state that the audit log entries are permanently deleted or destroyed, which is a critical behavioral trait for a clear operation.

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

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

The description is slightly verbose but well-structured with actionable instructions. It front-loads the core purpose and then provides detailed workflow steps. Could be more concise, but 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?

Given the schema covers all parameters completely and the description adds workflow guidance, the tool is well-documented. No output schema exists, but the description implies the response includes a preview on first call and a success indicator on confirmation, which is sufficient for an agent to understand the interaction.

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 100% with descriptions for all 3 parameters. The description adds context beyond schema for confirmWrite, explaining its role in the confirmation workflow and that 'Passing preflight is not confirmation.' This adds meaningful guidance.

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 clears the Red audit log for this MCP server session. It distinguishes itself from sibling tools like brc_list_audit_log by specifying the action (clear) and the scope (session).

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 explicit step-by-step workflow: first call without confirmWrite:true returns preview, then show plain-English preview in chat, then retry with confirmWrite:true only after user confirmation. Also warns not to set confirmWrite:true on first call or without explicit confirmation.

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 only states 'clears' without detailing side effects (e.g., whether it invalidates the connection, requires re-authorization, or is idempotent). Since no annotations are provided, the description should disclose more behavioral traits.

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

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

The description is a single sentence of 11 words, which is concise and to the point. However, it could include more useful context 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?

As a destructive mutation tool with no output schema and no annotations, the description is incomplete. It does not clarify what happens after clearing (e.g., need to reconnect), success indicators, or error scenarios.

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

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

Both parameters have schema descriptions (100% coverage). The tool description adds no new meaning beyond them; it merely restates 'named company context'. 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 clearly states the specific verb 'clears' and the resource 'API key for a named company context', distinguishing it from sibling tools like brc_clear_all_company_api_keys which clears all keys.

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 explicit guidance on when to use this tool versus alternatives like brc_clear_all_company_api_keys, or prerequisites such as having an active connection. The connectionRef parameter description provides some context but does not address tool selection.

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

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

With no annotations, the description must disclose behavioral traits, and it does so well. It clearly states that routeToken is not permission to post, that preview-before-posting and confirmWrite/confirmDelete still apply, and that the token must come from brc_route_request. It does not fully describe the irreversible effects or return behavior of closing a quote, but covers the critical safety and routing semantics.

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 sequence of five purposeful sentences, each carrying essential routing or safety information. It is slightly longer than minimal but every sentence earns its place, and the structure is logical: what it does, prerequisites, workflow, and safety caveats.

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 (no annotations, no output schema, transactional nature), the description covers the essential routing workflow, token handling, and confirmation requirements. It could more explicitly state the business effect of closing a quote (e.g., status change, reversibility), but the routing protocol is the primary complexity and it is well 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 coverage is 100%, so the baseline is 3. The description adds substantial value beyond the schema by explaining the routeToken lifecycle (call brc_route_request first, retain token through the workflow, never invent a placeholder) and reiterating that confirmWrite still applies. This gives the agent practical guidance not explicit in the JSON schema 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 begins with 'Closes a BRC quote,' which is a specific verb and resource, clearly distinguishing it from sibling operations like brc_delete_quote, brc_reopen_quote, or brc_update_quote. It does not explicitly name alternatives or contrast them, but the verb 'close' makes the 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 provides explicit workflow guidance: call brc_route_request first, retain the routeToken through lookup/preview/confirmation, and use the same token on the final transactional call. It also warns against inventing placeholder tokens and states that preview-before-posting and confirmWrite still apply. It lacks explicit exclusions or alternative-tool comparisons, preventing 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?

No annotations provided, so description carries full burden. It states 'Read-only' indicating no side effects, and lists the data reported. However, it does not mention rate limits or specific error conditions, which are minor omissions.

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 plus a helpful contrast with sibling. No unnecessary words, front-loaded with purpose, and 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?

Given no output schema, the description lists the types of data returned (connection status, financial year, reference data, etc.). It also contrasts with a sibling tool, making the context complete for a readiness check 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 coverage is 100% with both parameters already described in the input schema. The description does not add additional semantic meaning beyond what the schema provides, meeting baseline.

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

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

The description clearly states 'Read-only company health and readiness check' and lists specific reported items (connection status, financial year, etc.). It also distinguishes from the sibling brc_check_transaction_settings by contrasting 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?

Explicitly says 'Use this for overall company readiness before starting work' and contrasts with brc_check_transaction_settings for specific VAT-sensitive workflows, providing clear when-to-use and when-not-to-use guidance.

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

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

No annotations exist, so the description carries full burden. It discloses that the tool claims a completed secure connection code, returns an opaque connectionRef for session rotation, and should keep reusing the same connectionRef. It also clarifies that connectionRef is not an API key and does not expose credentials. Slightly lacking a clear statement on whether this is a destructive/mutating action, but the context of 'completing a connection' implies state change.

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 somewhat verbose, repeating the purpose with three synonyms (confirm, finish, complete) and including redundant phrases like 'This tool is brc_confirm_company_connection.' It front-loads the core purpose but could be trimmed by ~30% without losing meaning.

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 has 2 parameters, no output schema, and no annotations, the description covers usage context (after secure page, with confirmation code), the return value (connectionRef), and lifecycle advice (keep reusing, don't restart). It's almost complete but could briefly mention what happens if confirmation fails.

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 100%, so baseline is 3. The description adds value by explaining the 'code' comes from the success page and the 'connectionRef' is opaque, reused across calls, and must not be shown to users. This goes beyond the schema's bare 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 explicitly states the tool confirms/finishes/connects a company connection after a secure page. It specifies the verb (confirm/finish/complete) and resource (company connection), distinguishing it from siblings like brc_start_company_connection and other crud 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 clear when-to-use triggers (user says confirm, finish, complete connection, or pastes a confirmation code), explicitly says to use after the secure page, and warns against calling brc_start_company_connection while the connectionRef is valid. Also tells the agent to silently pass connectionRef and not show it to users.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key side effects (generates a reversing child transaction), the routing prerequisite, the preview-before-posting requirement, and the meaning of confirmWrite. It also explicitly warns that a routeToken is not permission to post. This is comprehensive and honest about the tool's operational constraints.

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

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

The description is dense but every sentence serves a purpose: purpose, side effect, confirmWrite warning, routeToken requirement, sequencing, token retention, token warning, and final reminder. No filler or repetition. It is appropriately front-loaded with the core purpose before diving into workflow details.

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

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

Given the complexity of this tool (7 required parameters, routeToken workflow, confirmWrite semantics), the description covers all critical operational context. It explains the parent/child transaction behavior, the routing dependency, and the confirmation step. The input schema fully documents all parameters, so the description need not repeat them. The only minor omission is return value details, but with no output schema and the focus on workflow, 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the routeToken lifecycle and the confirmWrite timing, which are not fully captured in the parameter descriptions alone. It reinforces these critical parameters' semantics without restating every field.

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: 'Creates a new parent Accrual.' It distinguishes this from sibling tools by noting the parent/child reversing transaction behavior, which is unique to accruals and not mentioned for other create_* tools. The purpose is immediately clear and unambiguous.

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

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

The description provides explicit workflow guidance: call brc_route_request first, retain the routeToken, pass the same token on the final transactional call, and never invent a placeholder token. It also clearly states when not to call with confirmWrite=true (until user explicitly confirms). This goes beyond vague usage hints and gives actionable prerequisites and sequencing.

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

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

With no annotations provided, the description carries full disclosure burden. It reveals confirmation requirements, the side-effect that omitting categoryId may auto-create a Bank Payments category, and that nominalAcCode must reference an existing account. It also states preview-before-posting still applies. A brief mention of return behavior would round it out, but the safety and side-effect profile is well 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?

The description is thorough but not bloated; every sentence adds operational value. It could be tightened with a more structured format (bullets) to improve scannability, but it avoids redundancy except for the routeToken emphasis.

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 large parameter set (20), lack of annotations, and no output schema, the description goes a long way: it covers workflow prerequisites, required vs optional fields, confirmation, and auto-creation behavior. It omits guidance on several optional fields and doesn't indicate return values, which would be helpful for a transactional 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 coverage is 55%, so the description must compensate. It explicitly names required fields (acCode, details, lastChq, nominalAcCode) that aren't marked required in the schema, explains categoryId's auto-creation behavior, and details the routeToken lifecycle. However, many optional fields (address, sortCode, accountNumber, etc.) remain undocumented, which prevents a 5.

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

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

The description opens with 'Creates a BRC bank account' – a specific verb and resource. It clearly distinguishes itself from update/delete/get/list bank account tools. The action is 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 provides explicit workflow guidance: call brc_route_request first, retain the routeToken through preview/confirmation, and do not set confirmCreate=true until user confirmation. It also warns that routeToken is not permission to post, which clarifies when the tool should be invoked.

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

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

With no annotations supplied, the description carries the full behavioral burden and does so thoroughly. It discloses that a routeToken is not posting permission, that preview-before-posting and confirmWrite/confirmDelete still apply, and that confirmCounterpartyExplicit must only be true after explicit user confirmation, plus it warns against inventing placeholder tokens. These are non-obvious, safety-critical behaviors beyond what the schema communicates.

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

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

The description is longer than average but every sentence earns its place: it covers mode selection, the routeToken lifecycle, confirmation gates, and category validation. It is front-loaded with the core purpose and avoids filler, though there is slight redundancy with the routeToken wording already present in the schema.

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 20-parameter transactional tool with no annotations and no output schema, the description supplies the essential workflow context: call brc_route_request first, retain the token, enforce preview-before-posting, and gate on explicit counterparty confirmation. Remaining details like connectionRef, entryDate, and procDate are already covered by the input schema, so the description is sufficiently complete despite not describing return values.

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

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

Schema coverage is high at 85%, so the baseline is 3, but the description adds valuable relational meaning by grouping parameters into three mutually exclusive modes (supplierId+ledger, bankAccountId+lodgement, analysisCategoryId+accountCode) and imposing the CP01-CP03 category constraint. This enhances understanding beyond the individual parameter descriptions without needing to restate every field.

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 the specific verb and resource 'Creates a BRC cash payment' and then distinguishes three concrete modes: supplier payments, bank lodgements, and analysed expenses. This makes the tool's purpose unambiguous and separates it from sibling create tools like brc_create_cash_receipt and brc_create_payment.

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

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

It gives explicit guidance on which parameter combinations to use for which scenario and clearly instructs the agent to call brc_route_request first and pass the returned token through to the final transactional call. It does not name alternatives to use or exclude, but the mode-specific usage conditions are clear enough to guide selection.

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

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

With no annotations, the description carries full behavioral disclosure. It transparently explains that routeToken is not permission to post, that preview-before-posting and confirmWrite apply, and that VAT fields are conditionally sent based on a company setting. It does not cover return values or error behavior, but for a mutating tool it discloses key safety and workflow traits.

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

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

The description is about 120 words and every sentence contributes useful workflow or safety information. It is front-loaded with the purpose and then organized into prerequisites and confirmation requirements. It is verbose but appropriate for a complex transactional tool with no annotation support.

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 thoroughly documents the routing and confirmation workflow, which is essential for correct use. However, it does not explain return values, error handling, or how to structure the raw payload versus flat fields. Given 32 parameters, nested objects, and no output schema, these gaps reduce 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 coverage is only 16%, so the description must compensate. It adds meaningful context for routeToken, confirmCounterpartyExplicit, entryDate/procDate defaults, and VAT conditional fields. However, it leaves the remaining 28 parameters including total, acCode, ledger, details, and nested objects without explanation, and only generically refers to 'common flat fields'.

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 'Creates a BRC cash receipt,' which is a specific verb and resource. It clearly identifies the tool's function but does not explicitly distinguish it from similar siblings like brc_create_cash_payment or brc_batch_cash_receipts.

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 usage context: call brc_route_request first, retain the routeToken, and pass it on the final transactional call. It also states when confirmCounterpartyExplicit is required. However, it does not mention alternative tools for other transaction types or explicitly state 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?

With no annotations provided, the description carries full burden and excels: it discloses required payload fields, instructs to ask the user rather than invent values, forbids placeholders, notes opening balance behavior, warns about email/name mismatches, and clarifies that routeToken is not permission to post (confirmWrite still applies). This is comprehensive, honest behavior disclosure beyond what schemas alone 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 longer than average but every sentence earns its place given the tool's complexity and safety requirements. It front-loads the core purpose and then systematically covers required fields, forbidden inventions, exclusions, email mismatch, routing, and confirmation. It is dense but not wasteful; could be slightly tightened but remains 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?

Given the tool's complexity (5 params, nested payload, no output schema, no annotations), the description covers prerequisites, routing, confirmation, placeholders, opening balances, and email checks — nearly all critical context. The only gap is that it does not mention what the tool returns (e.g., created customer ID or success/failure) or how errors are surfaced, which would be helpful for a create operation without an output schema.

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

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

Although schema descriptions cover 100% of parameters, the payload parameter is just 'Raw BRC-compatible payload' — the description adds essential semantics by specifying required payload fields (code, name) and optional fields, and by explaining how to handle missing user input. It also clarifies the routeToken and confirmWrite usage, adding meaning far beyond the schema's generic 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 starts with a specific verb+resource: 'Creates a BRC customer using a raw BRC payload,' clearly distinguishing it from batch creation (brc_batch_customers) and other entity creation tools. It also contrasts with update/delete tools by focusing on creation and explicitly listing what it does not do (e.g., opening balance transactions).

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 workflow guidance: call brc_route_request first, retain the routeToken, and use the same token on the final transactional call. It also states an exclusion (does not create/update opening balance transactions) and instructs to warn the user for opening balances. However, it does not explicitly compare with alternatives like brc_batch_customers or brc_update_customer, leaving some ambiguity about when single-create is preferred over batch.

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

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

With no annotations provided, the description carries full disclosure responsibility. It transparently explains the preview-before-posting workflow, that a routeToken is not permission to post, and that confirmWrite/confirmDelete still apply, which are critical behavioral traits for a create operation. It also warns against placeholder tokens.

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 focused paragraph with the purpose front-loaded. Every sentence adds essential information—creation, balance requirement, confirmation gate, routeToken workflow, and safety constraint—without fluff.

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 (9 parameters, transactional nature, no output schema), the description communicates the critical workflow and safety constraints. However, it does not describe the return value/response structure or explicitly mention connectionRef, though the schema covers the latter. Overall, it is adequately complete for an agent to act safely.

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 all parameters with descriptions, but the tool description adds crucial semantics for the routeToken (workflow origin, retention requirement) and confirmWrite (must be gated on explicit user confirmation). This goes beyond the schema's basic type/length info, though other parameters rely on their 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 opens with 'Creates a new Nominal Journal Batch,' a specific verb and resource that clearly differentiates this from sibling tools like brc_update_nominal_journal_batch or brc_create_accrual. It further clarifies the core business rule (balanced debit and credit lines), which aids selection.

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 directs the agent to call brc_route_request first, retain and pass the returned routeToken, and never invent a placeholder. It also states not to call with confirmWrite=true until the user explicitly confirms after reviewing the preview, giving clear when-to-call and when-not-to-call guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that routeToken is not permission to post, that preview-before-posting and confirmWrite/confirmDelete still apply, and that confirmCounterpartyExplicit requires explicit user confirmation. These are critical safety and workflow constraints.

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 yet efficient. Every sentence earns its place: it explains the core purpose, the two usage patterns, the routeToken workflow, and the confirmation rules. There is no redundancy or filler.

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

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

The description thoroughly covers workflow, token handling, and confirmation requirements, which is essential for a complex transactional tool. However, with no output schema, it does not describe the return value or error behavior, leaving a minor gap for an agent that needs to know what to expect after 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?

Schema coverage is 68%, and many parameters already have solid descriptions. The description adds value by explaining the two parameter modes and the constraint that analysisCategoryId must be from the Payments book (BP01-BP06) and accountCode must match the category. This goes beyond the schema's per-parameter descriptions but does not cover every parameter.

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

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

The description opens with 'Creates a BRC payment from the Payments book', which clearly states the action, resource, and source book. It further distinguishes between two payment modes (supplier vs analysed bank payments), helping the agent select this tool over siblings like brc_create_cash_payment.

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

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

The description provides explicit usage guidance: 'Use supplierId for supplier payments, or analysisCategoryId + accountCode for analysed bank payments.' It also mandates the routeToken workflow and warns against inventing tokens. However, it does not explicitly state when not to use this tool or name alternative tools, 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It clearly states that this is a write operation that creates a child transaction automatically, that routeToken alone is not permission to post, and that preview-before-posting plus confirmWrite confirmation still apply. It also warns against inventing placeholder tokens, adding critical safety context.

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

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

The description is efficiently organized: it leads with the primary action, then immediately states the most critical safety caveat, followed by the required workflow sequence. Every sentence adds essential information without redundancy or filler. The structure makes it easy for an agent to parse and act on.

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

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

Given no output schema and no annotations, the description provides comprehensive context for a complex transactional tool. It explains the parent/child transaction behavior, the required preliminary route_request call, the token management rules, and the confirmation requirement. This covers the critical operational aspects an agent needs to execute 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 100%, providing a strong baseline. The description enhances parameter understanding by detailing the routeToken lifecycle (source, retention, reuse, no placeholders) and reiterating the confirmWrite gating, which goes beyond the schema's individual parameter descriptions. It does not fully redefine all 11 parameters but adds meaningful operational context for the most complex ones.

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: 'Creates a new parent Prepayment.' It further distinguishes this tool from sibling create tools by noting the parent/child transaction behavior and the reliance on shared logic to generate the reversing child. This makes the purpose unambiguous and unique.

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 workflow guidance: call brc_route_request first with the complete original request, retain the returned routeToken, and pass it on the final transactional call. It also explicitly states a when-not condition: do not call with confirmWrite=true until the user has reviewed the preview and confirmed. These are clear directives for correct usage.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the need for a routeToken, that it is not permission to post, and that preview-before-posting and confirmWrite/confirmDelete still apply. It also warns against inventing tokens, which is important safety context. However, it does not describe response behavior or error cases, but the core transactional safeguards are well 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?

The description is a compact paragraph of four sentences, each adding critical workflow information. It is front-loaded with the core purpose, then details prerequisites and constraints. There is no filler or repetition of schema content, and 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?

Given the tool's complexity (5 params, nested payload, no output schema, no annotations), the description addresses the most critical operational context: the routeToken workflow, preview/confirmation requirements, and the fact that it is transactional. The schema covers all parameter details. The only gap is the lack of mention of return value/response structure, but the output schema absence makes that less 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?

Schema description coverage is 100%, so the baseline is 3. The schema already provides detailed descriptions for payload, routeToken, companyName, confirmWrite, and connectionRef. The description adds context on routeToken sequencing and confirms the confirmWrite gating, but it largely restates what the schema already conveys. No additional parameter-level semantics are provided 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 tool's function: 'Creates a BRC product using a raw BRC payload.' This is a specific verb+resource combination that distinguishes it from other create_* tools in the sibling list (e.g., brc_create_customer, brc_create_sales_invoice). The reference to the raw payload and route workflow further ties it to a specific transactional context.

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

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

The description explicitly instructs the agent to call brc_route_request first, retain the routeToken through lookup/preview/confirmation, and pass the same token on the final transactional call. It also states 'Never invent a placeholder token' and clarifies that a routeToken is not permission to post, providing clear when-to-use and workflow guidance. This goes beyond generic usage by naming the prerequisite tool and sequencing.

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

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

No annotations are provided, so the description carries full burden. It discloses important behavioral traits: historical dates are not automatically refused (the endpoint decides), routeToken is routing permission only (not posting permission), and confirmWrite/confirmCounterpartyExplicit must follow user confirmation. It does not mention rate limits, idempotency, or error handling, but the core workflow and safety constraints are well covered. Slightly more could be said about the nature of the write operation (destructive, irreversible) but it's 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 longer than average but retains no wasted sentences. Every sentence adds critical context. It is front-loaded with purpose and then flows into usage guidelines, behavioral notes, and parameter conditions. Could be slightly more concise in places (e.g., 'Never invent a placeholder token' is clear but redundant with earlier guidance), but overall 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 18 parameters, no output schema, and no annotations, the description is highly complete. It covers the multi-step workflow dependency on brc_route_request, the date handling behavior, and the confirmation requirements. It does not describe the return value or error responses, but the tool's output (likely success/failure) is implicitly understood. The description enables an agent to use the tool correctly in a complex workflow.

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

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

The schema has 100% parameter description coverage, but the description adds significant value beyond the schema. It explains the conditional requirement for 'reference', the semantics of 'routeToken' (opaque, from route_request, not permission to post), and the strict conditions for 'confirmWrite' and 'confirmCounterpartyExplicit'. It also clarifies the reuse of 'connectionRef'. This is a model of how to enrich 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 it creates a BRC purchase using structured MCP fields. It distinguishes itself from the sibling tool brc_create_purchase_gen_ref by mentioning when to prefer that alternative (when the company is configured for manual purchase references). The verb 'creates' and resource 'BRC purchase' are specific and unambiguous.

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

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

The description provides explicit usage guidance: requires a reference when manual references are configured, otherwise prefer the gen_ref sibling. It outlines the prerequisite call to brc_route_request, the need to retain routeToken, and the conditions for confirmWrite and confirmCounterpartyExplicit. It also specifies to never invent a placeholder token. This is comprehensive and actionable.

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

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

No annotations exist, so the description carries the full burden. It clearly states that a historical date is not automatically refused, and that the agent should attempt the request and let the endpoint decide. It also explains that routeToken is not permission to post, and that preview-before-posting and confirmWrite/confirmDelete still apply. This is thorough, though it could mention what happens on success/failure more explicitly.

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 fairly concise for the complexity involved, covering purpose, prerequisites, workflow, and constraints in a few sentences. It front-loads the primary purpose. Minor redundancy (e.g., 'routeToken is not permission to post' could be more concise, but it's not wasteful.)

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 high parameter count (17), lack of output schema, and no annotations, the description does a good job of covering the essential workflow and constraints. It does not document return values, but without an output schema that is expected. It could be more complete by describing the error handling or what a successful response looks like, but the provided context is sufficient for an agent to use the tool correctly.

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

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

Schema description coverage is very low (29%), so the description must compensate. While the description focuses on workflow and constraints rather than individual parameter semantics, it does add critical context for routeToken, confirmWrite, and confirmCounterpartyExplicit that is not fully explained in the schema. For the 14 required parameters, the description does not detail each one, but the workflow guidance is essential. A slightly higher score is warranted given the complexity and the description's focus on the most important 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 clearly states it creates a Purchases Book purchase with a generated reference. It explicitly distinguishes its use case (auto-generated references) from a standard purchase creation tool. This is a specific verb+resource+context, and the sibling list includes brc_create_purchase, which supports the differentiation.

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

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

The description provides explicit when-to-use guidance (company configured for auto-generated purchase references). It also gives detailed workflow instructions: call brc_route_request first, retain and pass the routeToken, never invent a placeholder token, and the need for preview-before-posting and confirmWrite. It also specifies the requirement for confirmCounterpartyExplicit and warns against reusing counterparty from earlier previews.

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

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

With no annotations provided, the description carries the full burden. It clearly states that nothing is written until confirmWrite is true, that previews are required before posting, and that routeToken is not permission to post. It also warns about inventing placeholder tokens and reusing counterparties without confirmation. It could add more about error handling or side effects of creating a quote.

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 well-organized, front-loading the core action and then addressing prerequisites, confirmations, and exclusions. It is slightly long but every sentence adds necessary context for a complex tool with 30 parameters. No waste, but could be broken into clearer sections.

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 (30 parameters, 20 required, no output schema, 40% schema coverage), the description covers most prerequisites, confirmation logic, and sibling interactions. It lacks explicit information about the return value or what happens on error. However, for a transactional create tool with many interdependent fields, the description is thorough.

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%, but the description adds extensive context for many parameters beyond what the schema provides. It explains the purpose and sourcing of saleRepId, saleRepCode, analysisCategoryId, accountCode, routeToken, confirmWrite, confirmCounterpartyExplicit, confirmCrAnalysisCategory, and reference. This compensates well for the schema gaps.

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

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

The description clearly states that this tool creates a BRC quote using structured MCP fields. It distinguishes itself from sibling tools like brc_create_quote_gen_ref by mentioning when to use that alternative, and the detail about manual/unknown references further sharpens its 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 provides explicit guidance on when to use this tool (manual or unknown quote references with user-provided reference), what not to use (default sales reps, default analysis categories), and prerequisites (routeToken from brc_route_request, saleRepId, analysisCategoryId). It also explains confirmation fields like confirmCounterpartyExplicit and confirmCrAnalysisCategory.

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

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

With no annotations provided, the description carries full burden. It covers key behavioral traits: nothing is written until confirmWrite=true, preview-before-posting requirement, routeToken routing vs. posting permission, and confirmation steps for counterparty and analysis category. Lacks details on error handling or rate limits, but the main behaviors are well disclosed.

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

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

The description is lengthy (~300 words) but every sentence provides necessary context for a complex tool. It front-loads the purpose and then systematically covers workflow, prerequisites, and confirmation rules. Could be slightly more concise, but all information is relevant 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 the high complexity (30 params, 20 required, no output schema, many siblings), the description is quite complete. It explains the full workflow, required preconditions, and confirmation steps. It does not describe the return value or error handling, which would be helpful, but overall it provides sufficient context for correct tool 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?

Schema description coverage is low (40%). The description adds meaning for critical parameters like saleRepId, saleRepCode, analysisCategoryId, accountCode, routeToken, and the boolean confirm fields. However, many other parameters (e.g., companyName, customerOwnerId, entryDate, productId, quantity) are not explained in the description beyond what's in the schema. The description compensates partially but not fully for the 30 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 explicitly states 'Creates a BRC quote with a generated reference' and specifies when to use it: when quote references are auto-generated or after user confirmation. This clearly distinguishes it from siblings like brc_create_quote (manual reference) and other create 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 when-to-use criteria ('Use only when quote references are auto-generated...'), prerequisites (saleRepId, routeToken, analysisCategoryId), and exclusions ('Do not use default or demo sales rep values'). It also references the required workflow (call brc_route_request first) and confirms alternatives.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It goes far beyond 'creates' by warning that routeToken is not permission, that preview-before-posting and confirmWrite/confirmDelete still apply, and that default/demo values must never be used. It also reveals when confirmCrAnalysisCategory and confirmCounterpartyExplicit may be set, providing deep transparency into the tool's guardrails.

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

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

The description is long but every sentence earns its place. It is organized by requirement blocks (sales rep, analysis category, route token, counterparty confirmation) and avoids filler. The density is high and directly actionable, with no redundant phrases.

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 (25 parameters, no annotations, no output schema), the description covers the essential workflow: routing, prerequisites, confirmation gates, and how to obtain missing values. The only notable gap is not describing the return payload or success indicators, but for a create tool this is secondary and likely inferable.

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 32%, so the description compensates for the non-obvious parameters: saleRepId/saleRepCode origin, analysisCategoryId/accountCode sourcing, confirmCrAnalysisCategory semantics, routeToken retention, and confirmCounterpartyExplicit requirements. Some standard parameters like entryDate or netAmount are left to schema names, but the high-risk parameters are well explained.

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: 'Creates a BRC sales credit note.' It also differentiates from the closest sibling by explicitly pointing to brc_create_sales_credit_note_gen_ref for auto-reference configurations, making the tool's role 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 gives clear when-to-use guidance: use this tool when manual sales references are configured, otherwise prefer the gen_ref sibling. It also provides an explicit workflow: call brc_route_request first, list sales reps if missing, and set confirmation flags only after user confirmation — turning the description into an actionable playbook.

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

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses the required saleRepId/saleRepCode, analysisCategoryId/accountCode, the routeToken lifecycle, the fact that routeToken alone is not permission to post, preview-before-posting requirements, and the precise conditions for confirmCrAnalysisCategory and confirmCounterpartyExplicit. This is rich, non-obvious behavioral detail beyond what any schema could convey.

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

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

The description is long but every sentence carries necessary information for a complex, multi-step transactional tool. It is front-loaded with the main purpose and then logically sequences prerequisites and confirmations. Slight structural improvement could be made with bullet points, but the density is justified.

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 all major invocation requirements: company configuration, sales rep validation, analysis category handling, route token workflow, and explicit confirmation gates. It doesn't mention return values, but with no output schema and a create tool, this is less critical. Overall it is complete for agent invocation in a complex workflow.

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?

While schema coverage is high (86%), the payload parameter is an opaque object. The description adds crucial meaning by specifying that payload must contain saleRepId, saleRepCode, analysisCategoryId, and accountCode, and clarifies that confirmCrAnalysisCategory should only be true after user confirmation. This goes beyond the schema's generic boolean descriptions and clarifies the nested structure.

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: 'Creates a BRC sales credit note with an auto-generated reference using a raw BRC payload.' This clearly states what the tool does and distinguishes it from sibling brc_create_sales_credit_note by specifying the auto-generated reference 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?

The description says 'Use when the company is configured for auto-generated sales references,' which gives clear when-to-use context. It also specifies to call brc_route_request first and includes explicit 'Do not use default or demo sales rep values' exclusions. However, it never explicitly names the non-gen-ref sibling tool as the alternative, so the guidance is strong but not fully explicit about alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond the schema by explaining that a routeToken is not permission to post, that preview-before-posting and confirmWrite/confirmDelete still apply, and that a placeholder token must never be invented. This is safety-critical context that directly informs correct invocation.

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

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

The description is front-loaded with the core purpose and then flows through the workflow requirements in a logical order. Every sentence earns its place, but the description is somewhat dense and lengthy, which is justified given the complex routing workflow.

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 (17 parameters, no annotations, no output schema), the description adequately covers the critical routing and confirmation steps needed for correct invocation. It does not describe the return value or error behavior, but the primary usage requirements are well specified.

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%, so the description must compensate. It adds valuable meaning for routeToken (source, retention, reuse, not permission) and confirmCounterpartyExplicit (explicit user confirmation required), which are non-obvious. However, it does not explain the remaining 14 required parameters (e.g., netAmount, vatRateId, procDate), leaving a large 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 it creates a BRC sales entry using structured MCP fields, providing a specific verb and resource. It doesn't explicitly distinguish itself from sibling create tools like brc_create_sales_invoice, but the resource 'sales entry' is distinct and the purpose is 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 gives explicit workflow guidance: call brc_route_request first, retain the routeToken, pass the same token on the final transactional call, and require confirmCounterpartyExplicit once the user explicitly names/confirms the counterparty. It clearly defines prerequisites and sequencing but does not mention alternatives or exclusions relative to other create 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure and does so extensively: 'Nothing is written to Big Red Cloud until you confirm,' productId 0 and 1 are blocked at runtime, non-Sales VAT rates are blocked, and routeToken does not grant posting permission. It also explains the preview-before-posting and confirmation workflow in 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 extremely long and runs as a dense single block, mixing parameter-specific warnings with workflow prerequisites. There is redundancy—'Nothing is written until you confirm' and the product-name-note warning both appear more than once—and the content would be easier to scan with bullets or section breaks. However, every sentence carries substantive safety or workflow guidance, so the length is partially justified by 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 28-parameter transactional tool with no output schema, the description is exceptionally complete: it documents prerequisites (route_request, sales rep lookup, product lookup), blocked inputs, confirmation flags, VAT constraints, and the preview-before-posting flow. An agent has enough context to correctly sequence lookups, previews, and the final posting 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 coverage is only 57%, but the description compensates by adding rich semantics for key parameters: priceBasis meanings for gross/net, note defaulting to customer name, deliveryTo not being defaulted, routeToken's role, and the confirm* flags' exact triggering conditions. It also warns against misusing product names as notes and explains where productId/productCode come from.

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

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

The first sentence clearly states the tool 'Creates a BRC sales invoice using structured MCP fields,' specifying both the verb and the resulting resource. It also distinguishes itself from the sibling brc_create_sales_invoice_gen_ref by noting when the reference is required and when the alternative should be preferred.

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

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

The description gives explicit guidance on when to use this tool versus brc_create_sales_invoice_gen_ref, and it names required predecessor actions like brc_route_request and brc_list_products. It provides strong exclusion guidance, such as not defaulting to CR01/Customer, not using placeholder product IDs, and not inventing delivery addresses.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It clearly states that nothing is written to Big Red Cloud until confirmation, preview-before-posting shows what will be posted, Red validates totals before posting, and certain values (productId 0/1, non-Sales VAT rates) are blocked at runtime. It also explains defaults for note and deliveryTo, and requires routeToken and explicit counterparty confirmation.

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 overly long and repetitive. The preview/write-confirmation behavior is stated multiple times, and the note field is described both in the open and later in an 'Optional' block. The structure mixes high-level guidance with field-level documentation, making it harder to scan.

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 create tool with nested objects, no output schema, and no annotations, the description is remarkably complete. It covers usage conditions, prerequisites, validation behavior, safety controls, blocked inputs, and required confirmations. No critical context appears 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 description adds substantial meaning beyond the input schema. It explains the nested productTrans[] and acEntries[] structure, required header fields, validation rules (qty × unit price, totals reconciliation), the behavior of note and deliveryTo, the priceBasis requirement for Gross Price Entry, and the confirm flags. Although schema coverage is 100%, the schema descriptions are terse; the tool description provides critical guidance.

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: 'Creates a BRC sales invoice with an auto-generated reference using a raw BRC payload.' It distinguishes this tool from brc_create_sales_invoice by stating it is used when the company is configured for auto-generated sales references.

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

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

The description explicitly states when to use the tool ('Use when the company is configured for auto-generated sales references'), provides prerequisites (call brc_route_request, list sales reps, list products), and gives exclusions (do not use demo sales reps, do not block non-Sales VAT rates). It also names sibling tools like brc_list_products and brc_list_sales_reps as needed alternatives.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that 'A routeToken is not permission to post — preview-before-posting and confirmWrite/confirmDelete still apply,' and warns 'Never invent a placeholder token.' This adds critical behavioral context beyond the raw schema, but could further clarify expected outcomes or error 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?

The description is four sentences long, each earning its place: purpose, routeToken requirement, usage workflow, and safety caveat. It is front-loaded with the core purpose and contains no redundant or filler content.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description effectively covers the critical non-obvious workflow: the routeToken prerequisite and the preview/confirmation requirement. It doesn't explain return values or post-creation behavior, but the schema already documents the parameters, and the workflow context is the most important missing piece.

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%, providing full parameter documentation. The description adds meaningful value by explaining the routeToken's origin and lifecycle ('Requires routeToken from brc_route_request... Retain the returned routeToken...'), which goes beyond the schema's static definition and clarifies the parameter's dynamic role.

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 'Creates a BRC sales rep using structured MCP fields,' identifying the specific verb (creates) and resource (BRC sales rep). This distinguishes it from sibling tools like brc_update_sales_rep or brc_create_customer, and the workflow references make its unique role clear.

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

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

The description provides explicit workflow guidance: 'Call brc_route_request first with the user's complete original action request' and 'Retain the returned routeToken through lookup, preview, and confirmation, and pass the same token on the final permitted transactional tool call.' This clearly states when to use the tool relative to routing, though it doesn't mention alternatives for reading or updating sales reps.

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

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

With no annotations present, the description carries full behavioral disclosure. It reveals non-obvious behaviors: the tool does not create/update opening balances, routeToken is a routing permission but not posting permission, and confirmWrite/confirmDelete still apply. It also warns against inventing placeholder tokens—critical context for safe invocation.

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

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

The description is front-loaded with the core action and then presents necessary caveats. It is somewhat repetitive around routeToken (requires, call first, retain, pass same token, never invent), but each sentence adds a distinct piece of guidance. It is economical for the complexity involved, though a slight trim would make it a 5.

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 5-parameter tool with nested objects, no annotations, and no output schema, the description covers the essential workflow (route request first, confirm step) and critical exclusions (opening balance). It does not mention the batch supplier alternative or expected return value, but these are not strictly necessary for correct invocation. Overall, it 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 100%, so the schema already documents all parameters well. The description adds little beyond what the schema provides for parameters themselves—it reiterates that payload is raw and routeToken comes from route_request, which is already stated. It does not explain payload content or confirmWrite nuances 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 opens with 'Creates a BRC supplier using a raw BRC payload'—a specific verb+resource pair that clearly distinguishes it from update/delete or batch supplier tools. It further clarifies scope by explicitly stating it does not handle opening balance transactions, making the purpose unambiguous.

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

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

The description gives explicit usage guidance: call brc_route_request first, retain the routeToken through the workflow, and never invent tokens. It also provides a clear when-not case (opening balance must be entered directly in Big Red Cloud). However, it does not explicitly mention alternatives like brc_batch_suppliers for bulk creation or brc_update_supplier for edits, which would make it a 5.

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

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

With no annotations, the description carries the transparency burden. It discloses the confirmation requirement (confirmWrite=true only after explicit user confirmation), the routeToken workflow, preview-before-posting, and the need to retain the same token. It doesn't explicitly state the deletion is permanent/irreversible, but the confirmation requirement implies 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 front-loaded with the main action and each sentence contributes important workflow or safety information. It is somewhat long (six sentences) but avoidable redundancy is minimal; the length is justified by the tool's destructive and transactional 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 destructive transactional tool with no annotations and no output schema, this description covers the essential workflow: retrieval, routing, token handling, and confirmation. It doesn't explain return values or all parameters (e.g., connectionRef is only in schema), but the schema covers those, and the critical usage context is fully addressed.

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

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

Although the schema has high coverage (100%), the description adds substantial semantic value: timestamp must be in Base64 and retrieved via brc_get_accrual, routeToken is obtained from brc_route_request and must be retained and reused, and confirmWrite must only be true after explicit user confirmation. These details go far beyond the schema and reduce invocation errors.

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 'Removes an existing parent Accrual by id,' which is a specific verb+resource+method that clearly distinguishes this tool from the many other delete_* siblings. It also notes the need for a Base64 timestamp, further refining the 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 explicit usage steps: call brc_get_accrual first to retrieve the timestamp, call brc_route_request first to obtain a routeToken, and only pass confirmWrite=true after explicit user confirmation. It also warns against inventing a placeholder token and clarifies that routeToken is not permission to post, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the need for routeToken from brc_route_request, the confirmation flow, and that routeToken is not permission to post. It also clarifies the connectionRef parameter indirectly. However, it does not explicitly describe side effects or whether the deletion is reversible beyond the reversal wording, but given the confirmation emphasis, it is fairly transparent.

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 dense paragraph, but every sentence earns its place by covering the workflow, prerequisites, and warnings. It is not overly long and front-loads the primary purpose. Slight lack of paragraph breaks, but acceptable.

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 (requires routeToken, confirmation flow, connectionRef), the description provides a complete workflow: call brc_route_request, retain token, pass same token on final call, use confirmWrite only after explicit confirmation. No output schema exists, but the description focuses on invocation rather than return values, which is appropriate for a delete mutation. It is complete for safe usage.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the workflow context for routeToken and confirmWrite, and by explicitly stating 'Never invent a placeholder token.' It reinforces the purpose of id and confirms the confirmation requirement. This exceeds the baseline 3 by adding operational context that the schema lacks.

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 "Reverses/deletes a single allocation by allocation resolver id," using a specific verb and resource. It also distinguishes from siblings by referencing brc_list_allocated_transactions to find the id, and implies this is the deletion counterpart among many delete 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 explicit when-to-use guidance: use brc_list_allocated_transactions first to find the id, and call brc_route_request first with the user's complete original action request. Also gives explicit exclusions: 'Do not call with confirmWrite=true until the user explicitly confirms,' and 'Never invent a placeholder token.' This clearly differentiates from other tools and outlines the workflow.

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?

Since no annotations are provided, the description carries the full behavioral burden. It discloses that deletion is confirmation-gated, that a routeToken is required and must not be invented, and that a routeToken is not permission to post—preview-before-posting and confirmWrite/confirmDelete still apply. This is substantially more transparent than a bare 'Deletes an account.'

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 four sentences, front-loaded with the action and required confirmation. Every sentence contributes essential workflow or safety information—there is no filler or unnecessary repetition. It is dense but appropriately sized for the complexity of the tool.

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

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

The description covers routing and confirmation well, but it stops short of explicitly stating that confirmDelete must be set to true for deletion to actually occur, which is critical given the schema's default of false. It also does not clarify the function of companyName beyond the schema. Given the destructive nature of the tool and no output schema, these gaps leave the description strong but not fully 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 83%, so the baseline is 3. The description adds value by explaining the routeToken lifecycle (retain, pass the same token, never invent a placeholder) and by explicitly stating that confirmWrite/confirmDelete apply. It does not add meaning for id or companyName, but these are adequately described in the schema.

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

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

The description opens with 'Deletes a BRC bank account by id,' which is a specific verb + resource + scope statement. It clearly distinguishes this from sibling tools like brc_update_bank_account or brc_get_bank_account, and the required identifier is 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 provides a clear precondition ('Only call this after the user has explicitly confirmed deletion') and a mandatory workflow ('Call brc_route_request first... retain the returned routeToken... pass the same token on the final permitted transactional tool call'). While it does not name alternative tools, it gives sufficient when-to-use and how-to-proceed guidance, though explicit exclusions (e.g., 'do not use for updates') are absent.

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

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

With no annotations provided, the description carries the full burden. It discloses the mandatory routeToken requirement, the sequence of calls, and warns against inventing placeholders. It also clarifies that routeToken is not permission to post and that confirmWrite/confirmDelete still apply, adding critical behavioral context beyond a basic delete statement.

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

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

The description is four sentences, front-loaded with the primary action, then efficiently covering the routing workflow and confirmation requirements. No fluff; each sentence contributes essential guidance for 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?

Given the complexity of the routed delete workflow, the description thoroughly covers the token lifecycle, confirmation steps, and the need to avoid placeholders. It does not mention return values, but for a delete operation with no output schema, that omission is acceptable; overall, it provides sufficient context for safe execution.

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

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

Schema coverage is high (83%), but the description adds meaning to routeToken by calling it 'Routing permission only' and explains that confirmDelete still applies, which is useful since confirmDelete has no schema description. It reinforces the role of id and routeToken, complementing the schema details.

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 'Deletes a BRC cash payment by id,' using a specific verb and resource, and clearly distinguishes from sibling delete tools for other entities like cash receipts or payments. The routing workflow detail further clarifies the tool's role in the delete process.

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

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

The description explicitly instructs to call brc_route_request first, retain the routeToken through the workflow, and pass the same token on the final transactional call. It does not explicitly mention alternatives, but the tool's name and purpose make its use clear; however, it lacks explicit 'when not to use' guidance.

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

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

With no annotations provided, the description carries the burden. It discloses the routeToken requirement, the need to retain it through the workflow, and the confirmation caveat. However, it does not explicitly state that the deletion is permanent or irreversible, nor what happens if the id does not exist — a modest transparency gap for a destructive action.

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, all relevant and directly tied to correct usage. The first sentence states purpose, then the workflow and caveats follow. Slight repetition of the routeToken concept (four mentions) prevents a 5, but it remains efficient and 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?

Given the complexity of the routeToken+confirmation workflow, the description covers the essential context: the prerequisite call to brc_route_request, token retention, and the applicability of confirmWrite/confirmDelete. It does not describe the tool's return value (no output schema), but the extensive schema descriptions for parameters fill most 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 high (83%), so the baseline is 3. The description adds workflow context for routeToken and mentions confirmDelete, but it largely restates information already present in the schema (e.g., routeToken description already covers 'routing permission only'). It does not explain confirmDelete's default false behavior or connectionRef beyond what the schema provides.

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

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

The description opens with 'Deletes a BRC cash receipt by id' — a specific verb, resource, and identifier. This clearly distinguishes it from other delete tools (e.g., delete cash payment) and immediately states the core function.

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

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

Explicit guidance is provided: 'Requires routeToken from brc_route_request for the matching action workflow. Call brc_route_request first...' and 'Never invent a placeholder token.' It also clarifies that a routeToken is not permission to post, and that preview-before-posting and confirmWrite/confirmDelete still apply — giving clear when-to-use and safety prerequisites.

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