Server Quality Checklist

Tool Scores

• delete_budgetC
  2.4/5.0
  Behavior2/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. 'Delete' implies destructive behavior, but nothing states whether deletion is permanent/irreversible, cascading effects on associated budget reports, or any confirmation requirements. This is a mutation tool with zero behavioral disclosure.

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

  Conciseness3/5

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

  The description is extremely short — essentially the minimum. While it is concise, the bulk is a docstring-style restatement of the parameter already in the schema. It's not wasteful, but it's under-specified rather than 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?

  For a destructive operation with no annotations, no behavioral detail, and 0% schema coverage, the description should do substantially more. It lacks return-value expectations, error conditions, and side effects. Despite having an output schema, the delete tool still needs more operational context.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only restates 'name: Budget name' which adds minimal value over the schema's type: string. It does not explain name format, uniqueness constraints, case sensitivity, or what happens if an invalid name is given.

  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 'Delete a budget' which is a clear verb+resource. However, it does not distinguish from siblings like delete_customer, delete_vendor, delete_invoice, etc. — though the name itself provides that differentiation. The purpose is clear but 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?

  There is no guidance on when to use this tool vs alternatives. While delete operations are fairly self-explanatory, no context is given about prerequisites (e.g., whether a budget must not be active, whether deletion is permanent), and no mention of alternatives when a budget should be retained or archived.

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

• update_vendorC
  2.9/5.0
  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 of behavioral disclosure. It does mention that 'active' deactivates/reactivates and notes clearing behavior via empty string, but it doesn't disclose whether changes are reversible, what happens to unmentioned fields (presumably preserved), whether id lookup fails loudly, or what the response is. For a mutation tool with zero annotation coverage, this is a significant gap.

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

  Conciseness4/5

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

  Effectively front-loaded: the tool purpose appears in the first line, followed by a compact args list. Every line earns its place. The reference to update_customer is efficient but slightly lazy. Slightly verbose with the blank lines and 'Args:' label, but overall clean and readable.

  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?

  This is a mutation tool with no annotations and an output schema present. The description covers each of the 6 parameters at least minimally. However, it's a write operation with 6 parameters, no annotation coverage, and heavy reliance on a sibling tool's documentation for the address structure. For a mutation tool of this complexity, it should state prerequisites (vendor existence), idempotence, or error behavior. Adequate but leaves meaningful 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 description coverage is only 17%, so the description must compensate. It does describe each parameter concisely (id, name, currency, notes, active, address). The notes and active semantics are useful and go beyond schema. However, it relies on external reference for 'address' details, and the schema itself provides some structure. The description adds moderate value but doesn't fully cover the 83% undocumented space.

  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 'Update an existing vendor' with a specific verb and resource. It adds parameter semantics for each field. However, it relies heavily on referencing 'update_customer' for address details rather than fully standing alone, and doesn't distinguish this from update_employee (siblings exist for both). The purpose is clear but sibling differentiation 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?

  There is no guidance on when to use this tool vs alternatives like create_vendor, delete_vendor, or update_customer. The reference 'Same semantics as update_customer' is helpful but doesn't establish when a user would choose update_vendor over other operations. No exclusions or prerequisites (e.g., vendor must exist) are stated.

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

• get_accountB
  3/5.0
  Behavior1/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states what the tool returns implicitly ('Get details') but doesn't disclose whether this is read-only, what data shape is returned beyond what the output schema provides, whether it raises errors for nonexistent accounts, or any edge-case behavior. For an unannotated tool, this is a significant gap.

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

  Conciseness3/5

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

  The description is compact and front-loads the purpose in the first sentence. However, the 'Args:' section with a single parameter is slightly redundant structure given there's only one param; it adds formatting overhead rather than semantic value. Still, it's efficient overall with little waste.

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

  Completeness3/5

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

  Given that an output schema exists and this is a simple single-parameter read operation, the description doesn't need to explain return values. It covers the purpose and the param formats adequately. However, with no annotations, it could usefully state read-only behavior or error conditions (e.g., what happens on nonexistent accounts). For a simple lookup tool, this is minimally adequate but not complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate, and it does. The param description explains the three accepted name formats (full path like 'Assets:Bank:Checking', %short GUID, or full 32-char GUID), which adds substantial meaning beyond the bare schema field labeled 'name'. This is genuinely useful semantic content.

  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 'Get details for a specific account by name' with a specific verb (Get) and resource (account details). It distinguishes from siblings like list_accounts and get_balance, though it doesn't explicitly reference sibling alternatives. The %short GUID and full 32-char GUID formats add useful specificity.

  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 context (looking up a specific account by name/ref/GUID) but doesn't explicitly disambiguate from siblings like list_accounts or get_balance. The param description does clarify the name format options, which is helpful, but there are no explicit when-to-use vs. 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.

• create_lotB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. For a create operation, it doesn't state whether the account must already exist, whether creating is reversible/deletable, what happens with duplicate titles, or what the response contains. Given the output schema is present, return-value details are somewhat covered, but durability and constraint behavior are unaddressed.

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

  Conciseness4/5

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

  The description is moderately sized and reasonably structured: a one-sentence purpose, a brief conceptual explanation, then a clear Args section. The account format detail is valuable, but the two-sentence conceptual preamble about cost basis could be trimmed slightly since much is implied by the tool name domain.

  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 this is a create operation with no annotations, an output schema present, and 3 params at 0% schema coverage, the description covers the key conceptual background and account format details well. However, it's incomplete on behavior (uniqueness constraints, reversibility, required account existence) and glosses over the 'notes' parameter. Adequate but has clear 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 description coverage is 0%, meaning the description must explain parameters. It does explain 'account' in detail (accepted ref formats: full path, %short GUID, full 32-char GUID) and gives a concrete example for 'title'. However, 'notes' receives only a terse 'Optional notes' with no elaboration. The account explanation is genuinely useful, but notes could use more context.

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

  Purpose4/5

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

  The description clearly states the verb + resource: 'Create a new lot for cost basis tracking.' It further explains what lots do ('group investment purchases for tracking cost basis and calculating capital gains when selling'). It distinguishes this as a create operation among lot siblings (list_lots, get_lot, close_lot, calculate_lot_gain), though it doesn't explicitly name them.

  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 provides background on what lots are for (tracking cost basis, calculating capital gains when selling), implying when you'd create one. However, it doesn't explicitly state when to use this vs alternatives like assign_split_to_lot or close_lot, nor does it mention any prerequisites (e.g., account must exist).

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

• net_worthB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation formula (assets minus liabilities) but doesn't disclose edge behaviors like handling of missing accounts, currency considerations, whether unrealized gains are included, or how empty books are handled.

  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 clear sectioning and parameter docstring format. It's front-loaded with the core definition. Slightly longer than ideal but every line earns its place explaining distinct functionality.

  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 an output schema present, the return-value burden is reduced. The tool has moderate complexity (two modes, three parameters) and the description covers the parameter surface well. It lacks clarity on when this tool is preferable to sibling reporting tools, but is otherwise complete for its 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 description coverage is 0%, so the description must carry full parameter meaning. It does this well: end_date (as-of date), start_date (optional time-series start), interval (month/quarter/year options). All three parameters are explained with format and 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 clearly states the verb (calculate) and resource (net worth = assets minus liabilities), and distinguishes between single-point and time-series modes. It doesn't explicitly contrast with sibling tools like balance_sheet or get_balance, but the resource concept is clearly defined.

  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 explains the date/interval parameters for controlling the calculation mode but doesn't say when to use this tool vs alternatives like balance_sheet, get_book_summary, or cash_flow. No exclusions or alternative tool references are provided.

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

• create_employeeB
  3.3/5.0
  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 discloses that currency defaults to the book's default and that address sub-fields are capped at 1024 characters, both useful. However, it doesn't describe what gets created/what the response returns, whether the employee is saved immediately (auto-backup implications), or any permissions/limits. The 1024 cap note is useful but largely duplicated in the input schema definition.

  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?

  Well-structured with a clear block per parameter and a tight lead line. The notes-field contrast sentence earns its place. Slightly verbose in repeating the 1024 cap that already appears in the schema, but overall efficient with no wasted sentences.

  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 this is a mutation tool with no annotations and no output schema return-value explanation, the absence of info about what the response looks like (returned employee object?), persistence semantics, and interplay with list_employees is a gap. The address shape clarification and currency defaulting help, but the description doesn't fully prepare an agent for a create operation on a real financial book.

  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 0%, so the description must compensate. It adds meaning for all 3 parameters: name gets an example format, currency gets ISO code semantics plus the default-to-book-currency behavior, and address gets explained as optional with the exact expected keys and the 1024-char cap. This adds value beyond the bare schema, though the sub-field details largely parallel the $defs definition already embedded 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 uses a specific verb+resource ('Create a new employee') and clearly distinguishes from siblings by contrasting Employee with Customer/Vendor (no notes field). Purpose is clear, though it could note the parent relation to siblings more explicitly.

  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 when-to-use or when-not-to-use guidance. It mentions the address shape is identical to Customer/Vendor and notes the absence of a notes field, implying comparison with siblings, but doesn't say when to prefer this over, say, create_vendor or create_customer, nor any prerequisites (e.g., currency must exist in book).

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

• delete_account_slotB
  3.3/5.0
  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 doesn't mention whether removal is permanent, whether an error occurs if the slot doesn't exist, or any prerequisites. For a destructive operation this is a notable 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 concise with an opening one-line purpose statement followed by structured parameter descriptions. It's efficient and front-loaded with the key action. Could be argued it's slightly under-specified but overall 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 simple 2-parameter tool with an output schema present, the description covers the essentials. The account parameter addressing formats are well documented, which is often a tricky area. However, for a destructive operation with zero annotations, the lack of behavioral notes about error handling or reversibility leaves it slightly incomplete despite the output schema.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It does a good job: it explains the account parameter accepts full paths, %short GUIDs, or full GUIDs, which is meaningfully beyond the schema's bare 'string' type. The key parameter is described as 'Slot key to remove' but could use more detail on format.

  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+resource combination: 'Remove a custom metadata slot from an account.' This clearly states what the tool does. It distinguishes from related siblings like get_account_slots and set_account_slot by using the 'Remove' verb, though it doesn't explicitly name them.

  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 provides context about what it does (removing a metadata slot) which implies usage for cleaning up account metadata. However, there's no explicit when-to-use or when-not-to-use guidance, nor alternatives named. The usage is clear from context but not spelled out.

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

