Red MCP Server

Official

by BigRedCloud

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.4.0
Disambiguation5/5
Every tool targets a distinct entity and action (e.g., create, update, delete, get, list for each business object). Variants like _gen_ref are clearly differentiated by auto-generated vs. manual references. There is no ambiguity.
Naming Consistency5/5
All tools follow a strict 'brc_verb_noun' snake_case pattern. Verbs are consistent across entities (create, get, list, update, delete, batch, etc.), and no mixing of styles is observed.
Tool Count1/5
With 154 tools, the server is extremely bloated. Even for a comprehensive accounting system, this number overwhelms an agent and violates typical well-scoped ranges (3-15 tools). The surface could be drastically consolidated.
Completeness5/5
The tool set covers the full lifecycle of major entities (customers, suppliers, products, invoices, purchases, quotes, etc.), plus supporting operations like emailing, allocations, audit logs, and settings. No obvious gaps are present.
Average 3.8/5 across 154 of 154 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 244 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
This repository is licensed under Apache 2.0.
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 provided, and the description does not disclose any behavioral traits such as read-only nature, data limits, or side effects. The agent is left entirely uninformed about how the tool behaves.
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, but it is under-specified rather than concise. It fails to provide necessary information in a structured way.
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 many sibling tools like brc_list_cash_payments and brc_list_prepayments, the description is completely insufficient to guide an agent in correct usage. Critical details about parameters, pagination, and filtering are omitted.
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?
With only 43% schema description coverage, the description adds no additional meaning to the parameters. It does not explain the purpose of any parameter, such as top, page, skip, or filter, beyond what little the schema provides.
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 payments' provides a verb and resource but is extremely minimal. It doesn't clarify what 'BRC payments' are or distinguish from sibling tools like brc_list_cash_payments or brc_list_prepayments. Barely above a tautology.
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 given on when to use this tool versus alternatives. There is no mention of context, exclusions, or prerequisites.
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?
Without annotations, the description must disclose behavioral traits. It does not mention whether the operation is read-only, if pagination is involved, or any side effects. The description is silent on 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness is not a virtue when it omits essential information. It does not earn its place as it provides no value beyond the tool name.
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 of 7 parameters and no output schema or annotations, the description is severely incomplete. It fails to explain how the parameters control the listing, what the response contains, or any constraints.
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 parameter information. It does not explain how to use the parameters (e.g., pagination controls, filtering) beyond what the schema already provides. For low coverage, the description should compensate, which it does not.
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 quotes' merely restates the tool name without specifying the type of quotes or distinguishing it from similar siblings like brc_list_customer_quotes or brc_get_quote. It provides no verb beyond 'lists' but fails to clarify scope or context.
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 over alternatives, such as when listing all quotes vs. customer-specific quotes, and omits any prerequisites or context.
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 provided. Description only says 'Lists BRC sales reps' without disclosing pagination, filtering, required parameters (e.g., companyName), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but at the cost of missing critical details. The description is too minimal to be useful.
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 vastly incomplete. It lacks information about pagination, filtering, and output structure.
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?
Description does not mention any of the 7 parameters. Schema coverage is 43%, but the description adds no context beyond the schema.
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?
Description states verb 'Lists' and resource 'BRC sales reps', which is clear. However, it does not differentiate from sibling tools like brc_list_sales or brc_get_sales_rep.
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. For example, it doesn't specify that this tool lists multiple reps whereas brc_get_sales_rep retrieves a single rep.
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 read-only nature, required permissions, or side effects. The agent cannot infer safety or constraints 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of being minimally informative. It fails to front-load critical details like pagination or required context, wasting the opportunity to aid the agent.
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?
Despite having no output schema and moderate schema coverage, the description provides no explanation of return values, pagination behavior, or the concept of product types. The tool's complexity (7 params) demands a richer 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?
The description adds no meaning beyond the input schema for any of the 7 parameters. With schema description coverage at 43%, the missing parameter details (top, page, skip, pageSize) are not clarified.
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 product types' is a tautology of the tool name and does not clarify what distinguishes product types from similar resources like products (see sibling brc_list_products). It lacks specificity about the nature of 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 over alternatives such as brc_list_products or brc_list_products_without_dormant. There is no mention of context, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('Lists'), but does not explicitly state read-only behavior or any other behavioral traits. With no annotations, the description carries full burden and fails to disclose relevant aspects like idempotency or data source.
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?
Extremely short (one sentence), but this is under-specification rather than conciseness. The tool has 7 parameters and no output schema; the description should be more detailed to be helpful.
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?
Incomplete for a tool with 7 parameters and no output schema. The description does not explain what 'book transaction types' are, how to use pagination parameters, or what the response contains.
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 beyond the input schema. Schema coverage is 43%, meaning many parameters lack descriptions, and the tool description does not compensate by explaining any parameter meanings or usage.
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 uses a specific verb 'Lists' and resource 'BRC book transaction types', but 'book transaction types' is vague without further context. It distinguishes from sibling list tools by topic, but does not clarify what a book transaction type is.
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. Sibling tools include many similar list functions, but the description provides 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?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination, filtering support (though params imply it), permissions, or side effects. The agent has no insight into expected behavior beyond the minimal description.
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 terse (one short sentence). It fails to front-load key information that would help the agent decide to use this tool. Important details like default sorting or pagination are omitted, making it under-specified rather than concise.
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 woefully incomplete. It does not mention return format, pagination behavior, or filtering capabilities. The agent cannot confidently invoke this tool based solely on the 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?
With only 43% schema description coverage, the description adds no value to parameter understanding. While some parameters have schema descriptions (filter, orderBy, companyName), the description does not explain any parameters, so the agent must rely solely on the schema.
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 customers.' clearly states what the tool does (lists customers), but it does not distinguish it from the sibling tool 'brc_list_customers_without_dormant'. The agent must infer that this tool lists all customers, including dormant ones, which is not explicit.
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_customers_without_dormant' or other list tools. There is no mention of prerequisites or contexts in which this tool is appropriate.
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 and a one-line description, behavioral traits like pagination, rate limits, or whether the operation is read-only are entirely omitted. The description adds no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified rather than concise. It lacks essential details expected for a list operation with seven parameters.
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 seven parameters, no output schema, and no annotations, the description fails to explain pagination, filtering, required fields, or return behavior. It is far from complete.
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%, leaving many parameters (top, page, skip, pageSize) undocumented in both schema and description. The description adds zero information about parameters, failing to compensate for the schema gaps.
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 bank accounts' clearly states the verb and resource. It differentiates from sibling tools like brc_get_bank_account (single) and brc_list_accounts (different entity), though it is minimal.
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 siblings such as brc_list_accounts or brc_get_bank_account. No context on prerequisites or conditions for use.
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 must disclose behavioral traits but fails to do so. It only states 'Lists BRC user defined fields' without indicating whether the operation is read-only, safe, or has any side effects, pagination behavior, or rate limits.
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 very short but lacks essential information. While it does not waste words, it fails to earn its place by omitting critical details, resulting in under-specification.
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 severely incomplete. It does not address pagination, filtering, required parameters, or the return format, 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.
Parameters1/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 information about parameters beyond what is in the schema. Parameters like top, page, skip, and pageSize are left unexplained in both the schema and description, requiring the agent to infer their meaning.
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 user defined fields', making the purpose understandable. However, it does not differentiate from sibling tools like brc_list_accounts or brc_list_customers, which have similar naming patterns.
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, conditions, or typical use cases, leaving the agent without 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. The description only states the action without disclosing any behavioral traits such as whether it is read-only, pagination behavior, authentication requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (4 words), it is too sparse for a tool with 7 parameters. Conciseness is undermined by lack of essential information; it should include more context to be useful.
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?
The tool has 7 parameters, no annotations, no output schema, and many sibling tools. The description does not explain return values, pagination, or filtering capabilities. It is grossly 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 coverage is 43% (only 3 of 7 parameters have descriptions in the schema). The description adds no additional meaning to parameters. It fails to compensate for the low schema coverage, leaving agents uninformed about how to use parameters like top, page, or filter.
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?
Description states 'Lists BRC accounts.' which provides a verb and resource, but it is vague and does not distinguish from sibling list tools like brc_list_customers or brc_list_bank_accounts. It is unclear what 'BRC accounts' refers to.
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. Sibling tools include many other list operations, but the description offers no context about what type of accounts are listed or when to choose this over others.
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 the full burden of disclosing behavioral traits. It only states 'Lists BRC suppliers' without indicating whether the operation is read-only, requires authentication, supports pagination, or has any side effects. The schema hints at pagination and filtering, but the description omits these important behaviors.
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 with a single sentence, but it is under-specified for a tool with 7 parameters and many siblings. While brevity is valued, the lack of structure and missing important details makes it inadequate.
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 of the tool (7 parameters, no output schema), the description is severely incomplete. It does not explain the returned data, pagination behavior, or filtering support. The presence of many sibling list tools further necessitates a more complete description to guide selection.
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), which is low. The description does not add any extra meaning beyond the schema; it fails to explain the purpose or usage of parameters like top, page, skip, and pageSize. The description must compensate for low coverage, but it does not.
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 'Lists BRC suppliers,' which identifies the specific resource (suppliers) and action (list). However, it does not distinguish this tool from sibling list tools such as brc_list_supplier_account_trans, which also involve suppliers but for account transactions.
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 mention when to use this tool versus alternatives, such as whether to use it for obtaining a full list of all suppliers or for filtering. There are no instructions on 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?
No annotations are provided, so the description carries the full burden. It does not disclose read-only nature, pagination behavior, side effects, or rate limits. The minimal 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?
Extremely concise (2 words), but under-specified. Every sentence should earn its place; this one barely repeats the tool name. Conciseness sacrifices necessary detail.
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 annotations, and no output schema, the description is completely inadequate. It does not explain return format, pagination, filtering, or any behavioral 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 low (43%), and the description does not mention any parameters. It adds no meaning beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists BRC owner types' with a verb and resource, but does not differentiate from sibling tools like brc_list_owner_type_groups. The purpose is clear 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 guidance is provided on when to use this tool versus alternatives (e.g., brc_list_owner_type_groups). There are no exclusions or 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?
With no annotations, the description carries full burden. It states 'Lists' implying a read-only operation, but provides no details on pagination behavior, return format, or other traits 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?
The description is very concise at one sentence, but it is under-specified for the tool's complexity (7 parameters, no output schema). Brevity does not substitute for missing 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 7 parameters, no output schema, and no annotations, the description is inadequate. It does not explain return values, pagination, or what VAT analysis types are, leaving the agent under-informed.
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% with only filter, orderBy, and companyName described. The description adds no parameter information, failing to compensate for the low coverage of 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 'Lists BRC VAT analysis types' uses a specific verb and resource, clearly indicating the tool's purpose. It distinguishes from sibling tools like brc_list_vat_types and brc_list_vat_categories by specifying 'analysis types'.
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 over alternatives such as brc_list_vat_types or brc_list_vat_categories. The description lacks any context for appropriate usage.
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 says 'lists,' implying read-only, but fails to disclose pagination (supported via top, skip, page, pageSize parameters), filtering, or ordering capabilities. The required companyName parameter is not highlighted.
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 (3 words) but at the cost of completeness. It omits critical information and is under-specified, making it less helpful than a slightly longer description would be.
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 multiple sibling VAT-related list tools, the description fails to explain what the returned VAT types contain or how pagination works. It does not provide enough context 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.
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 and filter/orderBy having descriptions. The tool description adds no parameter explanations. Common pagination parameters (top, skip, page, pageSize) lack any semantic addition, leaving agents to infer from schema alone, which is insufficient.
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 it lists 'BRC VAT types,' which is a specific resource, but does not differentiate from sibling tools like brc_list_vat_analysis_types, brc_list_vat_categories, or brc_list_vat_rates. The purpose is somewhat clear but lacks precision to distinguish from related 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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context that would help an agent choose this tool over other list VAT-related 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 exist, so the description must disclose behavioral traits. It only says 'lists,' implying a read operation, but doesn't mention pagination, filtering, or sorting behavior, even though the schema includes these parameters. Lacks disclosure of any side effects or 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?
Extremely short (4 words) but under-specified. Conciseness is not achieved when essential information is missing. The sentence is efficient but lacks substantive content to guide the agent.
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 (1 required), no output schema, and low schema coverage, the description is completely inadequate. It does not explain the purpose of the returned data, pagination behavior, or how to use filters. The agent has very little actionable 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 low (43%), and the description adds no parameter details. The parameters top, page, skip, and pageSize lack descriptions in the schema, and the tool description does not explain their meaning or usage. The companyName parameter is the only required one, but its context is minimal.
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 it lists BRC owner type groups, which is a specific resource. However, it does not differentiate from sibling tools like brc_list_owner_types or brc_list_customers, which also list entities. The verb 'lists' is clear, but lacks distinction.
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 example, it doesn't explain how owner type groups differ from owner types or other list tools. The description provides 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.
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 idempotency, side effects, authentication needs, or rate limits. It only states the basic function without 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 a single sentence, which is concise but lacks helpful structure. It could be longer to include necessary details without becoming verbose. It is not overly long, but it sacrifices informativeness for brevity.
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 no annotations, the description is incomplete. It does not explain return values, pagination behavior, or how to use filters/ordering. The agent lacks critical context for effective usage.
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% (3 of 7 parameters have descriptions). The tool description adds no parameter information, leaving the agent to rely solely on the schema. For a tool with 7 parameters and low coverage, this is insufficient.
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 it 'Lists BRC purchases,' which is a clear verb+resource combination. However, it does not differentiate from sibling list tools like brc_list_payments or brc_list_products, and 'BRC purchases' lacks context. It's minimally adequate but not distinctive.
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 are many list tools among siblings, and the description provides no context about filtering, pagination, or scenarios. The agent must 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, and the description does not disclose behavioral traits such as pagination, filtering, sorting, or required parameters. The agent is left unaware of important constraints.
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 action. However, it is too brief and could benefit from additional structure or detail.
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 critically incomplete. It fails to mention pagination parameters (top, page, skip, pageSize), filtering, sorting, the required companyName, or what the results contain. An AI agent would lack essential context to use the tool correctly.
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% (<50%), meaning the description must compensate for missing parameter explanations. It does not; no parameter is mentioned or described in the text. The schema provides minimal descriptions for companyName, filter, and orderBy, but the description adds nothing.
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 'Lists' and resource 'BRC sales entries'. However, it does not distinguish from siblings like brc_list_sales or brc_list_sales_invoices, which could confuse an AI agent selecting 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 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 (e.g., brc_get_sales_entry for a single entry, or brc_list_sales_invoices for invoices). No exclusion 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 carries full burden for behavioral disclosure. It only says 'lists' without explaining pagination behavior, default page size, ordering, or that the companyName parameter serves as a context filter. Important traits like rate limits, data freshness, or return structure are omitted.
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, making it concise in length. However, it lacks any structured breakdown (e.g., bullet points or logical separation). While brevity is valued, the extreme minimalism here undercuts useful detail, earning an average score.
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 lacking. It does not explain what cash receipts are, how pagination works, what the default order is, or what the response contains. This makes it nearly unusable for an agent without additional inference.
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% (descriptions for filter, orderBy, companyName). The tool description adds no additional meaning to any parameter. It does not explain the roles of top, page, skip, or pageSize in the context of listing cash receipts, which would be helpful given the lack of schema descriptions for those fields.
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 explicitly states the verb 'lists' and resource 'BRC cash receipts', clearly identifying the tool's basic purpose. It distinguishes from siblings like brc_list_cash_payments or brc_list_customers by naming the specific entity. However, it does not add any qualifiers about scope or unique features (e.g., 'all' or 'for a company'), missing a chance to be more specific.
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_get_cash_receipt (single receipt) or other list tools. There are no when-to-use, when-not-to-use, or alternative recommendations. The agent is left to infer context 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?
With no annotations provided, the description carries full burden. It only says 'Lists', implying a read operation, but does not disclose details like pagination behavior, default page size, or any side effects. For a list tool with pagination parameters, more transparency is needed.
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). While not verbose, it borders on under-specification. It is front-loaded but sacrifices 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 the tool has 7 parameters, no output schema, and no annotations, the description is severely incomplete. The agent lacks information about return format, pagination details, filtering capabilities, and how to use the parameters 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% (only filter, orderBy, companyName have descriptions). The tool description adds no parameter-specific meaning. Parameters like top, page, skip, pageSize lack schema descriptions and are not explained in the description, so the agent must guess their semantics.
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 category types' clearly identifies the action and resource. It distinguishes from sibling list tools which are for different entities (e.g., accounts, customers). However, it lacks context on what 'BRC category types' are exactly.
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 does not mention preconditions, typical use cases, or exclusions. The agent must infer from 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 should disclose behavioral traits such as read-only nature, pagination behavior, or data scope. It only says 'Lists,' which is insufficient for transparency.
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 (5 words), but this brevity sacrifices clarity. It is not overly verbose, but it lacks structure and key 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 lack of output schema, annotations, and low schema coverage, the description is severely incomplete. It fails to inform about result format, pagination, filtering, or other essential contextual details.
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 explanation for the 7 parameters. It does not compensate for missing parameter descriptions 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 credit notes,' effectively distinguishing it from sibling tools. However, it does not provide additional specificity beyond the resource name.
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_sales_entries or brc_list_sales_invoices). There is no mention of prerequisites, context, 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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, pagination behavior, or response format. The presence of pagination parameters implies listing behavior, but this is not explicitly stated.
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, making it concise but lacking detail. It front-loads the core purpose but sacrifices completeness. Given the tool's complexity (7 parameters, no output schema), the brevity is insufficient.
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, high parameter count, and no annotations, the description should provide more context about the tool's behavior, result format, and parameter usage. The single sentence fails to meet these needs, leaving the agent with many unknowns.
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 has 43% parameter description coverage (filter, orderBy, companyName have descriptions), but the tool description adds no additional meaning to any parameter. Key pagination parameters (top, skip, page, pageSize) are left undocumented by both schema and 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 action ('Lists') and the resource ('BRC cash payments'). It is specific and unambiguous, though it could differentiate further from sibling list tools by noting that it is specifically for cash payments (as opposed to cash receipts or 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?
The description provides no guidance on when to use this tool versus alternatives like brc_get_cash_payment, brc_batch_cash_payments, or other list tools. No when-to-use or when-not-to-use information is given.
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, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or potential side effects. The agent is left to infer that listing is safe, but this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) with no wasted words, but it is overly minimal and lacks necessary detail. It is structured appropriately but sacrifices completeness for brevity.
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 no annotations, the description is under-specified. It does not explain what company settings are included, the response format, or how parameters affect the result, leaving significant gaps for an 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?
With only 43% schema description coverage, many parameters (e.g., top, skip, pageSize) lack explanations. The tool description adds no additional parameter information, failing to compensate for gaps 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 action ('Lists') and the resource ('BRC company settings'), providing a direct purpose. However, it does not differentiate itself from sibling 'get_' tools for specific settings like brc_get_company_options, which could cause confusion.
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_company_options or other list tools). The description lacks context for appropriate usage.
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. It only says 'lists', which gives no insight into behavior such as pagination (top, page, skip, pageSize parameters), filtering (filter parameter), or ordering (orderBy). The description adds no value beyond the tool name for 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 extremely concise with a single sentence, which is front-loaded and wastes no words. However, for a tool with 7 parameters and critical context like required companyName, it is under-specifying. It trades brevity for 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?
The description lacks context such as what a nominal account is, the return format, pagination behavior, or how to use the filtering/ordering capabilities. With no output schema and complex query parameters, the description is too sparse to be complete for an 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?
Schema coverage is only 43%, meaning 3 of 7 parameters (companyName, filter, orderBy) have descriptions in the schema. The description does not explain any parameter, such as the required 'companyName' or pagination controls. It fails to compensate for the missing 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 action ('Lists') and the resource ('BRC nominal accounts'). However, it does not distinguish itself from the sibling 'brc_list_accounts', which might also list accounts but of a different type. The tool name already hints at nominal accounts, so the description is helpful but lacks explicit differentiation.
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 other list tools like 'brc_list_accounts' or 'brc_list_customers'. There is no mention of prerequisites, context, or exclusions. The description is purely functional without any usage recommendations.
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 disclosure. It only states the basic action, omitting important traits like pagination, data freshness, or any destructive implications.
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 is under-specified to the point of being minimally helpful.
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 is a list operation with pagination and filtering, yet the description does not explain what is returned or any pagination details. It is incomplete for an agent to use 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 coverage is 43%, and the description adds no parameter explanations beyond what the schema already provides. Parameters like 'filter' and 'orderBy' are left entirely to 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 action (list) and the resource (BRC products), distinguishing it from other list tools by resource. However, it lacks specificity about scope or filters.
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_products_without_dormant or brc_get_product. The description provides no context about 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, and the description merely says 'lists', implying a read-only operation but without detailing any behavioral traits such as authentication needs, rate limits, or return format. The description does not compensate for the lack of 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?
The description is a single concise sentence, but it lacks substance. While not verbose, it could be restructured to include more useful information without increasing length significantly.
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 incomplete. It does not explain what BRC stands for, the nature of sales invoices, pagination behavior, or how it differs from sibling 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?
The description does not add any meaning beyond the input schema. With schema description coverage at 43%, some parameters have descriptions, but the tool description itself provides no parameter context or usage hints.
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 lists BRC sales invoices, which is specific. However, it does not differentiate from sibling list tools like brc_list_sales_credit_notes or brc_list_sales_entries, lacking context on the distinction.
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, it does not mention that for listing credit notes or entries, other tools should be used.
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 carries the full burden but fails to disclose any behavioral traits—e.g., idempotency, error handling (supplier not found), or return data format. It is a bare statement of purpose.
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 (one short sentence), but for a tool with no annotations and low schema richness, it is under-specified. It states purpose but lacks necessary detail, making it minimally 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 no output schema and simple parameters, the description should explain the concept of opening balance or the relationship between companyName and itemId. It fails to provide enough context for an AI agent to use it correctly without external knowledge.
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 extra meaning beyond the schema's parameter descriptions, which are already present. No elaboration 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 'Gets a supplier's opening balance' clearly states the verb (Gets) and resource (supplier's opening balance), and it distinguishes from sibling tools like brc_get_customer_opening_balance by being supplier-specific.
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 list_supplier_op_bal_trans or get_supplier. It does not mention exclusions 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 must fully disclose behavior. It only states the basic function without mentioning whether transactions are all or filtered, pagination, return format, or side effects. For a read operation, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is very concise, but it lacks structure and depth. While it avoids verbosity, it could include more useful details without becoming overly long.
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 incomplete. It does not explain what 'account transactions' includes (e.g., dates, amounts, types) or any constraints like date ranges. The tool is simple, but the description leaves significant gaps.
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 parameters (itemId and companyName), with descriptions in the schema. The tool description adds no additional meaning beyond the schema's parameter descriptions, meeting the baseline for high 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 'Gets a customer's account transactions' uses a clear verb (Gets) and specifies the resource (customer's account transactions). It distinguishes from similar tools like brc_list_supplier_account_trans by focusing on customers. However, it does not differentiate from other customer list tools (e.g., brc_list_customer_quotes, brc_list_customers) beyond the resource name.
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_customer_quotes or brc_list_sales_invoices. The description omits context for selection, leaving the agent to infer based solely on the resource 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 must disclose behavior. It only says 'gets', without explaining the return format (URL, binary, etc.) or any side effects. Crucial behavioral details 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?
The description is a single concise sentence without redundancy. However, it could be slightly more informative 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 lack of output schema and the simplicity of the tool, the description should hint at the return type (e.g., image URL or file). It fails to provide enough context for an AI agent to know what to expect from the response.
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 the sole parameter 'companyName' well-described in the schema. The tool description adds no additional meaning beyond what the schema already provides, so 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?
The description clearly states it retrieves the company logo from BRC. It distinguishes from other get tools (e.g., brc_get_company_options) by specifying 'logo', though it doesn't explicitly differentiate from similarly named 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?
No guidance on when to use this tool versus other get tools. No prerequisites or context provided (e.g., whether a company connection is needed). The description is too brief to inform decision-making.
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 disclosure. It only states 'Gets', implying a read operation, but does not confirm idempotency, required permissions, or any side effects. Additional context like whether it returns current or historical data is 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?
The description is a single, concise sentence with no wasted words. It is appropriately front-loaded with the action and resource. While it could be slightly more informative, it achieves conciseness without 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?
Given the lack of output schema and annotations, the description should explain what the tool returns (e.g., financial year details). It fails to describe the output or any behavioral context, leaving the agent with insufficient information to understand the tool's complete functionality.
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 tool description does not add meaning beyond what the schema already provides. The parameter 'companyName' is fully described in the schema, so the description adds no extra semantic 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 a specific verb ('Gets') and resource ('BRC company financial year'), clearly indicating the action and target. It distinguishes itself from sibling 'get' tools which target other entities (e.g., get_accrual, get_bank_account). However, it doesn't elaborate on what exactly constitutes a financial year (e.g., start/end dates).
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 context on prerequisites, use cases, or distinguishing factors from other get/list tools. The agent receives no help in deciding when this tool is appropriate.
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 disclosure. It only states it 'gets' a credit note, omitting any mention of read-only nature, possible errors (e.g., ID not found), authentication requirements, or rate limits. The agent cannot infer safety or side-effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the core action. It is not unnecessarily long, though it could benefit from a bit more detail 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 lack of output schema and annotations, the description does not provide enough context. It does not describe the structure of the returned credit note, error handling, or prerequisites (e.g., needing the company name and a valid ID). The tool is simple but still leaves gaps.
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 ('Sales credit note id.', 'Company context name, for example YOUR-COMPANY-NAME.'). The description adds no additional semantic value beyond the schema, 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.
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 credit note by id'), distinguishing it from list operations like brc_list_sales_credit_notes. The purpose is specific and unambiguous, though it could more explicitly differentiate from other single-get 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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that brc_list_sales_credit_notes should be used to retrieve multiple notes, or that this tool requires a known ID. The agent receives no contextual usage advice.
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 states the basic operation without disclosing behavior like read-only nature, error states, or side effects. For a simple retrieval, this is acceptable but could be more 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?
Extremely concise with one sentence that front-loads the key information. No wasted words, though it borders on under-specification.
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 a simple retrieval, the description should at least hint at return value (e.g., 'returns the sales entry object'). It does not, leaving some ambiguity. However, for a straightforward get-by-id, it partially meets expectations.
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 tool description adds no additional parameter meaning beyond 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.
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 resource 'one BRC sales entry' with method 'by id'. It is specific and unambiguous, though it does not differentiate from many sibling 'get_*' 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?
No guidance on when to use this tool versus alternatives (e.g., brc_list_sales_entries) or prerequisites. The description is minimal and provides no 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 provided. Description only states 'Gets a customer's opening balance transaction list,' implying a read operation but missing details like pagination, filtering, ordering, or 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?
Single sentence, no wasted words, front-loaded with verb and resource.
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 list tool with no output schema, the description fails to hint at return structure (e.g., transaction dates, amounts). Minimal information leaves gaps 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 coverage is 100%, so the schema already defines parameters. Description adds no additional meaning beyond what is in the schema, 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?
The description clearly states it gets a customer's opening balance transaction list. It distinguishes from sibling tools like brc_get_customer_opening_balance (singular) and brc_list_customer_account_trans (different scope), but does not explicitly 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 on when to use this tool vs alternatives like brc_get_customer_opening_balance or brc_list_customer_account_trans. No context on 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?
No annotations provided; description only states 'Gets quotes for a specific customer' without detailing pagination, sorting, response format, or limits. Minimal transparency.
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, 6 words, no waste. Efficient but could benefit from more structure or detail without sacrificing 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 no annotations and no output schema, the description is minimal but covers the basic purpose. However, it lacks details on return type, pagination, or any prerequisites, leaving some gaps 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% and includes descriptions for both parameters. The tool description does not add any extra meaning beyond the schema, so baseline score 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?
Clear verb ('gets') and resource ('quotes for a specific customer'), but does not explicitly differentiate from sibling tools like brc_list_quotes or brc_get_quote, though the customer filter is implied.
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 (e.g., brc_list_quotes for all quotes, brc_get_quote for single quote). The description lacks any 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 exist, so the description must disclose behavior. It fails to explain what 'dormant' means, how filtering works, pagination behavior, or any side effects. The schema includes pagination parameters (top, page, skip, pageSize) but these are not mentioned in the description.
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 succinct (one sentence), which is concise, but it is too brief given the tool has 7 parameters. It lacks structure to present essential information efficiently.
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 insufficient for a tool with 7 parameters, no output schema, and no annotations. It omits details about the return format, pagination, meaning of 'dormant', and how to use the filtering/ordering parameters. The context of the BRC system is not explained.
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, orderBy, companyName have descriptions). The description adds no parameter-level information, leaving undocumented parameters like 'top', 'page', 'skip', 'pageSize' without context. With low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists BRC customers without dormant records' uses a specific verb ('Lists') and resource ('customers') with a clear modifier ('without dormant'), distinguishing it from the sibling 'brc_list_customers' which likely includes 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 explicit guidance on when to use this tool versus alternatives like 'brc_list_customers'. The description does not mention prerequisites, exclusions, or context for selecting 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, and the description only states 'Gets,' implying a read-only operation. It does not disclose pagination, data volume, or any other behavioral traits beyond the basic verb.
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 to the point. It could be slightly improved by front-loading 'List' instead of 'Gets,' but overall 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?
The description is too sparse for a list tool. It does not explain what 'account transactions' includes, return format, or any filtering capabilities. No output schema exists to compensate.
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 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Gets a supplier's account transactions,' which clearly indicates the tool retrieves transaction data for a supplier. However, it does not distinguish itself from similar sibling tools like brc_list_customer_account_trans.
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. Sibling tools exist for related purposes (e.g., brc_list_customer_account_trans), but the description provides 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.
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 read-only nature, return format, or any side effects. For a simple get tool, this is insufficient for an agent to understand behavior beyond a basic lookup.
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 lacks structure. It is not verbose, but it could be improved by front-loading key information or adding brief context.
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 too minimal. An agent may not know what the tool returns (e.g., a single balance value or object) or if there are any constraints.
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 does not add extra meaning beyond what is in the schema, so baseline 3 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 explicitly states the action 'Gets' and the resource 'customer's opening balance', which is clear and distinct from sibling tools like brc_get_customer (gets customer details) and brc_list_customer_op_bal_trans (lists transactions).
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 (e.g., brc_list_customer_op_bal_trans). No context about prerequisites or typical use cases is given.
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 bears full responsibility for behavioral disclosure. It does not state whether the operation is read-only, idempotent, requires specific permissions, or has any side effects. The name 'get' implies read-only, but this 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?
The description is a single sentence that conveys the core purpose efficiently. No unnecessary words or repetitions. It is optimally concise for the simplicity of the 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?
For a simple retrieval tool with 2 parameters and no output schema, the description is minimally adequate. However, it lacks information about the return value or any behavioral context (e.g., idempotency, access requirements). Given the presence of many similar sibling tools, additional context 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 description coverage is 100%, so the schema already documents both parameters. The description adds no further meaning beyond what the schema 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 verb 'gets' and the resource 'one BRC payment by id', indicating a specific retrieval operation. However, it does not distinguish this tool from sibling tools like brc_get_cash_payment or brc_list_payments, leaving ambiguity about what constitutes a 'BRC payment' versus other payment 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?
The description provides no guidance on when to use this tool versus alternatives such as brc_get_cash_payment, brc_list_payments, or other get tools. There is no information about context, 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 are provided, and the description only states the action. It does not disclose behavioral traits like error handling, authentication needs, or whether the operation is read-only. For a retrieval tool, minimal but lacks 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 a single sentence, front-loaded with the core purpose. It is concise but could be slightly more informative 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 absence of annotations and output schema, the description is too minimal. It doesn't mention return format, error cases, or related tools, leaving gaps 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 coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the 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?
The description states 'Gets one BRC purchase by id,' clearly identifying the resource (BRC purchase) and the action (get by id). It distinguishes from siblings like brc_list_purchases and brc_delete_purchase.
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_purchases or other get tools. No when-to-use or when-not-to-use information is given.
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 states it lists products without dormant records, but does not disclose read-only nature, pagination behavior, performance implications, or authorization requirements. The schema hints at pagination parameters but the description does not explain their behavioral impact.
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 structure. It is front-loaded with purpose, but does not earn its place by providing additional context. It is appropriately sized for a simple tool, but could be expanded 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 tool has 7 parameters, no output schema, and many siblings, the description is too sparse. It does not explain how to paginate, filter, or interpret results. Without annotations, an agent would lack essential context for correct invocation.
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 7 parameters with only 43% coverage (filter, orderBy, companyName have descriptions). The description adds no parameter-level information; it does not explain 'top', 'page', 'skip', or 'pageSize'. With low schema coverage, the description should compensate but fails to do so.
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 'Lists' and the resource 'BRC products', and distinguishes itself by specifying 'without dormant records'. Among siblings like 'brc_list_products' and 'brc_list_customers_without_dormant', this tool's purpose is explicit and unique.
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 listing non-dormant products, but provides no explicit guidance on when to choose this over 'brc_list_products' or other list tools. There is no mention of exclusions or alternative tools, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does not disclose whether the operation is read-only, what the response contains, or any prerequisites like the existence of an opening balance. The brief sentence implies a list operation but lacks behavioral detail.
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 it could benefit from additional structure or context without being overly long.
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 list tool with 2 parameters and no output schema, the description is minimally adequate. It lacks details on return format, error conditions, or prerequisites, making it incomplete for an agent to fully understand its 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 beyond the schema's parameter descriptions, which already state companyName and itemId are required.
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 retrieves a supplier's opening balance transaction list, using a specific verb and resource. It distinguishes from siblings like brc_get_supplier_opening_balance (which gets a single balance) and brc_list_supplier_account_trans (all transactions).
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 when to use brc_get_supplier_opening_balance instead. No exclusions or context for appropriate 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 indicates it uses GET calls, implying a read-only operation, but does not disclose behavioral traits such as whether the report is cached, pagination behavior, rate limits, or authentication requirements. 'Creates' could be misinterpreted as a state change, but the actual operation is idempotent retrieval.
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, focused sentence. It immediately states the purpose and the mechanism, with no wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 (one parameter, simple array input) and the presence of sibling tools, the description is adequate but not complete. It does not explain the output format or how results from multiple companies are grouped, which is essential 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'companyNames' having a clear description and example. The tool description does not add additional semantic value beyond what the schema already provides, so a baseline score of 3 is warranted.
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, specifying the verb 'creates' and the resource 'nominal accounts report'. It distinguishes from the sibling 'brc_list_nominal_accounts' (which lists accounts) but does not explicitly differentiate from 'brc_grouped_nominal_accounts_report', which may be a similar report 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 guidance is provided on when to use this tool versus its siblings. It mentions the underlying GET call but does not state prerequisites, when not to use, or mention alternatives like 'brc_grouped_nominal_accounts_report' for single-company reports.
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 behavior. It only states the basic action, omitting details about response format, error handling, or side effects. No read-only guarantee is given despite the get action implying safety.
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, clear sentence with no extraneous words. It is concise but could mention the expansion of BRC if ambiguous.
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 get-by-ID tool, the description is adequate but minimally complete. It does not explain what the ledger entry contains or any pagination/limitations, leaving the agent partially informed.
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 parameter-specific meaning beyond 'by id', which the schema already documents.
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 resource 'one BRC nominal account by id', distinguishing it from sibling tools like 'brc_get_nom_ac_ledger_by_ids' which retrieves multiple 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 usage guidance is provided. The description does not specify when to use this tool versus alternatives like list_nominal_accounts or the multi-ID variant, leaving the agent without explicit 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?
Without annotations, the description carries the full burden of disclosing behavioral traits. It only states the action, missing details like read-only nature, return format, or potential side effects. The description is insufficient for understanding 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 extremely concise with a single sentence that is front-loaded. However, it could include more useful information without becoming verbose, hence not a perfect 5.
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 annotations), the description is minimally adequate but lacks details on return values or constraints. It leaves gaps for the agent to infer 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 description coverage is 100% with basic descriptions for both parameters. The tool description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'one BRC quote by id', distinguishing it from sibling tools like brc_list_quotes and brc_create_quote which perform different operations.
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_list_quotes for multiple quotes or brc_create_quote for creation. No context about prerequisites or exclusions is given.
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; description only says 'Lists combined...' without disclosing pagination, filtering, ordering, or error behavior. Minimal behavioral context for a list tool with 7 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 efficient with no filler, but could include more contextual information 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?
With 7 parameters, no output schema, and no annotations, the description is too sparse. Missing details on required companyName, pagination, and returned data structure.
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 description adds no value beyond schema. Parameters like 'top', 'page', 'skip' are not explained, leaving gaps for the agent.
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 specific resource 'combined BRC sales entries, sales invoices and sales credit notes,' distinguishing from sibling tools that list each type individually.
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 versus individual list tools (e.g., brc_list_sales_entries). Usage is implied but not clarified with 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?
No annotations provided. The description does not disclose behavioral traits beyond the obvious read operation, such as required permissions, rate limits, or what happens if the id does not exist.
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 extraneous words. Highly 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?
The tool is simple, but there is no output schema or mention of return values. For a get operation, the description is adequate but could be improved by noting the expected return structure or any special 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 description coverage is 100% with both parameters documented. The description adds 'by id' but not meaningful extra context beyond what the schema already provides. 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 'Gets one BRC cash payment by id' clearly specifies the verb (gets) and resource (BRC cash payment) and distinguishes from sibling tools like list or create operations.
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_cash_payments or brc_create_cash_payment). The description solely states the action without 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 states it 'gets' a customer, implying a read operation, but no behavioral details are provided beyond that. With no annotations, the description carries the full burden but fails to disclose any constraints, required permissions, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is appropriately concise with no unnecessary 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 get-by-id operation, the description is minimally adequate. However, it does not mention that both parameters are required, nor does it indicate what the return value contains (e.g., full customer object). With no output schema, some additional context would be 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?
Schema description coverage is 100%, so the parameters are already well-documented. The tool description does not add any additional meaning or usage hints beyond what the schema provides, resulting in a baseline score 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 action ('Gets') and the resource ('one BRC customer by id'). It is specific and distinguishes from sibling tools like brc_get_accrual or brc_list_customers by identifying the target resource and the lookup method.
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_customers, brc_update_customer). There is no mention of 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description only states it retrieves an invoice, with no mention of read-only nature, idempotency, or other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, short sentence with no extraneous information. Every word is necessary.
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 get tool, description is adequate but lacks details on return value format or structure. Acceptable given no output schema and simple use case.
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 covers 100% of parameters and provides descriptions. The tool description adds minimal value beyond 'by id' implying the id parameter. Baseline 3 due to high 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?
Description clearly states action ('Gets'), resource ('BRC sales invoice'), and identifier ('by id'). Distinguishes from sibling list or create 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?
No guidance on when to use this tool versus alternatives like brc_list_sales_invoices or brc_batch_sales_invoices. Implied but not explicit.
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 must fully disclose behavior. It only states 'Gets', implying a read operation, but omits details on return format, error cases, idempotency, or required permissions. This is insufficient for an agent to understand its full effects.
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 that is front-loaded with the essential action and resource. No extraneous information, making it easy to parse quickly.
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 get-by-id tool, the description covers the basic purpose. However, with no output schema, it does not explain return values. Given the lack of annotations, it could be more complete by mentioning the output format or typical use case.
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. The description adds no extra meaning beyond what's in the schema, 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 specifies the verb 'Gets', the resource 'one BRC sales rep', and the method 'by id'. It effectively distinguishes from sibling tools like brc_list_sales_reps (list all) and brc_batch_sales_reps (batch operations) by implying a single-record retrieval.
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 (e.g., brc_list_sales_reps for listing, brc_update_sales_rep for modifying). No when-not or prerequisite info is given.
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 mentions 'creates' and cites a GET endpoint, but does not clarify if the report is persisted or generated on-the-fly, nor any read-only/mutation characteristics. This leaves ambiguity about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action. It is concise but could be more structured to include output behavior. However, it meets a high bar for brevity.
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 report-generation tool, the description lacks details on output format, grouping criteria specifics ('when available' is vague), and any constraints. Given no output schema, more contextual completeness is expected.
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 only parameter (companyName) is described fully in the schema (100% coverage). The tool description adds no additional semantic detail 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 the tool creates a grouped nominal accounts report, specifies the source endpoint (GET /v1/nominalAccounts), and mentions grouping by account group/type. This distinguishes it from sibling tools like brc_list_nominal_accounts (which likely lists raw accounts) 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for grouped reports, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when raw list or multi-company report is needed). 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the confirmation behavior and the need for explicit user confirmation, which is valuable. However, with no annotations, the description does not cover other behavioral traits such as permissions required, side effects, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and packs essential process details in a single sentence. However, a structured format could improve readability.
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 15 parameters, low schema coverage, and no output schema, the description is incomplete. It focuses solely on the confirmation flow and does not explain what fields can be updated, the expected response, or error handling.
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?
With only 20% schema description coverage, the description adds meaning only for confirmWrite. The other 13 parameters lack explanation, leaving the agent unclear about their purpose beyond the schema's sparse 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 updates a BRC purchase and explains the two-step confirmation process. However, it does not differentiate this tool from sibling update tools, though the name already serves that 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?
Provides explicit step-by-step guidance on the two-call pattern with confirmWrite, including the important instruction that preflight is not confirmation. However, it does not advise when to use this tool versus creating a purchase.
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 behavioral traits. It only states the basic operation without mentioning side effects, safety (read-only), authentication, or any constraints. For a getter, the lack of explicit read-only indication is a 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, clear sentence with no wasted words. While it is efficient, it could benefit from additional context about return behavior or prerequisites 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?
The description covers the core purpose but lacks information about the return value (e.g., it returns a single cash receipt object) and does not explain the role of the 'companyName' parameter. Given no output schema, the description leaves some ambiguity about expected outcomes.
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 100%, so both parameters ('id' and 'companyName') are already documented in the input schema. The description adds no additional semantic meaning beyond what the schema provides, resulting in a baseline score 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 action (get), the resource (BRC cash receipt), and the method (by id). It distinguishes from sibling tools like brc_list_cash_receipts which retrieve multiple receipts, and other getters which target 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single cash receipt by ID, but does not explicitly state when to use this tool versus alternatives like brc_list_cash_receipts or other getters. No guidance on 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?
No annotations are provided, and the description lacks behavioral details such as read-only nature, authentication requirements, or what happens if the product is not found. The minimal description does not compensate for missing annotations.
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 at five words and front-loaded. However, it sacrifices potentially useful detail for brevity.
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 (get by ID) and complete schema, the description is minimally adequate. However, it lacks details on return value or behavior, making it incomplete for a comprehensive 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% with descriptions for both parameters (id and companyName). The description adds no additional meaning 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 it gets one BRC product by id, using a specific verb and resource. It distinguishes from list, create, update, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single product by ID but provides no explicit guidance on when to use vs alternatives like brc_list_products or other get 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 carry the behavioral burden. It states the tool returns warnings but does not specify the nature of warnings, side effects (none expected), or any other behavioral traits like rate limits or authentication needs. Acceptable but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loads the purpose, and contains no redundant information. Every sentence contributes 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?
For a simple 2-param tool with no output schema, the description covers the main purpose but omits the return format of the warnings. It could be more complete by specifying the structure or content of the warnings.
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 only an example for companyName ('YOUR-COMPANY-NAME'), which adds marginal value beyond the schema. 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?
The description clearly states the tool checks BRC company processing settings before VAT-sensitive or payment-terms-sensitive workflows, and returns warnings for pre-validation. It differentiates from sibling tools by specifying the context (VAT/payment-terms sensitive), though not perfectly distinct from other check 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 implies usage before creating or changing records in specific workflows, but does not explicitly state when not to use it or provide guidance on alternatives like brc_company_readiness_check. No explicit exclusions or comparisons.
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 burden of behavioral disclosure. It only states the basic operation without mentioning permissions, rate limits, side effects, error handling, or what happens if the supplier ID does not exist. Additional context would be beneficial.
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 that immediately states the tool's purpose. No unnecessary words, efficiently 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 tool's simplicity (get by ID) and full schema coverage, the description is minimally adequate. However, it lacks details about return format, potential errors, or the role of companyName, making it incomplete for an agent needing full context.
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 describes both parameters (companyName and id). The description adds no extra meaning beyond what the schema provides, resulting in a baseline score 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 states 'Gets one BRC supplier by id,' which clearly specifies the verb (Gets), resource (one BRC supplier), and retrieval method (by id). It distinguishes from sibling tools like brc_list_suppliers and brc_batch_suppliers.
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 versus alternatives. The description implies usage for single supplier retrieval, but does not specify exclusions or mention sibling tools like brc_list_suppliers for multiple results.
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 for behavioral disclosure. It does not explicitly state that the tool is non-destructive, requires specific authentication, or has side effects. The description only hints at checking readiness but lacks explicit safety or behavioral details.
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-loaded with the primary purpose, and contains no redundant information. Every word serves a 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?
For a simple tool with one parameter and no output schema, the description covers the essential function and considerations. However, it would benefit from mentioning the format of the output (e.g., a readiness status or list of issues) to be 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% for the single parameter, and the schema description already provides clear guidance. The tool description does not add extra meaning beyond what the schema offers, so it meets 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 what the tool does: checks readiness for read-only and transaction workflows, and highlights specific considerations. It is distinct from sibling tools that perform batch operations, create/update, or other checks.
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 performing read-only and transaction workflows, but does not explicitly state when to use it over alternatives like brc_check_transaction_settings or other readiness tools. No exclusions or conditions are provided.
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 bears full burden. It discloses read-only nature and lists settings, but lacks details on potential side effects, permissions, error handling, or return format. Adequate but not thorough.
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: first enumerates what is retrieved, second clarifies read-only nature and where changes are made. Efficient and front-loaded with essential 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?
Given the tool's simplicity (1 param, no output schema) and no annotations, the description is largely complete. It explains purpose and usage context. Minor gap: 'raw' is undefined, and differentiation from similar siblings is absent.
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?
Only one parameter (companyName) with 100% schema coverage. The description adds no extra meaning beyond the schema's description. 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?
Description states it gets raw BRC company processing/options settings and lists included items (nominal ledger, VAT options, ageing). Clear verb+resource, but sibling tools like brc_get_company_processing_settings exist which may overlap, reducing differentiation.
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 notes it is read-only and changes must be made elsewhere, implying correct usage. However, it does not explicitly state when to use this tool over alternatives like brc_get_company_processing_settings or brc_get_company_reference_settings.
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 provided, so description bears full burden. It states it returns information, but does not explicitly disclose read-only behavior, authentication needs, or rate limits. However, for a simple getter, it's 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?
One sentence that front-loads the purpose. No wasted words, highly concise.
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, so description should indicate what 'information' is returned. It does not. Also lacks guidance among numerous sibling tools. Incomplete for an agent to fully understand the return value.
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 description does not need to add much. It mentions 'by id' but does not elaborate on companyName. Baseline 3 is appropriate as schema already documents both 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 it returns information about a single Nominal Journal Batch by id, distinguishing it from sibling tools like brc_create_nominal_journal_batch, brc_delete_nominal_journal_batch, brc_list_nominal_journal_batches, and brc_update_nominal_journal_batch.
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 when you have an id and need batch details, but does not explicitly mention when not to use it or suggest alternatives like brc_list_nominal_journal_batches for listing all batches.
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 the full burden. It discloses that the tool supports filtering and ordering, which is helpful. However, it does not mention read-only nature, pagination behavior, or any side effects. The description adds some value but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short sentences with no filler. The main purpose is front-loaded in the first sentence, followed by key features.
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 well-described parameters in the schema, the description covers the core functionality. It does not describe return values, but given no output schema and the simplicity of the operation, it is adequate.
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 a small amount of context by specifying which fields can be used in filter and orderBy (entryDate, id). This aligns with the schema, but does not significantly enhance understanding 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 that the tool returns a list of the company's Prepayments. It uses a specific verb and resource, distinguishing it from other list tools by the resource name. However, it does not explicitly differentiate from siblings like brc_list_payments or 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 mentions optional OData filtering and ordering, but does not provide explicit guidance on when to use this tool versus alternatives. No when-not 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the tool is a read-only check ('Checks whether'), but does not mention what the return value or error behavior is (e.g., boolean or exception if date is invalid).
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 one sentence, front-loaded, and every word is necessary. No fluff, ideal 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?
For a simple validation tool with no output schema, the description covers the core functionality. However, mentioning the return type or expected outcome (e.g., 'returns true/false') 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 schema covers 100% of parameters with descriptions. The tool description adds no extra meaning beyond what the schema already provides, 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 validates a transaction date against the current financial year (specific verb 'checks', resource 'transaction date'). It distinguishes itself from sibling tools, which are mostly CRUD or batch operations.
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. It is implied that it should be used before creating transactions, but no exclusions or sibling comparisons are provided.
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 full burden. It clearly discloses the two-step confirmation process and the meaning of confirmWrite. However, it omits other important behavioral traits: what happens after deletion (e.g., irreversibility, impact on related records), required permissions, error conditions, or success response format. This leaves gaps for a destructive operation.
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 compact with two sentences, front-loading the core purpose. The instructions in the second sentence are dense but necessary. Minor improvement could be separating the instructions into bullet points, but it remains readable and 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 complexity (destructive action with confirmation flow) and absence of output schema, the description covers the confirmation process well but lacks details on what happens after a successful deletion (e.g., return value, side effects). It also does not mention prerequisites like permissions or system state (e.g., note must exist). This makes it incomplete for an agent to fully understand the tool's 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 description coverage is 75%, high. The description adds significant value for the critical parameter confirmWrite by explaining its role in the two-step confirmation, complementing the schema. Id and companyName are already well-described in the schema. The parameter confirmDelete (with default false) is not mentioned in the description, but it is optional and less critical. Overall, the description enhances parameter 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 clearly states 'Deletes a BRC sales credit note by id using timestamp confirmation', specifying the verb and resource. The tool name and description together effectively distinguish it from sibling delete tools targeting other entities. However, it does not explicitly contrast with other delete tools, losing a point for full differentiation.
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 guidance: first call without confirmWrite:true returns confirmation_required and preview; then retry with confirmWrite:true only after user confirmation. Also warns that 'preflight is not confirmation'. This is strong, but it does not discuss when to use this tool versus alternatives (e.g., updating instead of deleting), so it's not a perfect 5.
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 the full burden. It discloses read-only behavior and supported OData operations but omits details like pagination limits, error conditions, or return format.
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 extraneous information, front-loaded with the action 'Returns'. 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?
The description covers the basics but lacks details on the returned fields or structure, which is important given no output schema. It also does not mention the required companyName context explicitly in the description, though it's in the schema.
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 description reiterates the OData filtering and ordering capabilities already indicated in the parameter descriptions. It adds marginal 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 returns a list of accruals, with optional filtering by entryDate and ordering by id. This distinguishes it from sibling tools like brc_get_accrual (single) and brc_create_accrual (create).
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 (to list accruals) but does not explicitly guide when to use this tool versus other list tools for different entities. No exclusions or alternatives 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 description carries full burden. It implies read-only but does not mention side effects, authentication needs, rate limits, or result structure. Lacks depth for a tool with no annotation safety net.
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 succinct sentences, front-loaded with purpose followed by usage context. Zero wasted words, highly 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?
No output schema exists, but description does not elaborate on return format or fields beyond 'eligible transactions'. Adequate for a simple list tool but leaves some gaps.
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 covers both parameters with descriptions (100% coverage). Description adds no extra meaning beyond reiterating that bookTranId is required, 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 the tool returns 'transactions eligible for allocation from the specified sender book transaction', which is a specific verb+resource. It distinguishes from siblings like `brc_list_allocated_transactions` (which lists already allocated transactions) by focusing on eligibility.
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 states 'Use this before updating allocations' and 'Requires bookTranId', giving clear context. Does not mention alternatives or when not to use, but the directive is strong.
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 states action and scope. Does not disclose side effects, reversibility, authorization requirements, or what 'MCP server memory' means. Lacks behavioral depth.
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, clear sentence with no unnecessary words. Front-loads key action and scope.
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?
Sufficient for a parameterless tool; describes what is cleared and scope. No output schema, so return values not required. Could mention confirmation or reversibility, but overall adequate.
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 in schema (100% coverage). Baseline score of 4 for 0 parameters; description adds no param info since none exist.
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 the verb 'clears', resource 'connection credentials for all company contexts', and location 'MCP server memory'. Differentiates from sibling brc_clear_company_api_key by specifying 'all company contexts'.
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?
Does not explicitly provide when to use or alternatives. The distinction from the singular clear tool is implied by name, but no explicit guidance on when to choose this over 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?
No annotations are provided, so the description carries full burden. It states 'clears ... from MCP server memory' indicating a destructive action. However, it does not disclose side effects, authorization needs, reversibility, or impact on ongoing operations.
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 of 12 words, front-loaded with the action verb. Every word is necessary, and it avoids any 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?
For a simple one-parameter tool with no output schema, the description covers the essential purpose and context. It could hint at the return value (e.g., success/failure) or mention that it affects the current MCP session, but overall it is satisfactory.
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 the parameter already described in the schema. The tool description does not add additional meaning or usage guidance beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'clears' and identifies the resource as 'API key for a named company context'. It clearly distinguishes from sibling tools like brc_clear_all_company_api_keys and brc_get_company_api_key_status.
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 clearing a specific company's API key but does not explicitly state when to use this tool versus alternatives like brc_clear_all_company_api_keys. No exclusions or prerequisites are provided.
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 states the tool returns information (implying a non-destructive read) and clarifies that child accruals are not exposed. However, it omits details like idempotency, potential error conditions, or any response format hints.
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, no fluff, and front-loaded with the core function. Every word contributes meaning.
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 has no output schema, yet the description does not hint at what information is returned (e.g., structure, fields). It also lacks any mention of authentication, error handling, or prerequisites, leaving gaps for an agent to understand the full context.
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 minimal value beyond the schema, confirming the id is for a parent accrual. The tool's note about parent vs child is more about purpose than parameter semantics.
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, distinguishing it from sibling tools like brc_list_accruals (for listing) and brc_create_accrual (for creation). It also notes that child accruals are not exposed, providing additional specificity.
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 defines the tool's use case—retrieving a specific parent accrual by ID—and the context of sibling tools suggests alternative tools for listing or creating. However, it does not explicitly state when not to use it or list prerequisites.
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, and the description does not disclose any behavioral traits beyond the basic get operation, such as required permissions or return value structure.
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 information, but could be slightly more detailed 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 no output schema and a simple retrieval operation, the description adequately defines the tool's purpose but lacks details about the return value, leaving the agent to infer the structure.
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?
Both parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning beyond what is already 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 action (Gets), resource (BRC bank account), and method (by id), distinguishing it from list/create/update/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?
The description implies usage for retrieving a single bank account, but lacks explicit guidance on when to prefer it over listing or other retrieval methods.
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 the burden. It indicates a read operation ('Gets'), but does not disclose any side effects, permissions required, or limits. It is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and front-loaded with the tool's purpose, listing key contents efficiently. No wasted 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?
With no output schema, the description provides a reasonable overview of what is returned (categories of configuration). It is nearly complete for a getter tool, though it could mention the response format.
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 description does not add meaning beyond the input schema for the single parameter companyName. Schema coverage is 100%, 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 it gets the full BRC company setup configuration and lists components (general details, financial year, reference settings, processing options), which distinguishes it from sibling tools that retrieve individual pieces.
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 need all listed components together, but does not explicitly state when to use this tool versus the specific getter siblings (e.g., brc_get_financial_year). No when-not-to-use or alternatives are 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?
No annotations exist, so description must carry behavioral disclosure. It describes basic function but omits details like pagination behavior, rate limits, or authentication needs.
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, concise. First sentence is clear purpose; second is detailed advisory. Could be slightly restructured for clarity but overall 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?
No output schema, yet description does not explain return value structure. Does not address the 7 parameters or pagination. Missing crucial context for a list 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 coverage is 43%; description adds no parameter information. For undocumented parameters (top, page, skip), no guidance; for documented ones, no added 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 explicitly states it lists BRC analysis categories, with specific guidance on sales vs CR categories, distinguishing it from sibling tools that list other entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (sales invoices/credit notes), what not to do (avoid CR categories), and a fallback strategy (ask user if uncertain).
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 read-only nature implicitly ('returns a list') and mentions filtering/ordering capabilities. No annotations exist, so description carries full burden; could be improved by stating it does not modify data.
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 fluff. First sentence states purpose, second provides usage guidance. Efficient and 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?
Adequate for a list tool with well-documented schema. Lacks output description (what fields are returned), but the usage context and parameters are sufficiently covered.
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%; description repeats the filtering by entryDate and ordering by id that is already in the schema. Adds no new meaning 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?
Clear verb ('returns a list') and specific resource ('nominal journal batches'). Does not explicitly differentiate from sibling list tools, but the name and description sufficiently identify the target resource.
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?
Explicit guidance to use before update/delete operations to obtain id and timestamp. Lacks explicit when-not-to-use or alternative tools, but the provided 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 provided, so description carries full burden. It discloses the two-step confirmation, max items, and that preflight is not confirmation. However, it omits details on final output after confirmWrite, error handling, idempotency, and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose and workflow efficiently. Information is front-loaded: first sentence states purpose, second details the confirmation process. Could be improved with bullet points for clarity, but 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?
Covers the core batch processing and confirmation flow. However, lacks information about return values (no output schema), error scenarios, or what happens after successful confirmWrite. More details on the final result 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 baseline is 3. The description adds value by explaining the confirmWrite workflow and preflight step, and clarifying that priceBasis applies to all items. This goes beyond the schema's individual 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 tool processes a batch of sales reps, with a specific verb and resource. It distinguishes from sibling batch tools (e.g., customers, products) by naming 'sales reps' directly. The two-step confirmation workflow is also explained.
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 confirmation workflow: first call without confirmWrite returns preview, second with confirmWrite only after user confirmation. It mentions max batch size and that preflight is not confirmation. However, it does not explicitly exclude scenarios or compare to 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 automatic category creation when categoryId omitted, and requirement for nominalAcCode to exist. Does not cover authentication or response.
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 of 4 sentences, concise and to the point. Could be slightly more structured (e.g., bullet points for required 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?
Given 18 parameters and no output schema, description covers core workflow and key constraints but lacks details on many parameters and return behavior. Sufficient for basic use but not fully comprehensive.
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 50%. Description highlights required fields (acCode, details, lastChq, nominalAcCode) and explains categoryId optionality, but many parameters (address, balance, sortCode, etc.) remain 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 clearly states 'Creates a BRC bank account', which is a specific verb+resource. Sibling tools are distinct create operations for other entities, so no confusion.
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 warns against calling with confirmCreate=true before user confirmation, and lists required fields. However, no mention of when not to use 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?
Discloses the two-phase workflow (preflight returns confirmation_required and preview, actual write on second call) and warns that preflight is not confirmation. No annotations existed, so the description carries the 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?
The description is two sentences, front-loaded with purpose. The workflow detail is necessary but could be slightly more concise (e.g., bullet points). 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 no output schema, the description mentions 'payload preview' but does not specify its structure or indicate that the output likely contains the created rep's ID. Lacks mention of prerequisites like company context existence.
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?
All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds context for confirmWrite's preflight behavior but does not enhance understanding of other parameters 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 explicitly states 'Creates a BRC sales rep', using a specific verb and resource. It distinguishes from sibling tools like batch creation and update tools by implying a single-entity creation with a 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?
Provides clear step-by-step guidance on using confirmWrite: first call without, show preview, then retry with confirmation. However, it does not mention when to use batch creation (brc_batch_sales_reps) as an alternative.
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 the full burden. It discloses the destructive nature and the user confirmation requirement. However, it does not elaborate on potential side effects, reversibility, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. First sentence states purpose and prerequisite, second sentence gives a critical rule. Highly 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?
The description covers the action, prerequisite step, and safety rule. For a deletion tool with no output schema, it is fairly complete. However, it does not mention return values or behavior on invalid ids.
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 all parameters. The description adds minimal additional meaning beyond the schema, such as the context of 'allocation resolver id' and the need for user confirmation, but this is mostly redundant.
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 'allocation by allocation resolver id', and it distinguishes from siblings by specifying the unique resource type and prerequisite step (using brc_list_allocated_transactions).
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 to call the tool (after finding the allocation id) and a critical safety rule (do not call with confirmWrite=true without user confirmation). However, it does not mention alternatives or when not to use this tool compared to other delete 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?
No annotations are provided, so the description carries the full burden. It clearly discloses the two-step preflight and confirmation behavior, including that the first call returns a confirmation_required and payload preview, and that subsequent calls require explicit user confirmation. This adequately covers the essential behavioral traits for a destructive 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?
The description is concise, consisting of three sentences that front-load the action and then explain the two-step process. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no output schema, the description covers the preflight step, confirmation requirement, and the need to show a draft in chat. It does not describe error handling or the exact format of the preview payload, but this is sufficient for an agent to understand the correct invocation flow.
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% (3 of 4 parameters have descriptions). The description reinforces the usage of confirmWrite with the preflight protocol but does not add meaning for id or companyName beyond schema. The confirmDelete parameter is not addressed. Overall, minimal added 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?
The description clearly states 'Deletes a BRC customer by id,' providing a specific verb and resource. While it does not explicitly differentiate from other delete tools among siblings, the tool name itself includes 'customer,' making the purpose distinct 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?
The description provides explicit guidelines: first call without confirmWrite triggers a preflight, then retry with confirmWrite only after explicit user confirmation. It also clarifies that 'passing preflight is not confirmation.' This gives clear context for when and how to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states it lists categories and gives examples, but does not mention result structure, pagination behavior, or whether it is read-only (implied). Lacks details on output format or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with the primary action and examples, then a specific usage note. Efficient and to the point.
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 without output schema, the description covers the core purpose and provides a key usage scenario. It could be enhanced by describing the return structure (e.g., list of category objects with IDs and names), but it is sufficient for basic 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?
With 7 parameters and only 43% schema coverage, the description does not add meaning beyond what the schema provides. It does not explain how parameters like top, page, skip affect the list. The description focuses on purpose rather than 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 lists BRC VAT categories with concrete examples (Sales, Purchases for Resale, etc.). It differentiates from sibling tools like brc_list_vat_rates by explaining that categories are the classification to which rates belong, making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool: 'Use this to tell which VAT category a VAT rate belongs to.' Additionally, it includes a rule about sales invoices requiring sales VAT categories, aiding correct tool selection. No explicit alternatives mentioned, but the context 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?
With no annotations provided, the description carries full burden. It adds the behavioral note 'Never exposes connection credentials', which is helpful but does not detail other behaviors (e.g., side effects, idempotency, permissions). The description is somewhat transparent but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence adds value. No redundancy or 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 simple tool with one parameter and no output schema, the description is complete. It explains the prerequisite (user submitted connection page), the trigger (confirmation code), and a safety note. No missing essential context.
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% and the parameter's own description already explains the code. The tool description adds context about when the code is obtained (from success page) but does not add new parameter meaning beyond the schema. Baseline 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 claims a completed secure Red connection code for the current MCP session, specifying the verb 'Claims' and the resource (secure connection code). This distinguishes it from siblings like brc_start_company_connection, which likely initiates the 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?
The description provides clear usage context: 'Use after the user has submitted the secure connection page and returns to this chat with the confirmation code shown on the success page'. It gives an example (MCP session changed after opening browser) but does not explicitly state when not to use or mention 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?
No annotations are provided, so the description carries full burden. It discloses the creation action and the need for user confirmation, but does not specify permissions, side effects, or success response. The warning about confirmWrite is good, but more behavioral context (e.g., whether it automatically validates balance, if it can be undone) would improve 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 extremely concise with two sentences. The first sentence states the primary purpose, and the second adds critical usage guidance. No wasted words, and the structure is optimal for quick comprehension.
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 hint at return values or status. It does not explain what the response contains (e.g., batch ID). While the schema documents the parameters, the description lacks completeness regarding the result of the operation. The balance and confirmation advice are helpful, but overall it could be more comprehensive for a complex creation 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%, so baseline is 3. The description adds meaning beyond schema by stating that debit and credit lines must balance and that confirmWrite should only be true after user confirmation. This extra context for the parameters (especially confirmWrite and accountTransactions) elevates the 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 'Creates a new Nominal Journal Batch' with a specific verb and resource, distinguishing it from siblings like update, delete, or list. It also adds essential constraints about balanced lines and confirmation flow.
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: not to set confirmWrite=true until user confirms, and that journal lines must balance. It implies a two-step creation process. However, it does not compare this tool to potential alternatives for obtaining the same result, though the sibling set makes the purpose 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?
Without annotations, the description bears full burden. It discloses the destructive nature, required timestamp format, and confirmation step. However, it omits information about side effects, irreversibility, or response 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 concise sentences. The main action is front-loaded, with critical usage instructions following. No unnecessary 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 delete tool with no output schema and no annotations, the description lacks return value information and error conditions. It provides key prerequisites and safety steps but not a complete operational picture.
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 4 parameters. The description adds context: timestamp must be retrieved from brc_get_accrual and confirmWrite should only be true after user confirmation. This exceeds what 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 (removes) and the specific resource (existing parent Accrual by id). It distinguishes itself from sibling delete tools by specifying the resource and mentioning the prerequisite timestamp retrieval.
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 and warns not to set confirmWrite=true without explicit user confirmation. However, it does not mention when not to use the tool or compare to other deletion-related 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?
Discloses the two-step confirmation behavior and payload preview. Lacks details on consequences of deletion (e.g., irreversibility), but annotations are absent so description carries the burden.
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: first states purpose, second details process. No fluff, front-loaded, but could be slightly more structured for readability.
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?
Sufficiently covers the confirmation workflow for a delete tool with no output schema. Does not explain errors or prerequisites, but overall complete for 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?
Adds significant value for confirmWrite parameter by explaining the preflight/confirmation workflow. Schema covers 75% of parameters; description compensates with usage details 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 deletes a BRC sales entry by ID using timestamp confirmation. It differentiates from sibling delete tools by specifying 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 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, show draft, then retry with confirmation. However, it does not compare to alternatives like other delete 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?
No annotations provided, so description carries full burden. It reveals that the tool makes individual GET calls per ID, indicating a read-only operation with potential performance implications. Adds value by explaining the mechanism, but does not detail error handling or merging of results.
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 16 words, front-loads the action. No unnecessary information. Extremely concise and well-structured.
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 value. It does not mention what the tool returns (e.g., array of accounts) or error behavior for invalid IDs. Adequate but missing return value details.
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 100% with clear descriptions for both parameters. Description adds mechanism context (calling endpoint for each id), which is beyond schema. Provides additional meaning about how parameters are used.
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 'gets' and resource 'nominal accounts for specific ids', and explains the mechanism (calling GET endpoint for each ID). It distinguishes from sibling tools like brc_get_nominal_account_ledger_by_id (single ID) and brc_list_nominal_accounts (all accounts).
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?
Implies usage when you have specific IDs, but does not explicitly state when to use this tool over alternatives. No 'when not to use' or explicit alternatives mentioned. Siblings provide context but description could be more direct.
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 the full burden. It discloses the two-step confirmation process, the need for explicit counterparty confirmation, and the maximum batch size. However, it does not detail the exact system behavior (e.g., what validation occurs, error handling, or side effects of the write operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences that front-load the purpose and constraints. Every sentence provides essential guidance without extraneous information, achieving high efficiency.
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 (confirmation flow, counterparty check, max items) well. It lacks details on error handling or the structure of the 'payload preview' and no output schema is provided, but the main usage scenarios are adequately addressed.
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 behavioral context: it explains the two-step usage of confirmWrite, the condition for confirmCounterpartyExplicit, and the meaning of priceBasis. This goes beyond the schema's 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 sales entries' and specifies a maximum of 5 items per batch. This distinguishes it from sibling tools like brc_batch_sales_invoices or brc_create_sales_entry, which handle different record types or single entries.
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 step-by-step instructions: first call without confirmWrite returns a preview, then retry with confirmWrite after user confirmation. It also mandates confirmCounterpartyExplicit when the user names the counterparty. However, it does not explicitly contrast with alternatives like single-entry 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?
No annotations are provided, so the description carries the burden. It discloses that the API accepts only the parent transaction and relies on shared logic for the reversing child, which is key behavioral insight. It also mentions 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?
Two sentences: first defines purpose, second provides crucial usage guideline. No wasted words; 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?
Given no output schema and no annotations, the description covers creation behavior and the critical confirmation step. It could mention return value, but it's not essential. The context of many sibling create tools makes the purpose 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 baseline is 3. The description adds meaning for confirmWrite (user confirmation requirement) but does not elaborate on other parameters beyond schema defaults.
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 new parent Accrual' and explains the API's behavior of generating a reversing child transaction. This is specific and distinguishes from siblings like brc_update_accrual or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to call with confirmWrite=true until user confirmation, providing clear usage guidance. However, it does not compare to other tools for when to use this one vs. alternatives like brc_update_accrual.
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 that the tool creates a parent Prepayment and relies on shared logic to generate a reversing child transaction. It also warns about the confirmWrite flag, giving important behavioral context beyond simple creation.
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 wasted words. The information is front-loaded and to the point.
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 creating a parent with an auto-generated child, the description and schema provide enough context for correct usage. No output schema exists, but description doesn't need to explain return values. The confirmWrite guidance fills a key 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 description coverage is 100%, so baseline is 3. The description adds semantic value for confirmWrite by explaining when to set it true, but for other parameters it adds no additional meaning 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 it creates a parent Prepayment, specifying the verb and resource. It distinguishes from sibling tools like brc_delete_prepayment, brc_get_prepayment, and other create tools by focusing on the prepayment entity and its parent-child aspect.
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 a critical usage guideline: 'Do not call with confirmWrite=true until the user has reviewed the draft and explicitly confirmed creation.' It does not explicitly compare to alternatives, but the resource name differentiates from other create 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 must disclose behavioral traits. It effectively reveals the two-step confirmation mechanism and that the first call is non-destructive but returns a preview. It does not mention idempotency, destructive potential beyond the preflight, or error conditions, but the preflight disclosure is strong.
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 plus a short warning. Every sentence adds essential information. The purpose is stated first, followed by the critical usage process. No wasted 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 complexity of the preflight workflow and no output schema, the description adequately covers the behavior: first call returns confirmation and preview, second call creates. It lacks detail on success response or error states, but for a create tool with clear preflight steps, it is fairly 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 value for the confirmWrite parameter by reinforcing its usage in the preflight flow, but does not add semantic detail beyond the schema for payload or companyName. The guidance on confirmWrite is helpful but does not significantly raise the score.
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 product using a raw BRC payload. The verb 'creates' and resource 'BRC product' are specific. However, it does not explicitly differentiate from sibling tools like brc_update_product or other create tools, relying on the name for distinction.
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 returns preview, then show draft to user, then retry with confirmWrite only after explicit confirmation. Also warns that passing preflight is not confirmation. This leaves no ambiguity about 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, description carries full burden. Explains two-step confirmation process, preflight behavior, and counterparty confirmation requirement. Lacks error handling details but provides substantial behavioral context 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?
Description is front-loaded with purpose and usage. Well-structured with clear sentences. Slightly verbose but every part contributes to understanding the tool's behavior and requirements.
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?
Explains core workflow and confirmation requirements, but lacks return value details (e.g., structure of payload preview, error responses). No output schema, so description should cover this. Incomplete for a complex tool with 15 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 20% (2 out of 15 parameters have descriptions in schema). Description adds meaning for confirmWrite and confirmCounterpartyExplicit by explaining when to set them, but provides no additional info for the other 12 parameters, partially compensating for 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?
Description clearly states 'Creates a Purchases Book purchase with a generated reference using structured fields.' This specifies the verb (creates), resource (Purchases Book purchase), and differentiator (generated reference), distinguishing it from siblings like 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?
Explicitly states 'Use when the company is configured for auto-generated purchase references.' Provides detailed workflow: first call without confirmWrite, show draft, retry with confirmWrite only after explicit user confirmation. Also specifies confirmCounterpartyExplicit requirement, clearly differentiating from other 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?
No annotations are provided, so the description carries the full burden. It discloses the two-step confirmation process, the preflight behavior, and that opening balance is not handled. This is detailed for a mutation tool, though it does not mention error states or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It packs essential information without excess. A slight improvement could be structuring as bullet points for the two-step process, but it remains clear.
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 does not explain return values or possible errors. The complex workflow is well-covered, but missing what the successful response looks like. Considering the many sibling tools, it is complete enough for its core 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 100% but descriptions are minimal. The description adds crucial behavioral context for confirmWrite (when to set true/false) and clarifies that payload is a raw BRC payload. This goes beyond the schema's bare description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 supplier using a raw BRC payload. It distinguishes from sibling tools like brc_batch_suppliers and brc_update_supplier by specifying that it does not handle opening balance transactions. The verb 'creates' and resource 'supplier' 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 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 to use confirmWrite: never on first call, only after user confirmation of a plain-English draft. It also warns about opening balance handling. However, it does not explicitly compare to other supplier-related tools like batch creation.
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 carry behavioral disclosure. It adds workflow context (timestamp retrieval and confirmation requirement) but does not detail side effects or data destruction beyond the implied delete 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?
Three sentences, each serving a purpose: first states action, second gives prerequisite, third provides usage instruction. No 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?
For a delete tool with a unique timestamp requirement and confirmation flow, the description covers the steps (retrieve timestamp, avoid premature confirmation) adequately. It does not describe return values, but no output schema exists, so 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?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by noting the timestamp is a Base64 string and that confirmWrite should only be true after user confirmation, which goes 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?
The description clearly states the verb 'removes' and the resource 'Nominal Journal Batch by id'. It distinguishes itself from sibling delete tools by specifying the unique requirement of a batch timestamp in Base64 format.
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 instructs to use brc_get_nominal_journal_batch first to retrieve the timestamp and warns not to set confirmWrite=true until user confirmation. It provides clear context but does not mention 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.
Behavior3/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 need for timestamp in Base64 and the confirmation flag, but does not mention irreversible effects, permissions required, or success/error behavior. Reasonable but could be more 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?
Three sentences, first sentence states action, remainder provides critical usage guidance. No unnecessary words; very 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 delete operation with no output schema, the description covers prerequisites (timestamp), safety (confirmWrite), and reference to companion tool. Does not specify return value or error handling, but these are less critical for delete. Slightly incomplete but solid.
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%, yet the description adds meaningful context: explains the timestamp format (Base64) and the conditional requirement for confirmWrite. This goes beyond the schema basics.
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 ('Removes an existing parent Prepayment by id') and specifies the resource and method. It distinguishes from sibling tools like brc_create_prepayment or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to first use brc_get_prepayment to obtain the timestamp and warns about confirmWrite only after user confirmation. It provides clear context but does not explicitly exclude other scenarios or mention 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?
Despite no annotations, the description discloses the two-step confirmation, the preview step, and the need for explicit user confirmation. It indicates the operation is irreversible but doesn't elaborate on 'timestamp confirmation.' Overall, good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Structure is logical and easy to follow.
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 4 params and no output schema, the description covers the critical delete workflow. Missing details on 'timestamp confirmation' and return format, but sufficient for selecting 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 75% (confirmDelete lacks description). The description adds value by explaining the confirmWrite parameter's role in the two-step workflow, but doesn't cover confirmDelete. 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 the tool deletes a BRC quote by ID with timestamp confirmation. It distinguishes from siblings like brc_close_quote and brc_update_quote by specifying deletion and the 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?
Explicit guidance on the two-step process: first call without confirmWrite:true, show preview, then retry with confirmWrite:true after user confirmation. Notes that preflight is not confirmation. Lacks explicit when-not-to-use, but the context is clear.
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 clearly explains the two-step preflight/confirmation flow and warns that 'Passing preflight is not confirmation.' However, it does not describe the behavior of the confirmDelete parameter or the response after successful 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?
The description is extremely concise (two sentences) with no filler. It front-loads the core action and immediately explains the unique two-step workflow, making it easy for an agent 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 (delete with confirmation), the description covers the essential flow and the key parameter usage. It lacks details about the return value or response after the second call, and does not mention alternative approaches like deactivation. Nonetheless, it provides sufficient context for 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 input schema already covers 75% of parameters with descriptions. The description adds meaningful context for confirmWrite, clarifying that it must only be set true after explicit user confirmation in a later message, which goes beyond the schema's description. Other parameters are not elaborated 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 action ('Deletes a BRC supplier by id'), specifying both the verb and the resource, and it implicitly distinguishes from sibling delete tools for other entities (e.g., brc_delete_customer) through the resource name.
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 explains the two-step confirmation process but does not provide explicit guidance on when to use this tool over alternatives (e.g., deactivating a supplier via brc_update_supplier). Usage context is clear but lacks exclusions or comparisons to 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?
In the absence of annotations, the description discloses that the settings are read-only in Red and changes must be made in Big Red Cloud. This adds important behavioral context beyond the schema. It does not cover auth or rate limits, but the key behavior is 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?
Three tightly focused sentences: purpose, usage recommendation, and behavioral note. No redundant words, and the most critical information 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 no output schema, the description provides sufficient context about what settings are covered (VAT, cash receipts, etc.). It could optionally describe the return format, but for a 'get' tool with clear sibling differentiation, it is largely 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 description coverage is 100%, so the schema already documents both parameters (includeRaw, companyName). The description does not add additional parameter-level detail beyond what the schema provides, so it meets the baseline but does not exceed 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 uses specific verb 'reads' and clearly identifies the resource as 'BRC company processing/options settings'. It lists the affected features (VAT, cash receipts, payment terms, debtor statements, gross price entry, transaction creation), distinguishing it from sibling tools like brc_get_company_options or brc_get_company_reference_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?
Explicitly advises 'Use this before VAT-sensitive write workflows where possible', providing clear context for when to call this tool. However, it does not explicitly state when not to use it or mention alternatives, though the context is strong enough for an agent to infer.
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 bears full responsibility. It discloses that the tool performs a read operation (returns transactions) and implies no destructive side effects. It covers the essential behavioral trait without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the main action, and contains no redundant words. 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?
The tool is simple (2 required params, read operation). The description covers the core purpose and usage context. It does not describe return format (no output schema), but for a list tool that is often implicit. Minor gap in not mentioning pagination or result structure.
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 only adds that bookTranId is required, which is already implied by the schema (required field). No additional semantic 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 returns allocated transactions from a specified sender book transaction. It also distinguishes this tool from siblings by framing its use case ('review existing allocations before reversing/deleting'), which is specific and helpful.
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 ('before reversing/deleting one') and mentions a prerequisite ('Requires bookTranId'). It does not explicitly list alternatives or when not to use it, but the context is sufficiently 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 provided, so description carries full burden. It discloses that connection credentials are never returned and that technical fields like credentialType and expiresAt should be hidden. However, it does not mention other behaviors such as performance, idempotency, or required permissions, leaving some 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?
Description is three sentences: the first states core purpose, the second and third provide usage instructions. No unnecessary words, front-loaded with 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?
Given zero parameters and no output schema, the description is complete enough for a simple listing tool. It explains what the tool does, how to present results, and what not to expose. Could optionally describe the return structure (e.g., array of objects with customerMessage and companyName), but not strictly necessary.
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?
Input schema has no parameters, so description has no additional parameter information to provide. Baseline score of 4 is appropriate as the description does not need to compensate for missing parameter details.
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 'list' and resource 'company contexts' with scope 'currently connected in this MCP server session'. Sibling tools include many list tools for other entities, but none for company contexts, so it 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on presenting results: show customerMessage and plain names, hide technical fields unless asked, and note that credentials are never returned. Does not explicitly state when not to use, but context is sufficient given no alternative 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 explains behavioral traits: it requires user confirmation, handles recipient email lookup, and manages multi-recipient sending. It also specifies that unsupported types should be rejected gracefully. However, it does not mention idempotency, rate limits, or what happens on failure beyond unsupported types.
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 detailed but somewhat verbose at ~150 words. It is front-loaded with the primary purpose. Some instructions to the agent (e.g., 'Do not call this tool...') are necessary but could be more concise. Overall adequate but not exemplary.
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 9 parameters with full schema coverage, the description compensates well by covering workflow constraints, supported/unsupported types, and multiple recipient handling. Minor gaps: no mention of error handling beyond unsupported types or return behavior, but still strong.
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 workflow context (e.g., confirmSend usage, multi-recipient logic) but largely repeats or slightly extends the schema descriptions. The added value is moderate, not transformative.
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 sends a quote email and specifies supported document types (quotes, sales invoices, customer statements), explicitly listing unsupported types. This distinguishes it from sibling send email tools like brc_send_email_statement and brc_send_sales_invoice_email by document type scope.
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 (for supported document types) and when not to use (for a long list of unsupported types, with instructions to inform user). It also gives a clear workflow: require user review before confirming send, handle missing email, and handle multiple recipients with BCC vs separate options.
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 were provided, so the description carries the full burden. It discloses the preflight mechanism (returns confirmation_required and payload preview), the need for explicit user confirmation, and that passing preflight is not confirmation. This is informative for an update 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 a single paragraph that front-loads the purpose and then details the confirmation workflow. It is concise and every sentence adds value, though it could be slightly more structured with bullet points.
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 behavior: the confirmation workflow, merge fields, and required parameters. It lacks return value details but mentions the preview, which suffices for agent 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%, but the description adds value by explaining the confirmWrite parameter's two-step usage, the payload/updates alias for merged fields, and the companyName format. 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.
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 bank account using merged fields, distinguishing it from sibling tools like brc_update_customer. However, it focuses heavily on the confirmation workflow rather than the core update action.
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 on when to call the tool: first call without confirmWrite to get a preview, show a summary to the user, and only retry with confirmWrite=true after explicit confirmation. It also warns against setting confirmWrite true prematurely.
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 discloses the update behavior and the two-step process involving confirmWrite, but lacks details on side effects (e.g., overwrite behavior, audit logging) or consequences of timestamp mismatches. The description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two focused sentences. Essential workflow guidance is front-loaded, and there is 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?
Given no output schema and 9 parameters, the description covers the prerequisite step and confirmation workflow. However, it does not describe return values or error conditions, leaving some gaps for an update operation. Overall, it provides sufficient context for the core task.
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%), so baseline is 3. The description adds workflow context to key parameters: timestamps (from get) and confirmWrite (only after user confirmation). This enhances understanding beyond the schema descriptions, justifying a score above baseline.
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 an existing Nominal Journal Batch by id, distinguishing it from create and delete siblings. It specifies the action (update) and the resource (nominal journal batch by id), leaving no ambiguity about its function.
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 to first retrieve the batch using brc_get_nominal_journal_batch to get timestamps, and warns against setting confirmWrite=true until user confirms. This effectively communicates when to use the tool and the prerequisite workflow, though it does not explicitly contrast with sibling update 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 discloses the two-step confirmation process and preview behavior. However, it does not detail other aspects like permissions, side effects, or return values.
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 provides necessary workflow details. It is slightly verbose but each 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 the lack of output schema and annotations, the description covers the confirmation process well but omits return value, prerequisites, and 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?
The description adds minimal value beyond the schema; it reiterates the confirmWrite workflow already in the schema description. Parameters code and name lack schema descriptions, and the tool description does not supplement them.
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 starts with 'Updates a BRC sales rep using structured MCP fields,' clearly stating the verb (updates) and the resource (sales rep). This distinguishes it from sibling tools like create and delete.
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 for preview, then retry with confirmWrite only after user confirmation. It clearly states when not to set confirmWrite.
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-call confirmation flow, maximum 5 items, and the requirement for explicit counterparty confirmation. It also warns against reusing counterparties from earlier drafts. This is thorough for a write operation, though it does not mention idempotency or error 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 paragraph that packs essential information without redundancy. It front-loads the purpose and limit. While it could be broken into bullet points for easier scanning, it remains concise and 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 no output schema and the tool's complexity (multi-step confirmation), the description adequately covers the interaction flow, preflight request, and confirmation flags. It does not describe return values or error scenarios, but for a batch tool with good annotations 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?
Schema coverage is 100%, so baseline is 3. Description adds significant value by explaining the two-call pattern for confirmWrite, the condition for confirmCounterpartyExplicit, and the net vs gross distinction for priceBasis. It also clarifies the items parameter as 'batch items to process'. 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 explicitly states 'Processes a batch of BRC cash receipts' with a clear verb and resource. It distinguishes itself from sibling tools like 'brc_create_cash_receipt' by being a batch operation, and from other batch tools by specifying '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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed step-by-step usage flow: first call without confirmWrite, show preview, get user confirmation, then retry with confirmWrite. Also specifies when to set confirmCounterpartyExplicit. However, it does not explicitly mention that for a single receipt the user should use brc_create_cash_receipt instead, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the confirmation flow and batch limit but does not specify whether 'processes' means create, update, or both. No annotations provided, so description carries full burden; missing side-effect clarity.
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?
Four sentences, front-loaded with purpose and limit, then concise workflow instructions. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers confirmation workflow well but lacks description of output (e.g., preview format, response structure) and doesn't clarify mutation type (create vs update). Given complexity of batch tools, more detail 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% with parameter descriptions. Description adds value by explaining the confirmWrite two-step flow beyond schema, though other parameters are not further elaborated.
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 'Processes a batch of customers', distinguishing from sibling batch tools for other entities. Explicitly mentions batch size limit (5 items), making purpose 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?
Provides explicit instructions for the two-step confirmation workflow: first call without confirmWrite returns preview, user must confirm explicitly. Warns that passing preflight is not confirmation, preventing misuse.
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 describes behavioral traits: two-step confirmation process, defaults for entryDate/procDate, conditional VAT fields, counterparty confirmation. 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?
Reasonably concise and front-loaded with main action. Contains useful details without excessive verbosity. Could be slightly tighter but 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 30 parameters and no output schema, description covers workflow and important constraints. Missing return value details beyond preflight. Fairly complete for usage context.
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 only 10%, so description should compensate. It explains confirmWrite, confirmCounterpartyExplicit, entryDate/procDate defaults, and VAT condition. However, many parameters (note, total, acCode, etc.) lack semantic description, leaving gaps.
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 cash receipt' with a specific verb and resource. It distinguishes from sibling create tools by specifying cash receipt, but does not explicitly compare to siblings like brc_create_cash_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed workflow: first call without confirmWrite for preview, then explicit user confirmation. Requires confirmCounterpartyExplicit for explicit counterparty confirmation. Notes conditional VAT fields based on company setting. Gives clear when-to-use instructions.
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, so description carries full burden. Clearly describes destructive action (delete) and the confirmation/preview pattern. Warns that preflight does not count as confirmation, which prevents accidental deletion. Does not specify permissions or side effects, but the confirmation mechanism 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?
Two sentences, front-loaded with purpose, then workflow details. No fluff. Could be slightly more structured (e.g., bullet points) but remains efficient and readable.
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 mentions return fields: 'confirmation_required' and 'payload preview'. Covers the input workflow. Missing explanation of confirmDelete parameter, but that's minor. Sufficient for a delete tool with confirmation.
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 confirmWrite parameter's role in the confirmation workflow. Schema already describes id and companyName sufficiently. confirmDelete is in schema with default but not elaborated in description – minor gap. Overall, supplements schema 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 'Deletes a BRC product by id' – specific verb and resource. Among many sibling delete tools, 'product' distinguishes it uniquely. No ambiguity.
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 two-step workflow: first call without confirmWrite returns preview and confirmation_required, then retry with confirmWrite after user confirmation. States 'Passing preflight is not confirmation' to avoid misuse. Could mention alternative delete tools for other entities, but the context is clear.
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 preflight/confirmation behavior, including that preview is returned. Could mention permanence of deletion, but overall sufficiently transparent for a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and workflow. Each sentence adds value, 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?
Description covers the deletion workflow and return preview. Lacks output schema info, but description mentions return values. Complete enough for agent to use 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 high (75%), so baseline is 3. Description adds context on confirmWrite timing but doesn't elaborate on confirmDelete. Adequate but not exceptional.
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) and resource (BRC sales rep) with a specific method (timestamp confirmation). It differentiates from sibling delete tools by referencing the 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?
Explicit instructions on when to use: first call without confirmWrite returns preview, then retry with confirmWrite: true only after user confirmation. Warns against assuming preflight 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 the description carries the full burden. It clearly states the tool returns connection status only and never the key, and includes a safety warning about not repeating keys from chat history.
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 with zero waste. Every sentence adds value: usage guidance, behavioral constraint, and safety instruction.
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 simple tool with one optional parameter and no output schema, the description covers all needed aspects: purpose, when to use, behavior, and agent constraints. No gaps.
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 covers the single parameter (companyName) at 100%, so the description does not need to add parameter details. It provides no additional parameter semantics.
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 connection status for API key queries, and distinguishes itself by explicitly saying it never returns the key. This differentiates it from sibling tools like brc_clear_company_api_key.
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 states when to use the tool ('when the user asks for an API key, secret, or what key was used'), but does not mention when not to use it or provide 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 indicates a read operation ('returns'), non-destructive. Could mention error behavior but for a simple get it's 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?
Single sentence of 15 words, directly states purpose and constraint (no child prepayments). No fluff, front-loaded.
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 simple read tool with 2 parameters and no output schema, the description is complete. It explains what it returns and what it doesn't cover (child prepayments). No additional context 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 covers both parameters with descriptions (id as parent prepayment id, companyName as company context). Description adds 'single parent' but that's already in schema's description. No extra semantic 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?
Clearly states verb 'returns', resource 'single parent Prepayment by id', and distinguishes from list tools and child prepayments. Sibling tool brc_list_prepayments lists all prepayments, so this is a specific get-by-ID.
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 says when to use (to get info on a single parent prepayment by id) and notes that child prepayments are not exposed, implying when not to use. No explicit mention of alternatives but sibling context makes it clear.
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 process and that passing preflight is not confirmation. However, it does not mention idempotency, authorization requirements, or whether it creates vs updates rates. The confirmation pattern 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?
Three sentences, all essential. First sentence states purpose and endpoint. Second and third explain the critical usage pattern. 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?
Covers purpose and workflow well, but fails to describe the response structure after successful processing. Since there is no output schema, the description should at least mention what the response contains (e.g., success message, updated rates). Also lacks error handling or edge case info.
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 83%, so baseline is 3. The description adds value by explaining that vatCategoryRates must be a full array and clarifies the confirmWrite workflow. It also emphasizes that confirmProcess=true is required, which complements the schema's default false.
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 VAT rates for VAT categories via a specific POST endpoint, distinguishing it from sibling list tools like brc_list_vat_rates. The verb 'processes' and resource 'VAT rates for VAT categories' provide specific intent.
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 two-step workflow: first call without confirmWrite: true returns preview, then retry with confirmWrite: true only after user confirmation. Warns that preflight is not confirmation. However, it does not explicitly state when to avoid this tool (e.g., for read-only queries, use 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?
The description discloses a critical behavioral trait: the confirmWrite parameter must only be set after user confirmation. However, it does not explicitly state that the initial call without confirmWrite creates a draft, nor does it describe other side effects or permissions. Given no annotations, the description carries the burden, and it does well but could be more 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?
The description is three sentences, front-loaded with purpose, followed by prerequisite and caution. Every sentence adds value without redundancy, making it concise and well-structured.
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 or annotations, the description covers the workflow but lacks detail on return values or how to retrieve the allocation draft. The prerequisite and caution are helpful, but the agent may need more information about post-invocation behavior to use the tool 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 100%, so the baseline is 3. The description reinforces required fields but adds no additional meaning beyond what the schema already provides for each parameter. It does not explain the nested structure of allocationResolvers beyond what is in 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's purpose: 'Creates or updates allocations for a sender book transaction.' This is a specific verb+resource combination, and the sibling tools include related but distinct operations like listing and deleting allocation resolvers, so it is well-differentiated.
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 provides when-to-use guidance: 'Use brc_list_allocation_resolvers first to identify eligible receiver transactions.' It also gives a clear when-not: 'Do not call with confirmWrite=true until the user has reviewed the allocation draft and explicitly confirmed posting.' This covers prerequisites and exclusions effectively.
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 the description discloses the two-step preflight/confirmation mechanism, including that the first call returns a preview and the actual update requires a second call. It does not mention side effects or auth, but the core behavioral pattern 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?
Three sentences, all essential: purpose, two-step process, and warning. No redundant information. Effectively 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?
For a tool with 5 parameters, no output schema, and a complex confirmation workflow, the description covers the key usage pattern and output expectation (returns confirmation_required and preview). Could mention error cases or what happens after successful update, but overall 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 has 100% coverage with descriptions for all 5 parameters. The description adds critical context for the confirmWrite parameter (explaining the two-step workflow) and reinforces the 'merged fields' semantics. This goes beyond the baseline 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 'Updates a BRC cash receipt using merged fields,' which is a specific verb+resource combination. While it doesn't explicitly differentiate from sibling update tools (e.g., brc_update_cash_payment), the name and description are sufficiently unique.
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 for preview, then retry with confirmWrite after user confirmation. Includes clear what-not-to-do (passing preflight is not confirmation). This is excellent, differentiating it from similar 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?
No annotations are provided, so the description carries full burden. It discloses the key behavioral trait of the two-step confirmation workflow: first call is a preflight returning confirmation_required and payload preview, and confirmWrite must be true to write. It explicitly states 'passing preflight is not confirmation.' Additional details like idempotency or side effects are not mentioned, but the core behavior is clear.
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 very concise—two sentences. The first sentence states the purpose, and the second explains the critical workflow. No filler or redundancy. Front-loaded with the action, then workflow 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 complexity (5 parameters, nested objects, no output schema), the description covers the core workflow but omits details like return value format (only mentions 'confirmation_required and a payload preview'), error handling, or required permissions. It is adequate but not fully 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 100%, baseline 3. The description adds meaning by explaining the confirmWrite parameter's role in the workflow (false on first call, true only after confirmation). It also implies that payload and updates are used for merging fields, aligning with schema descriptions. This adds 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 verb 'Updates' and the resource 'BRC product', distinguishing it from sibling tools like brc_create_product or brc_get_product. The mention of 'using merged fields' adds specificity, and the two-step workflow sets it apart from simple updates.
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 when-to-use guidance: a preflight call without confirmWrite: true returns a preview, and only after explicit user confirmation should confirmWrite be set to true. It warns against treating preflight as confirmation. While it doesn't compare to sibling update tools, it focuses on the correct usage workflow.
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?
Without annotations, the description fully discloses the preflight/confirmation behavior, maximum items, and the requirement for explicit user confirmation. However, it does not describe error handling, side effects, or the nature of the return value beyond mentioning confirmation_required and preview.
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?
Four sentences, front-loaded with purpose, no redundancy. Every sentence adds essential guidance (limit, confirmation workflow, non-confirmation clarification).
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 batch processing with a preflight confirmation workflow and no output schema, the description adequately conveys the core behavior. It covers the confirmation protocol and parameter semantics. Slightly lacking on what the tool returns after successful write, but schema description fills some 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%, so baseline is 3. The description adds significant value by explaining the workflow around confirmWrite (two-step process) and confirmCrAnalysisCategory (intentional CR account). It also clarifies priceBasis for VAT-inclusive/exclusive. This goes 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?
Clearly states the tool processes a batch of suppliers with a specific constraint (max 5 items). Distinguishes from sibling batch tools and single supplier creation tools through naming and context.
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 confirmation process: first call without confirmWrite, show plain-English draft, then retry with confirmWrite after explicit user confirmation. Provides critical guidance on what constitutes confirmation ('passing preflight is not confirmation'). Does not explicitly state when to use alternative tools like brc_create_supplier for single suppliers.
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?
Without annotations, the description fully explains the two-step behavior and the requirement for explicit user confirmation, adding significant value beyond a simple 'close' verb.
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 compact with three sentences, front-loading the purpose, and every sentence earns its place by explaining the critical usage pattern.
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 adequately explains the confirmation process and return of a preview. It could be improved by stating the final response for the second call, but it is largely 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%, but the description adds crucial semantics for the confirmWrite parameter, detailing the required flow. This goes beyond the schema's basic 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 'Closes a BRC quote' with a specific verb and resource. It distinguishes itself from sibling tools like brc_reopen_quote by focusing on the close 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?
The description provides explicit instructions on the two-step confirmation process, including when to set confirmWrite: true and that preflight is not confirmation. It does not mention alternatives but the context is clear.
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: no opening balance handling, preflight returns confirmation_required, email mismatch warning, and confirmation workflow. No contradictions. Missing auth or rate limit info, but these are not critical for basic 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?
Extremely concise at ~100 words, no filler. Front-loaded with purpose. Every sentence provides essential information. Excellent structure.
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 workflow, constraints (no opening balance), and preflight behavior. No output schema, but description mentions what first call returns. Could elaborate on payload structure, but schema covers that. Adequate for a create tool with moderate 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%, so baseline is 3. The description adds critical usage semantics for confirmWrite (workflow and when to set true) and clarifies payload as 'raw BRC payload'. This adds 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 verb ('Creates') and resource ('BRC customer'). It distinguishes itself from sibling tools by explicitly noting what it does NOT do (opening balance transactions), which helps differentiate from other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance, including a detailed confirmation workflow (preflight, confirmWrite) and email mismatch check. Could be stronger on when to use alternatives, but the explicit workflow instructions serve as good usage 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, but the description fully discloses behavioral traits: requires saleRepId and saleRepCode, requires analysisCategoryId and accountCode, warns against defaulting to CR01/Customer, describes the confirmation_required preview, and mandates explicit user confirmations.
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 densely packed with essential instructions. Every sentence adds value, though it could be slightly more structured (e.g., bullet points) for easier scanning. 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 28 parameters, no output schema, and no nested objects, the description is fairly complete. It covers the confirmation flow, prerequisites, and constraints. Missing explicit mention of success response structure, but the agent can infer from the confirmation flow.
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%), so the description carries the burden. It clearly adds meaning for critical parameters like confirmWrite, confirmCounterpartyExplicit, confirmCrAnalysisCategory, and the reference parameter. However, not all 28 parameters are explicitly described in the main description, but key ones are covered.
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 quote using structured MCP fields. It distinguishes from sibling tools like brc_create_quote_gen_ref by detailing quote reference requirements. However, it could explicitly name the sibling for contrast.
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 require a quote reference, not to use with unknown settings unless reference provided, do not use default sales rep values, requires explicit user confirmations for write, counterparty, and analysis category. It even specifies the two-step confirmation workflow.
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 takes full responsibility for disclosing behavioral traits. It covers crucial behaviors: draft previews include warnings for missing fields without inventing values, confirmation flags must be set only after explicit user confirmation, the first call returns a payload preview rather than executing, and preflight is not confirmation. This level of detail ensures the agent understands the tool's behavior thoroughly.
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 efficient, with every sentence providing necessary guidance. It is front-loaded with the purpose and then systematically covers usage conditions, requirements, and the multi-step process. No superfluous content is present, though the length is justified by the tool's complexity.
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 thoroughly explains the tool's behavior and usage constraints, but it lacks information about the return value on successful creation. Given the tool has 28 parameters, no output schema, and no annotations, this gap leaves the agent uncertain about what to expect after the final confirmWrite call. Additional context on the response format 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 description coverage is only 36%, so the description must compensate. It adds meaningful context for confirm booleans and sales rep parameters, describing when to set them true. However, many required parameters like acCode, entryDate, productId, unitPrice, etc., are left undocumented in the description, relying on the sparse schema descriptions. The description partially addresses the gap but does not fully cover all 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 starts with 'Creates a BRC quote with a generated reference using structured MCP fields,' which is a clear verb+resource combination. It also distinguishes from the sibling tool brc_create_quote by specifying auto-generated references, 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 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 ('when quote references are auto-generated' or after user confirmation of the setting) and includes detailed instructions on prerequisites (e.g., requires saleRepId, saleRepCode, analysisCategoryId, accountCode), prohibitions (e.g., do not use default sales rep values, do not default to CR01), and the two-call workflow with confirmWrite. This provides comprehensive guidance on usage context and 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 are provided, so the description carries full behavioral burden. It transparently discloses the two-phase confirmWrite mechanism (first call returns confirmation_required and payload preview, retry with confirmWrite only after explicit user confirmation), the need for explicit counterparty confirmation, and that preflight is not confirmation. It does not, however, mention potential errors, rate limits, or destructive consequences of creating a credit note, but given the complexity, the disclosed behaviors are thorough.
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 dense but somewhat verbose, containing multiple instructions in prose form without visual separation. It front-loads the purpose but then packs requirements in long sentences. While every sentence adds value, a more structured format (bullets or short paragraphs) would improve readability for an agent. It is concise relative to the complexity but could be better 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 23 parameters, 19 required, no output schema, and no annotations, the description covers the creation workflow, prerequisites, confirmation steps, and handling of missing data (e.g., listing sales reps). It is quite complete, but it doesn't describe the success response format or any post-creation steps. For a high-complexity tool, this is strong.
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 26%, but the description significantly compensates by explaining many key parameters: reference (conditionally required), saleRepId/saleRepCode (must be from brc_list_sales_reps and not default), analysisCategoryId/accountCode (must be from Sales Analysis category, not defaulted), and the three confirm parameters with precise conditions. This adds substantial meaning beyond the schema. However, some parameters like productId, customerId, etc. are not explained beyond basic type info.
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 itself from the sibling 'brc_create_sales_credit_note_gen_ref' by explicitly noting when to use each based on manual reference configuration. The verb 'creates' and resource 'BRC sales credit note' 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 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 prefer this tool over the gen_ref variant, requirements for saleRepId/saleRepCode (and not to use default/demo values), requirements for analysisCategoryId and accountCode, conditions for setting confirmCrAnalysisCategory, confirmWrite, and confirmCounterpartyExplicit. It also instructs the agent to list or ask for missing sales reps. This is exceptional context 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?
Despite no annotations, the description discloses many behavioral traits: creation mutation, preflight confirmation, blocked values (productId 0/1, purchase VAT), default behavior (note defaults to customer name), and the confirmation_required response. However, it does not describe the final success response structure, which is a notable omission.
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 overly verbose and repetitive (e.g., note and deliveryTo instructions repeated). It is a dense block of text lacking structure, which makes it harder for an AI agent to parse quickly. While front-loaded with purpose, conciseness is poor.
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 (6 parameters, nested payload, no output schema), the description covers most essential aspects: usage context, parameter semantics, behavioral rules, and confirmation flow. The only gap is the lack of output structure explanation, but overall it is quite complete.
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 input schema covers 83% of parameters, but the description adds significant value for the payload parameter, detailing expected fields (note, deliveryTo, saleRepId, etc.) and constraints. For priceBasis and confirmation flags, the description reinforces and clarifies schema descriptions, making parameter semantics excellent.
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 auto-generated reference, distinguishing it from the sibling brc_create_sales_invoice (which likely uses manual reference). The verb 'creates' and resource 'sales invoice' are specific, and the condition of auto-generated references is explicitly mentioned.
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 (auto-generated references), what to avoid (default values, placeholders, purchase VAT rates), and the precise confirmation workflow (preflight first, then confirmWrite, plus confirmCounterpartyExplicit). It explicitly states do's and don'ts.
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 carries full burden and excels. It explains the destructive nature (delete), the required two-step confirmation process, the return of confirmation_required and payload preview on initial call, and the critical warning that preflight is not confirmation. It fully discloses the behavioral pattern.
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 paragraph that is concise and front-loaded with the main action. Every sentence adds important information: deletion action, two-step process including draft display, and a warning. No wasted 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 is a delete operation with a confirmation pattern and no output schema, the description covers the essential process well. It explains the initial response and required next step. However, it could be more complete by mentioning potential error conditions or the behavior of the confirmDelete parameter, and by clarifying what happens on a successful delete.
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 high (75%) with descriptions for id, companyName, and confirmWrite. The description adds value by explaining the multi-step usage of confirmWrite but does not mention confirmDelete, which is in the schema with default false. This omission is a gap, keeping the score at baseline.
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 cash payment by id,' specifying the verb and resource. It distinguishes from sibling delete tools by the resource name and the unique two-step confirmation process, which is not described in other sibling descriptions.
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 safe usage: first call without confirmWrite:true, show plain-English draft in chat, then retry with confirmWrite:true only after explicit user confirmation. Warns that preflight is not confirmation. However, it does not compare to alternatives like other delete tools or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers the two-step confirmation behavior. It discloses that the first call returns a confirmation_required response and a payload preview. However, it does not mention the irreversible nature of deletion or what happens after successful 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: two sentences that front-load the core action and immediately follow with critical usage guidance. 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 no output schema, the description provides essential context about the confirmation flow. It mentions the return of confirmation_required and a payload preview but does not detail the preview structure or final success response. This is adequate for a delete tool but could be slightly richer.
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% (3 out of 4 parameters described). The description adds no additional meaning for id, companyName, or confirmWrite beyond what the schema already provides. It does not address the confirmDelete parameter at all, leaving its purpose unclear.
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 deletes a BRC sales invoice by id using timestamp confirmation. The verb 'deletes' and specific resource 'sales invoice' make the purpose unambiguous, and it stands out among sibling delete tools by mentioning the 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?
Explicit instructions are provided: first call without confirmWrite returns confirmation_required and a payload preview, then retry with confirmWrite only after explicit user confirmation. It also clarifies that passing preflight is not confirmation, which prevents misuse.
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 behavioral burden. It discloses that the tool is read-only ('These settings are read-only in Red') and explains a key behavioral nuance (conditional handling for Quotes Unknown). However, it does not describe return format, error handling, or what happens if settings are missing, which would be beneficial.
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 adding essential information: purpose, usage guidance, and a behavioral note with constraints. No redundancy or filler. 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?
The description covers the tool's purpose and usage well, but lacks detail on the output format since there is no output schema. It doesn't explain what values are returned for each document type or how to interpret the settings. For a read-only settings tool, this is a minor gap; the description is otherwise 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 description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema; it doesn't elaborate on the includeRaw parameter or how to use it in context. 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 the tool 'Reads BRC reference auto-generation settings' and specifies the exact document types (sales, purchases, quotes, debtors journal, creditors journal). This verb-resource pair is specific and distinguishes it from sibling tools like brc_get_company_options 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool 'before preparing or creating quotes, invoices, purchases, or other reference-sensitive records.' It also provides a specific conditional: 'If Quotes is Unknown, do not assume auto-generate; ask for a quote reference or user confirmation first.' This offers clear when-to-use guidance and a caution.
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?
Without annotations, the description carries full burden. It discloses that only data changes are logged, read-only calls excluded, and scope is limited to current session. It does not explicitly state it's a read-only operation or mention rate limits, but the behavior is well-described.
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 contains redundancy (multiple sentences about ignoring older entries). While front-loaded with the core purpose, it could be more concise and structured without losing important details.
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 single boolean parameter and no output schema, the description covers scope, exclusions, and usage well. It misses describing the output fields, but for an audit log list tool, the behavioral context is sufficiently 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 only parameter (includeTechnicalDetails) has a schema description, but the description adds usage guidance: 'Only set this to true if the user asks for technical details. Sensitive values are still redacted.' This adds 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 shows a record of data changes (create, update, delete, etc.) made through this Red MCP server session, distinguishing it from other list tools by focusing on audit log scope. It avoids tautology by adding nuance about read-only calls not logged.
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: for 'what did I do today in Red?' style questions. Provides clear exclusions: ignore other sessions, other users, disconnected companies, and unrelated chat history. Offers specific guidance on scope restrictions.
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 the full burden. It does not explicitly state that the operation is read-only or mention any side effects, auth needs, or rate limits. However, it does highlight the need to cross-reference another tool, which adds behavioral context about dependencies. The description is moderately transparent but lacks basic safety/behavioral disclosures.
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. The first sentence immediately states the purpose, followed by important usage details. No unnecessary information, and structure 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 has no output schema, the description does not explain return fields. However, it provides essential domain context about VAT rate selection and cross-referencing. The key field vatCategoryId is explained, which is critical for correct usage. Slight lack of return format details, but overall complete for a list tool with strong domain 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 description coverage is low (43%). The description compensates by explaining the concept of vatCategoryId and its role in distinguishing sales vs purchase rates, which adds meaning beyond the schema. It also suggests using brc_list_vat_categories, aiding understanding of related parameters. However, it does not detail pagination 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 that the tool lists BRC VAT rates, which is a specific verb+resource. It also provides additional context about VAT categories and distinguishes itself from sibling tools like brc_list_vat_categories and brc_list_vat_types by focusing on rates and their usage 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?
The description explicitly instructs when to use a sales VAT rate vs a purchase rate, even if percentages match. It also recommends cross-referencing brc_list_vat_categories to group rates, providing clear guidance on the workflow and 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?
With no annotations, the description carries full burden. It discloses the update action and the confirmWrite safeguard, but does not describe whether the update is partial or full, idempotency, or what the tool returns (no output schema). The concurrency control via timestamp is implied but not explicitly stated. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: first defines action, second provides prerequisite, third gives critical constraint. No wasted words, front-loaded with the verb. Excellent conciseness.
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 11 parameters, 8 required, no output schema, and no annotations, the description covers the essential workflow: get first, then update with confirmation. However, it lacks details on return values (e.g., success indicator or updated object) and update semantics (merge vs replace). Still, it is fairly complete for the critical 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 100%, so parameters are fully described. The description adds context: timestamp is base64 from the accrual, confirmWrite must only be true after user confirmation, and that the timeretrieval step is needed. This enhances the schema descriptions and clarifies 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 updates an existing parent Accrual by id. It distinguishes from siblings like create, delete, get, and list by specifying 'Updates' and mentioning child accruals are not exposed. The verb and resource are specific, leaving no ambiguity about what the tool does.
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_get_accrual first to retrieve current data and timestamp. Warns about child accruals not being exposed via public API. Provides critical guidance on confirmWrite: do not set to true until user has reviewed and explicitly confirmed. This clearly states 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?
With no annotations, the description shoulders the burden of behavioral disclosure. It reveals the two-step confirmation process, returning a preview. However, it doesn't mention potential need for specific permissions or the result after successful update.
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: first states purpose, second details the critical workflow. No redundancy, 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 the tool's complexity (update with confirmation) and lack of output schema, the description covers the essential workflow but omits post-confirmation behavior and error handling. It is complete enough for an AI agent to use correctly in most scenarios.
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 by explaining the confirmWrite workflow and noting 'structured safe text/reference fields' for note and reference, but doesn't provide additional constraints or format beyond what is in 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 sales credit note, which is a specific verb+resource. It distinguishes itself from sibling tools like brc_create_sales_credit_note and 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?
The description provides explicit workflow guidance: first call without confirmWrite for preflight, then retry with confirmWrite after user confirmation. It clarifies when not to set confirmWrite, which is highly helpful for correct 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 discloses the two-phase commit process, the need for explicit counterparty confirmation, and the 5-item limit. It does not explicitly state that the tool performs writes or mention error handling, but the workflow 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 concise with five sentences, each adding value. It is front-loaded with the main action. Could be improved with bullet points or clearer separation of steps, but effective as is.
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 essential aspects: batch limits, preview confirmation, counterparty confirmation. Lacks details on error handling or partial success, but for a batch tool with no output schema, it provides sufficient context for an 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%, but the description adds critical context for confirmWrite, confirmCounterpartyExplicit, and priceBasis beyond the schema descriptions. The items parameter is merely restated, but overall the description enhances 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?
The description clearly states it processes a batch of BRC cash payments with a maximum of 5 items, distinguishing it from single-item create tools and other batch 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step workflow: first call without confirmWrite returns a preview, then retry with confirmWrite: true only after user confirmation. Also mandates confirmCounterpartyExplicit after explicit naming, and warns against preflight or reused drafts.
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 fully discloses behavioral traits. It reveals the two-phase commit: first call returns a preview without writing, then requires explicit user confirmation. It also details the counterparty confirmation requirement and batch size limit. This is thorough 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 well-structured and front-loaded with the main purpose. It is moderately long but every sentence adds value. Minor redundancy with schema descriptions could be trimmed, but overall it is clear 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?
Given the lack of an output schema, the description mentions that the first call returns confirmation_required and a payload preview, instructing to show a plain-English draft. It covers the essential workflow and constraints. It could be more explicit about error scenarios or the structure of the preview, but it is sufficient for correct agent 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?
The input schema has 100% description coverage for all 6 parameters. The description largely restates or summarizes the schema descriptions (e.g., confirmWrite rules). It does not add significant new meaning beyond what the schema already provides. 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 begins by clearly stating the tool processes a batch of BRC payments. This distinguishes it from sibling batch tools like brc_batch_purchases or brc_batch_cash_receipts that handle different entities. The verb 'process' combined with 'BRC payments' 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?
The description provides explicit step-by-step instructions: first call without confirmWrite yields a preview, then retry with confirmWrite only after explicit user confirmation. It also mandates confirmCounterpartyExplicit when the counterparty is explicitly named. It warns against misusing confirmWrite (e.g., never on first call) and against reusing counterparty from earlier drafts. This is comprehensive guidance for correct usage.
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 details the confirmation workflow, maximum batch size (5), preflight behavior, and explicit user confirmation requirements for both write and counterparty. Does not cover error handling or idempotency, but covers key behavioral expectations.
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 dense paragraph front-loads purpose, then concisely lists constraints with no redundant sentences. All information is directly useful for an agent deciding to invoke 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 complexity (6 params, 2 required, workflow) and no output schema, the description covers the main flow and constraints. Mentions return value (confirmation_required + preview) but doesn't detail response format or error cases. Still comprehensive enough for most agent decisions.
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%, baseline 3. Description adds significant value: explains the workflow for confirmWrite (two-step), confirmCounterpartyExplicit (requires explicit user naming in current conversation), and priceBasis (context for gross/net). Goes well beyond schema descriptions, especially for confirmWrite and confirmCounterpartyExplicit.
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,' specifying the action (processes), resource (quotes), and batch context. It distinguishes from sibling tools like brc_create_quote (single quote) and other batch tools (e.g., brc_batch_sales_invoices) by focusing on quotes.
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 flow: first call without confirmWrite returns a preview, then retry with confirmWrite after user confirmation. Provides when-not-to-use for confirmWrite and confirmCounterpartyExplicit. No direct comparison to alternatives like brc_create_quote for single quotes, but the batch focus 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 are provided, so the description carries the full burden. It explains the two-phase commit behavior (preview then confirmation), clarifies that passing preflight is not confirmation, and requires explicit counterparty confirmation. It does not explicitly state the side effects (e.g., database creation), but the workflow details are sufficiently transparent. Could be slightly more explicit about success outputs.
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 for a complex tool with multi-step workflow. It front-loads the main purpose and key conditions, then structures the workflow. Every sentence serves a purpose, though it could be slightly more concise by combining some conditional statements.
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 16 parameters (13 required) and no output schema, the description covers the essential workflow, confirmation steps, and counterparty confirmation. It does not explain return values or error handling, but for a creation tool with two-phase commit, the guidance is sufficiently complete 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 covers 100% of parameters with descriptions, but the description adds significant context for confirmWrite and confirmCounterpartyExplicit, explaining their workflow semantics. It also clarifies when reference is required. For other parameters like netAmount, schema descriptions suffice, but the tool's description adds value for the nuanced boolean 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 starts with 'Creates a BRC purchase using structured MCP fields', clearly stating the verb and resource. It also distinguishes from sibling tool brc_create_purchase_gen_ref by specifying when each should be used (manual reference vs auto-generated), ensuring differentiation.
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 (company configured for manual reference) and when to prefer brc_create_purchase_gen_ref. Provides a detailed multi-step workflow: first call without confirmWrite, then retry with confirmWrite only after explicit user confirmation. Also requires confirmCounterpartyExplicit after the user explicitly names or confirms the counterparty. This is clear and actionable 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 the burden. It discloses the two-step confirmation, payload preview, and the requirement for explicit user confirmation. However, it does not mention final response or error handling, 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?
The description is extremely concise at two sentences, front-loading the core action and then explaining the process. Every sentence adds value 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 covers the main workflow but lacks details on the final response after successful deletion, error scenarios, and the behavior of other parameters like confirmDelete. Given no output schema, 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 75% with basic descriptions. The description adds significant value for confirmWrite by explaining its role in the confirmation workflow, but does not elaborate on id or companyName 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 'Deletes a BRC purchase by id using timestamp confirmation', providing a specific verb and resource. It explains the unique two-step confirmation process, which distinguishes it from other delete tools among siblings.
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 outlines the workflow: first call without confirmWrite: true, then show a plain-English draft, then retry with confirmWrite: true after user confirmation. It also warns that 'Passing preflight is not confirmation', giving clear 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?
The description is highly transparent about what the tool does (summarizes permissions), its constraints (do not expose technical details), and its audience (customer-facing). It lacks an explicit statement that it is read-only, but given its nature, this is sufficient. No annotations provided, so the description carries the full burden.
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 longer than ideal but front-loaded with the main purpose. Every sentence adds value by setting usage context and constraints. Could be slightly more concise, but the detail is warranted for a meta-introspection 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 zero parameters and no output schema, the description provides sufficient context for an agent to decide when to use this tool and what it returns (plain-English business responses). It outlines the summary categories and formatting rules, making it complete for its 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?
There are no parameters in the input schema, and schema description coverage is 100%. The description does not need to add parameter information since none exist. Baseline score for no parameters is 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 it is an authoritative permission and output policy summary for the Red session, and explicitly lists triggers like 'asks what they can do, what tools they have, what permissions are enabled'. It distinguishes itself from sibling tools by being a meta-summary rather than an operational 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 when-to-use scenarios ('user asks what they can do, what tools they have, what permissions are enabled, or whether technical details/code should be shown') and what to avoid (do not list tool names, JSON, etc.). It also gives formatting guidance for customer-facing answers.
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, description carries full burden. It discloses two-step confirmation, return of confirmation_required and payload preview, and the requirement for explicit user confirmation. Lacks mention of idempotency or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences packed with essential information, front-loaded with purpose, no fluff.
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 complexity (nested objects, confirmation workflow), description covers the two-step process, expected return values, and confirmation requirement. Adequate despite no output schema.
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. Description adds workflow context for confirmWrite and mentions 'merged fields' for updates/payload, but does not elaborate further on individual 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 verb 'Updates' and the resource 'BRC cash payment using merged fields', distinguishing it from create and 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step workflow: first call without confirmWrite for preview, then retry with confirmWrite only after user confirmation. Warns that preflight 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 provided, so description carries full burden. It discloses the two-step behavior, requirement for explicit user confirmation, and merged fields (partial update). Does not mention auth or rate limits, but workflow transparency is high.
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 long but each sentence adds value, especially the workflow instructions. Front-loaded with purpose. Could be slightly more concise but effective.
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 complex two-step workflow. Nested objects are documented in schema. The agent can infer behavior and requirements 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?
All 5 parameters have schema descriptions (100% coverage). The description adds crucial meaning to confirmWrite by explaining its usage in the workflow. Other parameters are adequately described in 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 updates a BRC customer using merged fields and explains the two-step confirmation process. It distinguishes from create and other sibling 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?
Provides explicit step-by-step guidance on when to call without confirmWrite first, show draft, then retry with confirmWrite true only after user confirmation. Clarifies 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?
With no annotations, the description carries full burden. It discloses the preflight confirmation behavior, but does not detail idempotency, side effects, or error states. However, the two-step workflow is well-explained, earning a high score.
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: purpose, workflow, warning. It is concise, front-loaded, and every sentence adds value 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?
Given no output schema, the description lacks details on the return structure (confirmation_required, payload preview). It mentions the preview but does not describe its contents. For a 5-parameter mutation tool, more context about outputs and field effects 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 60% (descriptions for id, companyName, confirmWrite). The description adds critical semantics for confirmWrite (explaining its boolean usage in the workflow), but does not elaborate on note and reference parameters. It adds value beyond schema but not fully comprehensive.
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 quote using structured safe text/reference fields,' specifying the verb and resource. It distinguishes from sibling tools like brc_create_quote and brc_close_quote by focusing on updates.
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 outlines the two-step process: first call without confirmWrite for preview, then retry with confirmWrite after user confirmation. It warns that 'Passing preflight is not confirmation,' providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It reveals the preflight confirmation pattern and defaulting behavior for notes. It does not mention side effects like idempotency or rate limits, but the confirmation mechanism mitigates accidental writes. Overall, good 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 yet comprehensive: two sentences that cover purpose, preflight process, and parameter nuances. No redundant or filler content. Each 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?
Given the complexity of the two-phase commit and lack of output schema, the description provides essential context about the first response (confirmation_required and preview). However, it does not describe the final successful response format. Still, it is largely complete for the expected usage pattern.
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. The description adds significant value: explains that leaving note blank defaults to customer name, details reference field relationships, and gives explicit usage for confirmWrite. This goes beyond the schema to clarify behavior and intent.
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. It also mentions 'structured safe text/reference fields', which hints at the nature of the update but does not explicitly differentiate from similar update tools like brc_update_sales_credit_note or brc_update_sales_entry. The purpose is clear but could be more 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?
Excellent usage guidance: describes a two-step process with preflight and confirmation. Explicitly states to first call without confirmWrite: true, then retry with confirmWrite: true only after explicit user confirmation. Warns that 'Passing preflight is not confirmation.' This provides clear when-to-use and when-not-to-use instructions.
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 the full burden. It thoroughly discloses behaviors: safety checks, placeholder blocking, VAT validation, priceBasis handling, CR analysis category confirmation, counterparty confirmation, note defaults, deliveryTo optionality, max items, and preflight not being 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?
The description is lengthy but well-structured, front-loaded with the purpose, and each sentence adds value. It could be more concise by grouping related rules, but given the complexity, it is appropriately detailed without 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?
The description covers most behaviors for a batch tool with complex rules, including the confirmation flow and blocking behaviors. It lacks explicit mention of the output after success, but that is partially inferred. With no output schema, it is fairly complete.
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%, yet the description adds significant meaning beyond the schema. It explains item-level fields (note, deliveryTo), the interplay between confirmWrite, confirmCrAnalysisCategory, and confirmCounterpartyExplicit, and provides context for priceBasis 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 'Processes a batch of sales invoices', which is a specific verb+resource. It distinguishes from siblings like 'brc_create_sales_invoice' (single) and 'brc_batch_sales_credit_notes' by mentioning batch-specific behaviors such as multiple customer confirmation and max items.
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 guidelines, including the confirmation flow (first call without confirmWrite, then with after user confirmation), maximum 5 items, and prerequisites like calling brc_list_products. It does not explicitly compare with other batch tools but clearly implies when to use this batch version.
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 explains the two-phase confirmation flow, constraints on analysis categories, and counterparty confirmation needs. However, it does not describe the final success response or potential errors, which is a gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence serves a purpose. It is front-loaded with the core purpose and usage patterns. Minor redundancy (e.g., 'Passing preflight is not confirmation' could be integrated) but overall 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?
Given the tool's complexity (18 parameters, three payment types, two-step confirmation), the description covers the essential workflow and constraints well. It lacks output schema details but mentions the preview response. Overall fairly complete for the complexity.
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 by explaining which parameter combinations to use for each payment type, the requirement that analysis categories be from CP01-CP03, and the semantics of confirmWrite and confirmCounterpartyExplicit. This is valuable given the tool's complexity.
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 cash payment and distinguishes among three usage patterns (supplier payment, bank lodgement, analysed expenses). This differentiates it from sibling create tools like brc_create_cash_receipt and 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?
The description provides explicit guidance on when to use each parameter combination (supplierId+ledger, bankAccountId+lodgement, analysisCategoryId+accountCode). It also details the two-step confirmation workflow and counterparty confirmation requirement, giving clear direction on how to invoke the tool correctly and safely.
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 key behavior: the two-step confirmation workflow. It does not describe other behaviors like return value types beyond mentioning 'confirmation_required and a payload preview', but this is sufficient for a delete 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?
The description is two sentences long, front-loads the purpose, and uses clear, direct language. Every part is necessary and no word is wasted.
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 delete tool with a non-trivial confirmation workflow, the description covers the essential usage pattern. It mentions the return of confirmation_required and payload preview despite no output schema. It could be slightly improved by noting that the deletion is permanent, but overall it is 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 75%, and the description adds meaningful context to the confirmWrite parameter by explaining its role in the two-step process. It does not cover confirmDelete, but the main workflow is well explained.
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 payment by id, and distinguishes itself from other delete tools by detailing a two-step confirmation process. It provides a specific verb and resource.
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 explicit step-by-step instructions on when to call without confirmWrite, to show a draft, and then retry with confirmWrite: true only after user confirmation. It also warns that preflight is not confirmation, providing clear usage boundaries.
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 exist, so the description bears full burden. It explains the two-step behavior (preflight vs. actual write) and that preflight does not constitute confirmation. However, it does not mention error handling or prerequisites like the quote needing to be closed.
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 purpose, then protocol. Every sentence adds value 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 tool's simplicity (3 parameters, no output schema), the description covers the essential workflow. It lacks some context about prerequisites or post-action results, but remains largely complete for the intended use.
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 already describes all parameters with 100% coverage. The description adds significant meaning to confirmWrite by specifying its role in the two-step protocol, which goes beyond the schema's simple boolean 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 'Reopens a BRC quote', which is a specific verb+resource pair. It distinguishes from sibling tools like brc_close_quote and brc_update_quote by indicating a distinct action.
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: first call without confirmWrite, show preview, then retry with confirmWrite after user confirmation. It also warns that preflight is not confirmation, offering 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 carries the burden of behavioral transparency. It discloses the preflight workflow, that writing only happens after explicit user confirmation, and that a plain-English draft should be shown to the user. No contradictions are present.
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 concise given the complex workflow it explains. It front-loads the main action and then provides step-by-step guidance. Could be slightly shorter, but necessary detail is present.
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 5 parameters (2 required), no output schema, and a complex interaction pattern, the description is complete. It tells the agent exactly how to handle preflight and confirmation, and covers all necessary behavioral aspects.
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 100%, so baseline is 3. The description adds significant value beyond schema for the confirmWrite parameter, explaining its usage in the two-step process and that it must only be set true after user confirmation. Other parameters are adequately described in 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's purpose: 'Updates a BRC payment using merged fields.' It uses a specific verb ('updates') and resource ('BRC payment'), differentiating it from sibling tools like brc_update_cash_payment or brc_update_purchase. The additional detail about the two-step confirmWrite process adds to 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 explicitly explains the two-step workflow: first call without confirmWrite for a preview, then after user confirmation in a later message, call with confirmWrite: true. It warns that 'passing preflight is not confirmation.' It provides clear guidance on when to use each step, though it could mention alternatives like other update tools for different 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?
No annotations provided, so description carries full burden. Discloses that updates are not immediate without confirmWrite=true, acting as a safety guard. Mentions timestamp parameter implied for optimistic concurrency. Lacks explicit statements on authentication, error handling, or idempotency, but covers key behavioral constraints adequately.
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 critical warning. Every sentence adds unique value. No filler. Front-loaded with the core action, then supporting guidance.
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, so return value is unknown, but the update flow and safety mechanism are well described. Includes prerequisite call and user confirmation requirement. Lacks error scenarios or post-update behavior, but given the tool's complexity, the description covers essential operational 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 100%, baseline 3. Description adds meaning by connecting parameters to the update flow: timestamp from brc_get_prepayment is used for concurrency, and confirmWrite must be user-verified. Also clarifies that 'id' refers to parent prepayment. This enhances understanding beyond 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 updates an existing parent Prepayment by id, distinguishing it from creating or deleting prepayments. It also specifies the scope (parent only) and prerequisite usage of brc_get_prepayment, which clarifies the resource and action.
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 retrieve the prepayment via brc_get_prepayment, implying a two-step process. Warns against calling with confirmWrite=true until user confirmation, providing clear usage boundaries. Also notes child prepayments are inaccessible through public API, preventing misuse.
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-phase commit behavior and the need for a plain-English draft before finalizing. While annotations are missing, the description covers key behavioral traits. Lacks details on destuctiveness or permissions, but sufficient 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?
Single paragraph that efficiently packs essential information. Could be slightly more concise, but no superfluous text. Front-loaded with the main action.
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 two-phase workflow and 5 parameters, the description fully explains the process, including what the first call returns (confirmation_required and payload preview). Without an output schema, this is adequate for the agent to invoke 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 covers all parameters, but description adds crucial context: explains the conditional confirmWrite workflow and clarifies that 'payload' is an alias for 'updates'. Baseline 3 is elevated because description adds meaning 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 'Updates a BRC supplier using merged fields.' It identifies the specific resource (supplier) and action (update), distinguishing it from other update tools like brc_update_customer or 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 guidance: first call without confirmWrite, show draft, then retry with confirmWrite true only after explicit user confirmation. Warns that 'Passing preflight is not confirmation,' which prevents misuse.
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 the description discloses the two-step confirmation workflow, including the return of a 'confirmation_required' response and a payload preview. It also clarifies that passing preflight is not confirmation. However, it does not detail error conditions or side effects 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?
The description is concise (three sentences) and front-loaded with the core purpose. Every sentence provides 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?
The description covers the confirmation workflow and key parameters. However, it lacks details about the output of the second call (e.g., success response or errors). Given no output schema, this would be helpful for the agent to understand the result.
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% with descriptions for all parameters. The description adds significant context beyond the schema: it explains the confirmWrite parameter's required usage pattern, the confirmCrAnalysisCategory parameter's purpose for CR analysis account confirmation, and the priceBasis parameter's condition and meaning (net vs gross).
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 products' and specifies the maximum batch size (5 items). It distinguishes itself from sibling tools like brc_create_product by handling batches and requiring a confirmation step.
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 the agent to first call without confirmWrite to get a preview, then retry with confirmWrite: true only after explicit user confirmation. Warns against setting confirmWrite on the first call or assuming preflight is 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?
Given no annotations, the description fully explains the two-call protocol, confirmation flags, and pitfalls. It does not explicitly state that the tool writes a record to the database or mention reversibility, but the creation nature is implied. Good transparency for a complex 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 lengthy but each sentence serves a purpose. It front-loads the core purpose and then details usage guidelines. A bit verbose but justified by the complexity of the tool. No wasted 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 the complexity (5 parameters, nested payload, no output schema), the description covers all necessary aspects: prerequisites, confirmation flags, preflight protocol, and common mistakes. It is complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (high), but the description adds critical meaning beyond the schema: it explains the hidden requirements inside the payload object (saleRepId, saleRepCode, analysisCategoryId, accountCode), the two-call protocol for confirmWrite, and the semantics of confirmCrAnalysisCategory and confirmCounterpartyExplicit. This adds significant 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 credit note with auto-generated reference using raw payload. It differentiates from the sibling tool 'brc_create_sales_credit_note' by specifying auto-generated reference, and the sibling list confirms both exist.
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: 'when company is configured for auto-generated sales references'. Provides thorough prerequisites, warnings against default/demo values, and detailed multi-step confirmation process. Clearly differentiates from preflight and write calls.
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 confirmation flow, the preview, and the requirement for explicit user confirmation. However, it does not explicitly state irreversible nature or success effects, though implied.
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 front-loaded with the core purpose, followed by step-by-step instructions. Every sentence is necessary and well-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 no output schema, the description fully covers the workflow, including the confirmation requirement, preview, and preflight warning. It is complete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), so baseline 3. The description adds significant context for confirmWrite parameter (first call false, then true after confirmation) and clarifies the two-step behavior beyond the schema's minimal 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 verb 'Deletes' and the resource 'BRC bank account by id'. It is specific and distinguishes from sibling delete tools by focusing on 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Only call this after the user has explicitly confirmed deletion.' Provides a two-step process with first call without confirmWrite and second call after confirmation, and warns against using preflight 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?
With no annotations, the full burden is on the description. It thoroughly explains the two-step behavior, the necessity of user confirmation, and the preview feature. It doesn't mention error states or impacts of deletion, but the core behavior is well-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, no unnecessary words. Front-loaded with the core action, then immediately provides step-by-step instructions. Every sentence serves a purpose.
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 complexity of a two-step deletion with confirmation, the description is remarkably complete. It covers the full workflow, the role of confirmWrite, and the need for explicit user confirmation. No output schema exists, but the preview step is implied.
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% (3 of 4 params described). The description adds significant value for 'confirmWrite' by explaining its two-step usage. Other parameters' descriptions are sufficient in the schema, and the description does not repeat them unnecessarily.
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 cash receipt by id.' It also details the two-step confirmation process, distinguishing it from other delete tools in the sibling list that may not require such confirmation.
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 to first call without confirmWrite, show the preview draft in chat, and retry with confirmWrite true only after explicit user confirmation. It also warns that preflight is not confirmation, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains what the tool returns (setup steps and example prompts). Could be improved by explicitly stating it has no side effects or is read-only, but it's clear enough for this 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?
Two sentences, front-loaded with trigger conditions and return value. No unnecessary words. Every sentence adds value.
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, no output schema, and low complexity, the description is complete. It covers all needed context: triggers, output content, and differentiation from siblings.
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 in input schema; schema coverage is 100%. Baseline is 4. Description adds context about when to use but doesn't need to describe 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 specifies the tool's purpose: to be used when the user asks 'how to start', 'start', 'getting started', or general help using Big Red Cloud. It states it returns setup steps and example prompts, and distinguishes from sibling brc_get_deployment_policy for permission queries.
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 (user asks for help getting started) and when not to use (if user asks about permissions, call brc_get_deployment_policy instead). Provides a clear alternative tool name.
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: returns a one-time URL, no expiry but single use, user enters info on secure page not in chat, and must provide confirmation code afterward. It doesn't mention side effects or failure modes but 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 concise (6-7 sentences) with no wasted words. Each sentence adds value, and the flow is logically structured and front-loaded.
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 simple tool with no parameters or output schema, the description covers purpose, usage flow, security guidance, and post-action steps. It is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters (0 params, 100% coverage), so baseline is 4. The 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 starts a secure company connection flow and when to use it (whenever user wants to connect companies). It distinguishes from sibling tools like brc_confirm_company_connection by describing the full flow.
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.' Provides when-not-to-use: 'Do not ask the user to type credentials into chat.' Also explains the follow-up action (provide confirmation code) and alternative 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?
No annotations provided, but the description fully discloses the tool's behavioral traits: two-phase confirmation, return of confirmation_required and payload preview on first call, need for explicit user confirmation, and prohibition of reusing counterparty without explicit confirmation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the tool's purpose, then details the workflow. Every sentence adds value without redundancy. Highly concise and 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?
Given the complexity (15 parameters, no output schema, no annotations), the description covers the key workflow and constraints. It explains the two-phase confirmation and counterparty confirmation, which are the most complex aspects. It does not detail other standard parameters (e.g., netAmount, vatRateId) but the agent can infer from names. Overall, it provides sufficient context for correct tool 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 description coverage is low (20%), but the description adds critical semantic context for the two boolean parameters (confirmWrite, confirmCounterpartyExplicit), explaining their usage rules in the workflow. For other 12 parameters, no additional meaning is provided beyond schema names/types. However, the workflow context for the booleans is essential and compensates somewhat.
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. It distinguishes itself from numerous sibling tools like brc_create_sales_invoice, brc_create_sales_credit_note, etc., by specifying the exact resource (sales entry) and the unique two-phase 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step guidelines: first call without confirmWrite: true yields preview, then retry with confirmWrite: true only after explicit user confirmation. Also requires confirmCounterpartyExplicit: true after user explicitly names counterparty. Clearly states when not to use (e.g., not on first call, not without explicit confirmation) and distinguishes from passing preflight.
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: productId 0/1 are blocked at runtime, purchase VAT rates are blocked, first call returns confirmation_required with payload preview, requires confirmCounterpartyExplicit, and addresses gross price entry behavior. All critical behaviors are transparent.
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 long and dense, lacking section breaks. While all information is valuable, it could be more concise. For a tool with 26 parameters, the length is somewhat justified, but improvement in structure would enhance readability.
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 high complexity (26 params, no output schema), the description is remarkably complete. It covers prerequisites, workflows, confirmation steps, relationships with other tools (brc_list_products, brc_list_sales_reps), and edge cases. It even instructs on what to do when no suitable product exists. Only missing detail is the return value after posting, but that is acceptable without an output schema.
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 54%, and the description adds significant meaning beyond the schema. It explains constraints for note (default to customer name), deliveryTo (do not invent), priceBasis (required when Gross Price Entry enabled), confirmWrite (never true on first call), and clarifies that productId 0/1 are placeholders blocked at runtime.
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 sales invoice using structured MCP fields.' It differentiates from the sibling brc_create_sales_invoice_gen_ref by specifying when each should be used (manual vs automatic reference generation). The verb 'creates' and resource '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?
Extensive guidance on when to use this tool vs alternatives (e.g., prefer gen_ref when manual references not needed). Includes many 'do not' instructions (invent values, use default sales rep, default analysis category) and explicit workflow steps (first call without confirmWrite, show draft, retry with 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, description carries full burden. It fully discloses supported document types, confirmation requirement, missing email handling, multiple recipient options, and instructs agent to stop without workarounds for unsupported types. 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?
Approximately 150 words, front-loaded with main purpose then detailed instructions. Every sentence adds value given the tool's complexity (confirmation, multiple recipients). Could trim slightly but well-structured.
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 essential aspects: supported document types, confirmation flow, handling missing email, multiple recipients, BCC vs separate. Missing return value info but no output schema exists. Complete for a send-email tool with workflow dependencies.
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 already present. The description adds operational context beyond schema, e.g., 'Only use sendMode="separate" when the user explicitly chooses separate emails' and detailed flow for confirmSend and toAddresses. Slightly above baseline due to added workflow 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?
Clearly states 'Sends a sales invoice email' and then specifies supported document types (sales invoices, quotes, customer statements) and explicitly lists unsupported types, distinguishing it from sibling tools like brc_send_quote_email and brc_send_email_statement.
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 when-to-use guidance: lists supported types, instructs agent to stop and list supported types for unsupported requests, details confirmation workflow (check draft, confirm send), handling missing email addresses, and BCC vs separate email choice. Explicitly says 'do not call with confirmSend=true until user confirmed'.
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, description fully discloses behavior: runtime blocking of placeholder productIds, preflight return of confirmation_required and payload preview, requirement for explicit user confirmation, and constraints on counterparty reuse. 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?
Single paragraph is effective and front-loaded, but could be slightly improved with bullet points or section breaks for easier scanning. No redundant sentences, every sentence adds value.
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?
Despite no output schema and nested items, description covers all necessary context: workflow, validation rules, parameter usage, and expected responses. Leaves no obvious gaps for typical usage scenarios.
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 description adds significant meaning: explains when and how to set confirmWrite and confirmCounterpartyExplicit, details priceBasis usage for gross/net, and clarifies the confirmCrAnalysisCategory parameter context. Adds 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?
The description clearly states the tool processes a batch of sales credit notes, with specific verb and resource. It distinguishes from siblings by detailing unique validation rules and confirmation workflow, not seen in other tool descriptions.
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 guidance: use brc_list_products to get real productIds, do not invent or use placeholder IDs, maximum 5 items, two-stage confirmWrite process with preflight, and counterparty confirmation requirements. Clearly differentiates from alternatives.
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?
Despite no annotations, the description fully discloses the destructive nature, the two-phase process (preview then confirm), and the necessity of user confirmation. Adds critical 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 clear and informative, though slightly verbose for a two-parameter tool. The step-by-step structure justifies the length for a destructive operation.
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 no output schema and two optional parameters, the description covers all necessary context: the preflight/preview behavior, the need for confirmation, and parameter usage. 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?
Schema coverage is 100% with descriptions, but the tool description adds significant semantics: explains the role of confirmWrite in the two-step confirmation flow and that confirmWrite must only be true after explicit user confirmation.
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 'Clear the Red audit log for this MCP server session,' specifying the action, resource, and scope. It distinguishes 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?
Provides explicit step-by-step instructions: first call without confirmWrite to get preview, then retry after user confirmation. Explains that passing preflight is not confirmation and sets clear conditions for setting confirmWrite 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 two-step creation process, that passing preflight is not confirmation, and the need for explicit counterparty confirmation. This makes the behavioral expectations clear.
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 paragraph, front-loaded with purpose, then explains two paths and confirmation process. Every sentence is necessary and informative without being verbose.
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 17 parameters and no output schema, description covers usage well but lacks details about return values (e.g., what the payload preview contains, what a successful response includes). Slightly incomplete for a complex tool.
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?
Adds meaning beyond schema: explains the relationship between supplierId and analysisCategoryId+accountCode, details confirmation parameters, and notes that analysis categories must be from BP01-BP06. Schema coverage is 65%, but 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?
The description clearly states it creates a BRC payment from the Payments book, specifying the resource and action. It distinguishes between supplier payments and analysed bank payments, differentiating from sibling tools like brc_create_cash_payment and brc_create_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?
Explicit guidelines are given: use supplierId for supplier payments or analysisCategoryId + accountCode for analysed bank payments. The two-step confirmation process is detailed, including not setting confirmWrite on the first call and requiring explicit user confirmation. Also explains confirmCounterpartyExplicit requirement.
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 fully carries the burden. It accurately discloses the two-phase behavior (preview then write) and the requirement for explicit user confirmation. This is transparent and prevents misuse.
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 earning its place: first states purpose, second explains the two-step process, third reinforces the confirmation requirement. No fluff.
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 no output schema, the description mentions return of confirmation_required and preview, which is sufficient. The tool's complexity is moderate and the description covers all necessary context for 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?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning for the confirmWrite parameter by explaining its role in the workflow (preview vs. actual creation), which goes beyond the schema's 'Must be true only after...' explanation.
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 from many sibling tools focused on other operations (create/update/list) by being the only one that generates an invoice from a quote with a two-phase workflow.
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: first call without confirmWrite for preview, then retry with confirmWrite: true only after user confirmation. It also warns that 'passing preflight is not confirmation,' leaving no ambiguity about 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It comprehensively discloses behavior: only sends statements, requires explicit user confirmation before sending, requires recipient email, handles multiple recipients with BCC/separate, and warns against drafting for unsupported types. Covers edge cases thoroughly.
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 verbose but each sentence serves a purpose. Front-loaded with core action. Could be slightly more concise, but complexity of tool (12 params, multiple conditional flows) justifies length. Good structure with explicit steps and conditions.
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 12 parameters, 2 required, no output schema, and sibling email tools, this description fully equips the agent. Covers all edge cases: unsupported types, confirmation, recipient handling, BCC/separate logic. No significant gaps remain.
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% description coverage, but description adds significant context beyond schema: explains conditional logic for sendMode (only separate if user explicitly chooses), confirmSend must be true only after review, toAddresses and bccAddresses usage with BCC logic. Adds semantic value for agent decision-making.
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 sends customer statement emails, lists supported document types (only statements), and explicitly distinguishes from siblings like brc_send_quote_email and brc_send_sales_invoice_email by detailing unsupported document types.
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 (statements), when-not-to-use (unsupported types like cash receipts, purchases, etc.), and precise instructions for handling unsupported types (say cannot, list supported, stop). Also clarifies confirmation flow, multiple recipient handling, and BCC vs separate emails.
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 discloses the two-phase commit behavior: first call returns a payload preview, requires user confirmation before setting confirmWrite. Warns that preflight is not confirmation. No annotations, so description carries full burden and meets it.
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?
Description is concise with three key sentences plus parameter details. Front-loaded with main action and confirmWrite pattern. No wasted 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 usage and parameters well, but lacks description of successful response beyond confirmation_required mention. Given no output schema, a brief note on what a successful update returns 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?
Adds significant meaning beyond schema: explains note default behavior (customer name, not product name), reference defaulting to 'Our Ref' and 'Your Ref', and precise confirmWrite usage rules. Schema coverage is 100% but description provides extra 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 updates a BRC sales entry with specific fields (note, reference). It distinguishes from siblings like brc_update_sales_invoice by specifying the resource and the safe text/reference fields.
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 call without confirmWrite to get a confirmation required response, show a draft, then retry with confirmWrite only after explicit user confirmation. Also provides rules for when to set note and reference 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?
Since no annotations are provided, the description fully discloses the two-phase confirmation behavior, the need for explicit user confirmation for writing and counterparty, and warns against reusing counterparties from earlier drafts. This goes beyond schema details.
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 yet comprehensive, with every sentence providing essential information. It is front-loaded with the main action and efficiently covers all critical behavioral aspects without redundancy.
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 parameters, 2 required, no output schema), the description thoroughly explains the entire workflow, including batch limits, confirmation flags, counterparty requirements, and the draft preview step, making it complete for agent use.
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 schema has 100% description coverage for all 6 parameters, but the description adds workflow context for confirmWrite and confirmCounterpartyExplicit, explaining the two-step process and the requirement for explicit user confirmation, enhancing 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 'Processes a batch of purchases' with a specific verb and resource, and distinguishes it from sibling batch tools like brc_batch_sales_invoices by mentioning purchases and the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to first call without confirmWrite: true to get a preview, then retry with confirmWrite: true only after user confirmation. Also requires confirmCounterpartyExplicit: true once the user explicitly names the counterparty, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 MCP server](https://glama.ai/mcp/servers/BigRedCloud/red-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/BigRedCloud/red-mcp-server)

Score Badge

Copy to your README.md:

[![red-mcp-server MCP server](https://glama.ai/mcp/servers/BigRedCloud/red-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/BigRedCloud/red-mcp-server)

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/BigRedCloud/red-mcp-server'

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