Red MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation4/5
Most tools target distinct entity-action pairs, but a few pairs (e.g., brc_create_sales_invoice vs brc_create_sales_invoice_gen_ref) could cause confusion without careful reading. Overall well differentiated.
Naming Consistency5/5
All tools follow a strict brc_action_entity pattern in snake_case, with consistent singular/plural for create vs list. Very predictable.
Tool Count2/5
154 tools is far beyond typical tool counts, making it difficult for agents to navigate and select the right tool efficiently. Despite covering many operations, the sheer number suggests scope creep.
Completeness4/5
The tool set covers a wide range of accounting entities and operations including CRUD, batch, email, and settings. Minor omissions like report generation or user management exist but do not severely hamper core workflows.
Average 3.7/5 across 154 of 154 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 68 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It fails to mention any traits such as read-only nature, pagination behavior, or required permissions, leaving critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single sentence, it is under-specified and adds no value beyond the tool name. True conciseness balances brevity with informativeness; this lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, high parameter count, low schema coverage, and lack of annotations, the description is grossly incomplete. It does not provide enough information for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, with 3 of 7 parameters having descriptions. The description does not explain the meaning or usage of top, page, skip, or pageSize, failing to compensate for the schema shortfall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC nominal accounts' is a tautology, restating the tool name without adding clarity or distinguishing from siblings like brc_list_accounts. It misses the opportunity to specify scope or differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling list tools (e.g., brc_list_accounts, brc_list_customers), the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Lists BRC sales reps.' It omits any mention of pagination (top, page, skip, pageSize), filtering, ordering, or the required companyName parameter. This is severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. One sentence repeats the tool name and does not add value. Structure is minimal but fails to provide necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is completely inadequate. It fails to explain pagination, required fields, or usage context, making it nearly useless for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (low), yet the description adds no meaning beyond the schema. Parameters like top, page, skip, pageSize have no descriptions in the schema or description, leaving the agent uninformed about pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name 'Lists BRC sales reps.' It does not differentiate from sibling list tools like brc_list_customers or brc_list_products. The purpose is clear but tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., brc_get_sales_rep for a single rep, brc_batch_sales_reps for batch operations). The description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It merely states that it 'lists purchases' but does not explain pagination behavior, read-only nature, or any side effects, leaving critical safety traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words), but this brevity results from under-specification rather than efficient communication. It lacks necessary details, making it insufficient for an agent to understand the tool's full behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is severely incomplete. It omits information about return values, pagination defaults (pageSize of 20), required companyName context, and how filtering/ordering work, leaving substantial gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters but only 43% have descriptions (filter, orderBy, companyName). The description adds no additional meaning beyond what is already in the schema, failing to compensate for the low coverage by explaining the role of top, page, skip, and pageSize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC purchases' clearly states the verb and resource, making the basic purpose understandable. However, it does not specify any scope or distinguish it from sibling list tools, reducing its helpfulness for tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_list_payments or other list tools. The description lacks any contextual clues about prerequisites or filtering capabilities, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Lists BRC products' does not mention pagination, authentication, rate limits, or any side effects, leaving the agent uninformed about crucial behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but conciseness should be coupled with completeness. It lacks critical information, thus not earning its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, pagination, filtering) and the absence of an output schema, the minimal description provides insufficient context for proper use. The agent cannot determine the tool's full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which itself only describes 3 of 7 parameters (filter, orderBy, companyName). Parameters like top, page, skip, and pageSize are undocumented, and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC products' clearly states the verb and resource, but it is nearly a tautology with the tool name and does not distinguish from sibling tools like brc_list_products_without_dormant or brc_list_product_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as brc_list_products_without_dormant (which likely filters out dormant products) or brc_list_product_types. The description offers no context about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'lists', which implies read-only, but does not confirm idempotency, side effects, or authentication requirements. The lack of detail undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too concise to be useful; it omits critical details that would justify its brevity. While not verbose, it loses value by under-specifying.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description does not provide enough context. It fails to explain what accounts are returned, pagination behavior, or output format, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (43%) and the description adds no extra meaning about parameters like top, page, skip, pageSize. It fails to compensate for missing schema explanations, leaving agents without guidance on pagination or filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC accounts' is vague; it does not specify what type of accounts (e.g., nominal, bank, or general). This is insufficient to distinguish from sibling tools like brc_list_nominal_accounts or brc_list_bank_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other list tools for specific account types. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as read-only nature, pagination, required company context, or any side effects. With no annotations, the description carries full burden but adds no value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise (4 words), the extreme brevity sacrifices necessary information. It is not appropriately sized for a tool with 7 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, low schema coverage, no output schema, and no annotations, the description is completely inadequate. It does not explain return format, pagination behavior, or the meaning of 'BRC payments'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the 7 parameters. Schema coverage is only 43% (3 of 7 params described), but the description compensates nothing. An agent gets no additional help interpreting 'top', 'skip', 'pageSize', etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC payments' is a clear verb+resource, but it lacks specificity about what constitutes a BRC payment versus other payment types (e.g., cash payments, prepayments) and does not differentiate from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. Sibling tools like brc_list_cash_payments or brc_list_customers exist, but no context about selection criteria or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information. It does not disclose that the tool is read-only, nor does it mention pagination, rate limits, or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) but under-specified. It is not helpful for an AI agent to understand the tool's capabilities or correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not cover pagination, filtering, required companyName, or return values, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. Schema coverage is low (43%), and the description fails to explain parameters like top, page, skip, and pageSize, which are left without schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists BRC sales entries', which is a clear verb+resource. However, it does not differentiate from sibling list tools like brc_list_sales or brc_list_sales_invoices, and lacks any scope or detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, exclusions, or comparison with brothers like brc_list_sales.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond the bare function. With no annotations, it fails to disclose whether this is a read-only operation, pagination behavior, or any side effects, making it insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), but this is under-specification rather than conciseness. It fails to include critical information that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the lack of output schema and the complexity of parameters (7 params, including pagination and filtering), the description is wholly inadequate. It does not explain return values or how to work with the parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters, nor does it explain required fields (e.g., companyName) or usage of pagination/filtering. With only 43% schema description coverage, the tool relies heavily on the description, which is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Lists) and the resource (BRC bank accounts), providing a clear purpose. However, it does not distinguish from sibling list tools like brc_list_accounts, which might cause confusion for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like brc_get_bank_account or other list tools, leaving the agent without context on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral context. It only states that the tool lists receipts, but doesn't disclose read-only nature, pagination behavior, or query capabilities (though schema has filter/orderBy, the description doesn't mention them).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it under-specifies the tool. It is not front-loaded with significant information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description is incomplete. It doesn't describe the return format, typical response structure, or how it relates to other listing tools in the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (3 of 7 params described), but the tool's description adds no parameter information. It does not explain critical parameters like top, page, skip, or pageSize, which are uncommented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC cash receipts' is a generic verb+resource but fails to distinguish this tool from siblings like brc_list_cash_payments or brc_list_payments. It does not specify what a cash receipt is or any unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination behavior, rate limits, or data freshness. The agent has no information about what happens beyond the basic list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is under-specified. It lacks important details such as required parameters or output format. Conciseness should not sacrifice necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is far from complete. It does not mention pagination, filtering, or the required 'companyName' parameter. The agent cannot adequately use this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (low), but the description adds no parameter information. It fails to compensate for the missing descriptions, leaving the agent without guidance on how to use properties like 'top', 'page', 'skip', etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC customers' clearly states the verb 'Lists' and the resource 'BRC customers', which is specific and provides a clear purpose. However, it does not distinguish from sibling tools like brc_get_customer or brc_list_customers_without_dormant, but the core action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, there is no mention of how this differs from brc_list_customers_without_dormant or when to use filtering/pagination. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only repeats the tool name. It fails to disclose any behavioral traits such as pagination support (evident from schema parameters) or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, the description is under-specified for a tool with 7 parameters. Conciseness should not sacrifice completeness; this is too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is grossly incomplete. It provides no information about return values, pagination behavior, or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (low); the description adds no additional meaning to the parameters beyond what the schema already provides. It does not explain what 'owner type groups' are or how parameters like 'filter' or 'orderBy' affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'BRC owner type groups', distinguishing it from the sibling tool brc_list_owner_types which lists owner types, not groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives, nor any context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It fails to disclose pagination, sorting, rate limits, or data freshness. The one-sentence description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified for a tool with 7 parameters. Conciseness without content is not helpful; every word should earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is severely lacking. It does not explain return format, behavior, or how to interpret results. The agent is left with a nearly empty description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (3 of 7 parameters described). The description adds no meaning beyond the schema; it doesn't explain what product types are or relate parameters to usage. The generic pagination parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('BRC product types'), which distinguishes it from listing tools for other entities like brc_list_products. However, it could be more specific about what constitutes a product type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Among many sibling list tools, the agent receives no help in choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It only says 'lists', failing to mention pagination, filtering, ordering, or that it is a read-only operation. The input schema hints at these features, but the description adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is short, but it is under-specified and does not adequately explain the tool. Conciseness is good, but at the expense of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 7 parameters including pagination, the description is far from complete. It does not explain return values, pagination behavior, or how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, with some parameters (filter, orderBy, companyName) having descriptions. The tool's description adds no additional meaning to the parameters, missing an opportunity to clarify their usage or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Lists' and the resource 'BRC cash payments', making the tool's purpose clear. However, it does not differentiate from sibling tools like brc_get_cash_payment or brc_list_cash_receipts, which have similar names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as brc_list_cash_receipts or other list tools. The description does not include when-not-to-use or contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but omits behavioral traits. It does not mention that the tool is likely read-only, requires authentication, or describes the pagination behavior implied by the schema parameters (top, skip, page, pageSize).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single sentence and thus concise, it is too brief to be helpful. It fails to earn its place by providing missing context, making it insufficient for effective tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (1 required), no output schema, and no annotations, the description is grossly incomplete. It does not explain the return format, pagination behavior, or any filtering capabilities beyond what the schema hints at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 43% (only companyName, filter, orderBy have descriptions). The description adds no parameter-level meaning, leaving 4 parameters (top, skip, page, pageSize) without any semantic guidance beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'BRC category types,' establishing a basic purpose. However, it does not define what a BRC category type is, nor does it distinguish this tool from other list tools (e.g., brc_list_analysis_categories, brc_list_vat_categories), limiting its uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., brc_list_vat_types or brc_list_analysis_categories). There is no context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Lists,' implying a read operation, but fails to mention that the tool requires the 'companyName' parameter, returns paginated results, supports filtering and ordering, or any side effects. The description is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, which is concise. However, it is too sparse and fails to front-load essential information that would help an agent understand the tool's function and usage. The conciseness sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, many sibling list tools), the description is incomplete. It does not mention the required companyName, pagination, filtering capabilities, or the structure of returned data. An agent would lack sufficient context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 43% description coverage, with some parameters like 'filter' and 'orderBy' having descriptions. However, the tool's description adds no additional meaning beyond the schema. For parameters like 'top,' 'page,' 'skip,' and 'pageSize,' the schema provides no description, and the tool description does not compensate. The required parameter 'companyName' is explained in the schema but not in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Lists BRC owner types,' which clearly communicates the action (list) and resource (BRC owner types). However, it is vague and does not differentiate from siblings like brc_list_owner_type_groups, which could be confused with this tool. The purpose is adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, such as other list tools (e.g., brc_list_accounts) or how to interpret the results. There is no mention of prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It only states 'lists' (read operation) but lacks details on safety, side effects, authentication, or rate limits, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), which is generally good, but it lacks substance and fails to provide useful information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, many siblings), the description is severely incomplete. It omits details on pagination, filtering, response format, and how it differs from similar list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, with only companyName, filter, and orderBy having descriptions. The tool description adds no additional parameter meaning, failing to compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists BRC VAT types,' which is a clear verb+resource. However, it does not distinguish from sibling tools like brc_list_vat_rates or brc_list_vat_categories, limiting its usefulness for tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives or any context on appropriate usage. The description lacks any usage notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states a read-like action but does not mention whether it is idempotent, what permissions are needed, the output format (e.g., binary data, URL), or side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it is excessively minimal, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., the image data, a URL, or file path). It does not, making it incomplete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for companyName. The tool description adds no extra meaning beyond the schema, so baseline is 3. No improvement needed but no degradation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets the company logo from BRC,' specifying the action (Gets) and resource (company logo). It distinguishes the tool from siblings like brc_get_customer or brc_get_accrual, but lacks detail on what a logo entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There is no mention of prerequisites, when not to use it, or any context that helps the agent decide between this and other get_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the basic listing function but fails to disclose pagination behavior, rate limits, or any side effects. The schema includes pagination parameters (top, skip, page, pageSize) but the description ignores them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary details. It is not appropriately sized for a tool with 7 parameters and no output schema; it could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and lack of output schema, the description is incomplete. It does not explain what a 'book transaction type' is, nor does it cover pagination, filtering, or expected return format. For a list tool, more context is needed for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43% (filter and orderBy have descriptions, companyName has a basic description). The description adds no parameter meaning beyond the schema. For the undocumented parameters (top, page, skip, pageSize), both schema and description are silent, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists BRC book transaction types,' which clearly identifies the verb and resource. The name itself distinguishes from sibling list tools, but the description does not further clarify the specific domain of 'book transaction types' versus other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like brc_list_accounts or brc_list_accruals. No exclusions or context are given, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only states the action without disclosing behavioral traits like pagination, rate limits, or safety (read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. Conciseness should not come at the expense of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and many sibling tools, the description omits return format, pagination details, and filtering capabilities that are hinted at in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (3 of 7 parameters have descriptions). The description adds no parameter information, leaving four parameters (top, page, skip, pageSize) without natural language explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists BRC quotes, with a specific verb and resource. However, it does not differentiate from related sibling tools like brc_list_customer_quotes, which might list quotes filtered by customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as brc_list_customer_quotes or brc_get_quote. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only says 'lists,' failing to mention pagination, read-only nature, permissions, or return format. The schema hints at pagination but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it sacrifices necessary detail. It is front-loaded but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, 7 parameters, low schema coverage, no annotations, and many sibling list tools, the description is insufficient. It does not cover pagination, filtering, or distinguish from similar list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description adds no meaning to parameters like companyName, filter, or pagination fields. The description does not explain the required companyName or any optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists BRC sales credit notes, using a specific verb and resource. However, it does not differentiate from sibling list tools like brc_list_sales or brc_list_sales_invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of context or exclusions, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral info beyond 'lists'. No mention of authentication, rate limits, pagination behavior, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. No wasted words, but conciseness comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. Missing details on pagination, filtering, sorting, required companyName context, and what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, but the description adds no meaning to parameters like top, page, skip, pageSize. Does not explain how pagination works or the filter/orderBy syntax beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'BRC sales invoices', making the purpose immediately understandable and distinguishing it from sibling tools like brc_get_sales_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., brc_list_sales, brc_get_sales_invoice). Missing context for typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that the tool is read-only, supports pagination/filtering, or any side effects. For a list operation, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. It is front-loaded but insufficient to guide an agent effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, no annotations, and many sibling tools, the description is incomplete. It does not cover return format, pagination behavior, or required parameters, leaving significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 43% (filter, orderBy, companyName have descriptions), but the description adds no additional meaning beyond what is in the schema. It does not explain the required companyName parameter or the pagination parameters (top, page, skip, pageSize) in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (lists) and resource (suppliers), but among sibling tools like brc_list_supplier_account_trans and brc_list_supplier_op_bal_trans, it lacks differentiation to help an agent distinguish which list tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as brc_get_supplier for a single supplier or other list tools. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or pagination behavior. It merely states the action without any additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), which is concise but under-specified. It loses points because it could have included more useful information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is far from complete. It does not describe return values, pagination behavior, or any other context an agent needs to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 43% of parameters with descriptions. The description adds no parameter-level details. While some parameters have descriptions in the schema (filter, orderBy, companyName), the overall description fails to explain how to use pagination parameters or any parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC user defined fields' clearly states the verb and resource. However, among many list tools, it does not differentiate what 'user defined fields' specifically are, but it's sufficiently clear for an agent to understand the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context about when to choose this over other list tools like brc_list_analysis_categories or brc_list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Lists', implying a read-only operation, but offers no details on pagination, filtering, side effects, or data scope. The agent is left to infer safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, achieving conciseness. However, it is so minimal that it borders on under-specification, lacking useful details that could fit in a slightly longer description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is incomplete. It does not explain what 'VAT analysis types' are, how to use pagination, or what the return values look like. A more thorough description is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 43% and the description adds no parameter information. It does not explain the required 'companyName' parameter or the pagination parameters (top, skip, pageSize). The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lists BRC VAT analysis types', identifying verb and resource. However, it does not differentiate from sibling tools like brc_list_vat_categories, brc_list_vat_rates, or brc_list_vat_types, which also list VAT-related entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description provides no context for selection, such as how 'VAT analysis types' differ from other VAT lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, authentication needs). It fails to add value beyond the minimal purpose, leaving the agent uninformed about side effects or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at the return value or provide context about the payment entity. It does not, leaving the agent uncertain about what data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional meaning beyond the schema: it only restates 'by id' without explaining the companyName parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets one BRC payment by id' clearly states the verb and resource. It is specific to BRC payments, but does not differentiate from siblings like brc_get_cash_payment, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., brc_get_cash_payment or brc_get_purchase). The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the basic action without disclosing authentication needs, side effects, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, but could be more structured to include key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description is too minimal to adequately guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information; schema coverage is only 43%, and the tool has 7 parameters with limited documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC company settings' clearly states the action and resource, and distinguishes from sibling tools that list other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, prerequisites, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'Gets', implying a read operation, but does not mention idempotency, side effects, permissions, or whether the call modifies state. The agent cannot infer safety or latency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words). While it saves tokens, it sacrifices completeness. The sentence is front-loaded and direct, but could include targeted details (e.g., return format) without becoming verbose. It earns its place but barely meets minimum informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description should at least hint at what the return value represents (e.g., year start/end, string, number). Without output schema, the agent is left guessing the nature of the financial year data. The description is incomplete for effective agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'companyName' is fully described in the schema (100% coverage), so the description adds no additional semantic value. The schema's comment is sufficient; the tool description does not elaborate on parameter usage or defaults, which is acceptable but provides no extra benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' and resource 'BRC company financial year', clearly indicating the tool's purpose. It is unique among sibling tools, so no confusion with other getters. However, it lacks specificity about what aspect of the financial year is retrieved (e.g., current year, start/end dates), which could be improved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, typical use cases, or when not to use it. Given the large number of sibling tools, explicit usage context would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'gets', which implies a read operation. It does not describe return format, potential errors, permissions required, or any other behavioral traits. The description carries the full burden and is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. It could benefit from slight expansion to clarify the company context, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description is adequate but minimal; it does not explain that the tool returns the bank account object or any additional context about the response. Slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (id and companyName). The description adds no additional meaning beyond the schema, meeting the baseline for a simple tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'gets', the resource 'one BRC bank account', and the key parameter 'by id'. It distinguishes from list tools like 'brc_list_bank_accounts' but does not elaborate on the companyName parameter, which is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., brc_list_bank_accounts or brc_create_bank_account). The context is implied (when you have an id) but no exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavior. It does not explicitly state the tool is read-only, nor does it mention any side effects, permissions requirements, or rate limits. The 'get' verb implies a read operation, but transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the tool's purpose concisely. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter, no output schema) and the presence of sibling tools for specific sub-configurations, the description provides a reasonable overview but lacks guidance on when to use this aggregated version versus the specific ones. The listing of included components is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'companyName' parameter, so the schema already explains it. The tool description does not add any additional semantic information beyond what the schema provides, resulting in no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Gets full BRC company setup configuration' which clearly indicates the verb and resource. It lists included components, but does not differentiate from sibling tools that retrieve specific parts (e.g., brc_get_financial_year).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the specific getters (e.g., brc_get_financial_year, brc_get_company_reference_settings). There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Gets', implying a read operation, but does not mention authorization requirements, error cases, or side effects. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the essential action. However, it is too brief and misses opportunities to add value without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (2 params, no output schema) and numerous sibling tools, the description is insufficient. It does not explain what the opening balance represents, how it is calculated, or how the response is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('companyName' and 'itemId'). The description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('customer's opening balance'), distinguishing it from sibling tools like brc_get_supplier_opening_balance or brc_get_customer. However, it does not elaborate on the meaning of 'opening balance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as brc_list_customer_op_bal_trans, which lists opening balance transactions. The description lacks any context about preconditions or frequency of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description merely states 'Gets', implying a read operation, but does not disclose side effects, authentication requirements, error scenarios, or return format. With full burden on description, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with clear front-loading. No redundant words. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists. The description fails to indicate what the tool returns (e.g., account details, ledger entries). Given the tool's name includes 'ledger', this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (id, companyName). The description adds no additional meaning beyond 'by id'. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (gets), resource (BRC nominal account), and identifier (by id). It distinguishes from the sibling 'brc_get_nom_ac_ledger_by_ids' which retrieves multiple. However, it does not clarify what a BRC nominal account is or what the ledger portion means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, it could mention that 'brc_get_nom_ac_ledger_by_ids' is for multiple accounts. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only indicates that this is a read operation ('Gets'), but does not disclose behavior on missing ids, required permissions, rate limits, or whether it returns full product details. Minimal transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 6 words, which is efficient for a simple get tool. However, it could be slightly expanded to include the required companyName for completeness, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation (get by id) and the presence of an input schema that fully describes parameters, the description is minimally adequate. However, it lacks information about return values, error handling, and the necessity of companyName, which could lead to incomplete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters having descriptions in the schema (id: 'Product id.', companyName: 'Company context name...'). The description adds no extra meaning beyond what the schema already provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'one BRC product by id.' It distinguishes from sibling tools like brc_list_products and other get_* tools by specifying the exact resource, but it doesn't mention the required companyName parameter, which is needed for the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of using brc_list_products for fetching multiple products or any prerequisites like needing a valid id. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose any behavioral traits such as read-only nature, required permissions, or what happens if the quote does not exist. The agent gains no insight beyond the fact that it retrieves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is not verbose, but some additional context could be added without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple operation, the description is minimally adequate. However, it does not specify the return format, error handling, or any contextual details that would help an agent understand the full scope of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'id' and 'companyName'. However, the tool description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'gets' and resource 'BRC quote', making the primary action clear. It distinguishes from siblings like brc_list_quotes (which returns multiple quotes) by indicating retrieval by a single id, though it does not explicitly contrast with other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as brc_list_quotes, brc_create_quote, etc. The description does not mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Gets'), but no annotations are provided to confirm safety. It does not disclose any behavioral traits such as authentication requirements, rate limits, or what happens if the ID is invalid. With no annotations, the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. It is front-loaded with the verb and resource. However, it could be slightly improved by mentioning the return value or including a brief example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with two parameters and no output schema, the description should at least hint at what the tool returns (e.g., the full credit note object). It is too brief, leaving the agent without information on response format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers 100% of parameters, so the baseline is 3. The description adds 'by id' but does not enhance understanding beyond the schema's descriptions for 'id' and 'companyName'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and the resource ('one BRC sales credit note by id'). It distinguishes from list tools like brc_list_sales_credit_notes. However, it does not elaborate on what a sales credit note is, which is acceptable given the sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives such as brc_list_sales_credit_notes or brc_get_sales_invoice. The description does not explain prerequisites or context (e.g., requiring the ID from a list call).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic purpose, omitting details about read-only nature, authorization requirements, error handling, or what happens if the entry is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no unnecessary words. It earns its place by being efficient, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what is returned (e.g., the full sales entry object). It does not, leaving the agent to infer from the tool name. For a retrieval function, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional meaning beyond the schema's property descriptions. It provides no examples or format hints, but the schema is already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and the resource ('one BRC sales entry by id'). It is specific and directly conveys the tool's purpose, though it could better distinguish it from sibling get tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list_sales_entries or other get tools. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose any behavioral traits such as whether it is read-only, permissions required, or error conditions. For a simple get operation, the minimal description lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. It wastes no words, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is insufficient. It does not explain the return value, pagination, or any post-condition behavior. For a tool with two required parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented in the schema. The description adds no extra meaning beyond stating 'by id', which is already implied by the id parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' and identifies the resource as 'BRC sales invoice' with the identifier 'by id'. It clearly distinguishes from list tools like brc_list_sales_invoices, but could explicitly state that it retrieves a single invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as brc_list_sales_invoices or brc_get_sales_entry. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors beyond the obvious fetch. It does not mention that the operation is read-only, idempotent, or any potential error conditions. The minimal phrase 'Gets one...' implies but does not explicitly state that no modifications occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, front-loaded, and no wasted words. However, it is perhaps too terse; a bit more detail on the expected result would improve usability without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description is minimally adequate. It tells what it does but lacks completeness about return value or context for companyName, relying on schema. Sibling tools suggest many related operations, but no comparison provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters with descriptions. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action 'Gets' and resource 'one BRC sales rep by id', making the tool's purpose obvious. It distinguishes from list tools that return multiple reps, but does not differentiate among other get tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_sales_reps or get tools for other resources). No usage conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as whether it returns paginated results, supports filtering, or has side effects. No annotations are provided to compensate, so the agent has minimal understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is so brief that it sacrifices necessary detail, making it less useful for complex decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no mention of what the tool returns (e.g., transaction details, any limits). Given the complexity of listing transactions and the presence of many sibling tools, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (itemId and companyName). The description adds no additional meaning beyond the schema, so it meets the baseline for high coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a customer's account transactions' clearly identifies the verb (gets) and resource (customer's account transactions). However, it does not differentiate from sibling tools like 'brc_list_supplier_account_trans' or 'brc_list_customer_op_bal_trans', which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only indicates a read operation ('Gets quotes') without disclosing behavioral traits like authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 5 words, no fluff. However, it might be slightly too brief given the lack of context from other fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description provides minimal completeness. It covers the basic purpose but lacks details on output format and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets quotes for a specific customer, but does not explicitly differentiate from sibling tools like brc_list_quotes which may list all quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as brc_list_quotes or brc_get_quote. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states the basic function without disclosing behavioral traits such as pagination, sorting, performance implications, or the exact meaning of 'without dormant'. Lacks detail for a list tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. However, given the tool's complexity (7 parameters, no annotations), it may be underspecified. Nevertheless, it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity (7 params, no output schema, no annotations), the description offers minimal context. It omits return format, pagination behavior, and a precise definition of 'without dormant'. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43% (3 of 7 parameters have descriptions). The description does not add any meaning beyond the schema; it fails to explain parameters like top, page, skip, pageSize, or how they interact. With low coverage, description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Lists' and resource 'BRC customers' with a specific filter 'without dormant records'. This distinguishes it from similar siblings like brc_list_customers, which likely lists all customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no exclusions or prerequisites mentioned. The description provides no context for selecting this tool over brc_list_customers or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions filtering and ordering but omits key behaviors like pagination (top/skip), required companyName, or rate limits. This is insufficient for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. However, it sacrifices valuable details for brevity. Still, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should provide more context about pagination, required parameters, and return format. It falls short, making it incomplete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no new semantics beyond what the schema provides (e.g., filter by entryDate, order by id are already in schema descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of the company's Prepayments, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like brc_list_payments or brc_get_prepayment, so it scores 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks when/when-not context or explicit alternatives, so it scores 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Gets', implying a read operation, but does not mention any constraints, side effects, pagination, or authentication requirements. The minimal description leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the action. However, it could include a bit more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no output schema. It does not explain what 'account transactions' entails, what the return data looks like, or any filtering. This leaves the agent with incomplete information to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no extra meaning beyond the schema, but this is acceptable given the high coverage. However, it does not clarify how the parameters relate (e.g., companyName as context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a supplier's account transactions' clearly specifies the verb 'Gets' and the resource 'supplier's account transactions', making the purpose understandable. However, it does not differentiate from sibling tools like brc_list_supplier_op_bal_trans or brc_list_customer_account_trans, which are similar list operations for suppliers or customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for listing supplier-related transactions (e.g., brc_list_supplier_op_bal_trans), the lack of usage context forces the agent to infer based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states it is a read operation ('Gets'), but does not disclose any other behavioral traits such as pagination, sorting, or handling of empty results. The agent has no additional context beyond the tool being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with front-loaded verb and resource. No wasted words, but could provide more useful guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and 100% schema coverage, the description is adequate but incomplete. It lacks details on output format, pagination, or error conditions. For a simple list tool, it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both required parameters (companyName and itemId). The description adds no extra meaning beyond the schema. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'gets' and the resource 'supplier's opening balance transaction list'. It distinguishes from siblings like brc_get_supplier_opening_balance (which likely gets the balance amount) and brc_list_supplier_account_trans (which lists all account transactions). However, it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of context like prerequisites or when to prefer this over list_supplier_account_trans or get_supplier_opening_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states it lists categories, omitting crucial details like pagination (top, page, skip parameters), output format, or any side effects. The schema provides some structure but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary action. However, it could be more structured (e.g., bullet points) to enhance readability, but it's adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is incomplete. It does not explain how to use the filtering/pagination parameters, what the response format is, or any error states. More detail is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, leaving many parameters (e.g., top, page, filter) with minimal descriptions. The tool description adds no parameter-specific explanation, relying on generic OData terms. It fails to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists BRC VAT categories with examples (e.g., Sales, Purchases). However, it does not explicitly differentiate from sibling tools like brc_list_vat_rates or brc_list_vat_types, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage context, such as telling which VAT category a rate belongs to and that sales invoices must use sales categories. But no guidance on when not to use this tool or mention of alternatives like brc_list_vat_rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It notes the use of GET requests (implying read-only) but does not explicitly state it is non-destructive, mention any rate limits, or describe the grouping or report structure. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. While it could be slightly more structured with bullet points for clarity, it is not verbose and front-loads the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, yet the description does not explain what a 'grouped nominal accounts report' entails, how the grouping is performed, or what the return format looks like. Given its complexity, more context is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameter. The description adds context that the report is created 'for each company,' which aligns with the array parameter. No additional syntax or format details are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a grouped nominal accounts report for multiple companies, using a specific API endpoint per company. This distinguishes it from siblings like brc_grouped_nominal_accounts_report (which may be single-company) and brc_list_nominal_accounts (which lists without grouping).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a report across multiple companies is needed, but provides no explicit guidance on when to use this tool versus alternatives like brc_grouped_nominal_accounts_report or brc_list_nominal_accounts. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It only states the action without mentioning side effects, read-only nature, permissions required, or return format. For a get operation, minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. While very brief, it wastes no words and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what is returned (e.g., a balance value, date context). It omits this, leaving the agent uncertain about the output format. Additional context about the opening balance calculation or its relationship to supplier transactions is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets a supplier's opening balance', specifying the verb 'gets' and the resource 'supplier's opening balance'. It differentiates from sibling tools like 'brc_get_customer_opening_balance' and 'brc_list_supplier_op_bal_trans', making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes many related tools (e.g., 'brc_list_supplier_op_bal_trans', 'brc_get_supplier'), but the description lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states 'creates a report' but does not clarify if this triggers a write operation or is read-only. It omits details on permissions, rate limits, error behavior (e.g., when grouping fields are unavailable), or whether the report is returned synchronously or stored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the tool's purpose and key behavior. It front-loads the action and resource. However, it could be slightly restructured to improve readability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is too sparse. It does not explain the output format, grouping criteria details, or potential edge cases. A report tool typically benefits from describing what the returned data looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only companyName), and the description adds no extra meaning beyond the schema's string type and example. Since schema already documents the parameter, baseline is 3. The description earns no bonus for parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a grouped nominal accounts report, identifies the data source (GET /v1/nominalAccounts), and specifies the grouping logic (by account group/type fields). This distinguishes it from sibling tools like brc_list_nominal_accounts (which likely lists without grouping) and brc_multi_company_nom_ac_report (multi-company variant).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not explain prerequisites, when grouping may fail, or how it compares to list_nominal_accounts or multi_company_nom_ac_report. The agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely bears responsibility for behavioral disclosure. It only states basic functionality but omits details like pagination, rate limits, side effects, or data scope (e.g., whether dormant records are excluded or filtered).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key action and resource, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is too brief. It lacks explanation of pagination, filtering, or the meaning of 'without dormant records', leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (only 3 of 7 parameters have descriptions). The tool description adds no parameter explanations, failing to compensate for the undocumented parameters like top, page, skip, and pageSize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('BRC products') with a clear qualifier ('without dormant records'), distinguishing it from the sibling 'brc_list_products' which likely lists all products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'brc_list_products'. It lacks any context about when to prefer this filtered version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not mention pagination, filtering, ordering, response format, or any side effects. Critical behavioral aspects (supported by schema like top, page, filter) are omitted, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. However, it is too brief and could include more useful information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations, many siblings), the description is incomplete. It does not explain how the three document types are combined, result structure, pagination behavior, or usage context, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (only companyName, filter, orderBy have descriptions). The tool description adds no parameter meaning beyond the schema; it does not explain top, page, skip, pageSize, or their relationships, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Lists combined BRC sales entries, sales invoices and sales credit notes,' which is a specific verb and resource. Sibling tools exist for individual lists, so this purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combined listing but does not explicitly state when to use this versus individual list tools. No when-not or alternative guidance is provided, only an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits beyond the implied read operation. No mention of authentication, rate limits, or what happens if the customer is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is minimally adequate but does not explain the return value or handle edge cases. It provides the core purpose but lacks completeness for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds no additional meaning beyond the schema, but it does not hinder understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'gets' and resource 'customer' with 'by id', distinguishing it from list tools. The description is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like brc_list_customers. Does not mention prerequisites or context, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention permissions, pagination, or what happens if no transactions exist. The description is minimal and adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that is clear and front-loaded. No unnecessary words, but it may be too minimal for a list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the tool is a simple list operation with two well-documented parameters. However, it lacks explanation of what constitutes a 'customer opening balance transaction' and the return format, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description does not add any additional meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'customer's opening balance transaction list', distinguishing it from siblings like brc_get_customer_opening_balance (which likely gets the balance itself) and brc_list_supplier_op_bal_trans (supplier version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., brc_get_customer_opening_balance or other list tools). The description only states functionality without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'checks' without explaining behavior (e.g., returns boolean, throws error, or side effects). For a validation tool, details on response format or error handling are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, conveying core purpose. However, it could include more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), description is adequate for basic understanding but lacks information about return values or validation results. Output schema is absent; description should clarify what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters (companyName example, transactionDate format). Description adds no additional context beyond schema, meeting baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks if a transaction date falls within the current financial year of the connected BRC company. Verb 'checks' and specific resource/scope are well-defined, distinguishing it from other validation tools like brc_check_transaction_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as brc_company_readiness_check or brc_get_financial_year. No explicit context about prerequisites or typical use cases (e.g., before creating transactions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only states the basic read operation, omitting details like permissions, error conditions, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core function without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and low complexity, the description is adequate but lacks details about the return format or what constitutes a BRC cash payment, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal value beyond schema descriptions (e.g., 'Cash payment id.' and 'Company context name').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single BRC cash payment by ID, using the verb 'Gets'. This distinguishes it from sibling list tools like brc_list_cash_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as brc_list_cash_payments or other get tools. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Gets one BRC cash receipt by id,' with no disclosure about what happens if the id is not found, permissions needed, or whether it is read-only. This is minimal and does not add value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, efficiently conveying the core purpose. It is front-loaded and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with no output schema, the description does not explain return values, error handling, or what a 'BRC cash receipt' contains. This leaves the agent with incomplete context for expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description adds no additional meaning, so it scores at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets one BRC cash receipt by id' clearly states the verb (gets), resource (BRC cash receipt), and method (by id). It distinguishes from sibling tools like brc_list_cash_receipts (list) and brc_batch_cash_receipts (batch), and from brc_get_cash_payment (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single retrieval, but does not explicitly state when to use this tool versus list or batch alternatives. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that multiple API calls are made (one per ID), which is key behavioral info. However, it lacks details on error handling, rate limits, or ordering. With no annotations, the description partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, one sentence. It is efficient but could benefit from additional context like usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch retrieval tool with no output schema and no annotations, the description is incomplete. It does not describe return format, error behavior, or potential limitations like ID count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no new parameter 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets nominal accounts for specific IDs by calling an API per ID. It distinguishes from the sibling brc_get_nominal_account_ledger_by_id by implying batch retrieval for multiple IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the singular get or list tools. The usage is only implied from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, error handling (e.g., if supplier not found), or any side effects. The minimal description offers little beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is appropriately sized for a simple get tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate but lacks details about return values or error conditions, which could be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters. The description adds no additional meaning or context beyond what is in the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a single BRC supplier by its ID. The verb-resource combination is specific and distinguishes it from sibling tools like brc_get_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as list_suppliers or other get tools. No context about prerequisites or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does state it is read-only, which is a key behavioral trait. However, it does not cover other aspects like response structure or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences, front-loading the action. Could be slightly more structured, but it is efficient for the amount of information needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description lists the returned fields adequately. However, it lacks detail on the response format or structure, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets raw BRC company processing/options settings and lists specific fields. However, it doesn't explicitly differentiate from sibling tool brc_get_company_processing_settings, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions read-only nature and that changes must be made elsewhere, implying usage context. No explicit when-to-use or alternatives are provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses support for optional OData filtering by entryDate and ordering by id, which adds beyond the schema. However, it does not mention that the tool is read-only, whether pagination is available (though implied by top/skip), or any authorization requirements. It provides some behavioral context but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two clear sentences. Every word is necessary and directly conveys the core functionality. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and no output schema, the description is adequate. It explains the resource (Accruals) and key filtering/ordering capabilities. However, it could be enhanced by noting that the response is paginated or by specifying return fields, but given the tool's simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 that filtering is by entryDate and ordering by id, which aligns with the schema but does not provide additional nuance or examples beyond what is in the parameter descriptions. It offers marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of the company's Accruals, using a specific verb ('Returns') and resource ('Accruals'). While it implicitly differentiates from sibling list tools by focusing on the Accruals entity, it does not explicitly distinguish itself from other list tools in the same family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., brc_get_accrual for single record retrieval). There is no mention of prerequisites, context, or scenarios where this tool is preferred. The agent is left to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the action but lacks disclosure of consequences (e.g., destructiveness, irreversibility, authentication requirements). Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the key action. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and covers the basic purpose but lacks context about the scope (all company contexts) and implications. Given no annotations or output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is fully covered. The description adds no parameter-specific information, but none is needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('clears') and specifies the resource ('all connection credentials for all company contexts'). It clearly distinguishes from the sibling tool 'brc_clear_company_api_key' which presumably clears credentials for a single company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention when not to use it or compare it to the sibling 'brc_clear_company_api_key'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies mutability (clearing) but does not elaborate on side effects, reversibility, or permissions needed. With no annotations, some burden is on description, but it adequately states the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with action. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple clear operation with one parameter, description is adequate but lacks explanation of what 'clearing' means operationally (e.g., requires re-authentication).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full parameter description; description merely echoes 'named company context'. No additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'clears' and resource 'API key for named company context', distinguishing it from sibling 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like brc_clear_all_company_api_keys, or prerequisites for clearing a key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions what the tool highlights but does not state whether it is read-only, required permissions, error conditions, or side effects. This leaves ambiguity for an AI agent about safety and invocation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and contains no redundant information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and key check points, but it does not mention expected return values, prerequisites (e.g., company must be connected), or error handling. Given the simplicity of the tool (one param, no output schema), the description is minimally sufficient but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'companyName' is fully documented in the schema with a description and example. The tool description does not add further semantics beyond what the schema provides, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('checks readiness'), the target ('connected Big Red Cloud company'), and scope ('read-only and transaction workflows'). It highlights specific considerations (financial-year, VAT, reference-data), distinguishing it from sibling tools that perform operations like batch processing, creation, or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used before initiating read-only or transaction workflows, but it does not explicitly state when to use it versus alternatives. It lacks exclusions or references to related tools like brc_start_company_connection or brc_confirm_company_connection, which would clarify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only discloses that child accruals are not returned, which adds minimal behavioral context. Missing details on idempotency, error states, or auth requirements—burden fully on description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence delivers the core action and resource; the second adds a key limitation. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not specify what information is returned. It mentions 'information about' but is vague. For a get tool, more detail on response fields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (companyName, id) have descriptions in the schema. The description does not add extra meaning beyond what the schema provides, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns information about a single parent accrual by ID, and explicitly notes child accruals are not exposed, distinguishing it from list tools like brc_list_accruals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (retrieve a single parent accrual by ID) but lacks explicit comparison to siblings like brc_list_accruals (for multiple) or brc_create_accrual (for creation). The exclusion of child accruals provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only states 'returns information' with no disclosure of idempotency, error handling on missing id, auth requirements, or other behavioral traits. The 'get' prefix implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, front-loaded with verb and resource, concise and without fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no nested objects), the description minimally covers the tool's function. However, the absence of details about return fields or structure leaves room for ambiguity. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes both parameters (id, companyName). The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns information about a single Nominal Journal Batch by id. The verb 'Returns' and resource 'Nominal Journal Batch' are specific, and the tool is distinct from the sibling 'brc_list_nominal_journal_batches' which likely retrieves all batches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs alternatives. However, the purpose is implied by the 'get' prefix and the parameter 'id', suggesting it is for retrieving a specific batch. Lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains the two-step commit pattern, preflight response, and explicit confirmation requirements. Could add details on error handling or response format, but covers essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with several sentences that convey necessary workflow steps. Some redundancy (e.g., 'retry with confirmWrite: true only after explicit user confirmation' is restated). Could be more structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
High number of parameters (15) and no output schema. Description covers agreement flow but omits explanation of core financial fields (netAmount, vatRateId, etc.), return values, or error scenarios. Incomplete for practical use without supplementary parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% with descriptions only for companyName, confirmWrite, and confirmCounterpartyExplicit. The description adds value for these two boolean flags, but over 13 other parameters (e.g., supplierId, acCode, netAmount) have no additional explanation. Fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a purchase with a generated reference. Lacks explicit differentiation from sibling brc_create_purchase for manual references, but the condition 'Use when the company is configured for auto-generated purchase references' provides context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use when the company is configured for auto-generated purchase references') and provides a detailed workflow: first call without confirmWrite, show draft, then retry with confirmWrite after user confirmation. Also covers counterparty confirmation and warns against reusing counterparty from earlier drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'gets,' suggesting a read-only operation, but does not disclose potential side effects, error handling (e.g., missing ID), or any authentication or rate limit details. The agent is left without behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the key operation. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description covers the essential purpose. However, it lacks return structure details or error scenarios, which could be helpful for a complete understanding. Still adequate for a basic get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (id, companyName) described in the schema. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets one BRC purchase by id,' specifying the verb (gets), resource (BRC purchase), and filter (by id). This distinguishes it from sibling tools like brc_list_purchases for listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a purchase ID, but lacks explicit guidance on when not to use or mention of alternatives. The context of 'by id' is present but could be more explicit about the use case versus listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions it never exposes connection credentials, which is important. However, it does not explain what 'claims' means in terms of side effects (e.g., state changes) or what happens on success/failure. The term 'claims' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the action and include a security promise. Every sentence adds value without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose and usage context adequately. However, it does not describe what the tool returns or the effect of 'claiming' a code, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% for the single parameter 'code', so the schema already describes it well. The description adds context about the code's origin (success page) but does not provide additional semantic value beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool claims a completed secure Red connection code, indicating its purpose. It distinguishes from sibling tools like brc_start_company_connection by referencing a specific post-submission step. The verb 'claims' is somewhat abstract but the context clarifies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: after the user has submitted the secure connection page and returns with the confirmation code. It provides an example scenario (MCP session changed). It does not explicitly mention when not to use or alternative tools, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the two-step confirm workflow but does not mention destructive nature, permissions required, or error handling beyond the confirmation step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description consists of two sentences that efficiently convey the core functionality and the required workflow. Somewhat run-on but overall clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, nested objects, no output schema), the description provides the key workflow but lacks details on how merged fields work, what the preview looks like, and error scenarios. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 practical context for the confirmWrite parameter beyond the schema description, explaining the workflow. However, it does not add semantics for other parameters like id or companyName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a BRC cash payment using merged fields. It does not explicitly differentiate from sibling tools like brc_update_cash_receipt, but the name itself is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on the two-step confirmation process, including instruction to first call without confirmWrite to get a preview, then retry with confirmWrite only after explicit user confirmation. It also clarifies that passing preflight is not confirmation. However, it does not discuss when to use this tool versus other update or create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals the mutation nature ('Updates') and the confirmation requirement to prevent accidental writes. However, it does not mention authentication needs, rate limits, side effects, or what gets updated beyond note and reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the action, explaining the confirmation workflow, and adding a warning. No extraneous information, and the critical workflow details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers the confirmation pattern but lacks details on what the preview contains, what fields can be updated, and the response format. It is adequate for a basic understanding but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (3 of 5 params have descriptions). The description adds value for confirmWrite by explaining its conditional usage, but for 'note' and 'reference' it only hints at 'structured safe text/ reference fields' without clarifying format or constraints. The schema descriptions for id and companyName are adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a BRC sales credit note, using 'structured safe text/reference fields'. While it does not explicitly distinguish from sibling update tools (e.g., update_sales_entry), the action and resource 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on the two-step confirmation workflow: first call without confirmWrite returns a preview, then retry with confirmWrite after user confirmation. It explicitly warns that 'Passing preflight is not confirmation.' However, it does not compare when to use this update tool versus create or other update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the confirmation pattern and max items per request, but lacks details on what happens during the batch (e.g., validation, error handling, idempotency). No annotations provided, so description carries the full burden but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy, front-loaded with key info. Every sentence adds essential context about the confirmWrite workflow and limits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core workflow but lacks details on return value structure (no output schema), the flexible items schema (what fields are expected), and error conditions. For a batch tool with complex behavior, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds context for priceBasis (enum explanation), confirmWrite (workflow), confirmCrAnalysisCategory (when to use), and companyName (example). Adds meaningful value beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Processes a batch of products' which is a verb+resource, but doesn't specify whether it creates, updates, or deletes. The workflow details suggest it's likely creating or updating, but the core action is vague. Distinguishes from siblings by referring to batch processing of products specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step workflow with confirmWrite, including when to set it to true and that preflight is not confirmation. However, does not compare to other batch tools or single-entity create/update tools, so integration with alternatives is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions returning warnings but does not disclose whether the tool is read-only, destructive, requires authentication, or has rate limits. The behavioral details are insufficient for an agent to fully understand side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no unnecessary words or redundancy. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two parameters, no output schema) and the presence of many sibling tools, the description provides sufficient context about its pre-check role and the types of workflows it applies to. However, it could benefit from indicating what specific warnings are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters ('workflow' and 'companyName'), each with descriptions. The tool description adds context about VAT and payment terms but does not enrich the parameter-level meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool checks BRC company processing settings before VAT-sensitive or payment-terms-sensitive workflows, and returns warnings to be shown before creating or changing records. This clearly distinguishes it from sibling tools like 'brc_company_readiness_check' or 'brc_get_company_processing_settings'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('before a VAT-sensitive or payment-terms-sensitive workflow' and 'before creating or changing records'). It provides clear context but does not explicitly list when not to use it or compare it to alternatives like 'brc_company_readiness_check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the confirmation requirement and automatic category creation, but lacks details on side effects, error conditions, or return behavior, which are important for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three well-organized sentences that front-load the purpose, then give warnings, requirements, and optional behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no output schema), the description covers essential usage but omits return values, error handling, and full parameter details, leaving some gaps for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description clarifies semantics for only a few parameters (required fields and categoryId). Many parameters remain unexplained, so the description only partially compensates for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a BRC bank account, using a specific verb and resource. It distinguishes from sibling tools like brc_update_bank_account or brc_delete_bank_account by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to call with confirmCreate=true (only after user confirmation), lists required fields, and explains optional behavior of categoryId. However, it doesn't explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the journal should be balanced and gives confirmWrite instructions, but it is ambiguous whether the tool creates a draft or requires confirmWrite to finalize. The first sentence 'Creates a new Nominal Journal Batch' may conflict with the later instruction, as it's unclear if creation occurs immediately or only after confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and front-loads the primary action. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a financial journal batch with 7 parameters and no output schema, the description should explain the outcome (e.g., returns batch ID or status), clarify the draft vs. final creation behavior, and possibly mention error conditions. It fails to do so, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 beyond schema by explaining the need for balanced debit/credit lines and the proper use of confirmWrite, which helps the agent understand constraints not fully captured in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Creates a new Nominal Journal Batch' and specifies the resource. It also distinguishes from sibling tools by being specific to nominal journal batches, and the guidance on balanced lines and confirmWrite adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use confirmWrite=true (until user confirms), implying a two-step workflow. It does not mention alternatives or when to use other batch creation tools, but for this tool alone, it is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses that settings are read-only and changes must be made elsewhere, but omits details on authentication, rate limits, side effects, or response structure. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the action, then usage guidance, and a warning. It is efficient and avoids redundancy, though it could be slightly more structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns. It mentions the settings cover specific areas but does not describe the response format or fields. For a simple read tool, this is borderline sufficient but leaves gaps for an AI agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides (e.g., includeRaw purpose is already described in schema, companyName is simply labeled). Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads BRC reference auto-generation settings for specific document types (sales, purchases, quotes, debtors journal, creditors journal). It uses a specific verb ('Reads') and identifies the resource, effectively distinguishing it from sibling tools that get other company settings or perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool before creating reference-sensitive records, and provides a specific caveat about handling Unknown quotes. However, it does not mention when not to use the tool or name alternative tools, leaving some ambiguity for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals the key two-step confirmation behavior and warns that preflight does not equal confirmation. However, it does not disclose details about permissions required, reversibility of updates, error handling, or the return format after a successful update. The description addresses the most critical behavioral nuance but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loading the purpose before detailing the process. It is concise and each sentence adds value. The phrase 'Passing preflight is not confirmation' is a bit cryptic but provides important caveat. Overall, it is efficient but could be slightly more structured with a clearer separation of purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description should cover more context. It adequately describes the main usage flow and confirmation mechanism, but does not explain what happens after a successful update (e.g., response format), what error conditions might occur, or any prerequisites like having an existing quote. The description is sufficient for the core behavior but incomplete for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 60%, meaning most parameters are already described in the schema. The description adds minimal parameter-specific meaning beyond the schema: it mentions 'structured safe text/reference fields' which hints at note and reference parameters, but does not elaborate. The confirmWrite parameter's semantics are well-covered in the schema already. Thus the description adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a BRC quote using structured safe text/reference fields. It distinguishes itself from sibling tools like brc_create_quote (creates new quote) and brc_close_quote (closes quote). The verb 'updates' plus the resource 'BRC quote' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the two-step confirmation process: first call without confirmWrite to get a payload preview, then after showing a plain-English draft to the user and obtaining explicit confirmation, retry with confirmWrite: true. It also warns that 'passing preflight is not confirmation.' However, it does not explicitly state when to use this tool versus other related tools like create or close, though this is implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read-only operation ('returns transactions') but lacks details on potential side effects, pagination, error cases, or rate limits. The description is minimal beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and usage. Every sentence adds value, no redundancy. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and usage, it omits details about the return value (no output schema) and potential error conditions. For a simple list tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'Requires bookTranId' which is already in schema as required. No additional semantic context beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'transactions eligible for allocation' from a specific sender book transaction, using a precise verb and resource. It distinguishes itself from siblings like 'brc_update_allocations' and 'brc_list_allocated_transactions' by specifying the nature of the transactions and the intended usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before updating allocations so the user can see which receiver transactions are available', providing clear context and a prerequisite ('Requires bookTranId'). It does not explicitly list alternatives or when not to use, but the context effectively guides the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full transparency burden. It discloses that 'connection credentials are never returned' and advises against showing technical fields to normal users. However, it does not mention authentication requirements, read-only nature, or any side effects. This is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states the core purpose, and the second provides user-facing presentation rules. No extraneous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return format by specifying 'customerMessage text and the plain company names' and what to avoid showing. However, it lacks details on the full response structure, pagination, or ordering. For a simple list tool with no parameters, this is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter-specific meaning because there are none, but it correctly confirms that no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lists company contexts currently connected in this MCP server session.' The verb 'lists' and resource 'company contexts' are specific. Among sibling tools, this is the only one for company contexts, distinguishing it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It provides presentation instructions but no guidance on prerequisites, when not to use, or comparison to related tools like brc_start_company_connection or brc_confirm_company_connection. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the critical behavioral trait of requiring a two-step preflight/confirmation pattern, which is not obvious from the schema alone. Describes that first call returns a preview and confirmation_required, and that preflight is not confirmation. With no annotations, the description carries this burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action. Efficiently conveys the critical workflow. Could be slightly more structured (e.g., bullet points) but remains clear and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the key confirmation workflow but lacks details on output format for successful update (no output schema) and error handling. With 5 parameters and nested objects, more context on return values and error states would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds significant value for confirmWrite by detailing the confirmation workflow. For other parameters like payload and updates, it minimally adds 'merged fields' which aligns with schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a BRC bank account using merged fields (verb+resource). It distinguishes from sibling update tools by specifying 'bank account.' However, it does not explicitly contrast with other bank account tools like create/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions for the two-step confirmation process, including when to set confirmWrite and how to show plain-English summaries. Does not compare to other tools but the name implies update vs. create/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only hints at update behavior via confirmWrite flag. Fails to disclose side effects, authentication needs, or what happens in draft mode vs. confirmed write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main action, no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description explains prerequisite and confirmWrite guard but omits return values and behavior when confirmWrite=false. Adequate for schema-covered params, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%), but description adds crucial context for confirmWrite parameter (user confirmation workflow) and implicitly links timestamp to get step.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a Nominal Journal Batch by ID, specifies prerequisite use of brc_get_nominal_journal_batch, and distinguishes from create/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: retrieve first using get tool, and don't set confirmWrite=true until user confirms. Lacks explicit when-not-to-use scenarios but covers the critical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains the two-step confirmation process and mentions the payload preview, but lacks details on the preview structure, error cases, or whether the deletion is reversible. The destructive nature is clear, but more context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose in the first sentence. Every sentence adds essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (delete with confirmation protocol) and lack of output schema, the description covers the core workflow and parameter usage adequately. It does not mention return values or error handling, but provides enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description adds value by explaining the confirmWrite parameter's role in the confirmation workflow. However, it does not add new meaning for the id or companyName parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a BRC cash payment by id'), specifying the verb and resource. It distinguishes from sibling tools like brc_delete_cash_receipt by targeting 'cash payment' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit steps: first call without confirmWrite returns confirmation_required, then retry with confirmWrite true only after user confirmation. It warns that passing preflight is not confirmation. However, it does not mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 destructive nature of the tool and the required confirmation workflow, including the need for user confirmation beyond initial intent. This is valuable beyond just saying 'deletes'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It is efficient in conveying the key workflow without extraneous text. However, it could be slightly better structured (e.g., separating steps) for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple delete tool with confirmation, covering the workflow and user interaction. However, it does not mention error cases (e.g., id not found) or what the return values are, which might be needed since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters have descriptions). The description adds meaning for confirmWrite by explaining the confirmation protocol, but confirmDelete has no description and is not addressed. The description could better explain how confirmDelete fits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a BRC cash receipt by ID, with a specific verb and resource. However, it does not explicitly distinguish from sibling delete tools like brc_delete_cash_payment, although the resource name differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the two-step confirmation process: first call without confirmWrite to get a payload preview, show a draft to the user, then retry with confirmWrite=true only after explicit confirmation. It also warns that 'Passing preflight is not confirmation,' covering when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is read-only and changes must be made in Big Red Cloud, which is crucial behavioral information. Since no annotations are provided, the description adequately covers transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no wasteful content. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, and behavioral constraints adequately for a read tool. Lacks description of return structure, but without an output schema, it still provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description adds minimal new meaning beyond usage context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads BRC company processing/options settings and lists specific areas affected (VAT, cash receipts, etc.). Distinguishes from siblings by its focus on processing settings, though not explicitly compared to similar get_company_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before VAT-sensitive write workflows, providing a clear context for when to employ this tool. Does not mention when not to use or alternatives, but the context is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. While it explains the selection logic, it does not explicitly state that the tool is read-only, idempotent, or any authentication requirements. The behavioral traits are implied but not clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the purpose and immediately providing actionable guidance. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should disclose what information is returned (e.g., category codes, names). It only says 'lists categories' and focuses on selection guidance. Pagination parameters exist but are not addressed. The guidance is thorough but the output structure is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, but the description does not add any information about the parameters (companyName, top, page, skip, filter, orderBy, pageSize). It does not compensate for the low schema coverage, leaving the agent to infer parameter meaning from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Lists BRC analysis categories' and provides specific guidance on how to use the results for sales invoice and sales credit note product lines, distinguishing it from CR categories. This makes the purpose unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for selecting Sales analysis categories for sales invoices/credit notes), what not to do (avoid defaulting to CR categories), and provides a fallback instruction (ask the user if uncertain). This provides excellent decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should clearly state read-only nature. It says 'Returns a list' implying a read operation, but does not explicitly mention safety or absence of side effects. Additional behavioral details like pagination or rate limits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description with no waste. First sentence states purpose, second provides use-case guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and 100% schema coverage, the description is sufficiently complete. It explains the typical use case (identify id and timestamp before update/delete). No output schema exists, but the list's purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 by mentioning filter by entryDate and order by id, but these are already described in the schema. No new parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a list of the company's Nominal Journal Batches', with a specific verb and resource. It also distinguishes itself from sibling list tools by focusing on nominal journal batches and explicitly linking to update/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this before updating or deleting a nominal journal batch so the user can identify the correct id and timestamp.' This tells when to use the tool, though it does not contrast with other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It transparently explains the preflight/confirmation workflow and what the first call returns (confirmation_required and payload preview). However, it does not mention any side effects or permission requirements, though the confirmation pattern mitigates risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the purpose. The second sentence is dense but packs essential workflow instructions. No extraneous words; could be slightly clearer by breaking into steps, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 15 parameters, no output schema, and low schema coverage, the description focuses on the critical confirmation pattern but omits details about what updates are possible (e.g., which fields can be changed) and return values. It provides enough for correct invocation but not full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%) and the description adds meaningful context for the confirmWrite parameter only, explaining its role in the workflow. Other parameters are not individually described beyond what the schema provides. This partially compensates for the low coverage but leaves many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Updates a BRC purchase', which is a specific verb and resource. While it doesn't list the specific updatable fields, the purpose is unambiguous and distinguishes it from siblings like brc_create_purchase or brc_get_purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit two-step instructions: first call without confirmWrite to get a preview, then retry with confirmWrite=true only after explicit user confirmation. It also warns that 'Passing preflight is not confirmation,' offering clear guidance on when and how to use the tool compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses preflight flow and confirmation requirements, which are not in annotations (none provided). Does not mention side effects, reversibility, permissions, or failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient with 5 sentences, each adding critical information. Front-loaded with core purpose and iteratively adds details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the multi-step batch flow, all confirmation parameters, and constraints. Lacks details on successful response or error handling, but no output schema exists to offload that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining the confirmation flow for confirmWrite, confirmCounterpartyExplicit, and confirmCrAnalysisCategory. Schema coverage is 100% with descriptions, but the tool description provides richer context for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Processes a batch of BRC cash receipts' and specifies maximum items per batch. It distinguishes from single-create tools like brc_create_cash_receipt and from brc_batch_cash_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step usage: first call without confirmWrite returns preview, then retry with confirmWrite after user confirmation. Details when to set confirmCounterpartyExplicit and confirmCrAnalysisCategory. However, does not explicitly differentiate from single creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the two-step confirmation workflow and the max items constraint, but does not explain post-confirmation behavior (e.g., what happens after successful processing, error conditions, or whether it creates or updates sales reps). This leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with the core action and constraint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covers the main workflow but lacks details about the result of a successful write, error handling, or side effects. It is adequate but not fully complete for a batch processing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: the confirmWrite two-step usage, that priceBasis applies to each item, and that confirmCrAnalysisCategory applies to all items. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 reps, with a maximum of 5 items. The verb 'processes' and resource 'batch of sales reps' are specific, and the tool is clearly distinguished from sibling batch tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: first call without confirmWrite returns a preview, then user must explicitly confirm before retrying with confirmWrite=true. It clarifies that preflight is not confirmation. However, it does not compare this tool to alternatives (e.g., singular sales rep creation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: does not handle opening balance transactions, performs email-name mismatch checks, and requires a two-step confirmWrite workflow. Lacks details on success/error responses but covers critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that covers multiple points. It is front-loaded with the primary action but could be more structured (e.g., bullet points) for clarity. Not overly verbose but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes key workflow and edge cases but omits details about the payload structure (though schema says 'raw BRC payload') and return values. Given no output schema, description should include what the tool returns or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but the description adds significant context: explains the confirmWrite workflow, warning about opening balances, and email-check logic. This goes beyond the basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a BRC customer using a raw BRC payload. It distinguishes from sibling create tools by specifying 'customer' and detailing unique behaviors like handling opening balances and email checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context and explicit workflow instructions (e.g., not to set confirmWrite on first call, warn about opening balances and email mismatches). However, does not explicitly state when not to use this tool or alternative tools for other entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavior: the API accepts only the parent transaction shape and automatically generates a reversing child transaction. It also warns about confirmWrite usage, which is important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: first states purpose and mechanism, second provides a critical usage warning. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description fails to mention what the tool returns (e.g., the created prepayment or success status). It does cover the parent/child transaction behavior, but omits return value information, which is a gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about confirmWrite (must only be true after user confirmation) which aligns with the schema, but does not significantly augment what the schema already provides for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'Creates a new parent Prepayment', identifying the specific verb-verb (create) and resource (prepayment). It distinguishes from siblings like update, delete, get by making creation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on the confirmWrite parameter: 'Do not call with confirmWrite=true until the user has reviewed the draft and explicitly confirmed creation.' This clarifies when and how to use the tool safely, though it does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the two-step confirmation behavior, the need for explicit counterparty confirmation, and the requirement for user confirmation before writing. Does not mention auth needs or success response, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is appropriately sized for the complexity, front-loaded with purpose, and each sentence adds necessary guidance. Could be slightly tighter but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, many required, and no output schema, the description covers the workflow and two boolean parameters well but leaves many other parameters unexplained. Moderate completeness for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so description should compensate. It adds meaning for confirmWrite and confirmCounterpartyExplicit (explaining workflow), but leaves many other parameters (e.g., note, acCode, procDate, entryDate) without explanation, relying on schema which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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' and outlines a specific two-step confirmation process, distinguishing it from other create tools like brc_create_sales_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions: first call without confirmWrite returns a preview, retry only after user confirmation; also requires confirmCounterpartyExplicit after user explicitly confirms counterparty. Warns against reusing counterparty from earlier drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral transparency. It implies read-only behavior (listing) but does not explicitly state safety, permissions, or side effects. It is adequate but lacks explicit disclosure for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, structure, usage guidance. No fluff, front-loaded with the action. Exceptionally concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should help the agent understand what data will be returned. It provides strong context on how to use the rates (Sales vs Purchase) but does not describe the response fields (e.g., percentage, vatCategoryId values). Still, the usage guidance is very helpful, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 7 parameters with 43% coverage; the description does not add meaning to any parameter except indirectly referencing vatCategoryId (which is not a parameter of this tool). It misses an opportunity to explain parameters like top, page, skip, pageSize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Lists BRC VAT rates' and explains the relationship to VAT categories via vatCategoryId. It distinguishes itself from the sibling tool brc_list_vat_categories by cross-referencing it, and the verb 'lists' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use a Sales VAT category rate for sales invoices/credit notes, and when not to use purchase rates even if same percentage. It also instructs to cross-reference brc_list_vat_categories to group rates by Sales vs Purchase before choosing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the confirmation workflow, preview requirement, and counterparty confirmation necessity. While it implies write operations, it omits error handling, idempotency, or success response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main action and max batch size. Every sentence contributes, but it could be slightly more structured with bullet points for clarity. Still efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description covers the main workflow but lacks details on the payload preview format, post-submit response, and error handling. More completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 workflow context for confirmWrite and confirmCounterpartyExplicit, and explains priceBasis. This adds meaning beyond the schema, especially the two-step process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 with a specific verb and resource. It distinguishes from siblings like brc_batch_sales_invoices by detailing the two-step confirmation workflow and maximum batch size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step usage: first call without confirmWrite to get confirmation_required and preview, then retry with confirmWrite after user confirmation. Also requires confirmCounterpartyExplicit. However, it does not explicitly mention when not to use this tool or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It explains the two-step flow, the need for user confirmation, and the return data (confirmation_required and preview). However, it does not specify the final response format, error behavior, or whether the operation is reversible (though brc_reopen_quote exists in siblings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses clear, step-by-step language. It is relatively concise for the complexity of the two-step flow, though the final sentence 'Passing preflight is not confirmation' could be integrated earlier for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the two-step flow well but lacks details on the success response after the second call. Without an output schema, the agent is left uncertain about the result (e.g., status, errors). Also, no mention of authorization requirements or side effects. Given the tool's mutating nature and complexity, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100% coverage). The description adds significant workflow context for confirmWrite, explaining its role in the two-step confirmation process. This goes beyond basic schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it closes a BRC quote, uses specific verb+resource. The description of the two-step workflow distinguishes it from other quote operations, and the sibling list includes brc_reopen_quote, brc_create_quote, etc., 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions for the two-step invocation: first call without confirmWrite returns a preview, then retry with confirmWrite only after user confirmation. It also warns that passing preflight is not confirmation. However, it does not explicitly state alternatives like brc_reopen_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the confirmation workflow, default values for entryDate/procDate, conditional sending of VAT rate fields, and the requirement for explicit counterparty confirmation. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but front-loads the core purpose. Each sentence adds value: creation, dual input, defaults, conditional behavior, workflow steps. It is not overly verbose, though a bulleted list could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (30), nested objects, and no output schema, the description covers the core workflow and key behaviors. However, it does not explain return values (e.g., the preview object) or required fields beyond companyName. The agent might struggle to construct a valid request without additional context for many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10% (3 out of 30 parameters have descriptions). The description adds meaning for key parameters like confirmWrite and confirmCounterpartyExplicit, explaining their roles in the workflow, and notes default dates and conditional VAT fields. However, many parameters (e.g., total, acCode, note) remain unexplained, so the description only partially compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a BRC cash receipt,' specifying the verb and resource. It distinguishes this creation tool from other create_ and batch tools by focusing on a singular cash receipt and mentioning the dual input method (raw payload or flat fields).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on the two-step workflow: first call without confirmWrite to get a preview, then retry with confirmWrite after user confirmation. It also specifies that confirmCounterpartyExplicit is required after explicit user confirmation. However, it does not explicitly mention alternatives like brc_batch_cash_receipts for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deletion (destructive) and confirmation workflow. No annotations exist, so description carries burden. Could elaborate on permanence or side effects, but core behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful: purpose, prerequisite/warning, confirmation constraint. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, full schema coverage, and no output schema, description covers key points: prerequisite action, confirmation logic. Slight gap on whether deletion is reversible, but adequate for the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema: timestamp must be Base64 from get_accrual (with example), confirmWrite usage warning. All 4 parameters are explained in schema, and description enriches meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Removes' and the resource 'existing parent Accrual by id,' distinguishing it from other accrual tools (create, get, update, list). The name also reinforces the deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use brc_get_accrual first to retrieve the timestamp and warns against setting confirmWrite=true without explicit user confirmation. Could add when not to use, but current guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive action and the safety measure for confirmWrite, but with no annotations, it does not elaborate on consequences like irreversibility or return behavior. It adds value by explaining the timestamp prerequisite but lacks depth on what happens upon success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: stating the action, explaining a prerequisite, and providing a safety warning. No redundant information, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers the deletion process, including prerequisite and safety. It does not describe the response or side effects, but for a simple delete tool, the information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 detail for 'timestamp' by specifying 'Base64 string format' and giving an example, which is not in the schema. For confirmWrite, it repeats the schema's confirmation requirement. Overall, it enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Removes an existing Nominal Journal Batch by id.' It uses a specific verb ('removes') and names the resource ('Nominal Journal Batch'), distinguishing it from other delete tools for different entities in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it requires the batch timestamp in Base64 format, instructs to use brc_get_nominal_journal_batch first to retrieve the timestamp, and warns against setting confirmWrite=true without user confirmation. This is strong procedural guidance, though it does not mention when to use alternatives like update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals the two-step confirmation process, that the first call returns confirmation_required and a preview, and that confirmWrite must only be true after user confirmation. This adequately warns of the destructive nature and correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, followed by clear instructions. No extraneous text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow but lacks details on the 'confirmation_required' response format, the payload preview, and error cases (e.g., non-existent purchase). Given no output schema, it should provide more context for the two-step process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, but the tool description adds no meaning beyond what the schema already provides. The undocumented confirmDelete parameter remains unexplained. The description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes a BRC purchase by id', specifying the verb (deletes), resource (BRC purchase), and identifier (by id). It distinguishes itself from sibling delete tools by focusing on purchases, though it does not explicitly compare to others. The additional confirmation detail reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit steps: first call without confirmWrite, show preview, then retry with confirmWrite only after user confirmation. It warns that preflight is not confirmation. However, it does not compare to other tools like update or other delete tools, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fully discloses the behavioral pattern: the mandatory preview step, the requirement for explicit user confirmation, and that a preflight call is not confirmation. It does not cover potential side effects (e.g., irreversibility or permissions), but the core interaction is well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but necessary to explain the confirmation workflow. Every sentence serves a purpose; no fluff. Could be slightly shorter, but the complexity warrants the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the confirmation mechanism well but lacks details on what happens after deletion (e.g., success response, error handling, whether it's a soft or hard delete). For a destructive operation, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3. The description adds significant value for the confirmWrite parameter by explaining its semantics and the two-step process. It does not explain id or companyName beyond the schema, but the schema already has adequate descriptions for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a BRC sales credit note by id') and distinguishes this from other operations by specifying the unique timestamp confirmation process. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details the two-call workflow: first without confirmWrite to get a preview, then with confirmWrite only after user confirmation. It warns against treating preflight as confirmation. However, it does not compare to alternative deletion methods 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention side effects, authentication needs, rate limits, or any operational behavior. The focus is on content style rather than tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear directives. It front-loads the core purpose and uses imperative sentences ('Use when...', 'Summarise only...', 'Do not list...'). It could be slightly more concise, but it earns its length by providing comprehensive guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description thoroughly explains what the tool returns and its constraints. It specifies the scope of the summary (reading, creating, deleting, technical output) and provides limitations on content style, making it complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. With no parameters, the description cannot add parameter semantics beyond what is inferable. A score of 4 is appropriate as the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'Authoritative customer-facing permission and output policy summary for this Red session,' specifying a distinct verb-resource relationship. It differentiates from sibling CRUD tools by its focus on policy summarization rather than data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (e.g., 'when the user asks what they can do, what tools they have, what permissions are enabled') and what not to do (e.g., 'Do not list MCP tool names...'). It provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately indicates a read operation and a behavioral constraint about child prepayments. It does not mention permissions or error conditions, but for a simple get tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Efficiently conveys the core purpose and key limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is adequate for a straightforward get tool with well-described parameters. However, the absence of an output schema and lack of detail on returned fields may leave some ambiguity, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters (id and companyName). The description adds no additional parameter details beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns information about a single parent Prepayment by id, and explicitly notes that child prepayments are not exposed. This clearly distinguishes it from list tools and other prepayment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (get a specific parent prepayment) and notes a limitation (no child prepayments), but does not explicitly state alternatives like the list tool brc_list_prepayments for browsing multiple prepayments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 describes a read-only operation (returns existing allocations) and suggests a safe context (review before destructive actions). While it doesn't detail side effects or rate limits, the read-only nature is sufficiently implied, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: three short sentences that immediately convey the tool's purpose, usage context, and a prerequisite. Every sentence is necessary and front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description adequately covers purpose, usage context, and the required parameter. It could mention return format or pagination, but the current level is sufficient for most use cases given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (bookTranId and companyName) with descriptions, achieving 100% schema description coverage. The description only reiterates the requirement for bookTranId without adding additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns transactions already allocated from a specified sender book transaction. It uses a specific verb ('returns') and resource ('transactions already allocated'), and distinguishes itself from sibling list tools by focusing on allocated transactions and pre-reversal use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to review existing allocations before reversing or deleting one, providing clear when-to-use guidance. It also notes the required parameter (bookTranId), but does not explicitly mention when not to use or list alternatives, though the context implies it is a prerequisite to mutation tools like brc_update_allocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the preflight/confirm behavior. It explains that the first call returns confirmation_required and a preview. However, it does not explicitly state that the update is irreversible once confirmed, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the main action, then clearly outlining the two-step process. No wasted words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return of confirmation_required and payload preview but doesn't detail the payload preview content. With 5 params and nested objects, it covers the essential behavior, but could be more complete about the return structure. The sibling context is not needed for this dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 significant semantic value for confirmWrite, detailing its usage conditions. For other parameters (id, companyName, payload, updates), it relies on schema descriptions. The critical confirmWrite guidance justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a BRC customer using merged fields', specifying verb and resource. It also explains the two-step process involving confirmWrite. However, it does not explicitly differentiate from sibling update tools like brc_update_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions: first call without confirmWrite:true returns confirmation_required and payload preview; show draft in chat; retry with confirmWrite:true only after explicit user confirmation. It also clarifies that preflight is not confirmation, offering strong guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the two-phase commit behavior (preview then confirm), the maximum batch size, and the confirmCrAnalysisCategory flag. It does not detail side effects or error responses, but the key behavioral traits are transparent. A score of 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses clear, imperative sentences. It is somewhat lengthy but each sentence adds relevant information. Minor repetition (e.g., 'Maximum 5 items' appears in both description and schema) but not wasteful. Score 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values. It mentions that the first call returns 'confirmation_required and a payload preview', which is helpful, but it does not describe the final success/failure response after confirmWrite or error conditions. This leaves gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema: it explains the workflow for confirmWrite, the nature of items (batch items with max 5), context for priceBasis (when to use net vs gross), and confirmCrAnalysisCategory. This is exemplary parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 clearly indicates it handles multiple customers in batch. It distinguishes from siblings like brc_batch_products or brc_batch_cash_payments. However, it does not specify whether 'process' means create, update, or both, so clarity is slightly diminished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step guidelines: maximum 5 items, first call without confirmWrite returns a preview, show a plain-English draft, then retry with confirmWrite: true only after explicit user confirmation. It also warns that passing preflight is not confirmation and mentions confirmCrAnalysisCategory. This clearly tells the agent when and how to use the tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It explains the two-call workflow, confirmation requirements, and counterparty verification. It lacks details on side effects or error handling, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence adds necessary detail. It front-loads the core purpose then explains workflow and constraints. Could be slightly tighter, but no wasteful sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, all documented in schema, and no output schema, the description provides sufficient workflow and confirmation context. Missing details on return values or error scenarios, but adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value by explaining the workflow for confirmWrite and confirmCounterpartyExplicit beyond schema descriptions, including prohibitions and context for priceBasis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies it processes a batch of BRC payments, distinguishing it from other batch tools (e.g., brc_batch_cash_payments). It clearly identifies the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use instructions for confirmWrite and confirmCounterpartyExplicit, including what not to do. However, it does not mention alternatives or when not to use this tool overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the preflight behavior (confirmation_required and payload preview), runtime blocking of invalid productIds, and the need for explicit user confirmation. It does not describe the success response or error handling, but the covered behaviors are critical and well-articulated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured. It starts with a succinct purpose statement, then lists restrictions and step-by-step instructions. While it could be slightly more concise, every sentence adds important guidance. The front-loading of key information is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain return values, but it does not describe the structure of the payload preview or final response. It covers usage thoroughly but omits details about error messages or success indicators. Completeness is adequate for usage but not for fully understanding the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 significant value beyond schema: it explains the preflight workflow for confirmWrite, the counterparty confirmation rule, and the productId restriction. It also provides context on when to use priceBasis (net vs gross) and companyName. This extra guidance is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it processes a batch of sales credit notes. However, it does not explicitly differentiate from sibling batch tools like brc_batch_sales_invoices, though the name implies the distinction. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive, explicit guidance on when and how to use the tool: instructs to first call without confirmWrite, show draft, then retry with confirmation; warns not to use productId 0/1; dictates counterparty confirmation rules; and specifies max items. It also advises to call brc_list_products if product lines are needed. This is comprehensive and leaves little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: creates a parent accrual and relies on shared logic for reversing child. It also warns about confirmWrite. However, it doesn't explain the draft concept or what the first call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no fluff. Critical usage warning is front-loaded alongside purpose. Each sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values (no output schema) and does not fully explain the draft process. Given the complexity (9 params, two-step with confirmWrite) and no output schema, it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 little beyond what parameter descriptions already provide. The only extra is the confirmWrite warning, which is already in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new parent Accrual, distinguishing it from update/delete/list tools among siblings. It also mentions the automatic generation of a reversing child transaction, which specifies the resource shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'Do not call with confirmWrite=true until the user has reviewed the draft and explicitly confirmed creation.' This helps the agent avoid premature writes and implies a two-step process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fully explains the two-step preflight confirmation behavior, including that the first call returns a confirmation_required response and payload preview. With no annotations provided, the description carries the full burden and does so clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and then explains the process. It could be slightly more concise, but the step-by-step explanation is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two-step confirmation complexity and no output schema, the description adequately explains the preflight process. It could mention what the payload preview contains, but overall it's complete enough for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional meaning to parameters like code, name, companyName beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 rep, but does not differentiate from sibling tools like brc_batch_sales_reps for batch creation, which would help the agent choose the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step guidance: first call without confirmWrite, show preview in chat, then retry with confirmWrite after user confirmation. Also warns that 'Passing preflight is not confirmation', leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses key behaviors: the tool creates a supplier, does not handle opening balances, uses a two-step confirmation flow, and clarifies that 'passing preflight is not confirmation.' This is sufficient for a create tool. Minor gaps: no mention of authentication, idempotency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, next sentence states what it does not do, then gives step-by-step usage instructions. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the confirmation workflow well, but the payload parameter is described only as 'Raw BRC-compatible payload,' which is vague and lacks structure. There is no output schema, and the description only mentions 'confirmation_required' and 'payload preview' without specifying the return format. For a tool with a nested object parameter, more detail on payload structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description adds significant value beyond the schema: explains the confirmWrite parameter's role in the confirmation workflow, and gives guidance on when to set it true. This extra context helps an agent use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core action: 'Creates a BRC supplier using a raw BRC payload.' It also distinguishes itself from siblings by explicitly noting what it does not do (create/update opening balance transactions) and by describing a unique two-step confirmation flow, which sets it apart from other create tools like brc_create_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed workflow guidance: first call without confirmWrite, then after showing a plain-English draft and obtaining explicit user confirmation, retry with confirmWrite: true. It also specifies how to handle opening balance input (warn user). However, it does not directly compare with sibling tools or specify when to prefer this tool over others beyond 'creating a supplier,' which is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the mutation behavior (create/update) and the special confirmWrite requirement. However, it does not detail error conditions, idempotency, or return values, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, prerequisite, and behavioral caveat with required fields. Front-loaded, no waste, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values; it does not. Given the mutation tool's complexity, the omission of what the tool returns is a notable gap, though schema coverage is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces required fields but adds little additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates or updates allocations for a sender book transaction,' specifying the verb (create/update) and resource (allocations). It distinguishes from siblings by referencing the prerequisite tool brc_list_allocation_resolvers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use brc_list_allocation_resolvers first to identify eligible receiver transactions and warns not to call with confirmWrite=true until user confirmation. Provides 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-step confirm mechanism and what happens without confirmWrite (returns preview). However, it does not detail the preview content or any side effects, and there are no annotations to supplement. Still, the core behavioral trait is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, no wasted words, and the most important information (purpose and confirmation workflow) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-step confirmation) and lack of output schema, the description covers the essential workflow. It could be more complete by specifying the exact return structure, but it is sufficient for an agent to understand and execute the process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 critical context for the confirmWrite parameter and explains the purpose of payload/updates as merged fields, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a BRC cash receipt using merged fields, which is specific and distinguishes it from create or delete sibling tools. However, it could be more explicit about when to use this versus the create tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step usage guidance: first call without confirmWrite for a preview, then retry with confirmWrite: true after explicit user confirmation. It clarifies that passing preflight is not confirmation, which is excellent advice for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the two-step preflight behavior, including the return of 'confirmation_required' and a 'payload preview' on the first call. It does not mention error handling or permissions, but the core behavioral trait is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each serving a distinct purpose: state intent, describe the required workflow, and clarify a critical nuance. No redundant information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key preflight flow but omits details on error conditions, final success response, or handling of partial updates. For a tool with 5 parameters and nested objects, it is fairly complete but could be improved with post-update behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 is appropriate. The description adds value by explaining the 'confirmWrite' parameter's role in the two-step flow and reinforcing 'merged fields' for payload/updates. The other parameters (id, companyName) are adequately covered by schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a BRC product using merged fields.' This specifies the verb (update) and resource (BRC product). It does not explicitly distinguish from the create tool or other update tools, but the name and first sentence are sufficiently clear for a focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions: 'First call without confirmWrite: true... then retry with confirmWrite: true only after explicit user confirmation.' It also clarifies a common mistake: 'Passing preflight is not confirmation.' This is excellent guidance for correct tool invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the two-phase preflight/confirm behavior and the importance of user confirmation. However, it does not mention error states if confirmWrite is set on first call, nor idempotency or rollback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the purpose in the first sentence, then provides the critical usage pattern in the second, and a warning in the third.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the confirmation pattern, the description covers the unique behavior well. It could be more complete by detailing the preview format or error scenarios, but the essential information for an AI agent is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, but the description adds value by explaining the confirmWrite parameter's role in the preflight pattern and noting that note defaults to customer name. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a BRC sales invoice' with a specific verb and resource, distinguishing it from create/delete siblings. However, it does not explicitly differentiate from other similar update tools, but that is unnecessary as there is only one update for sales invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step usage instructions: first call without confirmWrite:true returns a preview, then retry with confirmWrite:true only after user confirmation. It also warns that 'passing preflight is not confirmation,' which prevents common mistakes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the preflight/postflight pattern, the requirement for explicit user confirmation, and the confirmCrAnalysisCategory parameter behavior. It describes the return of confirmation_required and payload preview, making the behavioral traits very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with no redundant sentences. It front-loads the core action and then explains the workflow. Could be slightly more structured (e.g., bullet points), but is clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow for a batch tool with preflight confirmation. It explains the return values (confirmation_required, payload preview) and the confirmWrite parameter usage. Given no output schema, it provides sufficient context for agents to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context beyond the schema: it clarifies the usage of confirmWrite (only after user confirmation), priceBasis (net vs gross), and confirmCrAnalysisCategory (CR analysis confirmation). This adds value to the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool processes a batch of suppliers, which is clear. However, it does not explicitly differentiate from sibling batch tools (e.g., brc_batch_customers). The name and context imply the resource, but no direct sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the two-phase commit workflow: first call without confirmWrite for preview, then retry with confirmWrite only after user confirmation. It also warns that passing preflight is not confirmation, and specifies max batch size. This clearly tells 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the safe deletion workflow (preview then confirm), adding context about confirmation_required and payload preview. It does not mention side effects or permanence, but the two-step process 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the main purpose, and each sentence adds necessary context. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a delete operation with a confirmation mechanism, the description adequately covers the workflow and parameter semantics. It lacks details on return value format or prerequisites like customer existence, but is sufficient for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the baseline is 3. The description adds value for confirmWrite by explaining its role in the two-step process, but does not clarify confirmDelete. It relies on schema for id and companyName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a BRC customer by id'), making the purpose explicit. It distinguishes from sibling tools focusing on customers, setting it apart from other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage guidelines: first call without confirmWrite to get a preview, then retry with confirmWrite: true only after explicit user confirmation. It warns against treating preflight as confirmation, ensuring safe use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the need for user confirmation via confirmWrite and the prerequisite of getting a timestamp. However, it does not mention irreversibility, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential. Front-loaded with the main action, followed by key constraint and workflow step. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the essential aspects: purpose, prerequisites, parameter hints, and usage guardrails. It is adequate for a simple delete tool, though it could mention return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are described. The description adds value by specifying the timestamp format (Base64) and the workflow hint to retrieve it via brc_get_prepayment. It also reinforces the confirmWrite behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Removes an existing parent Prepayment by id.' This is a clear verb+resource pair that distinguishes the tool from its siblings, such as brc_create_prepayment and brc_update_prepayment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites: requires the prepayment timestamp in Base64 format, advises to use brc_get_prepayment first, and warns not to set confirmWrite=true until user confirms deletion. This offers 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly discloses the behavioral trait: the first call without confirmWrite: true returns a confirmation_required response and a payload preview, and the agent must not treat a preflight as confirmation. This gives the agent complete understanding of the required workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but each sentence serves a purpose. It is front-loaded with the primary action and endpoint. Some redundancy exists (e.g., mentioning the endpoint twice), but overall it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema), the description covers the essential behavioral and parameter aspects. It does not detail return values or error handling, but the focus on the two-step confirmation process is appropriate for the tool's primary use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 83% of parameters with descriptions. The description adds value by deprecating the 'payload' parameter in favor of 'vatCategoryRates', explaining the protocol for 'confirmWrite', and describing 'vatCategoryRates' as the full BRC payload array. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Processes VAT rates for VAT categories via POST /v1/vatCategories/vatRates.' It specifies the HTTP endpoint, making the action unambiguous. However, it does not explicitly differentiate itself from sibling tools, though the context of VAT rates is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on when and how to use the tool: requires a full vatCategoryRates array and confirmProcess=true, outlines a two-step process with a preflight call returning confirmation_required, and instructs the agent to show a plain-English draft and retry with confirmWrite: true only after user confirmation. It also warns against setting confirmWrite true on the 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the sending action, need for user confirmation, requirement to show recipient email, and handling of multiple recipients. Could be more explicit about side effects or error handling, but covers key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but not overly verbose given the complexity. It is front-loaded with the core purpose. Some redundancy in listing unsupported types could be compressed, but overall each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and complex workflow, the description covers the sending process well but lacks detail on what the tool returns (e.g., success/failure, sent confirmation). It also doesn't address error scenarios like invalid email format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 for sendMode (only use 'separate' when user explicitly chooses) and confirmSend (must be true only after review). It also clarifies the behavior of toAddresses (ask about BCC when multiple).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it sends customer statement emails for supported document types only, explicitly listing unsupported types. It distinguishes from sibling tools like brc_send_sales_invoice_email and brc_send_quote_email by focusing on statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance, including instructions for unsupported document types (stop and list supported types). Also details workflow steps like requiring user confirmation before sending, handling multiple recipients, and asking for recipient email if missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully describes the behavioral traits: the two-step confirmation, the need to show a draft, and that preflight is not confirmation. It implies mutation but does not cover permissions or rate limits, which is acceptable given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single sentence stating purpose followed by detailed workflow instructions. Every sentence is necessary and efficiently communicates critical usage steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, required fields, nested objects) and no output schema, the description adequately explains the confirmation workflow and parameter semantics. It does not detail return values, but the workflow mentions expected responses like confirmation_required and payload preview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 confirmWrite parameter's workflow context (preflight vs actual confirmation). It also mentions 'merged fields,' aiding understanding of updates/payload parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a BRC payment using merged fields. It distinguishes itself from sibling update tools (e.g., brc_update_cash_payment) by specifying 'BRC payment' and detailing a unique two-step confirmation workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance for the confirmation workflow: first call without confirmWrite, show draft, then retry with confirmWrite after user confirmation. It does not explicitly contrast with other update tools but the name and context imply its use for BRC payments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses preflight mechanism returning confirmation_required and payload preview, confirmation flags, and requirement for explicit counterparty confirmation. Lacks error handling details but covers key behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, the description is well-structured with specific guidance and minimal redundancy. Each sentence serves a purpose, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, required parameters, confirmation flow, and prohibitions. Does not fully describe success response or error conditions, but given no output schema, the description provides ample context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema descriptions: explains payload as raw BRC payload, confirmWrite only after draft confirmation, confirmCrAnalysisCategory after user confirms CR, confirmCounterpartyExplicit after explicit naming. Schema coverage is 80%, so baseline 3 but enhanced by description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a BRC sales credit note with auto-generated reference using a raw payload, distinguishing it from brc_create_sales_credit_note (which likely requires manual reference) and batch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (company configured for auto-generated references), what not to do (default/demo reps, CR01/Customer), and provides step-by-step confirmation flow including preflight, draft, and explicit user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses behaviors: draft preview with confirmation_required, blocked placeholder product IDs, defaulting note to customer name, requiring confirmCrAnalysisCategory and confirmCounterpartyExplicit conditions, blocking non-Sales VAT rates, and the preflight distinction. This level of detail ensures the agent understands side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes some repetition (e.g., note and deliveryTo are described twice). While each sentence adds value, the overall length could be trimmed without losing essential information. The structure is somewhat rambling rather than logically organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects, no output schema), the description is remarkably complete. It covers prerequisites, confirmation flows, common pitfalls, dependencies on other tools, and blocking conditions. The agent has enough information to use the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (high), so baseline is 3. The description adds meaning beyond schema by explaining nested payload fields (note defaults, deliveryTo optional), clarifying confirmCrAnalysisCategory and confirmCounterpartyExplicit triggers, and noting the required saleRepId and saleRepCode (though not in schema). This adds substantial context for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 invoice with an auto-generated reference using a raw BRC payload. It specifies the condition (company configured for auto-generated references), which distinguishes it from sibling tools like brc_create_sales_invoice. The verb 'Create' and resource 'BRC sales invoice' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive usage guidance: when to use (auto-generated ref), what not to do (do not invent values, do not use placeholder product IDs), and steps to follow (first call without confirmWrite, show draft, then retry). It mentions prerequisites like requiring saleRepId and saleRepCode, and suggests calling brc_list_products. However, it does not explicitly name sibling alternatives for reference generation, which would make it clearer which tool to use when auto-generation is not configured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that read-only API calls are not logged, only data changes are recorded, and sensitive values are redacted (via parameter description). This provides good behavioral insight, though it could mention if the tool is non-destructive (implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy but front-loaded with the core purpose. Every sentence provides useful guidance. It is well-structured for an AI agent to parse and apply rules, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description adequately explains the scope: logs data changes from the session, excludes read-only calls. It covers the context of use. It doesn't detail the output format (e.g., list of objects), but given the tool's simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'includeTechnicalDetails' with boolean type and default false. Schema coverage is 100%, and the description adds context: 'Only set this to true if the user asks for technical details. Sensitive values are still redacted.' This clearly explains when to set it true, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows a record of data changes (create, update, delete, etc.) made through the Red MCP server session. It specifies what is logged and what is not, and distinguishes it as the source of truth for 'what did I do today in Red?' questions. This clearly differentiates it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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: for answering questions about user activity in Red/BRC. It also explicitly tells when not to include unrelated chat history, and provides guidance on what to include and exclude. This helps the agent decide exactly when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the confirmation workflow, email sending behavior, and constraints like supported document types. Could mention error handling or side effects, but thorough without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured; each part earns its place but could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary context: supported types, confirmation steps, recipient handling, and multi-recipient options, making it complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters; description adds workflow context for confirmSend, toAddresses, and sendMode, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Sends a quote email' and distinguishes supported document types from unsupported ones, differentiating it from sibling tools like brc_send_sales_invoice_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use and when not to, with detailed instructions for confirmation, recipient handling, and multi-recipient scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains two-phase confirmation, preflight vs confirmation, and counterparty explicit consent. Lacks details on final success response or error scenarios, but covers core 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and max items, then details the two-step process. All sentences are informative, though slightly verbose. Could be more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes the two-phase return (confirmation_required with preview), but doesn't specify the final successful response structure. For a batch creation tool with no output schema, more detail on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds significant usage context: clarifies when to set confirmWrite and confirmCounterpartyExplicit, explains priceBasis conditions, and provides behavioral rules beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Processes a batch of purchases' with a specific verb (processes) and resource (batch of purchases), clearly distinguishing it from siblings like brc_create_purchase which handles single purchases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed when-to-use instructions: first call without confirmWrite returns preview, then retry with confirmWrite only after explicit user confirmation. Also requires confirmCounterpartyExplicit after user names counterparty. Excludes incorrect uses (e.g., not on first call, not from inference).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description fully covers behavioral traits: placeholder blocking, VAT validation, CR analysis, counterparty confirmation, preflight flow, item constraints. Discloses defaults and conditions for note and deliveryTo fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose and contains some redundancy (e.g., productId blocking mentioned twice). However, it is well-structured front-loading purpose, and the complexity justifies length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains preflight response and draft preview. Lacks details on success response and error handling. Usage flow is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning beyond schema: explains preflight flow, confirmation semantics, and details for items (note, deliveryTo). However, items schema is minimal so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it processes a batch of sales invoices. Distinguishes from single sales invoice tool and other batch tools by specifying batch-specific behavior and safety checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance, including maximum 5 items, requiring confirmWrite and confirmCounterpartyExplicit, not reusing counterparty, and calling brc_list_products first for product lines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the required two-step workflow (first call returns preview, second call with confirmWrite submits), the need for explicit counterparty confirmation, and the fact that preflight is not confirmation. However, it does not specify the return format of a successful final call, which would be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that efficiently conveys key information. It is front-loaded with the main purpose, then elaborates on usage paths and workflow. While effective, slight restructuring (e.g., bullet points for different payment types) could improve scanability, but the current form is far from wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 17 parameters, 5 required, no output schema, and many siblings, the description covers the core workflow: two payment modes, confirmation steps, and counterparty handling. It lacks explicit mention of the final success response or error scenarios, but the provided guidance is sufficient for an agent to execute the correct call sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. It clarifies the relationship between supplierId and the alternative analysisCategoryId+accountCode combination, and imposes constraints (analysisCategoryId must be from BP01-BP06, accountCode must match category) that are not fully captured in the schema. It also explains the confirmWrite and confirmCounterpartyExplicit semantics in plain language, complementing the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Creates a BRC payment from the Payments book,' providing a specific verb and resource. It further distinguishes two payment types (supplier and analysed bank), which helps differentiate from sibling tools like brc_create_cash_payment or brc_create_purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 supplierId for supplier payments, or analysisCategoryId + accountCode for analysed bank payments.' It also explains the two-call confirmation process and the condition for confirmCounterpartyExplicit, with explicit 'do not' instructions, making usage rules unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Transparently describes the two-step confirmation process (preflight then confirm). No annotations exist, but the description covers the key behavioral aspect, though it could mention success/failure responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then detailed instructions. The second sentence is long but packs important procedural info efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the preflight flow well, but lacks details on return values beyond 'confirmation_required and payload preview'. With no output schema, some return info would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds crucial context for confirmWrite, explaining its toggling based on user confirmation. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a BRC product using a raw BRC payload, distinguishing it from sibling tools like brc_batch_products and brc_update_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions: first call without confirmWrite: true, show preview to user, then retry with confirmWrite: true only after explicit confirmation. Warns that passing preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the two-step confirmation workflow, that preflight is not confirmation, and counterparty confirmation needs. It doesn't specify return values or error handling but discloses critical behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~100 words), well-structured with a clear opening statement, conditional usage, and sequential workflow. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 params, no output schema, no annotations), the description covers the required confirmation workflow well. Missing return value or error scenario description prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 significant value for confirmWrite and confirmCounterpartyExplicit by explaining their usage beyond schema descriptions. Other parameters rely on schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a BRC purchase and distinguishes itself from the sibling brc_create_purchase_gen_ref by mentioning the reference requirement scenario. It uses specific verb 'Creates' and resource 'BRC purchase'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs brc_create_purchase_gen_ref based on company configuration. Provides detailed workflow instructions for confirmWrite and confirmCounterpartyExplicit booleans, including preflight vs confirmation and explicit user confirmation requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates the operation is a reversal/deletion (destructive) and requires user confirmation before executing. However, it does not mention error handling, idempotency, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then prerequisite, then caution. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema, the description adequately covers purpose, prerequisite, and a critical safety note. However, it lacks details on return behavior, error states, or whether the operation is reversible, which a completely thorough description might include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 that the 'id' parameter is the 'allocation resolver id' and clarifying that 'confirmWrite' must only be true after user confirmation. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('reverses/deletes') and the resource ('single allocation by allocation resolver id'), distinguishing it from sibling delete tools that target other entities (e.g., brc_delete_customer, brc_delete_accrual).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first use brc_list_allocated_transactions to find the allocation id, and warns not to set confirmWrite=true without explicit user confirmation. This provides clear when-to-use and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It explains the confirmation mechanism and preflight handling well, but does not disclose irreversibility or consequences of deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose, no fluff. Information density is high and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, no output schema, and complex workflow, description covers the key uniqueness. Lacks mention of success response or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 75% of parameters. Description adds workflow context for confirmWrite but does not explain confirmDelete or add meaning beyond schema for required params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a BRC bank account by id') and differentiates from sibling delete tools (e.g., delete_customer, delete_sales_invoice) by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly details the two-step confirmation workflow: first call without confirmWrite, show preview, get user confirmation, then retry with confirmWrite=true. Also warns that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the confirmation workflow and the need for explicit user confirmation. No annotations exist, so the description carries this burden well, though it omits potential side effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a delete tool without output schema: covers the unique two-step pattern. Lacks details on success response or errors, but acceptable given the action type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the confirmWrite parameter beyond the schema by explaining its role in the confirmation flow. The confirmDelete parameter is not elaborated, but schema coverage is 75%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes a BRC payment by id', specifying the verb and resource, and is distinct from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step confirmation process: first call without confirmWrite for a preview, then retry with confirmWrite=true only after explicit user confirmation. Also warns that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-step confirmation process, payload preview, and the need for explicit user confirmation. Lacks mention of irreversibility or what happens after deletion, but the confirmation flow adequately signals destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence states purpose, remaining two explain the crucial confirmation flow. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core workflow and constraints for safe use. Could be improved by mentioning the response after successful deletion or error scenarios, but is sufficient given the absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines parameters with decent descriptions (75% coverage). The description adds critical semantics for confirmWrite and confirmDelete by explaining the two-step workflow, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a BRC product by ID, distinguishing it from sibling delete tools for other entities like customers or invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions: first call without confirmWrite to get confirmation_required and preview, then retry with confirmWrite: true only after explicit user confirmation. Also warns that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the two-step confirmation behavior, including the return of confirmation_required and payload preview, and the need for explicit user confirmation in a later message. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main action and efficiently explain the entire confirmation workflow without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the behavioral aspects well for a delete tool with confirmation, mentioning return values for the first call. However, without an output schema, it does not describe the final success response or error conditions, but this is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters are already described. The description adds semantic value by explaining the confirmWrite usage pattern and the overall timestamp confirmation flow, though it does not elaborate on confirmDelete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deletes a BRC quote by id using timestamp confirmation.' It distinguishes itself from sibling delete tools by describing a unique two-step confirmation process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on when to use each parameter: first call without confirmWrite, then retry with confirmWrite after user confirmation. It warns against common misuse. Does not explicitly compare to alternatives like brc_close_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 behavior. It explains the preflight check, the need for user confirmation, and that the first call returns a preview. It lacks details on authorization requirements or irreversibility, but the core deletion workflow is transparently documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. The first sentence immediately states the tool's purpose, and subsequent sentences efficiently explain the required workflow. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-step deletion with confirmation) and the lack of an output schema, the description adequately explains what to expect (preview, confirmation_required, retry). It does not detail the preview content or timestamp handling, but overall provides enough context for an AI to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 3 of 4 parameters with descriptions (75% coverage). The tool description adds process context for confirmWrite, explaining its role in the two-step workflow. However, confirmDelete is not mentioned in the description and only has a default value, so some gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Deletes'), the resource ('BRC sales entry'), and the method ('by id using timestamp confirmation'). It clearly differentiates from sibling delete tools by specifying the two-step confirmation process, which is unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions: first call without confirmWrite to get a preview and confirmation_required, then retry with confirmWrite after user confirmation. It warns against passing preflight as confirmation and clarifies that confirmWrite must only be true after explicit user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavior: the first call returns confirmation_required and a preview, and deletion only occurs after explicit user confirmation. However, it doesn't mention the final response status or any irreversible consequences beyond the confirmation flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The main purpose is front-loaded. Each sentence provides necessary instruction. The structure is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 4 parameters and no output schema, the description covers the critical confirmation workflow. It omits details about the final response (e.g., success indicator) and the role of confirmDelete. Still, it provides enough context for an agent to execute the two-step process correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to confirmWrite with a detailed usage rule (when to set true/false). It provides a helpful example for companyName. However, confirmDelete is not mentioned at all, and id's description in schema is minimal. With 75% schema coverage, the description compensates for the key parameter but leaves confirmDelete unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deletes a BRC supplier by id' with a clear verb and resource. This distinguishes it from sibling delete tools like brc_delete_customer or brc_delete_accrual by also detailing the unique two-step confirmation process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions: first call without confirmWrite, show plain-English draft, then retry with confirmWrite only after user confirmation. It clearly states when not to use (never set confirmWrite on first call) and that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: 'Returns connection status only — never the key' and 'The assistant must not repeat keys from chat history.' This provides security-relevant context and clarifies the tool's limitations. No annotations exist, so the description carries the full burden effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: when to use, what it returns, and a behavioral constraint. It is front-loaded with usage guidance and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the main purpose, behavioral constraints, and parameter usage. It could mention possible status values for completeness, but given the simplicity and clear guidance, it is largely sufficient. Minor gap in return value specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter 'companyName' with complete description (100% coverage). The tool description adds no additional parameter information beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use when the user asks for an API key, secret, or what key was used.' It specifies the verb (use) and resource (API key status), and distinguishes from siblings by noting that it only returns connection status, not the key itself. This differentiates it from sibling tools like clear operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool ('when the user asks for an API key, secret, or what key was used') and what not to do ('must not repeat keys from chat history'). While it doesn't mention alternatives, the sibling context clearly shows other tools for different purposes, and the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that it returns 'simple customer-friendly setup steps and example prompts' and instructs not to list tool names or counts when redirecting. This is adequate but could mention any limitations or format of output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no wasted words. Every sentence adds value: purpose, triggers, and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description sufficiently explains what the tool returns and when to use it. It could be slightly more detailed about the output format but is complete enough for a simple onboarding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters and 100% schema coverage, so baseline is 4. Description adds no parameter info because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use this whenever the user asks how to start, says start, says getting started, or asks for help using Big Red Cloud.' It also distinguishes from sibling brc_get_deployment_policy by specifying when to use that instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use conditions are given (specific trigger phrases) and when-not-to-use (user asks about capabilities/permissions, call brc_get_deployment_policy). This provides clear guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It discloses that only parent accruals are updated (child accruals not exposed), and the confirmWrite parameter must be set only after user confirmation. However, it does not mention potential side effects (e.g., overwrite behavior, idempotency) or permission requirements. Still, it provides key behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating the action, providing retrieval prerequisite, and warning about confirmWrite. No unnecessary words. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the update workflow, prerequisites, and a critical constraint (confirmWrite). However, since there is no output schema, the description could mention what the tool returns (e.g., success status, updated accrual). Given the complexity (11 parameters) and lack of output schema, it is mostly complete but missing return value hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds value by explaining the confirmWrite parameter's usage policy ('do not call with confirmWrite=true until user confirms') and implying the timestamp parameter must come from brc_get_accrual. This adds meaning beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing parent Accrual by id, specifying 'parent' to distinguish from child accruals. It uses a specific verb ('updates') and resource ('parent Accrual by id'), and differentiates from siblings like brc_create_accrual and brc_delete_accrual by focusing on update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use brc_get_accrual first to retrieve the current accrual and timestamp, and do not call with confirmWrite=true until the user has explicitly confirmed. This clearly states when to use the tool and cautions against misuse, covering prerequisites and user confirmation flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively conveys behavioral traits such as the required two-step workflow (get first, then update with timestamp) and the confirmWrite parameter acting as a confirmation safeguard. However, it could be more explicit about the permanence of the update or lack of rollback, but the current disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each serving a distinct purpose: stating the action, providing the prerequisite, and giving a critical warning. It is front-loaded with the primary purpose and contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow (get before update) and the confirmation step, which is critical for safe usage. While it does not describe the output or return value, the absence of an output schema reduces that expectation. For a tool with 11 parameters and no output schema, the description is sufficiently complete to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 11 parameters, so the description does not need to repeat parameter details. It adds value by explaining the purpose of the 'timestamp' parameter (from brc_get_prepayment) and the 'confirmWrite' parameter (user confirmation required), which enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates', the resource 'existing parent Prepayment', and the method 'by id'. It distinguishes itself from sibling tools like brc_create_prepayment and brc_get_prepayment by specifying it's an update operation and clarifying that child prepayments are not exposed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to first call brc_get_prepayment to retrieve the current prepayment and timestamp before using this tool. It also warns against setting confirmWrite=true until the user has reviewed and explicitly confirmed the update, providing clear guidance on when and how to use the tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses the two-step confirmation behavior and the preflight mechanism. It explains the merged field update approach. However, it does not detail error handling, side effects, or required permissions, which slightly limits transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that communicate the purpose, workflow, and key caution. It is front-loaded with the main operation and uses clear, direct language without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description adequately explains the preflight response and the need for user confirmation. It covers the essential agent workflow but could be more complete by noting expected response format or error scenarios. Still, it meets the agent's core needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are described in the schema (100% coverage), but the description adds significant value by explaining the confirmWrite parameter's workflow, including the preflight draft and user confirmation requirement. This goes beyond the schema's description of confirmWrite as a boolean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a BRC supplier using merged fields,' specifying the verb ('Updates'), resource ('BRC supplier'), and method ('merged fields'). It effectively distinguishes this tool from siblings like brc_create_supplier or brc_delete_supplier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step guidance: first call without confirmWrite true to get a preview, show the plain-English draft, then retry with confirmWrite true only after explicit user confirmation. It also clarifies that a preflight response is not confirmation, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully explains required confirmation flags and constraints (e.g., not reusing counterparty from drafts). Could mention side effects of processing, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet complete. Single paragraph with logical flow: purpose, constraint, workflow, then special requirements. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 required, no output schema, and complex workflow, the description covers all critical aspects for correct usage (batch limit, confirmation steps, counterparty handling).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Adds context: explains the preflight/confirmation workflow for confirmWrite and confirmCounterpartyExplicit, and priceBasis when Gross Price Entry enabled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (processes), specific resource (batch of BRC cash payments), and scope (max 5 items). Distinguishes from sibling tools like brc_create_cash_payment and 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step confirmation workflow (first call without confirmWrite for preview, then user confirmation). Provides exact conditions for setting confirmWrite and confirmCounterpartyExplicit, including what does not count as confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It fully discloses the destructive nature and the required confirmation flow. Lacks a detail like what 'payload preview' contains, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, no redundancy, every sentence carries essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action tool with no output schema, the description covers the entire expected behavior: what first call returns, what user must do, and consequences. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds workflow context for confirmWrite (first call false, retry with true after user confirmation), which adds value beyond schema descriptions. Does not mention confirmClear explicitly, but schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Clear the Red audit log for this MCP server session' – a specific verb ('clear') and resource ('Red audit log'), distinguishing it from sibling tools like brc_list_audit_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Exactly describes the two-step process: first call without confirmWrite:true returns a confirmation request, then retry with confirmWrite:true after user confirmation. Also warns that 'passing preflight is not confirmation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits: the two-step confirmation process, the role of confirmWrite and confirmCounterpartyExplicit, and the need for a plain-English draft. Without annotations, the description carries the full burden and does so effectively, though it omits details about the final success response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded: begins with the core purpose, then details use cases and workflow. Every sentence serves a purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters, three use cases, and a complex confirmation workflow, the description is remarkably complete. It covers all essential aspects: parameter selection, confirmation steps, and counterparty confirmation. The workflow is fully explained, making it usable without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the schema by grouping parameters into use cases and explaining constraints (e.g., analysisCategoryId must be from CP01-CP03, accountCode must match). With 83% schema coverage, the baseline is 3, but the description provides high-value context that clarifies the intended parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states it creates a BRC cash payment and enumerates three distinct use cases (supplier payments, bank lodgements, analysed expenses) with specific parameter groups. This clearly differentiates it from sibling create tools like brc_create_cash_receipt or 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions on when to use each parameter set (supplierId+ledger, bankAccountId+lodgement, analysisCategoryId+accountCode). Provides step-by-step workflow: first call without confirmWrite: true returns a draft, then retry with confirmWrite: true after user confirmation. Clarifies that preflight does not count as confirmation and that confirmCounterpartyExplicit requires explicit user naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description fully bears the burden of behavioral disclosure. It reveals many traits: draft previews include Missing sections for blank phone/email, warnings only; first call without confirmWrite returns confirmation_required with a payload preview; requires explicit user confirmation for write, counterparty, and CR analysis category; and warns against inventing values. This is comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (multiple sentences) but every sentence adds value. It is front-loaded with the core action and then lists important constraints. It could be slightly restructured for readability, but it avoids fluff. The density is justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 28 parameters (18 required) and no output schema, the description is very complete. It covers the multi-step creation flow, required preconditions, and explicit confirmation flags. It lacks details on return values (no output schema) but that is acceptable. Overall, it provides enough context 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (36%), and the description adds significant meaning beyond the schema. It explains the purpose of confirmWrite, confirmCounterpartyExplicit, and confirmCrAnalysisCategory with usage rules. It also clarifies that reference is required when manual/unknown, and warns against defaulting analysisCategoryId. While not every parameter is explained, the critical ones are well-covered, compensating for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a BRC quote using structured MCP fields. It distinguishes from sibling tools like brc_create_quote_gen_ref by specifying when to use that alternative (auto-generated references). The verb 'Creates' is specific and the resource 'BRC quote' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use the tool and when not to. It requires a quote reference when manual/unknown, specifies required fields (saleRepId, saleRepCode, analysisCategoryId, accountCode), warns against default/demo values, and outlines the two-step confirmation process with confirmWrite and confirmCounterpartyExplicit. It explicitly states not to use when settings are unknown without user-provided reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It extensively covers the tool's behavior: auto-generation vs manual reference handling, draft preview warnings, prohibition of default sales rep values, the two-step confirmation protocol (first call returns confirmation_required with a payload preview), and the need for explicit user confirmation on counterparty and CR analysis category. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information but well-structured: it starts with the main purpose, then provides usage conditions, and then details step-by-step workflow. Every sentence adds value. However, it could be slightly more concise in some parts (e.g., 'When missing, list sales reps or ask the user to choose one before creating' could be trimmed). Overall, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (28 parameters, 18 required, no output schema), the description is fairly complete. It explains the confirmation workflow, parameter constraints, and draft preview behavior. However, it does not describe the structure of the confirmation_required response or mention possible error scenarios (e.g., validation failures). The absence of an output schema makes it less complete, but the description compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, so the description must compensate. It adds significant meaning beyond the schema for key parameters: explains saleRepId/saleRepCode must come from brc_list_sales_reps, analysisCategoryId/accountCode must be from a Sales Analysis category and not defaulted to CR01, and details the confirmation flags (confirmWrite, confirmCrAnalysisCategory, confirmCounterpartyExplicit, confirmQuotesAutoGenerateInBrc). However, some parameters like ddNumber, poNumber, layoutType are not explained, leaving gaps for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a BRC quote with a generated reference using structured MCP fields.' It uses a specific verb (create) and resource (BRC quote with generated reference), distinguishing it from sibling tools like brc_create_quote which likely handles manual references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 the tool ('Use only when quote references are auto-generated... or when the user has confirmed auto-generate'), when not to use it ('Do not use default or demo sales rep values'), and alternatives ('If missing, list sales reps or ask the user to choose one before creating'). It also details the two-call confirmation workflow and warns against inventing values for missing fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It discloses the multi-step confirmation workflow, preflight preview, required explicit user confirmation, and conditions for each confirm flag. It also warns against default or demo values. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise given the complexity. Each sentence adds value, and the critical workflow steps are front-loaded. It could be slightly trimmed (e.g., repeated mentions of 'Do not use default'), but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow: prerequisites, confirmation steps, and preflight. However, it does not explain the return format (no output schema present) or potential error scenarios. For a tool with 23 parameters and no output schema, some details are missing, but the essential usage context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (26%), so the description must add meaning. It adds significant context for key parameters: reference, saleRepId/saleRepCode, analysisCategoryId/accountCode, and the confirmation booleans. However, many parameters (e.g., note, netAmount, quantity) are not elaborated beyond the schema. The explanation for critical parameters is strong but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 credit note using structured MCP fields. It distinguishes from the sibling tool brc_create_sales_credit_note_gen_ref, which handles auto-generated references. The verb 'Creates' and specific resource 'BRC sales credit note' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: when a manual reference is required, prefer the sibling tool; requires real sales rep values; requires analysis category and account code from a valid category; confirms for write, analysis category, and counterparty; and explains preflight behavior. The description tells when NOT to use defaults or reuse data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the two-step flow (first call returns preview, second with confirmWrite), blocking of productId 0/1 and purchase VAT rates, defaulting note to customer name, and the need for explicit confirmation. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but structured, starting with main purpose then detailing various constraints and workflow. Some redundancy exists (e.g., repeating 'do not invent') but given complexity of 26 parameters, it's acceptable. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, 26 parameters, 18 required. The description covers workflow, preconditions, required lookups, error blocking, confirmation flags. It mentions the preview includes a 'Missing or not provided' section but does not describe the final response on success. Minor gap, but overall comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 54% (14/26 parameters have descriptions). The description adds significant context beyond schema: explains the workflow flags (confirmWrite, confirmCrAnalysisCategory, confirmCounterpartyExplicit), relationships (reference defaults to ourReference and yourReference), and constraints (do not use default reps). However, some description text duplicates schema descriptions (e.g., note, deliveryTo). Overall, adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 invoice and distinguishes from the sibling tool brc_create_sales_invoice_gen_ref by noting when each is appropriate (manual references vs automated). The verb 'creates' and resource 'BRC sales invoice' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance: when to use this tool vs gen_ref, the required two-step process with confirmWrite, requirements for saleRepId/saleRepCode, analysisCategoryId/accountCode, and explicit user confirmation for counterparty and CR analysis category. It also warns against using default/demo values and tells when to list sales reps or ask user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the two-step confirmation process and the need for explicit user confirmation. However, it does not mention the return format or potential error outcomes, though this is acceptable for a delete tool with clear workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with action and immediately follows with essential steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers the tool's behavior given its complexity. No output schema is needed as the description explains the return value pattern ('confirmation_required and a payload preview').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the confirmWrite parameter by explaining its role in the two-step confirmation process. It also warns against setting it true incorrectly. The confirmDelete parameter is not explained, but has a default value and is less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes'), the resource ('BRC sales invoice'), and the method ('by id using timestamp confirmation'). It distinguishes this tool from siblings like brc_delete_sales_credit_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step guidance on how to use the tool: first call without confirmWrite, then retry with confirmWrite after user confirmation. Also warns that 'Passing preflight is not confirmation' and specifies when confirmWrite must be set to true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the confirmation pattern, preview behavior, and the rule that confirmWrite must only be set after explicit user confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph that includes all essential information. Could be slightly more structured, but every sentence adds value and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains the workflow and parameter rules. It does not detail the return format beyond 'confirmation_required and a payload preview', which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds significant value: explains when note defaults to customer name, when reference cascades to other fields, and confirms the confirmWrite usage rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it 'Updates a BRC sales entry' with a verb and resource. The mention of 'structured safe text/reference fields' adds specificity. Among many sibling update tools, the resource name distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes a two-step workflow: first call without confirmWrite:true returns preview, then retry with confirmWrite:true only after explicit user confirmation. Also warns that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the two-step write confirmation pattern, the need for explicit user confirmation, and the meaning of confirmWrite parameter. It is transparent about the non-trivial interaction protocol.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading of the action, followed by the step-by-step process. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core interaction pattern. It lacks details about response structure (no output schema) and prerequisites like quote state, but these are less critical given the detailed usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 significant meaning to the confirmWrite parameter by explaining the two-step pattern and when it should be true. For id and companyName, schema descriptions suffice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reopens a BRC quote' with a specific verb and resource, distinguishing it from sibling tools like brc_close_quote (reverse action) or brc_update_quote (modification without lifecycle change).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions: first call without confirmWrite, show plain-English draft, then retry with confirmWrite only after user confirmation. Also clarifies that passing preflight does not count as confirmation, giving 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behaviors: requires user confirmation before sending, only works with specific document types, handles multiple recipients with BCC/separate modes, and stops if no recipient address. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds value, with clear front-loading of the primary purpose. Minor redundancy exists (e.g., repeated references to supported types), but overall it is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, no output schema), the description covers all necessary aspects: supported documents, confirmation workflow, recipient handling, error conditions, and explicit prohibitions. It is fully complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, but the tool description adds critical usage context (e.g., confirmSend must be true only after user review, sendMode='separate' only on explicit request) that goes beyond the schema, making it highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a sales invoice email and explicitly distinguishes supported document types (sales invoices, quotes, customer statements) from unsupported ones, making 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides comprehensive guidance: when to use (for supported document types), when not (for unsupported types), explicit steps for user confirmation, handling of multiple recipients, and fallback actions when no email is on file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description fully discloses the flow: returns one-time URL with no expiry, user enters data on secure page, returns with confirmation code. No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with three sentences, front-loaded purpose. Slightly wordy but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description covers all necessary context for the agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 applies; no additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts the secure Red company connection flow for connecting companies, distinguishing it from sibling brc_confirm_company_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use whenever the user wants to connect one or more companies', warns not to type credentials in chat, and instructs to start a new connection for more companies later.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the non-destructive preview phase, requirement for explicit confirmation, and the meaning of confirmWrite. No annotations provided, so description carries full burden and meets it comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value. Front-loaded purpose, follows with concise workflow. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Workflow is thoroughly explained but no mention of return format after successful update. Lacks output schema details, though not strictly required. Adequate for an update tool with clear confirmation pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (descriptions for id, companyName, confirmWrite). Description adds critical semantics for confirmWrite (preview vs. commit). However, parameters 'code' and 'name' lack additional context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a BRC sales rep with a specific workflow. Distinguishes from sibling create/delete tools by detailing the two-phase confirmation process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step instructions: first call without confirmWrite, show preview, then retry with confirmWrite only after user confirmation. Also warns preflight does not constitute confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the behavioral traits: the confirmation flow, mandatory preview, explicit counterparty confirmation, and max items limit. It clarifies that passing preflight is not confirmation and that counterparty must be confirmed in the current conversation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but front-loaded with the most critical instructions. Every sentence adds value, though it could be slightly more concise. The structure is logical, starting with the overall purpose and then the step-by-step confirmation requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step confirmation, explicit counterparty requirement, no output schema), the description is complete. It explains what the first call returns (confirmation_required and payload preview), instructs to show a plain-English draft, and outlines all confirmation conditions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), but the description adds crucial semantics: explains usage of confirmWrite and confirmCounterpartyExplicit, defines priceBasis usage based on Gross Price Entry setting, and clarifies companyName context. This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Processes a batch of quotes' with a specific verb and resource. It distinguishes from sibling tools like brc_create_quote (single quote) and other batch tools by focusing on quotes and specifying a maximum of 5 items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step workflow: first call without confirmWrite to get a preview, then with confirmWrite after user confirmation. It also requires confirmCounterpartyExplicit once the user explicitly names the counterparty. Provides clear when-not-to-use conditions (e.g., never set confirmWrite on first call).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the confirmation mechanism, the preview step, and the requirement for explicit user confirmation. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then concise workflow details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with a confirmation workflow and no output schema, the description is complete. It explains the two-step process, the need for user confirmation, and the role of confirmWrite, enabling correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%; the description adds critical context for confirmWrite (when to set true) but does not elaborate on confirmDelete or the companyName/id parameters beyond what schema provides. However, the workflow description compensates for most semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (deletes), resource (BRC sales rep), and method (by id using timestamp confirmation), clearly distinguishing it from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed two-step workflow: first call without confirmWrite: true returns confirmation_required and a preview; then only retry with confirmWrite: true after explicit user confirmation. It also warns that preflight is not confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, description fully discloses the two-phase behavior: first call returns confirmation_required and payload preview, second call with confirmWrite: true performs the write. Also explains the confirmWrite parameter semantics and clarifies the confirmation process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, following sentences detail the two-step process. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a two-phase tool, but lacks description of the final output after confirmWrite (e.g., returns the created invoice). Still, the description covers the essential preview and confirmation mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining confirmWrite usage in detail (when to set true/false) and provides context for companyName with an example. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generates a sales invoice from a BRC quote' with a specific verb and resource. It distinguishes the two-step process from other creation tools like brc_create_sales_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides step-by-step usage: first call without confirmWrite returns preview, then retry with confirmWrite only after user confirmation. Warns that preflight is not confirmation and that confirmWrite must not be true on first call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Red MCP server](https://glama.ai/mcp/servers/loldwyer/Red/badges/card.svg)](https://glama.ai/mcp/servers/loldwyer/Red)

Score Badge

Copy to your README.md:

[![Red MCP server](https://glama.ai/mcp/servers/loldwyer/Red/badges/score.svg)](https://glama.ai/mcp/servers/loldwyer/Red)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/loldwyer/Red'

If you have feedback or need assistance with the MCP directory API, please join our Discord server