• create_vendorB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. As a creation tool, it implicitly mutates state, but it doesn't disclose what happens on success (returned vendor object?), whether duplicates are detected, whether the currency default behavior is visible, or whether prerequisites exist (e.g., book must be active). The description mentions currency defaults to book's default, which adds some value, but overall behavioral context is thin.

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

  Conciseness4/5

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

  The description is reasonably structured with an Args section and clear parameter bullets. It's efficient with no wasted words, though the parameter enumeration duplicates somewhat what the schema already shows. The address sub-field listing is duplicated with the schema definition, but it's brief enough to be acceptable.

  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 creation tool with an output schema present, the description doesn't need to explain return values, which helps. However, it doesn't address key create-operations concerns: duplicate name handling, required-field behavior, whether the new vendor is immediately usable, or whether deletion consequences exist. The address complexity is well-documented, but the overall tool is only partially contextualized.

  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 25% (only name and notes have descriptions in the schema; currency and address are bare). The description adds useful meaning for name (example 'Office Depot'), currency (defaults to book's default), notes (max 4096 chars), and address (enumerates sub-fields and caps). This compensates for the low schema coverage partially, but no mention of required-name constraint or currency format validation beyond an example.

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

  Purpose5/5

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

  Description states 'Create a new vendor' with a clear verb+resource pairing. It distinguishes itself from siblings like update_vendor, delete_vendor, list_vendors, and get_vendor by the create verb. The tool clearly represents a creation operation distinct from the many related vendor/customer/employee 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 purpose is clear as a create operation, but there is no explicit guidance on when to use this vs alternatives or when not to use it. No mention of required fields, unique constraints, or scenarios where one might prefer update_vendor. Usage context is implied by the verb but no exclusions or prerequisites are stated.

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

• delete_employeeB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It does add meaningful context (unconditional deletion after slot cleanup, no associated documents in 1.3.0). However, it doesn't explicitly state the destructive/irreversible nature of the operation, which is significant for a delete 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 compact and front-loaded, with the core action in the first line. The Args section is appropriately placed at the end. No wasted words, though the release-version detail could arguably be trimmed.

  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 single-parameter delete tool with an output schema present, the description covers the essentials: what it does, the parameter format, and the unconditional behavior. It lacks explicit warning of destructive consequences, but given the tool name itself strongly signals deletion, this is a minor gap.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. It documents the employee_id parameter with an example format ('000001'), which adds value beyond the bare schema. However, there's only one parameter, so the description's single arg note is adequate but 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?

  The description clearly states the action ('Delete an employee') with a specific resource, and provides useful context about the 1.3.0 release having no associated documents. It distinguishes from siblings like update_employee and create_employee through the delete verb and the unconditional-proceed behavior.

  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 that deletion proceeds unconditionally after slot cleanup, which implies there are no prerequisites or safety checks. However, it does not explicitly state when to use this vs alternatives, nor does it mention that this is irreversible or destructive.

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

• move_accountB
  3.4/5.0
  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's clearly a mutation tool, and the description is honest about the operation. However, it doesn't disclose edge-case behaviors such as what happens to the account's transactions, whether the account GUID changes, child accounts' paths, or any hierarchy-cycle restrictions. For a mutation with no annotations, more behavioral disclosure is warranted.

  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 and front-loaded with a clear one-sentence purpose, followed by a scannable Args list documenting accepted reference formats. No wasted words. Could argue for slightly more content on behavior, but as written it's tight 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?

  Has an output schema that presumably documents return value, so description needn't cover that. With 2 params and no annotations, description does reasonably document parameter formats. However, it leaves open important operational questions for a hierarchy-mutation tool (cycle prevention, descendant reparenting, transaction preservation) that reduce completeness for safe invocation.

  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 0%, so the description must compensate. The Args section documents both parameter formats (full path, %short GUID, or full 32-char GUID), which is genuinely useful and adds meaning beyond the bare schema field names. However, it doesn't clarify semantics like whether 'name' is the current path before or after move, and doesn't explain expected new_parent format beyond reuse of the same reference formats.

  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 (Move) + resource (account) + effect (to a new parent in the hierarchy). It's distinct from update_account and delete_account siblings. However, it doesn't explicitly state scope limits like whether the move preserves children or affects descendant 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?

  The description establishes clear context (moving accounts in hierarchy) and documents the two reference formats for both parameters in the Args block, which aids selection. However, it provides no when-not-to-use guidance or alternatives, and doesn't mention prerequisites (e.g., whether target parent must exist, whether moving to a descendant is prohibited).

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

• unvoid_transactionB
  3.4/5.0
  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 two behaviors: restoring original split values and removing void markers. However, it doesn't mention whether the operation is idempotent, what happens if the transaction isn't voided, or whether it modifies accounting state irreversibly. For a mutation tool, it does disclose the core destructive behavior reasonably 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?

  Concise single-paragraph description with a brief Args section. No wasted words, but the Args repetition of schema info is slightly redundant. Front-loaded with the action and effect, which is good practice.

  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 single-parameter mutation tool with full schema coverage and an output schema present, the description covers the essential semantics: what it does and what it changes. However, some edge-case behavior is undocumented (e.g., behavior when transaction isn't voided, empty GUID handling). Given the tool's simplicity, this is adequate but not rich.

  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% - the single 'guid' parameter is fully described in the schema as 'Transaction GUID (32-char hex or 8+ char prefix)'. The description repeats this same information in the Args section, adding no value beyond the schema. Baseline 3 applies since schema does all the work.

  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 restores a voided transaction, restores original split values, and removes void markers. The verb 'Restore' plus the resource 'voided transaction' makes the purpose clear. It doesn't explicitly differentiate from the sibling void_transaction, but the inverse relationship is implied by the name and description.

  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 this is the inverse of void_transaction and should be used when a transaction was voided and needs restoring. However, it doesn't explicitly state when to use this vs alternatives, doesn't mention prerequisites (e.g., transaction must be voided first), or note any conditions that would make the operation fail.

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

• create_transaction_from_scheduledA
  3.5/5.0
  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 a transaction is created from a template and that transaction_date defaults to next occurrence, which adds useful behavior context. However, it doesn't clarify whether the scheduled template is consumed/deleted after creation, whether it can be invoked repeatedly, or what side effects occur on the schedule.

  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 a clear Args section, front-loading the purpose. Two parameters documented in a readable format. Slight redundancy exists where the description's Args section largely mirrors the schema, but the length is appropriate and every line contributes.

  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?

  This is a state-changing creation tool with no annotations, but it has a basic output schema. The description covers the essential mechanics (what it creates, date defaulting) but omits important context like repeated-invocation behavior, side effects on the scheduled template, and whether the transaction is immediately posted or created as draft. For a mutation tool, more behavioral detail would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 50% (guid documented in schema, transaction_date not). The description adds the default behavior of transaction_date ('Defaults to next occurrence'), which goes beyond the schema's bare 'Date for the transaction'. It also adds the GUID prefix flexibility hint in the Args section, though the schema already covers this. The transaction_date semantics beyond what the schema states is the key added value.

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

  Purpose4/5

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

  The description uses a specific verb+resource ('Create an actual transaction from a scheduled template'), clearly distinguishing it from siblings like create_scheduled_transaction, update_scheduled_transaction, and the main create_transaction. The purpose is clear and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies its use context (materializing a scheduled transaction into an actual transaction) versus siblings like create_scheduled_transaction or list_scheduled_transactions, but doesn't explicitly state when-not-to-use or name alternatives. It doesn't explain the workflow relationship between scheduled templates and actual transactions.

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

• get_lotA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided (readOnlyHint, destructiveHint, etc.), so the description carries the full burden of behavioral disclosure. The description explains the return value structure well (splits with date/quantity/value, summary fields) which gives some transparency. However, it doesn't explicitly state that this is a read-only operation (non-destructive), or disclose any auth requirements, or clarify what happens with an invalid/nonexistent GUID. For a read operation, this is somewhat sufficient but could state safety explicitly.

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

  Conciseness4/5

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

  The description is reasonably concise and well structured. It front-loads the purpose statement, then documents the parameter, then enumerates the return fields in a clear bulleted format. Every sentence earns its place, though the parameter line duplicates schema information. The return section uses 'Returns:' leading with the general description, which is clean and scannable.

  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 an output schema present and 100% schema coverage on the single parameter, this tool is relatively simple and the description covers it well. Return values are documented (title, notes, splits, summary). The description is complete for a single-read tool with well-defined output. It would benefit from noting it's a safe/read operation, but given the simplicity and output schema, coverage 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 description coverage is 100% — the single parameter 'guid' is already documented in the schema as 'Lot GUID (32-char hex or 8+ char prefix)'. The description adds marginal value by repeating 'Lot GUID (or 8+ char prefix)' in the docstring, essentially matching the schema. This is redundant rather than additive, so it stays at 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 'Get detailed information about a lot' with a specific verb (get) and resource (lot). It lists the return structure explicitly, distinguishing it from related tools like list_lots (list vs get a single lot). However, it doesn't explicitly name sibling alternatives like list_lots for when to use each, so it stops short of a 5.

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

  Usage Guidelines3/5

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

  The description implies usage by describing what it returns (detailed lot info including splits), which suggests when to use it (when you need split-level and summary details of a specific lot). However, it doesn't explicitly state when NOT to use it vs alternatives like list_lots (for browsing lots) or calculate_lot_gain (for gain calc) or get_prices. Usage context is implied but no exclusions or alternatives are named.

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

• get_transactionA
  3.5/5.0
  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. The description discloses this is a read-only retrieval operation implicitly via 'Get details', which is helpful. However, it doesn't describe the return format/shape of the response or whether a missing GUID returns an error vs empty result. The presence of an output schema partially mitigates return-format concerns, but error behavior is undisclosed.

  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 - one purpose sentence plus a brief Args block. The Args section repeats schema info, which is somewhat redundant, but overall it's efficient and front-loaded with the core purpose statement. No wasted prose.

  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 single-parameter read tool with a provided output schema, the description is largely adequate. The GUID prefix-search capability is a valuable detail unique to this tool. The main gap is absence of explicit read-only disclosure given no annotations, but with the output schema covered and one simple parameter, this tool needs minimal additional context beyond what's provided.

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

  Parameters3/5

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

  Schema description coverage is 100% - the schema fully documents the guid parameter including the format (32-char hex or 8+ char prefix). The description repeats the same information in the Args section, adding no value beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting; the description's Args note about 8+ char prefix is a minor helpful addition.

  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 'Get details for a specific transaction by GUID' - a specific verb+resource pairing that clearly distinguishes this from list_transactions and search_transactions siblings. The verb 'Get' combined with 'by GUID' establishes a clear retrieval-for-one-entity purpose distinct from bulk listing 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 for retrieving a single transaction by GUID, which is reasonably clear context. However, it doesn't explicitly state when NOT to use this (e.g., when to prefer list_transactions or search_transactions for broad queries), though the 'by GUID' qualifier implicitly signals single-entity lookup instead of searching/filtering.

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

• update_employeeA
  3.5/5.0
  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. 'Update' implies mutation and 'false to deactivate; true to reactivate' for the active flag adds useful behavioral detail. However, it doesn't disclose side effects, whether this requires auth, whether changes are reversible, or what response looks like. With zero annotation coverage, this is only lightly covered.

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

  Conciseness4/5

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

  The description is reasonably compact with front-loaded purpose statement followed by a parameter list. Every sentence earns its place, though the reliance on update_customer for address details means some of the burden is outsourced.

  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?

  There's an output schema present, so return values need not be explained. The description covers parameter semantics and notes a key difference from the sibling update_customer (no notes column). For a parameter set of 5 with 1 required param, the coverage is adequate but relies on cross-reference to update_customer for full understanding of the address 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 description coverage is 0%, so the description must compensate for all 5 parameters. The description says 'id: Employee ID (e.g. "000001")', 'name: New display name', 'currency: New default ISO currency code', 'active: false to deactivate; true to reactivate', and 'address: Partial address dict'. These map well to the schema but the address and currency semantics are deferred to update_customer ('see update_customer'), leaving the reader dependent on another tool's docs.

  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 'Update an existing employee' with specific verb+resource. It also notes what's omitted (no 'notes' column) and distinguishes from sibling update_customer. However, it doesn't explicitly contrast against update_vendor, update_job, or other update tools, so it's clear but could be more distinguishing.

  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 references update_customer as a template ('otherwise identical to update_customer'), which provides implied usage context but doesn't explicitly state when to use this tool versus alternatives. It does clarify that 'notes' works for customers but not employees, a useful exclusionary detail.

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

• assign_split_to_lotA
  3.6/5.0
  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 explains the purpose and workflow but does not state what happens on success/failure, whether the operation is reversible, whether it can be called multiple times on the same split, or if it requires specific account types. For a state-mutating action with no annotation coverage, this is a meaningful 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 well-structured with a concise one-line summary, an Args section, and a three-step workflow example. The workflow is genuinely useful and earns its space. Slightly longer than strictly necessary but organized efficiently.

  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?

  With 2 simple parameters, 100% schema coverage, and an output schema present, the description covers the essential workflow adequately. It explains the sequencing and parameter origins. However, absence of annotations for a state-mutating action and lack of detail on integrity constraints (e.g., can a split only be assigned once?) leave moderate gaps for a financially consequential operation.

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

  Parameters3/5

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

  Schema coverage is 100% and both parameters are explicitly described in the schema (32-char hex or 8+ char prefix). The description adds the context that split_guid comes 'from transaction's investment account' and clarifies that both accept prefixes, which is minor value beyond schema. Baseline 3 is appropriate since the schema already documents the parameters thoroughly.

  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 'Assign a transaction split to a lot' and the resource (split→lot linkage for cost basis tracking). It includes a workflow example showing how it fits into a three-step process, which strongly distinguishes it from sibling tools like create_lot and close_lot.

  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 ('Use after creating a buy/sell transaction to link the investment account split to its lot') and provides a concrete numbered workflow showing the sequence of create_lot → create_transaction → assign_split_to_lot. No explicit when-not-to-use or alternatives, but the guidance is clear and actionable.

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

• create_billtermA
  3.6/5.0
  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 of behavioral disclosure. 'Create' implies mutation with persistence implications, but the description doesn't state whether duplicates are allowed, whether existing billterms can be modified, or any constraints. It does provide useful parameter detail but omits post-creation behavior (e.g., return value, 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 compact and front-loaded with the core purpose in the first sentence, followed by concise parameter documentation. Each parameter gets one line. No wasted verbiage, though it could potentially be trimmed slightly since some parameter info also appears in the schema.

  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?

  There is an output schema present, so return-value documentation is not required. The description covers all 5 parameters with meaningful semantics beyond the schema. For a create operation with good parameter coverage and an output schema, the level of detail is adequate and 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 description coverage is 0%, so the description must compensate, and it does well. Each parameter is explained with its purpose, and examples are given ('Net 30', '2' for 2%). The discount_percent being a string rather than number is explicitly clarified with an example. This significantly exceeds what the bare schema 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 'Create a new billing term' with a specific verb and resource. It distinguishes this from siblings like list_billterms and create_taxtable. A dedicated sibling create_billterm is not present, but the create/list pairing is clear enough to differentiate.

  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 doesn't explicitly state when to use this tool versus alternatives (e.g., update vs create on existing billterms). It does imply the use case through the name and context (creating a Net 30 type term), but no explicit when/when-not guidance or references to siblings is given.

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

• create_customerA
  3.6/5.0
  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 disclosure burden. It documents default-currency fallback for currency and character caps for notes/address sub-fields, which is useful. However, it doesn't disclose what the response contains, whether creation can be undone, or any auth/permission requirements for a mutation 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 well-organized with clear parameter sections and is reasonably concise. Every sentence adds value, especially the currency default explanation. The format is a bit docstring-like rather than prose but remains scannable 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 4-parameter schema with an output schema present, the description covers the key semantics: name requirement, currency default, notes cap, and address sub-structure. The output schema handles return values. The main gap is lack of usage context relative to sibling tools, but for a create operation the description is fairly 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 description coverage is only 25%, so the description compensates meaningfully. It explains the currency default behavior, provides a concrete name example, clarifies the address sub-field structure and caps, and states the notes limit. This adds real value beyond the bare schema.

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

  Purpose4/5

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

  The description clearly states it creates a new customer with specific verb+resource. It's distinct from sibling tools like list_customers, get_customer, update_customer, and delete_customer, though it doesn't explicitly name them as alternatives. The action and target are unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage (creating customers) but provides no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites. It offers parameter behavior context but nothing about when choose this tool over other customer-related tools.

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

• get_jobA
  3.6/5.0
  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 discloses what fields are returned (name, owner, active state, linked invoices/bills) which is genuinely useful. However, it doesn't specify behavior on invalid/unknown job IDs, error handling, or whether the job must exist. The return-value disclosure is decent but safety/error behavior is unaddressed.

  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: a one-sentence purpose followed by a returns summary and a short args block. Front-loads the purpose effectively. The returns summary is somewhat redundant given an output schema exists, but it's efficient and not bloated.

  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?

  There's an output schema present, so describing return values in the description is partly redundant but still helpful as a quick summary. For a single-parameter ID lookup tool, the description covers purpose, return contents, and parameter semantics adequately. It's reasonably complete for a straightforward getter 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 0% - the schema only shows job_id is a required string with no further meaning. The description compensates well by explaining job_id is the Job ID with an example format ("000001"). This adds value beyond the bare schema, though it could mention more about format constraints.

  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 retrieves a job's details by ID, and enumerates what's returned (name, owner, active state, plus linked invoice/bill count and IDs). Among siblings like list_jobs, get_job_report, update_job, it's distinct as the single-job detail fetcher. Verb+resource+scope are all clear, though it doesn't explicitly contrast with get_job_report.

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

  Usage Guidelines3/5

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

  The description implies use when you have a known job_id and need its details, but it doesn't explicitly state when to prefer this over get_job_report or list_jobs, nor any exclusions. Context is implied by the args and ID-based naming, but no alternatives or when-not-to-use guidance is provided.

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

• update_accountA
  3.6/5.0
  Behavior3/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 does disclose a meaningful behavior: cross-polarity changes to account_type are blocked (e.g., ASSET to LIABILITY), which is useful safety context. It also discloses the notes max 4096 bytes limit and shared Notes field. However, it doesn't describe what happens to unspecified fields (are they left unchanged?), reversibility, permissions, or error behavior. For a mutation tool with zero annotations, it provides meaningful but incomplete 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 structured as a clear first line plus an Args list, making each parameter's meaning scannable. Every sentence earns its place — no fluff. It's moderately sized for a 6-parameter tool with 0% schema coverage. The only slight inefficiency is repeating some information that the schema title fields already imply, but this is minor given the 0% coverage.

  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?

  This is a complex 6-parameter mutation tool with 0% schema description coverage and no annotations. The description compensates well: it documents every parameter's semantics, the important polarity constraint, and the notes format. An output schema exists, so return-value documentation is not required. The main gap is lack of guidance on partial updates (whether unspecified fields are preserved) and permissions, but overall it's reasonably complete for the tool's complexity.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description fully compensates. It explains each parameter in detail: name accepts three formats (full path, %short GUID, or 32-char GUID), new_name is leaf-only, placeholder means container-only, account_type has polarity constraints with concrete examples, and notes has a 4096-byte limit with clear clearing semantics (pass "" to clear). This substantially exceeds what the bare schema provides.

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

  Purpose4/5

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

  The description clearly states it updates an existing account's properties, with a specific verb (Update) and resource (account). It distinguishes from siblings like create_account, delete_account, and move_account. However, it doesn't explicitly contrast with get_account/delete_account in prose, though the name itself conveys the update intent clearly.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool vs alternatives like create_account, move_account, or delete_account. It implies usage by naming the specific properties it updates, but provides no exclusions or context for when another sibling would be more appropriate. No when-not-to-use guidance is given.

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

• update_scheduled_transactionA
  3.6/5.0
  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 of behavioral disclosure. It does explain the important behavior around the null-vs-empty-string distinction for end_date and notes, which is genuinely useful. However, it doesn't mention prerequisites, whether changes take effect immediately vs on next occurrence, permission requirements, or what happens to scheduled time/amount fields not covered. For a mutation tool with no annotations, this is partial coverage.

  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 with clear per-parameter sections and a helpful explanation of the empty-string sentinel rationale. It's moderately lengthy but every section earns its place, particularly the null-vs-empty-string distinction which prevents a real failure mode. Slightly verbose in the sentinel explanation but justifiable given the subtlety.

  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 there's an output schema, return values needn't be documented. The tool has 4 params with rich three-state semantics that are thoroughly explained. Coverage is good for a guided-mutation tool. Minor gap: the 'enabled' parameter behavior is assumed obvious, and there's no mention of read-only considerations like ledger state dependencies. Overall solid completeness for the tool's complexity.

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

  Parameters4/5

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

  Schema description coverage is only 25% (only guid has a description in the schema), so the description must compensate. It does so excellently for end_date and notes, explaining the three-state convention with the empty-string sentinel and the rationale behind it. It also explains notes' semantics (affects future transactions only, existing untouched). Enabled is not elaborated but is self-explanatory. The description adds substantial value beyond the bare schema.

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

  Purpose4/5

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

  Description clearly states the verb (Update) and resource (scheduled transaction) with a specific purpose. It doesn't explicitly distinguish from siblings like create_scheduled_transaction or delete_scheduled_transaction, but the update semantic is evident from the name and context. The description focuses on what fields can be modified, making purpose reasonably clear.

  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 provides detailed guidance on the end_date and notes three-state conventions, which is helpful usage context. However, it doesn't explicitly state when to use this tool vs alternatives (e.g., create_scheduled_transaction for new schedules, or when to use update_transaction for already-created transactions). Sibling differentiation is 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.

• vendor_spending_reportA
  3.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well: it states the tool reads posted vendor bills, implies read-only behavior, describes the default return format (compact aligned text table), and explains the verbose and group_by behavioral variations including that group_by 'Overrides verbose'. This is strong behavioral disclosure for a reporting 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 with an intro summary, blank-line-separated sections, and a clean Args list with each parameter on its own line. It's appropriately detailed for a tool with 5 parameters and 0% schema coverage, though slightly verbose with the group_by explanation.

  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?

  Considering the output schema exists (which relieves the description of explaining return values), no annotations, and 0% schema coverage, the description does well covering purpose, behavior, parameter semantics, and format toggles. It could add more context about what 'posted' means or prerequisites (e.g., bills must be posted first), and there's no mention of potential errors or date range limits, leaving minor gaps.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must fully document all 5 parameters to compensate. It does document each parameter (start_date, end_date, vendor_id as optional filter, verbose, group_by with its month/quarter/year values and behavior). However, it partially compensates — the descriptions add real semantic meaning (date formats, what group_by does, override behavior). Given 0% schema coverage, this is a significant contribution, but I'll rate it lower because the parameter explanations, while present, are brief and don't fully elaborate on formats or edge cases.

  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 'Get spending breakdown by vendor for a period' with a specific verb+resource and then details what it analyzes (posted vendor bills showing total billed, total paid, and outstanding amounts). It effectively distinguishes itself from similar reporting siblings like spending_by_category and get_budget_report by focusing on per-vendor bill analysis.

  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 when to use it (reporting period vendor spending) and documents the verbose and group_by toggles that change output format. However, it doesn't explicitly state when NOT to use it or name alternatives, though the tool's purpose is fairly distinct among a large sibling list.

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

• delete_priceA
  3.7/5.0
  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 discloses identification behavior (composite key, disambiguation logic) clearly. However, it doesn't disclose what happens on failure (e.g., if the price doesn't exist, or multiple found without source), the return format, or irreversibility implications beyond the obvious 'delete' semantic.

  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?

  Well-structured with a clear lead sentence followed by identification details and parameter documentation. Reasonably compact without waste. The Args section is standard and each item earns its place.

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

  Completeness3/5

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

  While there is an output schema, the description covers parameter semantics well. Some gaps: no mention of error behavior, whether deletion is idempotent, or what the return value indicates. For a 4-param delete operation with no annotations, it's solid but could be more complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description fully compensates. Each parameter (commodity, namespace, date, source) is documented with examples and format details (ISO date YYYY-MM-DD, source tag examples). Particularly valuable is explaining the 'source' parameter's conditional necessity.

  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 a clear verb+resource ('Delete a single price entry') and explains the identification keys (commodity, namespace, date). It's clear what the tool does, though given sibling tools like create_price, get_prices, get_latest_price, create_prices, the description doesn't explicitly distinguish delete from these by name — though the purpose is clear enough.

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

  Usage Guidelines4/5

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

  The description explains when to pass 'source' — 'to disambiguate when multiple prices exist on the same commodity+date (e.g. one user-entered and one fetched from a feed)'. It gives concrete examples of source values and clearly states it's 'Required when multiple prices exist'. This provides useful contextual guidance though it doesn't explicitly state when NOT to use vs alternatives.

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

• delete_scheduled_transactionA
  3.7/5.0
  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 of behavioral disclosure. It does disclose a key side-effect scoping detail (does not affect already-created transactions), which is valuable. However, it doesn't state whether the schedule deletion is reversible, what the return value is, or any other behavioral consequences beyond that single scope clarification.

  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 brief and front-loaded with the core purpose, followed by the critical scope caveat and an Args section. It wastes no words, though the Args section slightly duplicates the schema's parameter documentation, which is a minor 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 single-parameter deletion tool with an output schema, the description covers the essential context: what is deleted, the key side-effect scope, and the parameter format. The scope caveat is the most important contextual detail and is well covered. No major gaps remain for a tool of this complexity.

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

  Parameters3/5

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

  Schema coverage is 100%, with the guid parameter described in the input schema ('Scheduled transaction GUID (32-char hex or 8+ char prefix)'). The description repeats this same information in the Args section. The description adds some value by restating it in context, but does not go beyond what the schema already documents. 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 verb ('Delete'), the resource ('scheduled transaction'), and immediately adds scope: 'Does not affect transactions already created from this schedule.' It is specific and distinct from siblings like update_scheduled_transaction, create_transaction_from_scheduled, and delete_transaction.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives like void_transaction or delete_transaction. However, the scope clarification ('does not affect transactions already created') implicitly distinguishes it from deletion of actual transactions. There's no exclusion guidance for 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.

• get_server_configA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, and the description carries the burden of describing behavior. It states what values are returned (loaded modules, tool count, book path, debug mode, version), which is useful. However, it doesn't disclose whether this reflects live state, whether changes take effect immediately, or how this config relates to switch_book or other session-affecting tools. The returned-fields list adds some transparency but doesn't fully describe session semantics.

  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 at two short paragraphs. The first sentence states the purpose, the second enumerates returned fields, and the final sentence gives the use case. Every sentence earns its place with zero waste.

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

  Completeness4/5

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

  With zero parameters and no complexity, the description is fairly complete. It covers the purpose, the returned content, and a concrete use case. An output schema exists, which relieves the description of explaining the return format in detail. It could add a touch more about the session/configuration semantics, but this is adequate for a zero-parameter introspection 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?

  The tool has zero parameters, so the description doesn't need to explain parameter semantics. A baseline of 4 is appropriate given there are no parameters to document; the description's task of explaining the return fields is handled well.

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

  Purpose4/5

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

  The description clearly states what the tool does: 'Get the server's loaded configuration' with a specific verb+resource. It also enumerates the returned content (modules, tool count, book path, debug mode, version), which helps distinguish it from data-retrieval siblings like get_customer or get_book_summary since it targets the server/session itself rather than financial data.

  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 provides a usage hint: 'Use this to verify which tools are available in this session.' This gives a concrete use case. However, it doesn't explicitly contrast with alternatives or state when not to use it, though the given use case is fairly prescriptive and there aren't obvious sibling competitors for this configuration-inspection purpose.

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

• get_taxtableA
  3.7/5.0
  Behavior4/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 a notable behavioral nuance: refcount counts Entry rows referencing the table '— voided invoices still count.' This is genuinely useful edge-case context beyond the schema. It also clarifies the return includes resolved entry list with account paths.

  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—two focused sentences plus a short Args section. It front-loads the core purpose and key return fields. The voided-invoice nuance earns its place. Slightly more structure could separate return details more clearly, but overall it's efficiently written.

  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 output schema exists (covering return structure), the description needn't fully enumerate return values, but it does highlight key ones (guid, name, refcount, resolved entries). It handles the refcount nuance not obvious from schema. For a single-parameter getter, this is adequately 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 0%, so the description must compensate. It documents the single parameter 'name: Taxtable name.' This is a minimal but adequate explanation for a self-evident parameter name. The name parameter is straightforward, so it doesn't need extensive elaboration; the schema already declares it as required string.

  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 a specific verb+resource: 'Get full details for one sales-tax table.' It returns guid, name, refcount, and the resolved entry list. It distinguishes from siblings like list_taxtables (list all), update_taxtable, delete_taxtable, and create_taxtable, though it doesn't explicitly name them as alternatives.

  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 by being a single-item getter ('for one sales-tax table'), contrasted with the sibling list_taxtables. However, it doesn't explicitly state when to use this vs. list_taxtables or provide exclusions. The context is reasonably inferable but not stated.

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

• get_vendorA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so description carries the burden. It discloses that the ID is human-readable (not internal GUID), which is useful context. But it doesn't mention read-only nature, error behavior for invalid IDs, or return format. With an output schema present, some burden is lifted, but safety/error behavior is still undisclosed.

  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—a single sentence plus argument doc, zero waste. Every line earns its place. Front-loaded with the purpose statement.

  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 read operation with an output schema present, the description covers the key points: what it does, the ID semantics. The human-readable vs GUID distinction is important for GnuCash users. Could mention error/not-found behavior, but given the tool's simplicity this is largely 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 description coverage is 0%, so the description must compensate. It adds meaningful detail: the ID is the human-readable GnuCash ID, not the internal GUID, which prevents misuse. It also gives a format example ('000001'). This is genuinely helpful beyond the bare schema.

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

  Purpose4/5

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

  The description clearly states the tool fetches details for a specific vendor by ID. It distinguishes from siblings like list_vendors and create_vendor by the 'by ID' focus. However, it doesn't explicitly contrast with get_customer or other get_* 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 purpose implies usage (retrieve one vendor's details) and the ID-focused wording helps differentiate from list_vendors. However, there's no explicit mention of when to use vs. alternatives or any prerequisites.

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

• create_billA
  3.8/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the burden of behavioral disclosure. It does explain fallback behavior for currency ('Defaults to the vendor's currency, falling back to the book's default') and default auto-generation of bill_id. However, it doesn't disclose side effects, whether bills must be posted separately, required permissions, or what the response (output schema) contains.

  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?

  Structured with a leading one-line summary followed by an Args block. Each parameter is one or two lines with examples and defaults. Slightly verbose with some wrapping, but every sentence adds value. Reasonably efficient for a 7-parameter 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?

  For a 7-parameter creation tool with no annotations and zero schema description coverage, the description covers all parameters thoroughly with defaults and examples. An output schema exists, so return values need not be documented. Missing aspects are when-to-use guidance and any preconditions or side effects, but the parameter docs are strong.

  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?

  With 0% schema description coverage, the description fully compensates by documenting every parameter with examples, defaults, fallback behavior, and formatting requirements (ISO date, ISO currency code, billterm format). This is exactly what a high-coverage-gap description should provide.

  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+resource ('Create a vendor bill') and the description enumerates all key parameters with concrete examples. It distinguishes from 'create_invoice' and 'create_credit_note' by the explicit 'vendor bill' target, though it doesn't explicitly differentiate from the closely related sibling 'add_bill_entry'.

  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 'Args' format indirectly signals which parameters are used for what purpose, and gives practical examples like 'BILL-2026-001' and 'Net 30'. However, it doesn't explicitly state when to use this vs sibling tools (e.g., when to use create_voucher vs create_bill, or the relationship to add_bill_entry for adding line items). 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.

• create_accountA
  3.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that placeholder is a 'container-only account' and that notes show in GnuCash's Notes field, but it does not disclose side effects such as whether creating an account is reversible, whether it affects balances, what happens on duplicate names, or whether permissions are required. For a mutating tool with zero annotation coverage, more behavioral disclosure 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.

  Conciseness4/5

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

  The description is well-structured with an Args section and bullet-list style parameter documentation. It's denser than ideal because it documents 8 parameters, but every sentence adds value—examples like 'AI Subscriptions', 'USD', 'VTSAX', and 'NASDAQ' make it immediately usable. No fluff or 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 an 8-parameter creation tool with 0% schema coverage and no annotations, the description is remarkably complete. It documents all parameters with types, defaults, and cross-constraints. Since an output schema exists, not describing return values is acceptable. The main gaps are behavioral aspects (duplicate handling, side effects) rather than parameter or semantic coverage.

  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 0%, so the description MUST fully compensate. It does an excellent job here: every parameter is documented with its meaning, acceptable values (account_type enum list, commodity_namespace choices), defaults, and interdependencies (e.g., commodity_namespace required with non-currency commodities). The parent ref formats (full path, %short GUID, 32-char GUID) are also 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 the purpose: create a new account in the chart of accounts. The verb (create), resource (account), and scope (chart of accounts) are all explicit, and the extensive parameter documentation makes it clear what this tool does versus sibling tools like update_account or move_account.

  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 field-by-field guidance on what each parameter means and when to include them (e.g., commodity_namespace required with non-currency commodities, omit parent for top-level). It doesn't explicitly say when NOT to use this tool vs alternatives like create_commodity, but the domain distinction is fairly clear from the sibling names and account-specific context.

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

• create_budgetA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose some meaningful behaviors: that year defaults to current year, start_date falls back to January 1, and start_date overrides year. However, it doesn't disclose whether creation can overwrite existing budgets, what happens with duplicate names, whether any fields are immutable, or what the return/response looks like. Since an output schema exists, some return details are covered elsewhere, but side effects and constraints remain understated.

  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 well-structured using an Args-style list with clear indentation, default values, and concrete examples. Every sentence earns its place, adding semantic value without redundancy. It's appropriately detailed for a tool with 6 parameters and zero schema coverage.

  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?

  Despite 0% schema coverage and no annotations, the description covers all 6 parameters thoroughly with defaults, types, and precedence rules. An output schema exists to handle return-value documentation. The only minor gap is the lack of mention of validation rules (e.g., min/max year), constraints, or error conditions, which would make it complete for a creation tool that likely has side effects.

  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 0% and there are no enums, so the description carries full parameter documentation burden — and it does an excellent job. It explains defaulting behavior (year defaults to current), precedence rules (year ignored when start_date provided), valid period_type values (monthly/quarterly/weekly), and gives concrete usage examples (start_date='2024-01-01'). It even motivates the start_date parameter for historical comparison.

  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 'Create a new budget' with a specific verb+resource. It distinguishes itself from siblings like delete_budget, set_budget_amount, get_budget_report, and list_budgets. The detailed parameter documentation further clarifies the scope and semantics of the creation operation.

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

  Usage Guidelines2/5

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

  The description provides rich parameter semantics (e.g., when start_date vs year is used, historical budget example) but does not explicitly state when to use this tool versus alternatives or when NOT to use it. It gives context on mid-year vs historical budget creation but no explicit exclusion criteria or alternative tool references. No when-to-use guidance is provided versus related budget tools.

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

• create_credit_noteA
  3.9/5.0
  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, and it delivers substantially: explains posting direction reversal (debit Income/credit A/R for customers; debit A/P/credit Expense for vendors), audit trail preservation, and the employee limitation with a GnuCash-specific rationale. Rich behavioral detail about what the post-time effect is.

  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 well-organized with a clear workflow summary and per-parameter Args section, and front-loads the core purpose. However, it is fairly long with the detailed posting-direction accounting details and the embedded employee-reimbursement digression, somewhat stretching 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?

  Despite being a complex tool with 8 parameters and zero annotation coverage, the description covers purpose, workflow, posting mechanics, limitations, and per-parameter semantics thoroughly. The output schema exists so return values need not be described. Complete enough 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 description coverage is 0%, so the description fully compensates. It explains every parameter meaningfully: applies_to_invoice_id constraints (same owner, same currency, audit trail value, floating note option), currency inheritance rules, owner_type restrictions, and credit_note_id auto-generation from the shared counter. High value added beyond bare schema.

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

  Purpose4/5

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

  Description clearly states the tool creates a credit note against a customer invoice or vendor bill, with specific verb and resource. It distinguishes from siblings like apply_credit_note and add_credit_note_entry by describing the full workflow, though it doesn't explicitly name those sibling alternatives.

  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 workflow context: use add_credit_note_entry to add line items then post_invoice to post. Mentions settled by refund (pay_invoice) or netting (apply_credit_note), which contextualizes when this tool fits. Does not explicitly state when NOT to use it, but gives adequate usage framing.

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

• get_customerA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It correctly implies this is a read-only fetch operation ('Get details'), which aligns with expected behavior. However, it doesn't add richness like what happens on missing/invalid IDs, whether it returns 404 or errors, or what fields are returned. With zero annotations, a 3 reflects that it's correct but minimal.

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

  Conciseness4/5

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

  The description is appropriately brief at two short sentences with a clear 'Args' section documenting the parameter. No wasted words. It's slightly padded with the Args formatting but fundamentally lean.

  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?

  Despite zero annotations, the tool has a single simple parameter and an output schema, so the description is adequate. The key domain knowledge (human-readable ID vs GUID) is captured. For a simple get-by-ID tool with an output schema covering return shape, this is essentially complete - missing only guidance about error/not-found behavior.

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

  Parameters4/5

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

  Schema coverage is 0% so the description must compensate, and it does meaningfully. It clarifies that 'id' is the human-readable GnuCash ID (e.g., '000001'), NOT the internal GUID - which is critical domain knowledge that prevents the agent from passing the wrong identifier. This is real value added beyond the bare 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+resource: 'Get details for a specific customer by ID.' It distinguishes from siblings by targeting a single customer retrieval (as opposed to list_customers which lists all, and create_customer/update_customer/delete_customer which are CRUD operations). The scope is precise and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when to use it (when you need a single customer's details) and contrasts implicitly with list_customers, but it doesn't explicitly state 'use list_customers when you need to enumerate customers' or provide exclusions. No explicit when-not guidance or named alternatives is given.

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

• get_employeeA
  3.9/5.0
  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. Since this is a read-only fetch operation, the description adequately signals non-mutating behavior by its wording ('Get details'). It does not add notes about permissions, caching, or error behavior, but for a simple retrieval the implicit read-only nature is reasonably 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?

  Extremely efficient — a single purpose sentence plus one parameter clarification. Every sentence earns its place, especially the ID/GUID distinction that would be invisible without it. Well front-loaded with the main purpose first.

  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 an output schema present (covering return values), the description need not explain response format. For a 1-parameter, no-nested-objects tool, the description handles the essential ambiguity (ID format) and the read-only nature is clear. The only gap is no explicit safety/read-only confirmation given absent annotations, but the tool's nature makes this low-risk.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate — and it does excellently. The crucial distinction between the human-readable ID (e.g., '000001') and the internal GUID is a critical semantic clarification that entirely prevents misuse. This is high-value parameter documentation that the bare string schema could not convey.

  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 a specific verb+resource ('Get details for a specific employee by ID'), which clearly identifies the tool's purpose. It distinguishes reasonably from siblings like list_employees (which lists all) and get_customer/get_vendor (different entity), though it doesn't explicitly name a sibling alternative.

  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 context is implied: you use this when you have a specific employee ID and need that employee's details, versus list_employees for enumerating. However, there's no explicit when-to-use/alternatives guidance. The id parameter guidance orients the user but doesn't discuss exclusions or alternatives.

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

• close_lotA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It usefully discloses that lots are normally auto-closed at zero quantity and that this tool is for edge cases/manual cleanup. However, it doesn't disclose side effects (e.g., does closing affect gain calc, reconciliation, or related splits) or whether closure is reversible.

  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 well-organized with a concise intro, usage section, and note. Every sentence earns its place, explaining the purpose and the automatic behavior context without padding. No waste.

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

  Completeness4/5

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

  With a single parameter, 100% schema coverage, and an output schema present, the tool is relatively simple. The description covers when to use, what happens automatically, and the argument format. It could add post-condition details (what changes after close) but is reasonably complete for a simple mutation tool.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear parameter description ('Lot GUID (32-char hex or 8+ char prefix)'). The description repeats the same guidance ('8+ char prefix') without adding meaningful semantics beyond the schema. Baseline 3 is appropriate since the schema fully documents the single parameter.

  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 'Mark a lot as closed' with a specific verb+resource. It distinguishes the tool from siblings by explaining it's for manual cleanup when lots aren't automatically closed, differentiating from create_lot/list_lots/get_lot/assign_split_to_lot.

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

  Usage Guidelines4/5

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

  The description provides clear when-to-use guidance ('Use when a lot is fully sold but wasn't automatically marked closed, or to manually close a lot with zero shares'). It explains the automatic closure behavior, but doesn't explicitly name alternative tools for other lot operations, leaving some ambiguity about 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.

• get_budget_reportA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burdens. It discloses return format behavior (compact text table by default, full dict with verbose), the ⚠ markers on budget-exceeding categories, and period selection behavior (None = current period). This is a read/report tool and the description is consistent with that, but doesn't explicitly confirm it's non-mutating or describe error conditions (e.g., budget not found).

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

  Conciseness4/5

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

  The description is well-organized with a clear opening sentence, a return-format note, then a structured Args section. The period enum is clearly documented. It's slightly long but every element earns its place since schema coverage is 0%. 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?

  For a report-generation tool with 5 params, the description covers all key aspects: input semantics, output format controls, and default behaviors. There is an output schema present which covers return values. Minor gaps include no explicit error-case handling (e.g., missing budget) or mention of whether account filtering requires exact names, but overall this is fairly complete for a reporting 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 description coverage is 0%, so the description carries full parameter documentation burden. The description thoroughly explains period semantics (None/0-11/'ytd'/'all' values with meanings), account filtering behavior, include_children relationship to account, and verbose meaning. This compensates effectively for the absent 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 starts with a clear verb+resource: 'Compare actual spending against budget.' It clearly distinguishes from siblings like get_budget (which retrieves budget definitions), net_worth, balance_sheet, etc. by focusing on spend-vs-budget comparison. However, there are multiple budget-related siblings (get_budget, list_budgets, set_budget_amount) so the differentiation is implicit rather than explicit but still clear.

  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 gives clear contextual usage including default behavior (current period based on today's date) and the return format (compact text table with ⚠ markers vs full structured dict with verbose=true). It explains the output format choices but does not explicitly state when-not to use it versus alternatives like get_job_report or spending_by_category.

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

• list_customersA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full disclosure burden. It reasonably discloses: the lead summary line format, default compact output vs verbose full JSON, pagination behavior, and the active_only default filtering. It doesn't mention sort order or total result limits beyond the max 250 page size, but overall provides solid 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 well-structured with an intro paragraph explaining output format, then a clean args list. Every sentence adds value. Slightly verbose in the intro but each sentence covers distinct behaviors (summary line, default format, pagination, count-only, verbose mode). Efficient overall.

  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, this covers the key operational details: output format, pagination, defaults, and filtering. An output schema exists, so return value details are covered. Slight gaps: no mention of sort order, timezone behavior, or relationship with other customer-related tools, but these are minor for a listing operation.

  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 0%, so the description must fully compensate. It does: each of the 4 params (active_only, verbose, limit, offset) is explained with defaults and special behavior (limit=0 count-only, max 250). This exceeds what the bare schema provides. Minor gap: doesn't state what 'active' means, but full defaults and ranges are provided.

  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 'List all customers' with a specific verb and resource. Among siblings, list_customers is distinguished from get_customer (single vs bulk) and create_customer, though it doesn't explicitly name these alternatives. The first line is clear and unambiguous.

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

  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: the default one-line-per-customer format, how to paginate with offset, that limit=0 returns count only, and when to use verbose=true for full JSON. It explains the alternative output modes well, though it doesn't explicitly say when to prefer this over get_customer.

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

• create_commodityA
  4.1/5.0
  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 that mnemonic is 'Unique within namespace' and explains fraction semantics (smallest fractional unit with concrete examples). It doesn't state whether creation is reversible (is there a delete_commodity counterpart?), what happens on duplicates, or what the output schema contains. The uniqueness constraint and fraction explanation are useful behavioral disclosures, but some gaps remain for a creation tool with no annotation coverage.

  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 efficiently organized with an opening summary and per-parameter bullet points. Every sentence earns its place. It's slightly longer than strictly necessary but every detail (fraction examples, namespace mapping) is genuinely useful. The format is scannable and the most critical guidance is 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?

  Despite 5 parameters and 0% schema coverage, the description is remarkably complete for a mutating tool. It covers all parameter semantics, known constraints (uniqueness), and examples. An output schema exists so return value explanation isn't required. For a straightforward creation tool, this description is complete and self-sufficient.

  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?

  Despite 0% schema description coverage, the description provides thorough explanations for all 5 parameters. The fraction field gets especially detailed treatment with concrete examples (1=whole, 100=2 decimals, 10000=shares, 1000000=crypto). Namespace gets asset-type mapping. Mnemonic gets uniqueness and example. Fullname and cusip are described. This fully compensates for the absence of 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 'Create a new commodity (stock, mutual fund, etc.)' with a specific verb (create) and resource (commodity). It distinguishes from siblings by covering a distinct domain (commodities) and defines commodity scope with 'stock, mutual fund, etc.' This is a precise, unambiguous purpose statement.

  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 gives excellent per-field guidance for the namespace parameter explaining which namespaces map to which asset types (FUND for mutual funds, NASDAQ/NYSE/AMEX for stocks, any custom string). However, it doesn't explicitly state when to use this versus alternatives like create_lot or create_price, and doesn't mention whether commodities need to be created before prices can be set. The implied usage is clear but no exclusions or alternatives are named.

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

• debt_payoff_planA
  4.1/5.0
  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 important behaviors: auto-discovery of accounts, dependency on pre-set 'apr' slots, YETI calculation logic with a concrete example sentence ('A $1.00 purchase will cost you $1.68'), and the two return formats (compact text vs verbose dict with detailed fields like interest_paid, credit_limit, minimum_payment). This is noteworthy behavioral detail for a computational 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 somewhat long but each section earns its place: the mechanism (avalanche), the setup prerequisite, the two output modes, the YETI explanation, and the Args block. It's front-loaded with the core purpose in the first sentence. The YETI example and verbose field breakdown are useful but add length; the structure (prose then Args) is clear and scannable.

  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 (avalanche computation, auto-discovery, YETI multiplier, dual output modes), the description covers the essential gaps: setup prerequisites, parameter meanings, output format differences, and the YETI definition. An output schema exists, so return-value enumeration is covered. Minor gap: it doesn't specify behavior when no accounts have 'apr' slots set (edge case), but overall it's comprehensive for a moderately complex 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 description coverage is 0%, meaning the schema itself provides no description for any of the 3 parameters. The description partially fills this gap: it documents monthly_budget ('Total monthly amount available for all debt payments combined'), additional_purchase ('Dollar amount to calculate YETI for'), and verbose ('If true, return the full structured dict'). This is substantial compensation for zero schema coverage.

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

  Purpose5/5

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

  The description clearly states what the tool does: 'Calculate an avalanche-method debt payoff schedule with YETI multiplier.' It names the specific verb (calculate), resource (debt payoff schedule), and method (avalanche), and 'auto-discovers CREDIT/LIABILITY accounts' defines the scope. It distinctly differentiates from siblings like get_budget or create_transaction.

  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 explains the prerequisite setup explicitly: 'Set APRs via set_account_slot' with a concrete example. It also distinguishes output modes (compact text summary vs verbose structured dict) and indicates when to use verbose=true ('suitable for programmatic consumers'). It doesn't explicitly state when NOT to use it, but the setup context and output-mode guidance provide clear usage direction.

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

• delete_credit_noteA
  4.1/5.0
  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 discloses the key behavioral constraint (only unposted notes can be deleted, posted ones rejected) and the validation behavior. However, it doesn't mention what happens on failure for non-credit-note targets, whether deletion is irreversible, or any permission/auth requirements.

  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 with a concise lead sentence followed by clear Args section. It front-loads the key info (delete unposted credit note) and uses formatting effectively (backticks, bullet-style Args). Slightly longer than minimal but every sentence adds value.

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

  Completeness4/5

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

  Given the tool has 3 params, no required fields, an output schema, and moderate complexity, the description covers the essential exclusions (posted cannot be deleted), the validation behavior, and all parameter semantics. The exclusion of same-tool sibling (delete_invoice) isn't needed since the deletion workflow is well specified. Missing return-value explanation is acceptable since an output schema exists.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains each parameter well: id as the preferred name (matching sibling naming conventions), credit_note_id as a legacy alias, and owner_type as a customer/vendor disambiguator. It also clarifies 'pass exactly one of id or credit_note_id'. This provides strong semantic value beyond the bare schema fields.

  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 a specific verb+resource ('Delete an unposted credit note') and clearly distinguishes the tool's scope: it validates the target is a credit note before deletion. It differentiates from sibling tools like post_invoice/unpost_invoice by explicitly referencing the unpost-then-delete 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?

  Explicit guidance is provided: posted credit notes cannot be deleted and must be unposted first via unpost_invoice. This gives clear when-to-use and precondition context, effectively preventing misuse. The call to unpost_invoice is a named alternative.

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

• delete_vendorA
  4.1/5.0
  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 of behavioral disclosure. The description does disclose the key constraint (can't delete vendors with bills) which is a critical behavioral trait. However, it doesn't describe what happens on failure (error behavior), permanence/reversibility of the deletion, or any affected related records beyond stating the bill precondition.

  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?

  Efficient and front-loaded. The opening sentence states the purpose immediately. The next two lines state the constraint and workaround. It includes an Args section that's compact. No wasted words, though the description could be considered slightly verbose given the constraint explanation, it earns its space.

  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?

  This is a destructive delete operation with no annotations, but the description covers the most critical behavioral constraint (bill dependency) and provides a clear failure-avoidance path. An output schema exists but the description doesn't need to explain return values. The single-param schema is fully explained. Minor gap: doesn't clarify whether deletion is irreversible or what related history (audit log) might persist.

  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 0%, so the description must compensate. It provides a clear parameter explanation with a concrete example ('e.g., "000001"'), describing vendor_id as the identifier used to target the vendor. With only one parameter this is adequate — the example anchor format directly addresses the 'Vendor Id' schema label's vagueness. A small deduction because it doesn't mention format rules (leading zeros, length constraints), though for a single param with an example, this is strong.

  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 ('Delete a vendor') with a specific resource and an explicit precondition constraint ('with no bills'). It distinguishes this from siblings like update_vendor, list_vendors, and get_vendor by specifying the destructive delete operation.

  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 clearly states when the tool can be used (vendors with no bills) and when it cannot (vendors with any posted or unposted bills), plus provides an explicit workaround: delete bills first then delete vendor. It doesn't explicitly name alternative tools, but the direction is clear and actionable.

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

• list_backupsA
  4.1/5.0
  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 behavioral burden. It discloses the output format precisely (the 'Showing X-Y of Z' lead line, tab-separated table columns, ISO UTC timestamps), explains retention stages (session/weekly/monthly/manual), describes pagination semantics, and the count-only mode. This is strong behavioral coverage for a read-only list tool, though it could note that it doesn't affect data or require auth.

  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: a brief one-line summary followed by output format details and an Args section. It's information-dense but every sentence earns its place — output format, stage taxonomy, and pagination are all essential for correct use. Slightly long but justified by the richness of the output format that needs explanation. Could be tightened but is not bloated.

  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?

  There's an output schema present, so return-value documentation burden is reduced. The description covers output format, stage types, pagination semantics, and edge cases (limit=0). For a straightforward read-only list with two simple pagination params, this is comprehensive. The only minor gap is no mention of prerequisites or authentication, but for a list tool in a system where auth is presumably uniform, this is acceptable.

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

  Parameters3/5

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

  The input schema has only 2 params with defaults and no descriptions (0% coverage), so the description carries the full explanatory load. It does document both: limit (page size, default 50, max 250, 0=count only) and offset (0-indexed, default 0). Both params are explained clearly in the Args section, fully compensating for the zero schema coverage. The descriptions are accurate and complete for these simple pagination 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 and resource: 'List all available backups, newest first.' It differentiates from siblings by being the only pure list tool in the backup domain, distinct from create_backup and prune_backups which are mutations. The description also richly details output format and stage semantics, making it unambiguous.

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

  Usage Guidelines4/5

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

  The description explains the output format and pagination behavior in detail, giving clear context on how to page through results and interpret the count-only mode (limit=0). It doesn't explicitly name alternatives or state when NOT to use it, but the backup-focused siblings (create/prune) are implicitly distinguished by the read-only nature of listing. No explicit exclusion guidance, but usage context is strong.

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

• set_account_slotA
  4.1/5.0
  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 burden. It usefully discloses that 'Values are stored as strings' and describes the key-value pair storage model, plus the account reference formats (full path, %short GUID, 32-char GUID). However, it doesn't specify whether setting an existing key overwrites it, whether there's a size limit, or whether this requires specific permissions. For a write/mutation operation, this is useful but incomplete behavioral disclosure.

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

  Conciseness4/5

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

  The description is well-structured with a one-line summary, then a context paragraph, then an Args section. It's concise without wasted words. The only slight inefficiency is the docstring-style 'Args:' section format, but all content is informative and 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?

  The tool has 3 params, no annotations, and an output schema exists. The description covers param semantics thoroughly and gives usage context for a write operation. While it could disclose overwrite behavior and permission requirements, the description is largely complete for this straightforward metadata-set operation given the available schema 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 0%, so the description must compensate for parameter documentation. It does this well: 'account' gets explicit format examples (full path, %short GUID, full GUID), 'key' gets example values ('apr', 'credit_limit'), and 'value' notes it's always stored as a string. This adds real meaning beyond the bare schema which only defines types.

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

  Purpose5/5

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

  Clearly states it 'Set a custom metadata slot on an account' with specific verb+resource. Distinguishes from siblings like get_account_slots and delete_account_slot by the action (set vs get/delete) and gives concrete use cases (APR, credit limits, reward rates). The purpose is unambiguous.

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

  Usage Guidelines4/5

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

  The description explains it's for 'per-account metadata' and lists example use cases, providing clear context on when to use. However, it doesn't explicitly contrast with siblings or state when NOT to use it. The sibling tools get_account_slots and delete_account_slot imply the complementary operations, but no explicit guidance is given.

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

• set_reconcile_stateA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral burden. It appropriately discloses that reconcile_date defaults to today and is required for 'y', which is useful behavior context. However, it doesn't state return values, whether this mutates an existing transaction, or any prerequisites (e.g., account must be reconciled). The mutation nature ('Set') is clear, but richer behavior context would help.

  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 and efficiently structured, with a one-line purpose statement followed by a clean Args block. Each parameter line adds information. No wasted words. Slightly more behavioral context (return/effects) could be added without bloating it, but the current structure is well-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 an output schema (so return format need not be explained) and a modest 3-parameter surface, the description covers purpose, parameter semantics, and conditional requirements well. The state enum values and reconcile_date requirement are the key knowledge an agent needs, and both are present. A tiny bit more about what 'reconcile' means or side effects would round it out, but it's quite complete for the 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 only 33% (only split_guid has a description). The description meaningfully adds to the schema: it documents the valid state enum values ('n'/'c'/'y'), specifies the date format (ISO YYYY-MM-DD), explains when reconcile_date is required, and notes the default behavior. This substantially compensates for the low 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?

  Specific verb+resource: 'Set the reconciliation state for a split.' It clearly states the action (set state) and target (a split), and distinguishes from siblings like get_reconciliation_status and get_unreconciled_splits which are read operations, and reconcile_account which operates at account level rather than split level.

  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 Args section provides clear usage context, including the valid state values ('n', 'c', 'y'), the requirement that reconcile_date is required for 'y', and the default behavior (defaults to today). It doesn't explicitly state when NOT to use this vs alternatives, but the domain context is clear enough.

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

• calculate_lot_gainA
  4.2/5.0
  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 does disclose key behavioral traits: the two calculation modes, defaulting to latest price, defaulting to all remaining shares. However, it doesn't disclose what 'capital gain' means operationally (e.g., how cost basis is computed), whether this is read-only, or the return format. With an output schema present, some of this is mitigated, but the mutation vs read nature is not clear from the description alone.

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

  Conciseness5/5

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

  Two-sentence functional summary followed by a clean Args section. Every sentence earns its place: the mode distinction, the defaults for each parameter, and the lot GUID format. No filler or redundancy. Well front-loaded with the core purpose in the first sentence.

  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 3 params, an output schema present, and a moderately complex two-mode calculation tool, the description covers the mode logic, parameter defaults, and lot identification. It could further explain gain semantics (capital gain formula) or clarify this is a read-only calculation, but for a calculation tool the mode disambiguation is the critical completeness element. The output schema covers return expectations.

  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 33% (only lot_guid has a description in the schema). The description compensates well: it explains lot_guid format (GUID or 8+ char prefix), explains shares defaults to all remaining shares, sale_price defaults to latest price. This adds significant semantic meaning beyond the bare schema, which only describes lot_guid. The shares and sale_price descriptions are absent from schema but well explained in the 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?

  Description opens with a specific verb+resource ('Calculate potential or actual capital gain for a lot') and clearly distinguishes between the two modes: hypothetical gain (with shares+sale_price) vs actual/current gain (using lot state and latest price). This clearly separates it from sibling tools like get_lot, get_latest_price, close_lot, and net_worth.

  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 explains the two usage modes with clear conditions ('If shares and sale_price provided, calculates hypothetical gain. Otherwise uses lot's current state and latest price.'). It doesn't name explicit alternatives, but the mode-based branching gives strong functional guidance. It lacks exclusions or when-not-to-use statements, but context for both invocation paths is clear.

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

• create_jobA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so description carries the full burden. It discloses the employee limitation and describes the container semantics. However, for a creation/mutation tool, it doesn't disclose what happens on success, whether creation is idempotent, or what the output schema provides. Description partially compensates but leaves gaps.

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

  Conciseness5/5

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

  Well-structured with a clear intro sentence, conceptual background in one sentence, and a clean Args block. Every sentence earns its place — the background explanation justifies the tool's existence, and the Args block covers all parameters. No verbosity or repetition.

  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 4-parameter creation tool with an output schema and no annotations, this is quite complete. It documents all parameters, gives a motivating use case, and clarifies edge cases (employees not supported). Minor gaps: doesn't describe return-value semantics beyond what output schema presumably covers, and doesn't mention what happens with a duplicate job name. Given the output schema exists, the description is nearly 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 description coverage is 0%, so the description must compensate fully. It does: owner_id (with example format '000001'), owner_type (customer/vendor, with explicit employee exclusion and reasoning), name (human-readable example), and reference (optional, with examples of PO number/project code). This adds substantial meaning beyond the bare schema with no enum or description. All 4 parameters are documented.

  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?

  Specific verb+resource: 'Create a job for a customer or vendor.' It explains what a job is (groups invoices/bills under a project-level container) and distinguishes from siblings list_jobs/get_job/update_job which operate on existing jobs. The conceptual clarification about multiple engagements for one counterparty adds clear purpose 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?

  Clear context: describes when jobs are useful (multiple distinct engagements per customer needing separate reporting). Specifically notes employees are not supported. However, it doesn't explicitly reference sibling tools like create_customer/create_vendor as prerequisites, nor explicitly say when NOT to use this tool. Lacks explicit alternative naming.

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

• create_voucherA
  4.2/5.0
  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 accounting behavior (post debits expense accounts/credits A/P, pay settles from cash), the voucher counter auto-generation, currency fallback logic, and that vouchers rarely use payment terms. This is rich behavioral context beyond what the schema shows.

  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 with a brief conceptual intro followed by an Args list. The conceptual paragraph about how vouchers behave like vendor bills is valuable context, though it could arguably be trimmed. The Args section is efficiently formatted with defaults and examples inline. Slightly verbose but 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 6 parameters are all documented despite 0% schema coverage, and the accounting behavior is explained. An output schema exists but since the description doesn't describe returned values anyway, that's acceptable. The description is thorough for a creation tool - it covers defaults, format, and behavioral semantics. Could mention response/return format but the output schema covers that.

  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 0%, so the description must compensate entirely. It does this excellently - explaining each of the 6 parameters with defaults, fallback behavior (currency defaults to employee's, then book's), format expectations (ISO dates, e.g. '000001'), and conditional logic (voucher_id auto-generates, term optional because vouchers rarely use them). This far exceeds the bare parameter names 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 'Create an employee expense voucher' with a specific verb+resource. It distinguishes it from related tools like create_bill and create_invoice by explaining it's specifically for employee expense reimbursement, which is helpful 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?

  The description explains the voucher concept well - that it behaves like a vendor bill, with post creating an obligation and pay settling it. However, it doesn't explicitly say WHEN to choose this over create_bill or other alternatives, only implying it through the employee-expense framing.

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

• get_account_slotsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full disclosure burden. It correctly implies a read-only operation ('Read slots') with no side effects disclosed, which is consistent with the tool name. However, it doesn't detail behaviors like error handling for missing accounts, whether the optional key parameter returning null indicates absence, or any permission requirements. For a read-only lookup, the transparency is adequate but not rich.

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

  Conciseness5/5

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

  The description is tight and well-organized. It opens with a one-line purpose, adds context in a supporting paragraph, then documents the two parameters with precise, actionable details. No filler, every sentence earns its place. Front-loaded with the primary purpose statement.

  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 straightforward read tool with an output schema present, this is well covered. It explains the core concept (slots as key-value metadata), documents both parameters thoroughly despite no schema coverage, and the output schema presumably describes the return shape. The main gap is the absence of behavioral notes like what happens on unknown account or key, though the output schema may cover some of this.

  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?

  With 0% schema description coverage, the description must compensate fully, and it does well. It explains the 'account' parameter with three distinct accepted formats (full path, %short GUID, full 32-char GUID) and gives a concrete example. It also clarifies 'key' semantics: specific key retrieval vs. omitting to return all slots. This adds substantial value over the bare input 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 'Reads slots (custom metadata) from an account' with a specific verb+resource. It distinguishes itself from siblings like set_account_slot (write) and delete_account_slot (delete) semantically, and further clarifies the resource type with detailed field-level context (APR, credit limit, reward rates).

  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 what slots are and when you'd use them (key-value metadata), which gives context for usage. It doesn't explicitly state when NOT to use this vs alternatives, but sibling tools set/delete slots are clearly the write counterparts, so the usage domain is reasonably inferred. Could be improved with explicit exclusion of the write variants.

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

• get_invoiceA
  4.2/5.0
  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 makes clear this is a read-only retrieval operation ('Get full details... Returns all entries'), which implies non-destructive behavior. However, it doesn't disclose the return format structure, pagination, or error behavior, though the presence of an output schema reduces the burden somewhat.

  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-organized with a clear opening summary followed by Args documentation. It's compact—two paragraphs plus parameter notes. The only minor inefficiency is the slightly redundant phrasing in the Args section, but it's largely front-loaded and 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?

  With an output schema present, the description needn't explain return values. The two parameters are both well-documented. For a simple retrieval tool with an output schema, the description covers purpose, dual-resource scope, parameter nuance (GUID vs human ID, owner_type disambiguation), which is reasonably complete. Could note what happens without owner_type but that's a minor gap.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must fully compensate. It does: 'id' is explained as the human-readable ID (e.g., '000001') rather than internal GUID, and owner_type is explained with the 'customer' vs 'vendor' mapping and the rationalization for why filtering matters (independent counters). This adds significant meaning beyond the bare 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 ('Get full details'), the resource ('invoice or bill'), and the scope ('including line items'). It explicitly distinguishes itself by covering both customer invoices and vendor bills, distinguishing from sibling get_invoice-like operations. The 'Returns all entries with quantities, prices, and totals' adds concrete detail about what the tool retrieves.

  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 explains that it works for both customer invoices and vendor bills, and the owner_type parameter rationale (independent counters for invoice vs bill) gives clear context on when that parameter matters. However, it doesn't explicitly state when-not-to-use or explicitly name alternatives like list_invoices for enumeration, though the context is clear enough.

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

• income_by_sourceA
  4.2/5.0
  Behavior4/5

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

  The description discloses return format behavior: compact text table by default, structured dict with verbose=true, and a multi-period TSV table with Total/Avg columns when group_by is set. It also explains the group_by overrides verbose interaction. This provides meaningful behavioral context, though it doesn't address side effects/limits (which are largely irrelevant for a read-only report).

  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 compact given it documents 5 parameters and return formats. The parameter descriptions are integrated into the Args block. Each sentence earns its place, though the parameter documentation duplicates what could be inferred from schema in part.

  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 has an output schema and 5 params (2 required). The description covers all parameter semantics including depth meaning, verbose behavior, and the group_by multi-period output. It is self-contained for a read-only reporting tool. No annotation coverage exists but the description compensates with return-format detail.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries full burden. It documents all 5 parameters well: start/end date format (YYYY-MM-DD), depth meaning (1 vs 2 mapping to category levels), verbose behavior, and group_by options with detailed output implications (month/quarter/year sub-period columns, Total and Avg). Strong compensation for zero 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?

  Specific verb+resource: 'Get income breakdown by source for a period.' This clearly distinguishes from sibling report tools (spending_by_category, cash_flow, balance_sheet) by naming the income-by-source scope and period constraint. Clear and differentiated.

  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?

  Implicit usage context is clear: it's a report/category breakdown tool analogous to spending_by_category. The description doesn't explicitly name when-not-to-use or alternative tools, but the 'income by source' vs 'spending by category' distinction in sibling names provides contextual signal. No explicit exclusions or when-to-use guidance is stated in the text itself.

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

• list_lotsA
  4.2/5.0
  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 and does so well. It discloses the default output format (compact one-line-per-lot), what verbose=true does, the meaning of limit=0, and that include_closed controls whether fully-sold lots are shown. It does not mention performance implications or whether this triggers any side effects, but for a read-only list operation on investments that's a minor 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 somewhat long but front-loaded with the core purpose sentence first, followed by the output format details, then the Args block. Every sentence earns its place — the output format description is important for agent expectation-setting, and the Args block is comprehensive without redundancy. Could trim slightly but remains readable 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?

  For a read-only pagination tool with 5 parameters (4 having defaults) and an output schema present, this is complete. It covers output format, defaults, special values (limit=0), accepted account reference formats, and verbose behavior. The output schema presumably documents the return structure, so the description doesn't need to. The only minor gap is not describing error conditions (e.g., invalid account), but that's acceptable.

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

  Parameters3/5

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

  Schema description coverage is 0%, so all 5 parameters are undocumented in the schema. However, the description compensates well by explaining each parameter in the Args section: account (with accepted ref formats), include_closed (with default and meaning), verbose (with behavior), limit (with range and special value 0), and offset (with semantics). This maps closely to the schema fields, so the description adds needed meaning that the sparse schema lacks.

  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 'List all lots for an investment account' with a specific verb and resource, plus scoping. The first line distinguishes it from siblings like list_accounts, list_transactions, and get_lot. The description also details the output format ('Showing X-Y of Z lots' line, one-line-per-lot format), making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description explains pagination, count-only mode, and verbose mode clearly. It mentions 'Use verbose=true for full JSON' which gives guidance on when to use verbose. However, it does not explicitly state when to use this over alternatives like get_lot or calculate_lot_gain, though the purpose is clear enough that alternatives are not ambiguous.

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

• list_transactionsA
  4.2/5.0
  Behavior5/5

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

  With NO annotations provided, the description carries the full burden and does an excellent job. It discloses the leading count line (so truncation isn't mistaken for the full set), pagination behavior with offset, limit=0 count-only semantics, the compact vs verbose output formats, split collapsing behavior (top 3 by |value| plus +N more), and the register form output format. This is exceptionally rich behavioral disclosure.

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

  Conciseness4/5

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

  The description is well-organized with clear sections (leading behavior, formats, collapse behavior, Args). It's front-loaded with the most important caveat (count line) first. However, it's somewhat long and could potentially trim the register form format details, though these earn their place by explaining column semantics.

  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 is comprehensive for a listing tool with an output schema (which presumably documents return structure, so the description needn't repeat that). It covers pagination, formats, collapse behavior, and filter semantics. Given the tool has an output schema and no annotations, this is well-rounded, though it could mention whether results are sorted or the date range default.

  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 0%, so the description must fully compensate, and it does. Every one of the 6 parameters is described: account (switches to register form), start/end dates (ISO format), limit (default 50 max 250, 0=count only), offset (0-indexed), verbose (full JSON details). This adds meaning well beyond the raw schema types, though some details like date format are somewhat obvious from the type.

  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 lists transactions with optional filters, using a specific verb+resource. It distinguishes itself from get_transaction (for full breakdown of a single transaction) and search_transactions implicitly. However, it doesn't explicitly differentiate from search_transactions, which is a sibling, so it doesn't reach a 5.

  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 gives solid when-to-use context: it explains the register form for account filtering, when the '+'N more' collapse happens, and when to call get_transaction for full breakdowns. However, it doesn't explicitly state when NOT to use this tool versus search_transactions or list_transactions alternatives, and doesn't discuss prerequisites like date range requirements.

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

• switch_bookA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the persistent side effect (all subsequent calls and logs operate on the new book until next switch) and the conditional availability (only when 2+ books). However, it doesn't disclose any effects on in-flight operations or whether the switch is reversible, but given it's a niche state tool with no safety annotations, the disclosure is reasonably good.

  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 and front-loaded: first sentence states the core purpose, second line covers persistent side effects, final line states availability condition. Zero wasted words, every sentence earns its place.

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

  Completeness4/5

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

  The tool is simple (single parameter, output schema present) and the availability condition plus behavior are covered. The output schema exists so return values are documented. Could mention what happens with an ambiguous or unmatched name, but the parameter description's 'Must uniquely identify' covers the constraint implicitly. Adequate for the tool's complexity.

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

  Parameters3/5

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

  Schema coverage is 100% — the schema thoroughly describes the 'name' parameter, including case-insensitive prefix matching, unique identification requirement, and pointer to get_server_config for the list. The description adds the behavioral scoping (state persists until next switch) but doesn't add much beyond schema for the parameter itself. Baseline 3 is appropriate since schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the verb (switch), resource (active GnuCash book), and scope (multi-book sessions only). It distinguishes this from siblings — it's the only state-changing operation that affects which book subsequent tool calls operate on, and clarifies it's only present when 2+ books are configured.

  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?

  It explains that this applies to multi-book sessions only and that all subsequent tool calls and audit/debug logs operate on the newly-selected book until the next switch. It doesn't explicitly name an alternative tool, but 'get_server_config' is referenced in the parameter description for listing books, providing directional context. An explicit 'when not to use' for single-book sessions isn't stated, though the '2+ books' condition implies it.

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

• add_bill_entryA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the disclosure burden. It reveals meaningful behavior: the tax component routes to an ASSET account (input-tax credit) per taxtable, and how tax_included affects price extraction at posting. It does not disclose side effects or whether the operation is reversible, but for a line-item addition it covers the key behavioral nuance 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 well-organized with an Args block that is easy to parse, and front-loaded with the core action in the first sentence. Every parameter entry earns its place with format/semantic hints. Slightly longer than strictly minimal, but the tax and tax_included explanations are valuable and justify the 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?

  This is a 9-parameter, 5-required mutation tool with 0% schema coverage and no annotations, so it needs substantial description. The description documents all parameters, key behavioral details (posting constraint, asset tax routing, gross/net handling), and even gives examples for required fields. An output schema exists, so return-format explanation is not needed. Minor gaps: no mention of validation errors or whether bill_id must be an existing bill, but overall strong coverage.

  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 0%, so the description must compensate, and it does: each of the 9 parameters is documented with format hints (decimal strings, examples like 'Expenses:Office Supplies', '000001') and semantic meaning (tax_included gross vs net, action as GnuCash line-type label). This goes well beyond the bare 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 uses a specific verb+resource ('Add a line item to a vendor bill') and clearly distinguishes the tool from its sibling add_invoice_entry / add_credit_note_entry / add_voucher_entry by focusing on vendor bills. It also includes the prerequisite that the bill must not be posted yet, adding concrete scope.

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

  Usage Guidelines4/5

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

  It clearly frames usage as adding line items to vendor bills and includes the 'must not be posted yet' constraint, giving practical context. However, it does not explicitly name alternatives or state when not to use it (e.g., for inventory items vs expense lines), so it lacks an explicit exclusion or alternative-pointer.

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

• create_scheduled_transactionA
  4.3/5.0
  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 several non-obvious behaviors: currency is 'Not updatable after creation — delete and recreate to change it', notes are visible in GnuCash's double-line register view, and quantity is required on commodity-mismatch legs. These are meaningful behavioral traits beyond what the schema reveals. Some gaps remain (e.g., no return-value description, no mention of validation errors), but the key constraints are surfaced.

  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 thorough but somewhat verbose and repetitive. For instance, split details about quantity/commodity are explained both in the top-level description and echoed in the SplitInput $def. The notes section reads awkwardly ('what the payment is — visible in GnuCash's...'). Front-loading is good (purpose first), but it could be tightened without losing 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 9-parameter creation tool with zero schema coverage, the description delivers strong coverage: all params documented, frequency enums listed, currency's edge case articulated, splits format delegated to create_transaction. An output schema exists, partially relieving the need to describe return values. Minor gaps: no mention of duplicate detection, ID return, or error behavior — but the essential usage surface is complete for a complex creation 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?

  Schema description coverage is 0%, so the description must fully compensate. It explains every parameter with format specs (YYYY-MM-DD, decimal strings), enumerates valid frequency values ('weekly', 'biweekly' (2w), 'monthly', 'bimonthly' (2mo), 'quarterly', 'yearly'), clarifies enabled default, and gives a worked example for splits. The currency guidance is especially rich — it explains the exact scenario requiring it and its immutability. This fully compensates for the empty 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 opens with a specific verb+resource ('Create a recurring transaction template'), clearly distinguishing it from the sibling create_transaction (one-off) and create_transaction_from_scheduled (template instantiation). The recurring/template semantics are explicit and unambiguous.

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

  Usage Guidelines4/5

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

  The description states it references create_transaction for splits format ('Same format as create_transaction'), giving the agent a pointer to a sibling for details. It also explains when currency is needed (no leg in book currency, e.g., USD-to-USD card payment in CNY book). However, it doesn't explicitly state 'when NOT to use this vs create_transaction' or mention alternative template-editing tools like update_scheduled_transaction.

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

• delete_accountA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that safeguards exist (deletion blocked with children or transactions), which is valuable behavioral context beyond what 'delete' implies. It doesn't mention permissions/auth requirements, but the safeguard disclosure is meaningful 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 (three short sections) and front-loaded with the purpose. The safeguards and parameter format details are useful. Slight improvement possible by integrating parameter info more naturally, but overall well-structured and lean.

  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?

  This is a single-parameter destructive tool with zero annotations but has an output schema. The description covers the purpose, failure conditions (safeguards), and parameter formats. It's reasonably complete for a simple delete tool, though it could note whether the operation is reversible or describe output 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 0%, so the description must compensate. It does: 'name' parameter is explained as an account ref accepting three formats (full path, %short GUID, or full 32-char GUID). This adds substantial meaning beyond 'Name' 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 deletes an account from the chart of accounts, a specific verb+resource combination. It distinguishes from sibling tools like delete_account_slot, delete_transaction, and delete_budget by specifying the 'chart of accounts' resource 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?

  The description mentions safeguards prevent deletion if the account has children or transactions, giving the agent context on when deletion would fail. However, it doesn't explicitly name alternative tools or state when NOT to use this tool versus other delete operations, though the purpose is clear enough to infer.

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

• delete_customerA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses the mutation behavior (delete), the constraint (only customers without invoices), and the recommended workflow. While it could mention irreversibility, the delete semantics plus the invoice restriction provide solid 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?

  Efficient 4-line description with a clean structure: purpose statement, exclusions, workflow hint, and parameter example. The Args section adds marginal value since there's only one parameter and it's simple, but the example is genuinely useful for format.

  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?

  Has an output schema and only 1 parameter, so completeness burden is moderate. The description covers the core behavioral constraint (no invoices) and prerequisite workflow. It lacks details on error messages/return behavior, but for a delete operation with one clear precondition, this is reasonably 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 0%, so the description must compensate. It documents customer_id with an example format ('000001'), which is useful but minimal addition beyond the schema's string type. No additional semantics about uniqueness, lookup behavior, or validation rules are 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 'Delete a customer with no invoices' using a specific verb+resource combination. It distinguishes itself from siblings like update_customer and create_customer by specifying the delete operation and the critical precondition (no invoices).

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

  Usage Guidelines5/5

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

  Provides explicit exclusions: 'Customers with any invoices (posted or unposted) cannot be deleted' and actionable guidance: 'Delete the invoices first, then delete the customer.' This tells the agent when it can and cannot use this tool versus alternatives.

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

• delete_invoiceA
  4.3/5.0
  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 of behavioral disclosure. It discloses the destructive consequence ('Automatically removes associated entries (line items)'), warns that posted invoices cannot be deleted, and explains the alternative (void or credit note). This covers the key behavioral traits for a delete operation reasonably well, though it doesn't specify idempotency or error behavior for nonexistent invoices.

  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-organized with sections for the main behavior, the associated-entry side effect, posted-invoice handling, and parameter guidance. It is concise and front-loaded with the core purpose. The Args section is formatted clearly with a code-style layout. Minor verbosity in the legacy-alias explanation, but overall 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 tool has an output schema (mentioned in context signals) and two parameters fully documented in the description. The description covers the delete action, side effects (line item removal), preconditions (unposted), and parameter disambiguation. It leaves a small gap around what happens if the invoice_id doesn't exist or error handling, but for a straightforward delete operation with output schema present, it's fairly 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 0%, so the description fully compensates. It explains the 'id' parameter with a format example ('000001' or 'INV-2026-001'), designates it as the preferred parameter matching sibling tools, and explains 'invoice_id' as a legacy alias with the constraint to pass exactly one of the two. This adds substantial meaning beyond the bare 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 states a specific verb + resource: 'Delete an unposted customer invoice.' It clearly distinguishes the tool from siblings through the 'unposted' qualifier and explicitly references alternatives (post_invoice, void, credit note). The scope is precisely defined, differentiating it from delete_bill, delete_credit_note, delete_voucher, and delete_transaction.

  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 context on when the tool applies (unposted invoices) and explicitly states when it cannot be used ('Posted invoices cannot be deleted — void them or issue a credit note instead'), pointing to the alternative actions. It does not name specific sibling tools by name but describes the alternative paths sufficiently.

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

• delete_taxtableA
  4.3/5.0
  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 for behavioral disclosure. It does well: it discloses the refusal behavior, explains that voided invoices still pin their taxtables because voided entry rows persist for audit-trail purposes, and explains the prerequisite ordering. This is substantial behavioral detail beyond simple 'deletes X'.

  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: a clear one-line purpose, followed by refusal behavior, audit-trail nuance, and a prerequisite instruction. The Args section at the end is slightly redundant given the schema, but the whole is compact and front-loaded with the most important behavioral warnings.

  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 (refusal logic, audit-pinning nuance), the description is thorough. An output schema exists, so return values needn't be described. The only minor gap is not explicitly naming alternative tools or documenting error response formats, but the behavioral prerequisites are well covered.

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

  Parameters4/5

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

  The schema has 1 parameter (name) at 0% description coverage, but the description explicitly documents the argument ('name: Taxtable name.'), fully compensating for the schema's lack of description. The parameter semantics are clear and correct.

  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 (Delete) and resource (sales-tax table), with a specific, focused scope. It's distinct from siblings like update_taxtable, create_taxtable, list_taxtables, and get_taxtable, so there's no ambiguity about what this 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 Guidelines4/5

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

  The description provides clear context on when deletion will be refused (when entries reference the taxtable) and instructs the user to remove or re-assign referencing entries first. It doesn't explicitly name alternative tools, but the referral logic is well-explained for correct usage.

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

• get_balanceA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses meaningful behavioral traits: the account ref formats (%short GUID, full 32-char GUID, full path), that future-dated transactions are excluded by default, and that passing an as_of_date past today enables projection including future entries. This is strong behavioral disclosure for a read-only balance tool.

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

  Conciseness4/5

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

  The description is concise and front-loaded — the main purpose and the key temporal nuance appear in the first two sentences. The Args block follows Google-style docstring convention. Slightly redundant wording in the projection sentence ('pass an explicit as_of_date past today' is a bit awkward) but no wasted sentences overall.

  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 2-param read-only tool with an output schema present, the description covers the subtle date semantics thoroughly and documents both parameters in detail. The output schema handles return value documentation. What's missing is a note about edge cases (e.g., what happens with closed accounts or accounts with no transactions), but given there's an output schema and the tool is fairly simple, this is complete enough.

  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 0%, so the description must compensate for both parameters. It does this well: account_name gets the three accepted formats explained, and as_of_date gets both its default behavior and ISO format specification. This is exactly the kind of parameter enrichment needed when the schema provides only field names and types.

  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 a specific verb+resource ('Get the balance of an account') with a clear temporal qualifier ('as of a specific date'). It clearly distinguishes from sibling tools like get_account, list_accounts, get_latest_price, and create_transaction. The purpose is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description clearly explains the date semantics (defaults to today, excludes future-dated transactions) and explicitly tells users when to pass an explicit as_of_date to project forward. While it doesn't name alternative tools for projection ('create_transaction' or budget tools), the temporal boundary guidance is clear. It lacks explicit 'when NOT to use' guidance distinguishing from get_account, but the core use case is well-delineated.

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

• get_budgetA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full transparency burden. It discloses the default compact table behavior, the collapsing of uniform periods with an example, and the verbose alternative. It also mentions the return format ('compact text table'). It doesn't mention side effects (implying read-only, which aligns with the read-like name), does not note permissions/errors, but the behavioral disclosure is substantive and useful.

  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 tight and front-loaded: first line states the primary purpose, then the compact-vs-verbose behavior, then a clear Args section. Every sentence earns its place — no fluff, no repetition of tool name or schema titles. The example ('250/mo (all periods)') is illuminating, not padding.

  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 two simple params (one string, one boolean with default), no nested objects, and an output schema present, the description covers the behavioral nuances (compact vs verbose return) well. The compact-table collapse behavior is the key differentiator and is clearly explained. The presence of an output schema relieves the description of returning-format burden. This is complete for a tool of this complexity.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate for the two parameters. It does explain both: 'name: Budget name.' and verbose behavior is described in prose ('Use verbose=true for the full structured periods dict per account'). Both params are covered at a basic level. However, the description for name is minimal (just 'Budget name') with no details on format, case sensitivity, or how to find valid names — though at least it addresses both parameters, earning the 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?

  Description clearly states 'Get full details of a budget including all budget amounts' with a specific verb+resource. It distinguishes from siblings like list_budgets (listing vs details), get_budget_report (report vs full details), and set_budget_amount (write vs read). The purpose is unambiguous.

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

  Usage Guidelines4/5

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

  The description explains the compact vs verbose return mode and when to use verbose=true ('Use verbose=true for the full structured periods dict per account'). It implicitly differentiates from list_budgets/get_budget_report by focusing on full details, though it doesn't explicitly name alternative tools or state when NOT to use this tool. Clear context but no explicit exclusions of sibling tools.

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

• get_latest_priceA
  4.3/5.0
  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 of behavioral disclosure. It does a good job: it explains the return format (JSON with date, value, type, source), documents the null-return case when no price exists, and explains the currency defaulting behavior. It could disclose more (e.g., error handling, whether latest means by date), but the key behaviors are covered.

  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-organized with Args and Returns sections, and each parameter gets a one-line explanation. It's moderately compact without wasted words. Minor inefficiency: currency explanation is slightly redundant ('Defaults' vs 'Pass explicitly' could be tighter), but the structure is clean and front-loaded with the purpose statement.

  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?

  Despite having no annotations, the description covers purpose, parameters with examples, return format, and edge case (null). Since an output schema exists, the Return shape doesn't need full elaboration. For a read tool with good sibling differentiation, this is reasonably complete. Could add a note on when get_prices would be preferred for historical data, which prevents a 5.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate for all three parameters, and it does well. It explains commodity with an example ('VTSAX'), namespace with an example ('FUND'), and currency with its defaulting behavior and when to pass it explicitly. This meaningfully enhances what the bare schema (just string titles) provides.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the most recent price for a commodity, specifying a clear verb+resource combination. It distinguishes from siblings like get_prices (plural, likely range-based) and delete_price by explicitly targeting the 'most recent' price. The 'Returns' section clarifies output format (date, value, type, source) and documents the null-return behavior, making the purpose fully clear.

  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 clearly explains when to use this tool (to get the latest price) and how to handle currency (explicitly passing currency to get non-default quotes). It does not explicitly name alternative tools like get_prices for historical queries, but the sibling context plus the 'most recent' emphasis implies the differentiation. It lacks explicit 'when not to use' guidance, so not a full 5.

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

• list_employeesA
  4.3/5.0
  Behavior4/5

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

  This is a read-only listing operation, so no destructive/mutating disclosure is needed. The description transparently documents output defaults (compact format by default, verbose switch), the leading count line, and the active_only default filtering. It conveys the tool's behavior well beyond what a bare schema would show.

  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 with a clear lead sentence, a compact behavior overview, and bullet-style Args section. Each sentence adds value. Slightly more verbose than strictly necessary, but the information density is high and well-organized.

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

  Completeness4/5

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

  For a listing tool with an output schema, pagination, and a count-only mode, the description covers all key operational aspects: pagination mechanics, formatting modes, defaults. The output schema handles return-value documentation. It's complete for this tool's complexity level.

  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 0%, so the description carries full responsibility for parameter meaning. It explains all four params (active_only, verbose, limit, offset) with semantics beyond the schema, including defaults, max values, special-case behavior (limit=0 = count only), and active_filter default. This fully compensates for the zero schema coverage.

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

  Purpose5/5

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

  The description clearly states 'List all employees' with a specific verb+resource, and further distinguishes itself from siblings by describing the output format (compact one-line-per-employee, count-only mode, full JSON with verbose). It's unambiguous and differentiates from list_customers and list_vendors.

  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 solid usage guidance covering pagination (offset, limit), count-only mode (limit=0), and output format selection (verbose=true). It doesn't explicitly state when NOT to use this tool vs alternatives like get_employee, but the context of listing vs single-fetch is reasonably implied.

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

• list_jobsA
  4.3/5.0
  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 documents several behavioral details: leads with a count line, compact rows vs full JSON dicts based on verbose, default active_only=True behavior, and pagination semantics. This adds significant value beyond the schema.

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

  Conciseness5/5

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

  The description is well-organized with an intro line followed by a bulleted Args section covering all 6 parameters. Every sentence earns its place—no fluff or redundant information. The structure makes key behaviors (count line, pagination) front-and-center.

  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?

  There is an output schema present, so return values need less explanation. The description covers the key behaviors: count line, pagination, filters, output formats. It's adequate for an optional-filter list tool, though it could note how verbose=False rows differ exactly (tsv structure) without relying on the 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 description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with its values and defaults (owner_type filter options, owner_id prerequisite, active_only default, verbose output format, limit page size/max/count semantics, offset indexing). This is comprehensive.

  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 'List jobs, optionally filtered' using a specific verb+resource. It doesn't explicitly distinguish from sibling tools like get_job or get_job_report, but the plural 'list' naming and description make the list-vs-get distinction obvious from 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?

  The description provides clear guidance on how to use the tool: page with offset, pass limit=0 for count-only, filter by owner_type/owner_id, active_only behavior. It doesn't explicitly state when NOT to use this tool or offer alternatives, but the usage patterns are clearly documented.

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

• list_scheduled_transactionsA
  4.3/5.0
  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 default output format (compact one-line-per-schedule), the count-only behavior with limit=0, pagination semantics, and that verbose returns full JSON. It does not mention whether enabled_only filters out disabled schedules by default beyond parameter docs, though the Args section covers this. Good disclosure for a read-only listing 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 the core purpose in the first line, then uses a helpful structured Args section. The output-format explanation (count line, compact format, verbose) is valuable in the prose. Could tighten slightly but the structured parameter documentation justifies the 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?

  A listing tool with 4 optional parameters, an output schema present, and no nested objects. The description adequately covers output format quirks (count line, limit=0 behavior, verbose full JSON) and pagination, which are the nontrivial aspects. With an output schema available for return values, this is reasonably complete for a list operation.

  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 0%, so the description must compensate for all 4 parameters. The Args section explains each: enabled_only (default True), verbose (full JSON), limit (page size, 0=count only), offset (0-indexed). This adds meaningful semantics beyond the bare schema, which only shows titles and defaults. Not a 5 because some nuances (e.g., max 250 boundary) are mentioned but parameter interdependencies are light.

  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 'List all scheduled transactions' with a specific verb+resource. It distinguishes itself by covering the list output format (count line, one-line-per-schedule), pagination behavior, and verbose mode for full JSON details. Distinguishes from siblings like create/update/delete/get_upcoming.

  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?

  Description gives explicit guidance on pagination (offset/limit), count-only mode, and verbose mode. However, it does not explicitly name alternative tools for filtering (e.g., get_upcoming_transactions for date-specific queries) or state when NOT to use this tool. Context is clear but exclusions are absent.

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

• list_vendorsA
  4.3/5.0
  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 helpful behavioral details: the 'Showing X-Y of Z vendors' leading line, default compact format, limit=0 count-only semantics, and that active_only defaults to True (implying inactive vendors are hidden unless explicitly requested). These behaviors go beyond what the schema reveals.

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

  Conciseness4/5

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

  The description is moderately sized but front-loads the essential behavior in the first two sentences, then systematically documents each parameter. The multi-line Args block is clearly structured. Slightly verbose in places but earns its 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?

  The tool has 4 parameters, no annotations, and schema coverage of 0%, but has an output schema. The description explains output format, pagination rules, special cases (limit=0, verbose mode), and document each parameter's semantics including defaults. Given no annotations exist, the description does a strong job of covering the behavioral surface. The output schema presumably covers return structure, so return format isn't a gap.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must carry the weight for all 4 parameters. It does well: explains active_only (filter behavior + default True), verbose (full JSON with guid, address, notes), limit (page size, max 250, 0=count only), and offset (0-indexed, default 0). The active_only default being hidden by schema default is explicitly called out.

  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 'List all vendors' with a specific verb+resource. It distinguishes itself from siblings like create_vendor, get_vendor, update_vendor, and delete_vendor by focusing on listing. The additional detail about output format (count line, one-line-per-vendor) further clarifies scope.

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

  Usage Guidelines4/5

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

  The description explains output format nuances, pagination with offset, limit=0 count-only behavior, and verbose mode. It clearly says when to use verbose=true. However, it doesn't explicitly say when NOT to use this tool vs alternatives (e.g., when to use vendor_spending_report), but the context is reasonably clear for a listing operation.

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

• search_transactionsA
  4.3/5.0
  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 key behavioral traits: the pagination header 'Showing X-Y of Z transactions', the split-collapsing behavior for >4 splits, the compact vs verbose output mode, and the default/return behavior. This is substantive disclosure of behavior 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.

  Conciseness4/5

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

  The description is well-organized with a compact-format spec first, then the search-result behavior, then a clear Args section covering all 5 parameters. It's front-loaded with the essential purpose and output format. Slightly verbose in the amount-syntax explanation but each part earns its place and no sentence 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?

  There is an output schema present which reduces the burden of explaining return values. The description covers the compact format's structure, collapse behavior, pagination mechanics, and all parameter semantics comprehensively. The only minor gap is not explicitly clarifying edge cases in amount parsing, but this is well covered for a search tool with a strong output schema.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate fully. It does: explaining query syntax for amounts (exact '100', greater '>100', less '<100', range '100-200'), field choices, limit semantics (default 50, max 250, 0=count only), offset semantics (0-indexed), and verbose flag behavior. This is rich parameter documentation well beyond the bare 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 'Search transactions by description, memo, notes, or amount' with a specific verb (search), specific resource (transactions), and the fields being searched. It distinguishes well from siblings like list_transactions and get_transaction by specifying search-by-field semantics and describing the compact output 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 explains how to page with offset, use limit=0 for count-only, and calls out that transactions with >4 splits collapse to top-3 with '+N more' requiring get_transaction call. It gives clear context on when to use this tool (searching across fields) though it doesn't explicitly name alternatives like list_transactions or get_transaction as exclusions, relying on the implicit distinction via output format description.

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

• update_jobA
  4.3/5.0
  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 that unspecified fields are left unchanged (patch semantics), that the return is diff-style, and that deactivation via active=False preserves history. This is valuable behavioral context beyond the schema. It doesn't address authorization/rate limits, but for a mutation tool the disclosed semantics are substantive.

  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?

  Well-structured with a clear top-line summary, then semantics, then per-parameter Args list. The docstring format is scannable and front-loaded. Slightly verbose in places but every sentence earns its place, including the important history-preservation note.

  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 4-param tool with an output schema and no annotations, this description covers the essential semantics: partial updates, optional fields, the deactivation semantics, and diff-style return. It could mention what happens with an invalid/unknown job_id or include permissions requirements, but it is largely complete for a mutation tool of this 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 description coverage is 0%, and the description compensates well. It explains each parameter's purpose, flags that all except job_id are optional, and clarifies the nuanced behavior of the 'active' parameter (pass False to deactivate, implying it defaults to not changing). This adds meaningful meaning beyond the bare schema types.

  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 (update) and resources (job's name, reference, active state). Explicitly distinguishing from delete_job by describing the 'active' flag as a way to deactivate without deleting. The patch-style semantics ('any subset of fields') are clearly communicated.

  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 explains partial-update behavior and explicitly discusses the 'active' flag use case (deactivate a completed job without deleting, preserving history). It doesn't explicitly name alternative tools, but given the sibling list includes delete_job, the semantics imply this is for mutation while delete_job is for removal. It lacks explicit 'when not to use' guidance but has clear context.

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

• balance_sheetA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses an important behavioral detail: that A=L+E holds by construction and non-zero unrealized P&L appears as a synthetic equity row. This is genuinely valuable behavioral context beyond the schema. However, it doesn't disclose details like performance characteristics, data freshness, or permissions, though the disclosed construction detail is substantial.

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

  Conciseness4/5

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

  The description is efficiently structured with a summary line, a details paragraph, and a well-organized Args section. Every sentence provides value. Slightly verbose in the default-date explanation but the rationale for tying to get_book_summary is operationally important, so it 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 tool has an output schema (so return values needn't be explained), only 1 parameter, and no annotations, the description covers the essential semantic territory well. It explains the date parameter thoroughly, discloses the synthetic equity behavior, and provides cross-tool context. Minor gap: doesn't mention how it relates to or differs from net_worth or get_balance among financial reporting siblings.

  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 0% description coverage and only defines as_of_date as a nullable string with null default. The description compensates excellently by explaining the ISO format (YYYY-MM-DD), the default behavior (today), the rationale for matching get_book_summary's cutoff, and when to pass an explicit date. This adds meaningful semantic value beyond the bare 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 generates a balance sheet as of a specific date, showing assets, liabilities, and equity with account breakdowns. It distinguishes itself from sibling reporting tools by specifying the date-based snapshot nature and the accounting identity (A=L+E), making the purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly explains when to use an explicit as_of_date (historical snapshots) versus defaulting, and connects the default behavior to get_book_summary's implicit cutoff for cross-tool comparison. It provides clear context for usage but doesn't explicitly exclude alternatives or state when NOT to use this tool versus net_worth or get_balance.

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

• create_priceA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavior disclosure. It transparently reveals the upsert semantics, the currency default interaction with book currency, and default values for date, price_type, and source. The behavior that updates rather than duplicates is a significant disclosure not inferable from the schema. It doesn't describe return values, but output schema exists to cover that.

  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 using Args blocks, which aids scanning. It's thorough, covering all 7 parameters plus upsert behavior. It's slightly long but every sentence earns its place given the 0% schema coverage. 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?

  For a 7-parameter tool with zero schema description coverage and no annotations, the description thoroughly compensates. It explains defaults, edge cases (currency), and value formats. The worked example for currency is especially valuable. Output schema exists so return values need not be explained. It's complete 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 description coverage is 0%, so the description must fully compensate — and it does. Every parameter is explained: commodity as symbol, namespace as commodity namespace, value as decimal string, currency with a worked example of the default-currency behavior, date as ISO format, price_type with enumerated meanings, and source identifier default.

  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 a specific verb ('Record a price') and resource ('commodity (stock, NAV, exchange rate)'). It clarifies the critical upsert behavior — existing price with same commodity/currency/date/source is updated rather than duplicated. This distinguishes it from sibling tools like create_prices (batch) and get_prices (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?

  The description provides clear context around currency defaults, explaining the natural reading for default-currency behavior and instructing when to pass currency explicitly (cross-currency pairs not involving the book default). It also documents defaults for date and source. It lacks explicit when-not-to-use guidance or alternative tool names, but the context given is substantive and actionable.

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

• get_outstanding_invoicesA
  4.4/5.0
  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 and largely meets it. It discloses the response format (lead line, compact rows), sorting behavior (overdue-first), pagination semantics, and the limit=0 count-only behavior. It could add detail on whether it returns posted-only by default or any filtering nuances, but overall it's transparent about its 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?

  Well-structured with a clear purpose statement, behavioral detail, and an Args section that's easy to scan. Slightly verbose with the markdown formatting examples, but every sentence earns its place. The leading behavior summary is front-loaded before the Args detail.

  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?

  This is a complex tool with 6 parameters and no annotations, yet the description covers the output format, sorting, pagination, count-only mode, and verbose flag's downstream use in pay_invoice workflows. It's essentially complete for an agent to select and invoke correctly. An output schema exists, reducing the need to describe return values.

  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 0%, so the description must fully document parameters, and it does. Every parameter (owner_type, customer_id, vendor_id, verbose, limit, offset) has an explicit one-line explanation with defaults and semantics (e.g., 'limit=0 returns the count only', '0-indexed first row'). This fully compensates for the zero 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?

  Clear verb+resource+scoping: 'Get all posted invoices/bills with outstanding balances.' Distinguishes from list_invoices by emphasizing 'outstanding balances' and mentioning the verbose mode that feeds pay_invoice workflows. The description adds meaningful detail about sorting (most-overdue-first) and default formatting (compact one-line-per-doc) that differentiates this from siblings.

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

  Usage Guidelines4/5

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

  Provides strong usage context: describes the output format, count-only behavior via limit=0, pagination with offset, and explicitly states verbose=true is the shape pay_invoice workflows expect. However, it doesn't explicitly contrast this with list_invoices or say when NOT to use it, leaving some sibling-differentiation implicit.

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

• get_upcoming_transactionsA
  4.4/5.0
  Behavior4/5

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

  The description reveals meaningful behavioral details beyond the schema: returns a summary line 'Showing X-Y of Z upcoming transactions', sorts soonest first, and documents key behaviors like limit=0 returning count only and verbose mode changing output format. No contradictions with annotations (none provided).

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

  Conciseness5/5

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

  Well-structured with a clear lead framing, a 'what bills are coming up?' hook, then a compact Args section. Every line serves a purpose—no filler, no repetition of schema defaults that aren't useful.

  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 read-only paginated listing tool, the description is thorough. An output schema exists so return value documentation burden is reduced. Could mention what happens with no scheduled transactions, but given good annotations-free disclosure of format and paging, this is very solid coverage.

  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 0%, so the description carries the full burden of explaining parameters. It describes each arg's purpose and default: days (look-ahead window), verbose (full JSON vs compact line), limit (page size with count-only special case), offset (0-indexed pagination). This is genuinely additive beyond the bare 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 this lists scheduled/upcoming transactions due within a time window, with the specific 'what bills are coming up?' use case. It distinguishes from siblings like list_transactions and search_transactions by focusing specifically on scheduled/recurring transactions due soon.

  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 makes the use case explicit ('what bills are coming up?') and explains pagination and the leading summary line format. It doesn't explicitly contrast with alternatives like list_scheduled_transactions or create_transaction_from_scheduled, but the purpose framing gives clear context for when to use it.

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

• list_billtermsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full responsibility. It discloses the leading 'Showing X-Y of Z billterms' summary line, the default compact format vs verbose output, pagination behavior, and the count-only mode via limit=0. This is meaningful behavioral context beyond what a schema alone would convey.

  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 well-structured: a one-sentence purpose, a behavior overview paragraph, and a clean Args section. Every sentence earns its place with concrete details (defaults, max, special values) and zero filler.

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

  Completeness4/5

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

  For a list tool with an output schema present, the description covers the key user-facing behaviors: output format, pagination, count-only, and verbosity control. It doesn't need to describe return values since an output schema exists. Minor gap: doesn't mention max 250 limit in the Args section vs overview, but the overview-carrying version is present.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate entirely. It explains all three parameters: verbose (full JSON vs compact), limit (page size, default 50, max 250, 0=count only), and offset (0-indexed first row). This goes well beyond what the raw schema types/defaults convey.

  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 'List all billing terms' with a specific verb and resource. It distinguishes itself from siblings by describing the compact output format and verbose option, which is unique to this listing tool.

  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 explains the default output format ('one-line-per-term format by default'), how to page with offset, use limit=0 for count-only, and when to use verbose=true for full JSON. It gives clear context on invocation options but doesn't explicitly name alternative tools or when not to use it, which is acceptable for a list operation.

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

• list_budgetsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It explains the default compact format, the 'Showing X-Y of Z' lead line, pagination semantics, limit=0 count-only behavior, and the difference between verbose and default output. This is strong behavioral context though it doesn't disclose performance or rate-limit characteristics.

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

  Conciseness5/5

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

  The description is compact and front-loaded. The first sentence states the core purpose, followed by a brief paragraph on output format and pagination, then a terse Args block. Every sentence earns its place with zero filler.

  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 output format, pagination, count-only mode, and verbose mode. An output schema exists, so return-value details beyond the envelope distinction aren't required. It could mention the verbose field's interaction with the envelope more, but overall it's complete for this 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 description coverage is 0%, so the description must fully compensate. It does: verbose=true explained as returning the full JSON envelope, limit explained as page size with default 50, max 250, and 0=count-only, offset explained as 0-indexed first row. This adds substantial meaning beyond the bare schema field names.

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

  Purpose5/5

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

  The description clearly states the tool 'Lists all budgets in the book' with a specific verb (list) and resource (budgets in the book). It also describes the output format, pagination, and verbose mode, distinguishing it from siblings like get_budget and create_budget.

  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?

  While it doesn't explicitly name alternative tools, the description gives clear context on when to use each parameter (limit, offset, verbose) and the tool's purpose is clearly for listing all budgets. It covers paging behavior and count-only mode. It lacks explicit when-not-to-use guidance but the verb+scope distinction from get_budget/create_budget is implied.

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

• replace_splitsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses critical behaviors: splits must balance to zero, unchanged legs preserve memo and reconcile state, and force is required for changing reconciled splits or removing from lots. This is strong behavioral disclosure for a destructive mutation tool, though it doesn't cover what happens on failure 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.

  Conciseness4/5

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

  The description is well-structured with a summary paragraph, behavioral notes, and an Args section. It's somewhat verbose but each section earns its place, particularly the UNCHANGED leg explanation which is genuinely useful. Front-loads the core purpose before details.

  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 having an output schema and only 33% schema coverage, the description thoroughly covers all 3 parameters, the split sub-object semantics, balancing requirements, reconcile-state behavior, and force requirements. It's complete for a complex mutation tool with no annotations.

  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 only 33% (only guid described), so the description must compensate. It does, providing detailed semantics for splits (account ref formats including full path, %short GUID, full GUID; amount in transaction currency; quantity required when commodity differs; memo override behavior). The description meaningfully extends the sparse schema documentation.

  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 (replace) and resource (all splits in a transaction) and distinguishes this from siblings by specifying it replaces splits with a completely new set. It also states what is preserved (currency, description, date, notes), disambiguating it from related transaction tools.

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

  Usage Guidelines4/5

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

  The description explains when the tool is safe, specifically that resubmitting an unchanged reconciled bank leg keeps its state, making recategorization safe. It also documents the 'force' requirement for when changes would alter reconciled splits. It doesn't explicitly name alternative tools (like update_transaction or assign_split_to_lot) for when not to use this, which prevents a 5.

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

• set_budget_amountA
  4.4/5.0
  Behavior4/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 this is a mutation (setting targets), describes the account reference formats accepted (full path, GUID, short GUID), and documents the period semantics including default behavior. It doesn't state idempotency or whether existing budget amounts are overwritten, 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.

  Conciseness4/5

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

  The description is well-structured with a clear one-line summary followed by labeled Args documentation. Each parameter gets its own line with format explanation. Slightly verbose with the numbered period list but every sentence earns its place.

  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?

  The tool has 4 parameters (3 required), 0% schema coverage, and an output schema exists. The description exhaustively covers all parameters including format expectations and period semantics, which is the critical missing info. The output schema handles return-value documentation, so the description is complete for this moderately complex 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 description coverage is 0%, so the description must compensate fully. It does: account format is documented with examples ('Expenses:Groceries'), amount format is exemplified ('500.00'), and period semantics (None/all, integer, quarter strings) are exhaustively covered. All 4 parameters have added meaning 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 'Set a budget target for an account' with a specific verb (set) and resource (budget target for an account). It distinguishes from siblings like create_budget (creates the budget definition) and get_budget (reads), making the mutation purpose clear.

  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 context on the primary use case (setting budget targets), and the period parameter options explain how to target specific periods vs all. However, it doesn't explicitly name alternative tools or exclude cases (e.g., when to use create_budget instead), though the task distinction is inferable from siblings.

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

• spending_by_categoryA
  4.4/5.0
  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 output format behavior (text table vs dict, TSV table with Total/Avg columns when group_by is set) and the override relationship (group_by overrides verbose). It could add more about edge cases (empty periods, date validation) but the core behavioral traits are disclosed.

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

  Conciseness4/5

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

  The description is well-structured with an overview sentence followed by a compact Args block. It front-loads the purpose and output format before parameter details. Slightly verbose with the full sentence explanations per arg, but each earns its place by adding meaning beyond the schema. Could be tightened but is efficient overall.

  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 an output schema present and 5 parameters, the description handles the core behaviors well: output format switching, group_by multi-period behavior, and hierarchy depth. Minor gaps: no mention of what happens with overlapping dates or default period behavior, but for a read-only reporting tool the coverage is strong.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description fully compensates. It documents all 5 parameters: start_date and end_date with format (YYYY-MM-DD), depth with hierarchy levels (1=top-level, 2=subcategories), verbose with programmatic consumer rationale, and group_by with valid values and behavioral effect (multi-period TSV, overrides verbose). Every parameter receives meaningful semantics beyond the bare 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 ('Get spending breakdown'), the resource ('by expense category'), and the scope ('for a period'). It distinguishes itself from siblings like income_by_source (income vs spending) and vendor_spending_report (category vs vendor breakdown). The purpose is specific and immediately understandable.

  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 explains the two output modes: default compact text table vs verbose structured dict for programmatic consumers/plotting, and the group_by override for multi-period analysis. This gives clear guidance on when to use verbose mode. However, it doesn't explicitly name alternatives or state when NOT to use this tool vs report siblings, though sibling differentiation is fairly obvious.

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

• update_customerA
  4.4/5.0
  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 does an excellent job: discloses that currency here is the customer's *default* trading currency for future documents (not retroactive), that 'false' for active archives without deleting, and that address merges onto existing (with empty string to clear). These are non-obvious behavioral nuances 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.

  Conciseness4/5

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

  Well-organized as a top-line summary followed by an Args block. Each parameter gets a compact bullet. Slight redundancy with the notes parameter already having a schema description, but the functional trade-off is minor given the poor overall schema coverage. No wasteful filler.

  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 6-parameter mutation tool with no annotations and only 17% schema coverage, this description is thorough. It covers all parameters, explains mutation semantics, archival behavior, currency non-retroactivity, and address merging. An output schema exists so return-value detail isn't needed. This is comprehensive for the complexity level.

  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 17%, so the description must compensate. It adds meaning to essentially every parameter: id format example, currency notation ('default' trading currency), notes clearing semantics ('Pass "" to clear'), active deactivate/reactivate meaning, and address partial-merge behavior with sub-field clearing. This significantly exceeds what the sparse 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 'Update an existing customer' with specific verb+resource. It specifies the partial-mutation semantics ('Mutates only the fields supplied; everything else stays') and distinguishes this from the create_customer sibling by focusing on updating rather than creating.

  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 explains the partial-update semantics clearly ('Mutates only the fields supplied; everything else stays'). However, it doesn't explicitly name alternatives or state when not to use this tool versus create_customer/update_vendor/update_employee, though the intended usage context is reasonably inferable.

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

• add_credit_note_entryA
  4.5/5.0
  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 several important behaviors: the credit-note flag inverts posting/tax-split direction at post time (not entry-add time), prices stay positive, and the slot flag acts as the gate for validating the target is a credit note. It does not mention auth requirements or failure modes, but the core behavioral nuances are well disclosed.

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

  Conciseness4/5

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

  The description is compact and front-loads the core purpose in the first sentence, then structures parameter details in a clear Args block. It's somewhat long given the 10 parameters, but each sentence earns its place by adding meaning. Formatting with backticks and line breaks aids 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?

  With 10 parameters, 0% schema coverage, and no annotations, this is a complex tool requiring full documentation — and it delivers. It explains the run-time inversion behavior, tax handling, owner-type constraints, and optional disambiguation. The output schema exists, so return-value documentation isn't required. Minor gaps: no explicit prerequisites (e.g., must the credit note exist/unposted?) or error scenarios.

  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 0%, so the description must compensate for all 10 parameters — and it does. Every parameter is explained: credit_note_id format, account owner-type rules, owner_type disambiguator, taxtable semantics tied to posting-time inversion, tax_included meaning, notes purpose/limit, and action conventions. Only minor detail is missing on quantity/price decimal-string validation beyond their types.

  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 'Add a line item to a credit note' — a specific verb+resource. It explicitly mirrors add_invoice_entry/add_bill_entry while distinguishing itself by the credit-note slot-flag validation, which differentiates it from its closest 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 names the sibling alternatives (add_invoice_entry / add_bill_entry) and explains when this tool is appropriate vs the non-credit twins. It also gives account-type rules (INCOME for customer, EXPENSE/ASSET for vendor) and owner_type disambiguation guidance — clear context on when to use it and how to configure it correctly.

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

• add_invoice_entryA
  4.5/5.0
  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 does disclose key behaviors: the invoice must not be posted, tax behavior at posting time (multi-entry taxtables produce one split per entry), and how tax_included affects price interpretation. However, it doesn't fully describe what happens on error (e.g., if invoice is posted), what gets destroyed/reverted, or the exact return behavior. The tax timing disclosure is genuinely useful beyond schema.

  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-organized with a clear header paragraph, precondition statement, and a labeled Args section mapping directly to the parameters. Somewhat long but every section adds value — no wasted words. The Args section mirrors the schema property names for easy cross-referencing.

  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 9-parameter mutation tool with no annotations, 0% schema coverage, and no sibling clarification needed, this description is thorough. It explains all parameters with examples, discloses the posting and tax-timing behavior, and gives the GnuCash convention for the action field. No output schema is needed since the tool's behavior is self-explanatory in terms of what it mutates (adds a line). This is a complete description.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate fully. It does: every parameter gets a detailed explanation including examples (invoice_id '000001', account 'Income:Sales', quantity '1'/'2.5', price '100.00'). It explains meaning beyond types for taxtable (tax components at posting), tax_included (gross vs pre-tax), notes (what doesn't belong on printed line), and action (GnuCash convention).

  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 'Add a line item to a customer invoice' with a specific verb (add) and resource (invoice entry). It distinguishes from siblings like add_bill_entry (bill vs invoice) and add_voucher_entry (voucher vs invoice). It also adds an important precondition ('The invoice must not be posted yet').

  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 gives clear context on when to use this tool (adding line items to invoices, before posting), and the sibling names help distinguish from add_bill_entry for bills. However, it doesn't explicitly name alternative tools or state when NOT to use it (e.g., after posting), though 'must not be posted yet' implies that constraint. It doesn't mention when to use post_invoice vs this.

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

• add_voucher_entryA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full disclosure burden. It clearly reveals that tax_included=true means price is gross with pretax extracted at posting, and notes have a 4096-byte limit. It doesn't describe authorization requirements, but given no annotations the disclosure of mutating behavior and edge cases (tax handling, size limits) is reasonably strong.

  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 organized with a clear intro paragraph followed by a parameter list with examples. It's somewhat verbose but each line adds value — examples for decimal strings and account paths are genuinely useful. The taxtable reference to add_bill_entry avoids repetition. A slight trim of the 'typically a separate expense category' line could tighten it.

  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 9-parameter tool with 0% schema coverage, the description is comprehensive: all parameters documented with types and examples, and even an output schema exists to cover return values. Preconditions (not posted, account type) and edge cases (tax_included, notes byte limit) are addressed. Minor omissions: no mention of error conditions or behavior when voucher_id is invalid, but overall quite 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 description coverage is 0%, so the description must fully compensate. It documents all 9 parameters with concrete examples for voucher_id ('000001'), account ('Expenses:Meals & Entertainment'), and decimal-string formats for quantity and price. It adds semantics for taxtable (optional, references add_bill_entry), tax_included (gross vs pretax), notes (max bytes, examples), and action (GnuCash conventions with examples). Only marginal gaps remain around 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 states 'Add a line item to an employee expense voucher' with a specific verb+resource combination. It distinguishes context by noting the voucher must not be posted yet and that each entry is typically a separate expense category, which positions it against sibling tools like add_bill_entry and add_invoice_entry.

  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 this tool can be used ('The voucher must not be posted yet'), gives a prerequisite condition, and clarifies the account type restriction ('Account must be EXPENSE or ASSET'). It also references add_bill_entry for taxtable semantics, providing cross-tool context.

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

• cash_flowA
  4.5/5.0
  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 discloses that internal transfers are filtered by default, explains what the default totals represent, and clarifies that account= of any type works despite the narrow default. It does not, however, disclose return format beyond the group_by TSV case, or any auth/permission requirements. Still, the core filtering behavior is well documented.

  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 with a clear summary paragraph followed by an Args section. It is moderately long but every sentence earns its place — scope definition, exclusion guidance, filtering behavior, and use cases are all packed efficiently. The prose is tight and front-loaded with the core purpose before diving into edge cases.

  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?

  There is an output schema present, so the description doesn't need to explain all return values. For a 5-parameter analytical tool with subtle default behaviors (narrow scope, transfer filtering), the description covers the key semantic complexity comprehensively. It could mention output format for the default case (beyond the TSV mention for group_by), but the presence of an output schema mitigates this gap.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must fully compensate for all 5 parameters. It does: start_date/end_date get format hints (YYYY-MM-DD), account gets default behavior explained, include_transfers gets detailed True/False semantics, and group_by gets the allowed values plus output behavior ('split the range into sub-period columns, Inflows/Outflows/Net trend table'). This is strong compensation for zero schema coverage.

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

  Purpose5/5

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

  The description opens with a clear verb+resource+scope statement: 'Calculate cash flow (inflows and outflows) for a period.' It explicitly defines the default scope (BANK and CASH accounts) and distinguishes itself from balance_sheet for credit-card/investment movements. The distinction from siblings is notable and specific.

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

  Usage Guidelines5/5

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

  The description explicitly states when NOT to use this tool (credit-card/investment movements should use balance_sheet), explains the default filtering behavior for internal transfers, and gives a concrete use case for include_transfers=true ('reconciling against a bank statement'). It also explains the conceptual distinction between 'where did money come from' vs 'every debit and credit.'

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

• create_backupA
  4.5/5.0
  Behavior5/5

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

  No annotations provided, so the description carries full burden. It richly discloses concurrency safety via SQLite online backup API, integrity verification with PRAGMA integrity_check, deletion of bad backups and raising on failure, indefinite retention (not touched by auto-retention), and the restore_hint in the response. This is exemplary behavioral disclosure beyond any structured field.

  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?

  Well-organized multi-paragraph structure covering safety, retention, restore, and args. Every sentence adds distinct value. Slightly longer than strictly necessary, but the density of useful information justifies the 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 tool with one optional param, an output schema, and considerable behavioral nuance (concurrency, integrity, retention, restore), the description covers all relevant aspects well. It could mention any permission/auth requirements, but nothing suggests those exist. Complete enough for confident 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 0% (the label param isn't documented in the schema descriptions), and the description compensates by explaining the label is a free-text optional label, sanitized to [A-Za-z0-9_-], appended to the filename, with concrete examples. It fully documents the only parameter. Baseline would be 3 but coverage is 0%, so it climbs for compensating.

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

  Purpose5/5

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

  Description states a specific verb+resource ('Create an on-demand backup of the GnuCash book') and differentiates from siblings like list_backups and prune_backups by focusing on the creation/on-demand aspect. The purpose is immediately clear and distinct from the many other tools.

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

  Usage Guidelines4/5

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

  The description clearly explains when to use this tool (on-demand/manual backup) and explicitly distinguishes it from automatic retention stages. It even mentions the sibling prune_backups and restore is a human action not an MCP tool. However, it doesn't explicitly state 'use X instead when...' for common alternatives since no other create-backup sibling exists.

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

• create_invoiceA
  4.5/5.0
  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 important behaviors: auto-generation of invoice_id from book's invoice counter when omitted, currency fallback chain (customer's currency → book's default), and job grouping constraints (must belong to same customer, must be a customer-job with owner_type='customer'). For a mutation tool with no annotations, this is strong behavioral disclosure.

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

  Conciseness5/5

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

  The description is well-structured with a one-line summary followed by a clean Args list. Every sentence adds value - examples, defaults, interactions, and constraints. No filler or redundant content. Param-doc-per-line formatting makes scanning easy.

  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 7-parameter invoice creation tool, the description covers all parameters with examples and fallback behaviors. It documents the job_id prerequisite (create_job first), which is critical domain knowledge. An output schema exists to handle return value documentation. The description is 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 description coverage is 0%, so the description fully compensates by explaining every parameter with concrete examples. Each parameter gets its own Args entry with type hints and example values: customer_id ('000001'), invoice_id ('INV-2026-001'), term ('Net 30'), date format (YYYY-MM-DD). This adds substantial meaning beyond the raw 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+resource: 'Create a customer invoice.' It distinguishes from siblings like create_bill, create_credit_note, create_voucher, and create_job by explicitly naming the resource type. The 'Create' verb plus 'customer invoice' resource makes the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool, particularly around the job_id parameter, instructing to 'Use create_job first to define the job, then attach invoices to it via this parameter.' It also explains the currency fallback behavior. However, it doesn't explicitly state when NOT to use this tool vs. alternatives like create_bill, though the intended domain is clear.

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

• create_taxtableA
  4.5/5.0
  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 key behaviors: entries must reference ASSET or LIABILITY accounts, all entries must share the same commodity, and percentages are expressed as rates ('5.00' = 5%, not '0.05'). This is substantial behavioral disclosure for a tool with zero 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?

  Well-structured with clear sections (overview, Args, Example). The overview and Args sections are informative without redundancy. Slightly long but every sentence adds value — the example is helpful and the rate-format caveat is important. Could trim the asset/liability explanation marginally.

  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 2-parameter tool with no annotations, the description thoroughly covers purpose, entry structure, account constraints, commodity requirement, and provides a complete executable example. The output schema exists but the description needn't cover return values. Handles the complexity well.

  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 0% and the schema gives only bare types (string name, array of objects). The description fully compensates by defining the 'entries' structure ({type, amount, account}), the allowed type values ('value' or 'percentage'), the amount format, account address forms (path, %short-guid, GUID), and account type constraints. This is excellent parameter documentation.

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

  Purpose5/5

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

  Description clearly states it creates a new sales-tax table, explains that a taxtable holds entries, and provides the composition model (percentage rate or flat-value surcharge per GL account). It distinguishes from siblings like update_taxtable and list_taxtables by the 'create' verb.

  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?

  Explains what a taxtable is and how entries contribute, noting multi-entry composites produce multiple tax splits at posting time. However, it doesn't explicitly say when to use this vs alternatives like update_taxtable, nor state preconditions like whether accounts must already exist in the book.

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

• delete_billA
  4.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the destructive side-effect (automatically removes associated line items) and the posting constraint. However, it doesn't disclose whether deletion is permanent/reversible, requires any authorization, or guarantees cascading behavior beyond line items. For a destructive tool with zero annotation coverage, this is decent 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?

  Every sentence earns its place. The core purpose is front-loaded in the first two lines, followed by the deletion side-effect, then the posted-bill exclusion. The Args section is compact and directly maps to parameters. No filler, no redundant restating of schema fields.

  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 having no annotations and 0% schema coverage, the description covers the essential operational context: what gets deleted (bill and associated line items), when it's allowed (unposted), what to do for posted bills, and full parameter semantics. An output schema exists which presumably documents the return, so it needn't describe that. This is well-complete for a destructive 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 description coverage is 0%, so the description must fully compensate. It does so by explaining both parameters, including the relationship between them (id is preferred, bill_id is a legacy alias), the format expectation ('000001' or 'BILL-2026-001'), and the exclusivity rule (pass exactly one). This adds meaning well beyond the bare schema which shows only nullable string fields.

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

  Purpose5/5

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

  The description uses a specific verb+resource ('Delete an unposted vendor bill') and clarifies scope precisely — only unposted bills qualify. It also distinguishes from related actions by noting posted bills must be voided or issued a credit note instead, which differentiates this from sibling tools like delete_invoice.

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

  Usage Guidelines5/5

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

  Explicitly states when this tool applies (unposted bills only) and what to do when it doesn't (void or issue credit note for posted bills). The parameter guidance is also strong, explaining that id is the preferred named parameter matching sibling conventions and bill_id is a back-compat alias requiring exactly one to be passed. This gives clear exclusions and alternatives.

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

• delete_jobA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full disclosure burden. It clearly explains the default refusal behavior, the re-parenting side effect of force=True, and the data-loss prevention rationale. The only minor gap is not describing the return value or confirmation payload, but the core mutation semantics and side effects are well disclosed.

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

  Conciseness4/5

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

  Well-structured with the headline verb first, then a clear paragraph on behavior, then the Args section that separates into a parsable docstring. Slightly verbose but every sentence adds value, no filler. The docstring format is consistent and easy to parse.

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

  Completeness4/5

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

  Given this is a mutation tool with no annotations, the description covers the critical behavioral aspects: default refusal, force semantics, and the alternative tool to use. Has output schema present so return values needn't be detailed. Could mention what happens to the job's children/line items beyond invoices, but for a 2-param delete tool this is strong coverage.

  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 0%, so the description must compensate. It explains that force=True re-parents linked invoices instead of refusing, which adds substantial meaning beyond the bare boolean type. job_id is simply identified as 'Job ID' which aligns with schema. Could add type/format hints but the force semantics are the critical value-add.

  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 'Delete a job' with a specific verb+resource, then adds significant detail about force behavior and data-loss prevention. It also distinguishes from update_job(active=False), clearly differentiating it from the most relevant sibling 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?

  Explicit when-not-to-use guidance: refuses by default when invoices/bills are linked (data-loss prevention), explains force=True behavior, and explicitly recommends update_job(active=False) as the alternative when keeping the job is preferred. This is model usage guidance.

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

• delete_voucherA
  4.5/5.0
  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 that 'associated entries are automatically removed' as a side effect of deletion, which is important destructive behavior. It could further clarify irreversibility or permission needs, but the cascade-deletion disclosure is meaningful.

  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?

  Well-organized with logical sections (delete rule, cascade behavior, posted-voucher note) and an Args block. Slightly verbose with the back-compat explanation and preferred-parameter rationale, but each sentence earns its place for guiding correct usage. No wasted 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?

  For a 2-param destructive tool with no annotations and 0% schema coverage, the description does substantial heavy lifting: usage precondition, cascade side effects, parameter disambiguation, and cross-tool references. An output schema exists, which relieves the need to document return values. Complete given 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 description coverage is 0%, so the description must compensate, and it does. It explains both parameters: 'id' is the preferred name with an example format ('000001'), and 'voucher_id' is a legacy alias accepted for back-compat. It also states the constraint to pass exactly one of id or voucher_id — genuinely additive 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?

  Specific verb+resource: 'Delete an unposted employee expense voucher.' Clearly scopes the action to unposted vouchers, distinguishing it from the many sibling delete tools (delete_invoice, delete_bill, delete_budget, etc.) and from post/unpost operations. Strong statement of what is and isn't deletable.

  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 the precondition (voucher must be unposted) and gives a pathway: 'unpost first via unpost_invoice, then delete.' Also clarifies that posted vouchers cannot be deleted. This is strong when/how guidance that a sibling comparison supports.

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

• get_audit_logA
  4.5/5.0
  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 key behaviors: the leading indicator line format, that each write op is one entry separated by blank lines, that reads are not logged, and the backward-paging anchor. The 'what happened lately' rationale adds useful context about intended use. Minor gap: nothing about permission requirements or retention limits.

  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 with a leading summary, a behavioral paragraph, and a parameter list. It front-loads the core purpose. Slightly wordy in places (the date format parenthetical and blank-line explanation are essential), but every sentence earns its place. The Args section format is efficient and scannable.

  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?

  Despite having an output schema (which removes the need to document return format), the description still explains the indicator-line format and entry separation, which adds value. All 3 parameters are documented, the backward-paging nuance is handled, and the read-only caveat ('Reads are not logged') is clearly stated. Complete for a read tool with zero annotations.

  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 0% (no descriptions in the schema), so the description must compensate fully. It does: each parameter (log_date with YYYY-MM-DD format and default, limit with page-size and 0=count-only semantics, offset with backward-skip meaning) is fully documented with formats and defaults. The backward-offset explanation adds meaning the bare schema cannot convey.

  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 a specific verb+resource ('Read audit log entries for a date') and clearly distinguishes it from the row-list tools by explaining the unique backward-paging behavior ('offset pages backward into history'). This separates it from sibling list tools like list_customers and list_transactions.

  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 explains when to use it ('what happened lately is the usual question'), contrasts with 'the row-list tools,' and documents the backward-paging semantics and limit=0 count-only behavior. It provides clear context on how the window differs from sibling tools.

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

• get_pricesA
  4.5/5.0
  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 does well: explains the default output format (text table with header line), the verbose structured alternative, pagination/count-only semantics, and default parameter values. This is a read operation and non-destructive, though no return-value detail is given beyond 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?

  Well-organized with a concise intro paragraph describing output behavior, then a structured Args section listing each parameter with purpose. Every sentence adds value; no fluff. Front-loaded with the essential behavior (default text table, count line, pagination, verbose option).

  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 an 8-param read tool with an output schema and zero annotations, this is thorough. It explains output formats, pagination, defaults, count-only mode, and every parameter. The output schema exists to document return structure, and the description covers behavioral aspects comprehensively.

  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 0%, so the description must compensate for all 8 params. It documents all of them with purpose and examples (e.g., commodity 'VTSAX', currency 'USD'), making clear which are filters (start_date, end_date, currency), which control pagination (limit, offset), and the verbose flag. Only minor gaps: no explicit format hints for date strings in the schema context, though examples are 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 'Get price history for a commodity' — a specific verb+resource. It distinguishes well from siblings like get_latest_price, create_price, delete_price, and list_commodities by explicitly being about price history 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?

  The description explains output formats (default compact text table with count line vs verbose structured envelope) and pagination behavior (offset, limit=0 count-only). However, it doesn't explicitly state when to prefer this over get_latest_price or when-not scenarios, leaving some ambiguity among price-related siblings.

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

• list_invoicesA
  4.5/5.0
  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 transparently discloses the non-obvious output format behavior (leads with a 'Showing X-Y of Z' line, compact one-line-per-invoice default), the verbose=true mode for full JSON, and the limit=0 count-only behavior. These are behaviors not inferable from schema or enums, and the description shares them 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?

  Well front-loaded: the first sentence states the purpose. The output-format disclosure comes immediately after, followed by a clean numbered Args list. Slightly verbose with the example phrase 'useful for the what's part of this engagement? listing pattern' and the redundant default restatements (offset default 0, limit default 50 are already in schema), but overall efficient and scannable.

  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 6-parameter read tool with no annotations, this is quite thorough. The output schema exists, so return-value documentation isn't strictly required. The description covers output format, filtering semantics, pagination, and the count-only mode. Minor gap: it doesn't explain default sort ordering or whether all six parameters compose together, but for this complexity level it is near-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 description coverage is 0%, so every parameter must be documented in the description. All six parameters (owner_type, status, verbose, limit, job_id, offset) are given semantic meaning beyond their schema types — including enum-like values for owner_type and status ('customer'/'vendor', 'posted'/'open'), the special limit=0 count behavior, and the practical use case for job_id. This fully compensates for the zero 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 verb 'List' plus resource 'invoices and/or vendor bills', with immediate disambiguation of owner_type (customer=invoices, vendor=bills). It also distinguishes from sibling get_invoice (singular fetch) and describes the output format lead line, firmly establishing purpose and scope.

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

  Usage Guidelines5/5

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

  Explicit guidance on when to use this tool: the job_id parameter is framed for the 'what's part of this engagement?' listing pattern, and owner_type disambiguates between invoices and bills. While it doesn't name specific alternative tools, it gives clear usage context for filtering and pagination patterns that are not obvious from schema alone.

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

• unpost_invoiceA
  4.5/5.0
  Behavior4/5

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

  Discloses substantial behavior: deletes posting transaction and lot, clears posted-state metadata, returns to open/edit-able state, and the refusal condition on applied payments. No annotations exist, so the description fully carries the burden, and it does so admirably. Minor gap: no statement about irreversibility or audit implications of deletion.

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

  Conciseness4/5

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

  Well-structured with a concise main paragraph followed by a compact Args section. Every sentence earns its place. Slightly verbose in describing the state transition, but all info is relevant given the lack of annotations.

  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 has a mix of action plus preconditions and disambiguation logic, all covered. The output schema exists and return values need no explanation. Complete enough despite no annotations; the mutation risks (deleting a lot/transaction) are disclosed.

  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 0%, so the description must compensate. It explains id with an example ('000001') and clarifies owner_type as a disambiguation mechanism for ID collisions with valid values 'customer'/'vendor'. This adds real semantic value beyond the bare 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?

  Clear verb+resource pairing ('Reverse a posted invoice or bill') that distinguishes it from post_invoice and delete_invoice siblings. States the primary effect and the resulting state transition explicitly.

  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 (reverse a posted invoice/bill) and names the key precondition — refuses if payments applied, with direct instruction to void payments first. This exclusion criterion is actionable and important for avoiding failures.

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

• update_taxtableA
  4.5/5.0
  Behavior5/5

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

  No annotations provided, so the description carries full burden—and it shines. It discloses the destructive nature of entry replacement on in-use taxtables ('destructive to FUTURE entries' tax math'), explains that existing posted invoices retain splits because splits are stored-not-derived, and specifies the return format (diff-style, only changed fields). This is exactly the kind of behavioral context an agent needs for a mutation with risk implications.

  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?

  Well-organized: opening statement, bolded destructive caveat, args block. The dangerous-behavior warning is front-loaded near the top rather than buried, which is ideal. Slightly verbose in the caveat wording but every sentence earns its place given the risk profile. The Args section cleanly maps 1:1 with schema parameters.

  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?

  Complex mutation with an output schema present (making return format less critical to document—yet the diff-style note still adds value over schema). The description covers safety (force/refcount), persistence semantics (splits stored not derived), dependencies (create_taxtable shape), and params. It's complete for an agent to decide and invoke correctly. Minor gap: doesn't state error behavior when name isn't found or force is omitted with refcount > 0, but force's requirement is already stated.

  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 0% and entries is an opaque anyOf array, so the description's per-parameter notes add real value: name (current name, needed to target), new_name (optional), entries (replacement list matching create_taxtable validation and shape), force (required when refcount > 0). The description doesn't deeply detail the entries object structure itself, but it points to create_taxtable for that, which is a reasonable delegation. Minor deduction for not describing force's full effect or what happens on failure.

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

  Purpose5/5

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

  Clear verb+resource: 'Update a sales-tax table's name and/or entries.' It distinguishes itself from create/delete/list/get siblings by specifying exactly which aspects (name and/or entries) are mutable. The description also reveals it's a mutating sibling to update_customer/vendor/employee in the same family.

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

  Usage Guidelines4/5

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

  Description implies context: used to rename a taxtable and/or replace its entries, with the diff-style response and references to create_taxtable for shape/validation. It doesn't explicitly exclude alternatives or state when NOT to use it (e.g., preferring delete+recreate), but it does explain the force/refcount prerequisite clearly, which is strong situational guidance.

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

• update_transactionsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden, and it does well: it explains the empty-cell-UNCHANGED semantics, the abort vs skip on_error behavior, the reconciled-splits rejection rule with force, and that results return a TSV keyed by input guids. It's missing explicit mutation/reversibility notes but covers the critical traps 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 information-dense but appropriately organized with labeled sections (INPUT, clearing note, error handling, force, returns, performance tip). While long, every sentence adds operational value. The TSV format block is necessary given the complex input. Slightly verbose but 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?

  This is a complex bulk-edit tool with a TSV-format input, error modes, reconciliation edge cases, and an output schema mentioned. The description covers the input format, error behavior, reconciliation constraint, output keying, and performance alternative. It's missing explicit prerequisite states (single open book requirement is stated), but is otherwise remarkably complete for the 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 description coverage is 0%, so the description must fully explain all 3 parameters. It does: updates gets deep TSV format documentation with a header spec and example rows, on_error gets both 'abort' and 'skip' behaviors, and force gets the reconciled-splits context. This compensates strongly for the zero schema coverage.

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

  Purpose5/5

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

  The description clearly states the verb+resource+scope: 'Update MANY transactions with per-row values (bulk edit)'. It explicitly distinguishes from the sibling update_transaction (single-transaction) by contrasting semantics, making the purpose unambiguous and 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 provides explicit when-to-use guidance: it names the cheaper alternative (update_transaction with guid list for same-value batches), the single-transaction alternative for clearing fields, and replace_splits for splits/memos. It also explains when force=true is needed for reconciled splits. This is model-level guidance.

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

• create_transactionsA
  4.6/5.0
  Behavior4/5

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

  Despite no annotations, the description thoroughly discloses behavior: one book-open/one atomic save, structural errors abort the whole batch by default, on_error='skip' behavior, duplicate handling, force and dry_run semantics, and detailed OUTPUT envelope structure. It explains what references are echoed back and what the server never reuses. Slightly lower score because it doesn't explicitly state auth/permission needs or reversibility of the writes, but the write semantics are very well covered.

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

  Conciseness4/5

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

  Exceptionally well-structured with clear sections (INPUT, BEHAVIOR, OUTPUT), code-block examples, and consistent formatting that makes a complex format navigable. It is long, but the complexity of a TSV-driven bulk tool with six extensions arguably justifies the length. A small deduction because some sections (e.g., the notes/memo targeting discussion) verge on over-detailed for the headline decision, though the information is genuinely valuable.

  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?

  This is a high-complexity tool (TSV parsing with header-declared layout, six combinable extensions, atomic batch behavior, auto-fill semantics) with zero annotation coverage and zero schema description coverage. The description compensates fully: it exhaustively documents input format, all extensions with examples, edge cases (empty qty, trailing memo cells, row width variance), error handling modes, output tables, and the interaction between extensions (first group fixes order). Complete 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 coverage is 0%, so the description carries the full burden, and it does remarkably well. It documents the transactions TSV format in exhaustive detail (header-driven layout, six extensions, per-row semantics for ref/date/amount/qty/cur/notes/memo, auto-fill behavior). It also explains force, dry_run, and on_error with concrete values and defaults. This exceeds what the bare input schema provides for all 4 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 opens with a specific verb+resource: 'Create MANY transactions in one atomic command (bulk entry).' It clearly distinguishes itself from the sibling create_transaction (single) by emphasizing MANY and bulk entry. The purpose is unmistakable and 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?

  Provides extensive when-to-use guidance: explicitly names create_transaction as the alternative for non-default currency transactions ('use create_transaction with its currency parameter'), explains when extensions apply (cur for multi-currency, qty for investment/foreign accounts), and when auto-fill is ideal ('Perfect for recurring monthly entries'). Contrasts with create_transaction_from_scheduled implicitly through auto-fill mechanics.

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

• get_reconciliation_statusA
  4.6/5.0
  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 behavior burden. It clearly states this is 'Reporting-only', disclosing ordering behavior (most-behind first, with pending-split counts), bucketing logic, and the no_reconcile opt-out mechanism. It doesn't detail the exact output row structure or pagination edge cases, but given it's a read-only reporting tool and an output schema exists, the coverage is reasonably strong.

  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 with a clear opening question framing, then bucket definitions, then an exclusion-setting aside, then args. It's dense but every sentence earns its place; slightly long but the content justifies the length given the conceptual categories being explained. The Args section is clean and tabular.

  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?

  This is a moderately complex reporting tool with 5 output buckets and special semantics (excluded accounts, count-only mode), but the description explains each bucket, ordering, the no_reconcile relationship, and parameter behavior. An output schema exists which covers return-value structure. For its complexity level, little is left unexplained.

  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 0%, so the description must compensate for all parameter meaning. It explains verbose ('Full JSON rows instead of compact TSV lines'), limit ('Page size, default 50, max 250, 0 = count only'), and offset ('0-indexed first row'). The explanation adds meaningful semantics — particularly the '0 = count only' for limit and verbose's TSV/JSON distinction — beyond what a bare schema with defaults would convey.

  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 gives a specific verb+resource (per-account reconciliation table) and explicitly differentiates it from the dashboard's aggregate counts, answering the precise question 'WHICH accounts are never reconciled / dormant / behind?'. It distinguishes itself clearly from sibling tools like get_unreconciled_splits and reconcile_account by framing this as the reporting/status layer.

  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 details each output bucket (behind, never, current, dormant, excluded) and explains the excluded category's purpose, including when to set no_reconcile (loans, escrow payables, statement-less accounts) with a concrete example call to set_account_slot. It also flags that reconcile tools still work on excluded accounts, clarifying when this reporting tool is appropriate independently.

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

• get_unreconciled_splitsA
  4.6/5.0
  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 CLI-like output structure (showing X-Y of Z indicator, one line per split, summary footer reflecting full set even when clipped) which is genuinely useful behavioral context. It clearly documents the pagination semantics and 'honest headline' behavior. While it doesn't mention read-only status explicitly, the get_ prefix and 'get' verb make it clear this is a read operation. Minor gap: no mention of performance or error conditions, but the behavioral details disclosed are strong.

  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 with a leading summary sentence, prose paragraphs explaining output format and pagination, and a clearly formatted Args section. Every sentence adds information. Slightly verbose in the output-format explanation (showing indicator explanation could be compressed), but the structure is clean with no repetition of schema defaults that are already visible.

  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?

  Has an output schema and 5 parameters with 0% schema coverage. The description compensates thoroughly for the parameters and documents output format (compact lines, verbose JSON, count-only mode) and pagination semantics. It's complete for a read-only side-effect-free tool with a good output schema. Minor gap: doesn't clarify how 'unreconciled' relates to reconciliation status, but the tool is focused enough that the description is largely sufficient.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate entirely, and it does excellently. Every parameter is documented with format details: account ref formats (full path, %short GUID, full 32-char GUID), as_of_date format (YYYY-MM-DD), limit default/max/special value (50, 250, 0=count only), offset semantics (0-indexed first row), and verbose behavior (full JSON with GUIDs, amounts, totals, showing indicator as structured field). This exceeds what the bare 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?

  Description clearly states verb (Get) + resource (unreconciled splits) + scope (for an account). The sibling tools like list_transactions, get_balance, and set_reconcile_state are distinct enough, and this description clearly distinguishes pagination/limit behavior making it easy to tell apart from get_reconciliation_status or reconcile_account.

  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 on when to use (unreconciled splits for an account), how to page with offset, that limit=0 returns count only, and when to use verbose=true. It also clearly distinguishes the compact one-line format from full JSON, and explains the account ref formats (full path, %short GUID, or full GUID). This is explicit usage guidance with no ambiguities.

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

• list_accountsA
  4.6/5.0
  Behavior4/5

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

  Despite no annotations being provided (so the description carries full burden), it discloses key behavioral traits: that it leads with a 'Showing X-Y of Z accounts' line, emits %short GUIDs that other tools accept, and that limit=0 returns count only. It lacks explicit read-only declaration, but the output-schema plus detailed behavioral description adds significant context. Minor gap: doesn't explicitly state it's a safe/read-only operation given zero annotation coverage.

  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?

  Well-structured with clear sections and a documented Args block. The description is moderately verbose but every sentence earns its place—paging format, query behavior, and cross-tool references are all valuable. Could be tightened slightly but the added value justifies the length.

  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?

  Even though an output schema exists, this tool has 5 parameters and multiple behavioral modes (paging, count-only, verbose, querying). The description thoroughly covers the return format, paging semantics, GUID output, and cross-tool guidance. Given the tool's complexity and zero annotation coverage, the description is complete and self-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 description coverage is 0%, so the description carries the full burden. The description thoroughly explains all 5 parameters: root (subtree filter with expenses example), verbose (full JSON), limit (default 50, max 250, 0=count), offset (0-indexed), and query (case-insensitive substring with concrete examples like query='grocer'). This compensates fully for the schema coverage gap.

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

  Purpose5/5

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

  The description clearly states 'List all accounts in the GnuCash chart of accounts' with a specific verb+resource. It differentiates from siblings by describing the paging format, verbose mode, and query filtering. It explicitly distinguishes from search_transactions, showing good sibling 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?

  The description explicitly explains when to use this tool vs searching: 'To FIND an account without paging the whole chart, pass query' and explicitly directs transaction searching to 'search_transactions'. It also explains when to use verbose=true, providing clear context for alternative approaches.

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

• list_taxtablesA
  4.6/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full disclosure burden. It reveals substantial behavioral detail: the leading 'Showing X-Y of Z taxtables' line, pagination semantics, limit=0 count-only special case, compact vs verbose output differences, and resolved account paths/refcount in verbose mode. This is rich behavioral context beyond mere intent.

  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 well-structured with clear sections and front-loaded purpose. It opens with the purpose, explains output formats with a memorable example of the leading line, then concisely documents each parameter in a compact Args block. Every sentence adds value with zero filler.

  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?

  This is a moderately complex list tool with format toggling, pagination modes, and count-only special case, but has an output schema present. The description is thorough for selecting and invoking correctly. It slightly misses explicit detail on the exact shape of the compact per-line output (what fields constitute 'rate→account routing'), but overall a list tool with this richness is nearly 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 description coverage is 0%, so the description must fully compensate. It does: verbose ('return full JSON for each taxtable'), limit ('page size default 50 max 250, 0=count only'), and offset ('0-indexed first row'). All three parameters get meaningful semantic detail beyond the bare schema definitions.

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

  Purpose5/5

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

  The description clearly states 'List all sales-tax tables' with a specific verb and resource. It distinguishes pagination behaviors, compact vs verbose formats, and the count-only mode, which sets it apart from sibling taxtable tools (get/update/delete/create).

  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 explains when to use this tool for listing taxtables, and documents key usage behaviors like pagination (offset/limit), count-only mode (limit=0), and output format selection (verbose). It doesn't explicitly name non-list siblings as alternatives, but the list context is clear and it covers the main usage decisions.

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

• pay_invoiceA
  4.6/5.0
  Behavior5/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, and it does so comprehensively. It reveals the auto-routing logic for fx_account and discount_account (with matching rules and fallback behavior), the fx_notice return signal for ambiguous candidates, specific rejection conditions for discounts and stale FX rates, the force override behavior, and the memo-vs-description distinction. It also notes the 7-90 day stale-FX guard and the 90-day un-forceable cap — rich operational detail beyond what any schema could convey.

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

  Conciseness3/5

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

  The description is dense and technically thorough but quite long, spanning multiple paragraphs plus a labeled Args section. The front-loaded first sentence is strong, but the extensive FX routing and discount sections add substantial length before the Args list, creating some redundancy (the prose section restates the auto-resolution details that the Args also cover). It's structured and scannable, but could be tightened by ~25-30% without losing information.

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

  Completeness5/5

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

  Given the tool's high complexity (11 params, cross-currency FX handling, discount validation, stale-rate guards) and zero schema description coverage, the description is remarkably complete. It explains the payout flow, both advanced routing policies, error/rejection behaviors, override semantics, and edge cases (multiple/count zero FX matches, credit-note rejection for discounts). The output schema exists, so return-format details are relieved; for a complex financial mutation tool this is about as complete as one could expect.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries the full load for all 11 parameters. Every nontrivial parameter is explained: id (specific format example '000001'), payment_account and amount (format examples), fx_account/discount_account (GUID/path/percent-short matching accepted), apply_discount (explicit opt-in, hard-reject conditions), force (stale-FX guard details), and memo (distinguished from description). This far exceeds what bare parameter titles provide.

  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 opens with a clear verb+resource statement: 'Record a payment against a posted invoice or bill.' It then distinguishes subtypes (partial payments, cross-currency with FX splits, early-payment discounts), each with concrete specifics. It clearly differentiates itself from sibling tools like apply_credit_note (which handles credit notes) and create_transaction (which is generic), establishing pay_invoice as the invoice-settlement 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 gives strong context on when to use the tool: for posted invoices/bills with A/R or A/P payment, partial payments, and cross-currency or discount scenarios. It doesn't explicitly name alternative tools for when NOT to use it (e.g., apply_credit_note for credit-based settlement), but the payment-vs-credit distinction is implicit and the prerequisite ('posted invoice') is clearly stated. Explicit exclusions would push this to 5.

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

• prune_backupsA
  4.6/5.0
  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 explicitly discloses that dry_run defaults to True, what response shows (what WOULD be deleted), and the deletion semantics for dry_run=False. It also explains the auto-retention vs manual stage behavior. Minor gap: doesn't mention whether deletion is reversible or what the response includes beyond 'what would be deleted'.

  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?

  Well-organized with a clear lead sentence, then default-behavior context, then a paragraph on stage semantics, then Args section. Slightly verbose in the Args section repeating schema defaults, but each section earns its place and the structure is scannable.

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

  Completeness5/5

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

  For a destructive-adjacent tool (deletion operation) with no annotations, the description thoroughly covers the safety default (dry_run), the stage scoping rules, and parameter constraints. An output schema exists, so return-format details aren't required. This is comprehensive for a 3-param 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 description coverage is 0%, so the description must compensate. It does: explains keep_last_n must be >= 0, enumerates valid stage values (session/weekly/monthly/manual), and clarifies dry_run's True/False semantics with defaults that match the schema. Adds meaning well beyond the bare 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 uses specific verb+resource 'Remove older backups, keeping the most recent N per stage'. It clearly distinguishes scope (per-stage retention) and explicitly differentiates from siblings like create_backup and list_backups by describing the pruning behavior.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: dry_run default behavior, how to target manual backups explicitly with stage='manual', and the safety mechanism for confirmation before committing. It also states that manual backups are never auto-pruned, giving clear exclusions.

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

• void_transactionA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so the description carries full burden. It discloses key behavioral traits: preserves for audit purposes, zeroes out all split values (a significant side effect not obvious from the name). However, it does not mention whether this is reversible (there is an unvoid_transaction sibling suggesting reversibility, but the description doesn't state it explicitly), nor what happens to reconciled/linked splits.

  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 tight paragraphs, zero filler. The key contrast (safe void vs delete) is front-loaded. Every sentence earns its place, and the Args section is a clean, minimal parameter restatement. No redundancy with the input schema.

  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?

  There is an output schema (context signal), so return values need no explanation. The tool has a serious side effect (zeroing all splits), which is disclosed. The only gap: it doesn't note that unvoid_transaction is the reversal operation, but that sibling's own description likely covers it. Adequate for the complexity level.

  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 only 50% of params in description (guid has description, reason has none). The description compensates by explaining the guid format beyond schema (32-char hex or 8+ char prefix, which schema also documents) and adding the crucial reason requirement: 'required for audit trail'. This adds meaning the schema lacks for the reason parameter.

  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+resource ('Void a transaction') and explicitly contrasts with delete ('proper accounting void, not delete'). It distinguishes from sibling delete_transaction and pairs with unvoid_transaction. The distinction between void (preserves record, zeroes splits) vs delete is precisely what the agent needs.

  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 this instead of delete when you need to maintain an audit trail', giving a clear when-to-use condition and naming the alternative (delete). This directly guides selection among sibling tools delete_transaction, unvoid_transaction, and update_transaction.

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

• apply_credit_noteA
  4.7/5.0
  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 of behavioral disclosure. It states 'No cash moves' (a key non-obvious behavior), that both documents must be posted and from the same owner/currency/account, and describes the amount defaulting behavior. It could add what happens on partial netting or whether the operation is reversible, but the core behavioral profile is well disclosed.

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

  Conciseness4/5

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

  Well-organized with a lead behavioral sentence, a context paragraph, and a tidy Args block. Every sentence earns its place. Slightly longer than strictly necessary due to the worked example paragraph, but that example materially aids usage understanding, so the length is justified.

  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 5-parameter, no-annotation, 0%-schema-coverage tool, the description is exceptionally complete. It explains the business purpose, constraints on every parameter (posted, same owner, same currency, same post account), defaults, when to use alternatives, and the optional owner_type disambiguator. The output schema exists so return-value documentation is not needed. This is a genuinely excellent tool description.

  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 0%, so the description bears full responsibility for the 5 parameters, and it delivers. Each parameter is explained with type guidance (Decimal-string), defaults ('Defaults to today', 'Defaults to min(...)'), posting/currency/owner constraints, and the purpose of the disambiguator (owner_type). The default formula for amount is particularly valuable semantic information not inferable from 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 states a specific verb+resource ('Net a posted credit note against a posted invoice or bill from the same owner') with a clear behavioral scope ('No cash moves — the credit balance transfers between lots on the same A/R or A/P account'). It clearly distinguishes from sibling pay_invoice by explicitly saying to use that tool instead for cash settlement.

  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 context ('the most common credit-note settlement path'), a concrete workflow example (overcharge → net against next invoice/outstanding bill), and explicitly names the alternative (''Use pay_invoice instead when the credit note will be settled by sending or receiving cash''). This is a model of usage disambiguation.

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

• delete_transactionA
  4.7/5.0
  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 does significantly well: it explains the all-or-nothing batch behavior, the force override for reconciled splits, the invoice-posting-record safeguard, and the response format for both single and list calls. It does not explicitly state it's destructive (though implied), but the safeguards and response shape give substantial 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?

  The description is tightly packed with substantive content — purpose, safeguards, batch semantics, response shape, and args. Every sentence earns its place. The args section cleanly mirrors the schema. No filler or 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?

  Despite having an output schema, the description still describes the response shape precisely for both single and list invocations, which is valuable since the shapes differ between modes. It addresses the complexity of batch all-or-nothing behavior, safeguards, and the force flag, covering the important edge cases. The description is essentially complete for this tool's complexity.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It does: 'guid' is explained as a Transaction GUID (32-char hex or 8+ char prefix) or a list; 'force' is explained as allowing deletion with reconciled splits. It also adds return-shape semantics. It doesn't go beyond the schema in terms of edge-case validation details, but the coverage it provides is solid given zero 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 'Delete one transaction by GUID — or several in one call' with a specific verb+resource. It distinguishes itself from the sibling tools like void_transaction (which voids rather than deletes), delete_account, and delete_invoice by making the target scope precise. The description explicitly notes it deletes transactions, which differentiates it from the many other delete_* 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?

  The description gives explicit when-to-use guidance including safeguards: it explains that deletion is prevented for transactions with reconciled splits (with force=true override) and that invoice posting records require unpost_invoice first. It also explains the batch behavior (list of GUIDs, all-or-nothing semantics). This is strong usage guidance, including exclusions and prerequisites.

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

• get_job_reportA
  4.7/5.0
  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 delivers: the return shape (totals_by_currency keyed by ISO code), the multi-currency handling behavior, and the draft-invoice treatment ('drafts contribute their face value as billed + outstanding with paid=0, so the report shows the full pipeline'). This is rich behavioral disclosure far beyond what annotations would typically provide.

  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 tightly structured with a summary line, a return-format paragraph, and a args section. Every sentence earns its place — zero filler words, clear line breaks for scannability, and important details front-loaded in the introductory sentence.

  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 being a single-parameter tool with an output schema present, the description thoroughly covers return value structure (totals_by_currency dict), included invoice types, draft handling behavior, and multi-currency semantics. This is complete for the tool's complexity.

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

  Parameters4/5

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

  Schema coverage is 0% — no description field on the job_id parameter in the input schema. However, the description's Args section provides 'job_id: Job ID (e.g., "000001")' with a concrete format example, compensating for the schema gap despite being minimal. A clear example helps agents format correct values.

  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 'Per-job summary: billed / paid / outstanding totals across all linked invoices, plus the per-invoice breakdown.' This is a specific verb+resource with clear scope that distinguishes it from sibling tools like get_invoice (single invoice) and get_outstanding_invoices (filtered list).

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

  Usage Guidelines4/5

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

  The description explains what invoice types are included ('Both posted and unposted (draft) invoices') and how drafts are treated, providing clear context for when results include draft contributions. It doesn't explicitly exclude alternatives or name sibling comparisons, but the purpose is specific enough that usage intent is clear.

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

• get_book_summaryA
  4.8/5.0
  Behavior4/5

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

  The description discloses that the tool operates on the 'entire' book (not a filtered subset), returns a single text response rather than structured data, and covers specific data categories. This gives useful behavioral context beyond a bare tool name, though there are no annotations to supplement.

  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 short paragraphs with zero waste. The first sentence states the purpose, the second enumerates content, and the final sentence gives usage guidance. Every sentence earns its place and it is extremely efficient.

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

  Completeness5/5

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

  For a read-only overview tool with 0 parameters, no annotations, and clear output expectations, the description is complete. It explains what's included, how results are returned (single text response), and when to use it. Nothing material is missing for an agent to invoke it correctly.

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

  Parameters5/5

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

  The tool has 0 parameters, so the description's job here is minimal — there's nothing to clarify beyond what the schema shows. The baseline for 0-param tools is 4, and the description adds value by confirming the tool is intended to be a self-contained orientation call with no inputs needed.

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

  Purpose5/5

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

  The description clearly states the tool returns a compact overview of an entire GnuCash book, listing the specific fields included (path, currency, account structure, transaction counts, balances, net worth, commodities, scheduled transactions). This is specific verb+resource with a distinct scope that separates it from sibling report tools.

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

  Usage Guidelines5/5

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

  Explicitly instructs 'Use this first to orient yourself,' which provides clear when-to-use guidance. This orients the agent to call this tool before diving into specific queries, differentiating it from the many sibling get_* and report tools.

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

• list_commoditiesA
  4.8/5.0
  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 significant behavioral details: that limit=0 returns count only, that stale_days excludes the book default currency, that held_only filters to commodities real accounts are denominated in, and that filters AND-combine. An output schema exists to document return structure, and behavioral traits like pagination and filtering semantics are well covered.

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

  Conciseness5/5

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

  The description is well-structured with a clear lead sentence, a pragmatic workflow hint (THE PRICE-UPDATE WORK LIST), and a clean Args block. Every sentence earns its place, explaining real usage patterns rather than padding. It's longer than minimal but all content is operationally valuable.

  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 listing tool with 5 parameters, 0% schema description coverage, and an output schema present, the description is remarkably complete. It explains output format, pagination, filtering semantics, and even ties into the broader workflow (create_prices) for the stale-quotes use case. The output schema covers return values, so the description needn't duplicate that.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description fully compensates. Every parameter is explained beyond its schema definition: verbose (full JSON details, default false), limit (default 50, max 250, 0=count only), offset (0-indexed, default 0), stale_days (at least N days old, includes never-priced, excludes default currency), and held_only (only denominations in real accounts, AND-combines with stale_days).

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

  Purpose5/5

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

  The description clearly states the tool lists all commodities (currencies, stocks, etc.) with specific verb+resource+scope. It distinguishes itself from siblings like list_accounts and list_lots by naming the resource explicitly, and it provides detail on output format (count line, one-line-per-commodity default, verbose JSON option).

  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 guidance on when to use the stale_days+held_only combination as a price-update work list, naming the follow-up tool create_prices. It clearly explains filter semantics (AND-combining, excludes book default currency, includes never-priced) and pagination conventions.

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

• reconcile_accountA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral burden and largely carries it: it discloses the sign convention for liability accounts, highlights that both modes 'verify the resulting reconciled balance ties to statement_balance before mutating' and that mismatch 'rejects with the discrepancy amount', and explains that except_guids prefixes that don't resolve are 'silently ignored'. Slight gap: doesn't describe return value/confirmation details beyond the mismatch 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?

  Well-structured with clear headers (SIGN CONVENTION, two modes, TYPICAL STATEMENT FLOW, Args) and formatted with bold/markdown. Every section earns its place — the token-cost argument in reconcile_all and except_guids justifications is practical and informative. Front-loaded with purpose before diving into details.

  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 complex 7-parameter mutation tool with no annotations, the description is thorough: it covers the two modes, sign convention, verification-before-mutate behavior, default behavior for through_date, batch workflows, and even edge cases like silently-ignored unresolvable prefixes. Has an output schema present, so return-value detail isn't required. This is complete enough for an agent to invoke correctly in both modes.

  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 only 57%, so the description must compensate and it does substantially. It adds the sign convention for statement_balance, explains the through_date defaulting behavior, clarifies split_guids are SPLIT guids not transaction guids, and details the reconcile_all workflow token-cost rationale plus mutual exclusivity with split_guids. The description meaningfully enriches every parameter beyond what the schema states.

  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+resource ('Reconcile splits against a statement balance') and distinguishes targeted vs bulk modes. It differentiates from siblings by noting split_guids come from get_unreconciled_splits, and the STATEMENT FLOW section contrasts with related tools like set_reconcile_state.

  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 guidance: 'Use when statement and book disagree and you need to pick a subset' for targeted mode, and a full TYPICAL STATEMENT FLOW section explaining the standard credit card/bank workflow and multi-month catch-up pattern with oldest-first ordering. Mentions the through_date default keeps each sweep inside its own statement.

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

• create_transactionA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden and it delivers richly: discloses the duplicate-detection behavior (rejected status or returned alongside success), the exact TSV format of the duplicates response with column layout and signal coding, force_create and dry_run semantics, and the decimal-string requirement explaining why raw JSON numbers lose precision. This is outstanding behavioral disclosure.

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

  Conciseness4/5

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

  Dense but well-structured with clear section headers (FIELD TARGETING, duplicate-detection block, Args list). Every sentence earns its place given the tool's real complexity. Slightly long, but the length is justified by the genuine ambiguity around field targeting and duplicate handling that would otherwise confound an agent.

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

  Completeness5/5

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

  For a tool with 8 params, 0% schema coverage, no annotations, but a complex duplicate-detection response contract, this description is exceptionally complete. It covers split balancing, field semantics per GnuCash register convention, response format details, and all behavioral flags. Return-value handling is disclosed even though an output schema exists.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate entirely — and it does comprehensively. Every parameter is explained: splits structure with each sub-field (account, amount, quantity, memo, action), date format, currency default behavior, notes interpretation guidance, and omissions like splits auto-filling from most-recent matching transaction. Also details the decimal-string formatting requirement that the schema barely hints at.

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

  Purpose5/5

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

  Clear verb+resource: 'Create a new transaction with splits. Splits must balance to zero.' Distinguishes from siblings like create_transactions (plural, batch) and create_transaction_from_scheduled (derived from template). The scope and invariants are explicit.

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

  Usage Guidelines5/5

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

  Extremely detailed FIELD TARGETING section explains exactly what goes in description vs notes vs split memo vs action, with concrete examples for each. This is exceptional when-to-use guidance that prevents common misuses (e.g. putting raw statement text in description instead of the clean name, or filling action for ordinary spending). Contrasts with create_transactions implicitly via 'create over a single transaction'.

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

• post_invoiceA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and delivers richly: it discloses that entries cannot be added after posting, that exchange rates are etched at posting and cannot be updated retroactively, and that forced stale rates are recorded in the response and audit log as fx_stale/'forced'. The 90-day staleness cap boundary is also disclosed. This is exemplary behavior disclosure for a mutation tool.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose in the first line, followed by behavioral notes, then a clean Args block. It's slightly long but every section earns its place given the complex FX-guard behavior. The stale-FX paragraph is dense but necessary; the Args block is well-formatted. A minor deduction for length, but structure is exemplary.

  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?

  This is a complex 7-parameter mutation tool with no annotations and 0% schema coverage, yet the description thoroughly documents the post-conditions (A/R or A/P transaction, immutable entries), the FX edge-case with its full resolution flow, and every parameter. An output schema exists so return-value explanation is appropriately omitted. For its complexity, it is essentially 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 description coverage is 0% (no param documentation in the JSON schema), so the description is the sole source of parameter meaning. The Args block annotates all 7 parameters with types, examples ('000001', 'Assets:Accounts Receivable'), defaults, and one optionality note. It adds real semantics for owner_type (disambiguation when IDs collide) and force (override behavior) that the bare schema titles don't convey.

  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 a specific verb+resource ('Post a customer invoice or vendor bill') and explains the consequence (creates a transaction in A/R or A/P, makes the invoice official). It clearly distinguishes from the create_* tools and unpost_invoice sibling, establishing what makes posting 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?

  The description explicitly explains when posting is refused (stale_fx_rate beyond GNUCASH_FX_GUARD_DAYS) and precisely the steps to resolve it: run create_price, retry, or pass force=True. It names the sibling tool create_price directly and documents the 7-day vs 90-day staleness boundaries, giving clear alternative paths. The owner_type disambiguation guidance is also useful for post-date error conditions.

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

• update_transactionA
  4.9/5.0
  Behavior5/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 — and it delivers. It reveals the all-or-nothing batch semantics, atomic one-save behavior, that splits stays single-transaction, the force requirement for reconciled splits with detailed explanation of why a date move is destructive, and the notes-to-clear behavior. This is comprehensive for a mutation tool with zero annotation coverage.

  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 with clear sections, front-loaded purpose, and minimal waste. It uses code formatting for parameters and covers important edge cases. It's slightly long but every sentence contributes value — the length is justified by the tool's complexity (batch semantics, split constraints, force behavior). Only minor redundancy (repeating GUID format details also in the schema).

  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?

  This is a complex mutation tool (6 params, batch behavior, split reconfiguration, reconciled-state handling) but the description covers all critical aspects: batch semantics, split matching rules, cross-currency handling, force requirements, and per-field optionality. An output schema exists to handle return-value documentation. The description is essentially complete for an agent to use this tool correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate fully — and it does. It explains GUID formats (32-char hex or 8+ char prefix, or a list), ISO date format, the splits matching requirement ('must match existing splits by account name and balance to zero'), cross-currency quantity semantics, memo-override behavior, decimal string format for amounts, and the notes-empty-string-to-clear behavior. Every parameter gets meaningful semantic context beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool updates existing transactions, with a specific verb (update) and resource (transaction). It explicitly distinguishes from siblings: 'For per-row DIFFERENT values, use update_transactions' — providing direct differentiation from the sibling tool update_transactions, and notes splits stays single-transaction. The distinction from update_transactions is particularly strong, giving the agent clear selection guidance.

  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 when/when-not guidance. It explains the batch case explicitly ('one book open / one save, all-or-nothing'), gives a concrete use case ('one note across 35 related entries, one call'), and explicitly directs to the alternative tool (update_transactions) for per-row different values. The force requirement for reconciled splits is clearly articulated with reasoning about date moves shifting out of reconciled statement periods.

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

• create_pricesA
  5/5.0
  Behavior5/5

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

  Despite no annotations being provided, the description thoroughly discloses behavioral traits: update-in-place semantics (never duplicated), atomic batch behavior on error, dry_run preview states (would_create/would_update), provenance default, currency default to book default, and namespace auto-resolution. This fully carries the burden normally expected 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.

  Conciseness5/5

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

  Exceptionally well-structured: bold labels (INPUT, required/optional columns), a concrete TSV example, colon-delimited parameter explanations, semantic reference to create_price, and a companion work-list note. Every sentence adds value with zero waste.

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

  Completeness5/5

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

  For a tool with 3 params, 0% schema coverage, and an output schema, the description is complete: it documents input format precisely, error modes, update semantics, defaults, and edge cases (empty cells take defaults, rows may end early). The mention of the output schema behavior via status/would_create/would_update states ties the documented behavior to expected results.

  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?

  With 0% schema description coverage, the description fully compensates by documenting every parameter in detail: the prices TSV format with required/optional columns, ref as correlation key, ns auto-resolution, cur defaulting, source/type semantics, plus dry_run and on_error default values and behaviors. The TSV example makes the format unambiguous.

  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 records MANY prices in one call (bulk quote entry) with specific verb+resource+scope. It distinguishes from the sibling create_price by emphasizing it's the bulk version, and explicitly references per-row semantics being create_price's exactly.

  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 (bulk entry), detailed input format, error handling behavior (on_error='abort'), dry_run preview behavior, and even a companion work list suggestion (list_commodities with specific parameters). This is exceptionally actionable guidance.

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