Server Quality Checklist

Tool Scores

• get_balanceA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It adds useful context about the signed normal balance and that as_of recomputes from the journal, but it does not explicitly state that the tool is read-only or describe error behavior if the account does not exist.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main purpose, and adds the sign convention and as_of explanation without any 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 simple two-parameter tool, the description covers the core semantics and point-in-time behavior. However, it does not mention the return format (e.g., numeric value) or error cases, which would be more important given no output schema and no annotations.

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

  Parameters2/5

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

  The as_of parameter is well-described in both the schema and description, but the required account parameter has no schema description and the description only says 'one account' without clarifying whether it expects an account name, ID, or other identifier. This leaves a significant gap for the required 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 the tool gets the current signed normal balance of a single account, and specifies the sign convention for different account types. This distinguishes it from sibling tools like trial_balance (which likely provides aggregate balances) and list_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 implies usage for querying a single account balance and mentions using as_of for historical balances, but it does not explicitly contrast with alternative tools or state when not to use it. The context is clear but no exclusions are given.

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

• list_accountsA
  3.7/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 the output content (type, overdraft policy, balance) but does not explicitly state whether this is a read-only operation, whether filtering or ordering applies, or any limitations. It is adequate for a simple listing tool but lacks explicit safety or behavior notes.

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

  Conciseness5/5

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

  The description is a single, straightforward sentence that conveys all necessary information without any wasted words. It is highly concise and well-structured.

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

  Completeness4/5

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

  For a parameterless listing tool with no output schema, the description provides sufficient context: it names the resource and the three key attributes returned. It lacks explicit alternatives or caveats, but given the simplicity, this 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?

  The tool has zero parameters, so the baseline of 4 applies. The description correctly focuses on the returned data rather than parameter details, which is appropriate since there is nothing to document.

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

  Purpose4/5

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

  The description clearly states the tool returns every account along with type, overdraft policy, and current balance. It is specific and implies listing all accounts, distinguishing it from sibling tools like get_balance or list_entries, though it does not explicitly name alternatives.

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

  Usage Guidelines3/5

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

  Usage is implied: it should be used when you need a comprehensive list of all accounts and their key attributes. However, there is no explicit guidance on when to prefer this over sibling tools or any exclusions, though the context makes it reasonably obvious.

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

• trial_balanceA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the output contents (account balances, total debits/credits, equality) but does not mention side effects, read-only nature, or any constraints. This is adequate for a report tool but lacks depth.

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

  Conciseness4/5

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

  The description is a single sentence, but uses a colon to introduce the proof of balance, which is slightly awkward yet still concise. Every phrase conveys essential information without fluff.

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

  Completeness4/5

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

  With no output schema, the description explains the return values well: per-account balances, total debits, total credits, and the guarantee of equality. It is complete enough for a simple report tool, though it omits details like time period or formatting.

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

  Parameters4/5

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

  There are zero parameters, so the baseline is 4. The description adds meaning by explaining what the report contains, which compensates for the lack of parameter documentation. No parameter details are needed here.

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

  Purpose5/5

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

  The description clearly identifies the tool's purpose: generating a trial balance showing every account's balance plus total debits and credits. This distinguishes it from sibling tools like get_balance (single account) and list_accounts (account listing) by emphasizing the equality proof.

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

  Usage Guidelines2/5

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

  No explicit guidance is given about when to use this tool versus alternatives. It does not mention scenarios like checking ledger balance or when to use get_balance instead, leaving the agent to infer usage from the description alone.

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

• open_accountA
  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 of behavioral disclosure. It reveals two important behaviors: all accounts post in the ledger currency (single-currency constraint) and accounts may not go negative unless allow_negative is set, framing overdraft as an intentional policy. This provides meaningful context beyond the schema.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every sentence earns its place. It is concise without sacrificing key behavioral constraints.

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

  Completeness4/5

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

  Given no annotations, no output schema, and only three simple parameters, the description covers the essential behavioral constraints (single currency, negative balance policy). It does not mention error cases like duplicate account IDs, but for a simple creation tool, it 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 100%, so baseline is 3. The description does not add meaningful parameter-level detail beyond what the schema already explains; it only restates the allow_negative policy in prose, which is already captured in the schema description. No new syntax or format guidance is provided.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb and resource: 'Open a ledger account.' It also adds context about ledger currency and negative balance policy, which distinguishes it from sibling tools like get_balance, post_entry, and list_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 usage is implied rather than explicit; the description implies this tool is for creating accounts but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided, so guidance is minimal.

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

• allocateA
  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 algorithm (largest-remainder method), the exact-sum guarantee, and gives a concrete example showing the output. It does not cover edge cases like all-zero ratios, but for a simple tool this is sufficient; notably it clearly indicates the splitting 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?

  Two sentences: the first defines the behavior and method, the second provides an instant example and use cases. Every word earns its place; no fluff or repetition.

  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, no-output-schema tool, the description covers the core algorithm, exactness property, a concrete input-output pair, and explicit use cases. This is fully sufficient for an agent to invoke it correctly and interpret results.

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

  Parameters3/5

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

  Schema coverage is 100%, meaning both amount and ratios already have descriptions. The description reinforces with an example and clarifies the interpretation, but does not add substantive new semantic detail beyond the schema. This fits the baseline 3 for high schema coverage.

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

  Purpose5/5

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

  Description opens with a specific verb ('Split an amount') and resource ('an amount by integer ratios'), immediately distinguishing it from sibling financial tools like get_balance or list_entries. The largest-remainder method and exact-sum property further clarify its unique function.

  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 cases: 'commission splits, installments, and tax apportionment' and provides the alternative 'instead of doing division yourself.' This gives clear when-to-use guidance even without naming a specific sibling tool.

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

• list_entriesA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden. It discloses that the journal is append-only, entries are ordered newest first, and that pagination is supported via before_seq. This gives the agent critical behavioral context without any safety hints.

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

  Conciseness5/5

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

  Two sentences, perfectly sized. The first sentence states the core purpose; the second provides crucial usage guidance. No unnecessary words 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?

  The description covers usage, ordering, and pagination well. However, without an output schema, it doesn't describe what fields each journal entry contains (beyond implying seq). This is a minor gap given the simplicity of the tool and the strong guidance provided.

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

  Parameters4/5

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

  The schema already documents both parameters with descriptions (100% coverage). The description adds value by explaining how before_seq is used (from the previous page) and why it matters (append-only, long journal), going beyond the schema's basic type and constraint info.

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

  Purpose5/5

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

  The description clearly states it lists journal entries with specific ordering (newest first) and pagination. This distinguishes it from sibling tools like post_entry, get_balance, and list_accounts, which serve different resources or actions.

  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 pagination ('when walking further back'), and explicitly advises against asking for everything at once. Also explains the append-only nature that justifies this usage pattern.

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

• post_entryA
  4.8/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 substantial behavioral context. It discloses the balanced-entry invariant, the two-leg minimum, the reversal-not-edit rule, and the idempotent retry behavior (returning original entry with replayed=true). This is far more transparent than typical descriptions.

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

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the primary purpose, then key constraints, then retry guidance. Every sentence provides unique value with no redundancy or fluff. The structure is logical and easy to parse.

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

  Completeness4/5

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

  For a tool with no output schema, the description covers the essential operational aspects: how to construct legs, the balancing invariant, idempotency behavior, and the correction policy. It could go slightly further by stating the normal success return value, but the mention of replayed=true on retries implicitly covers the response shape. Overall, it is complete enough for an agent to confidently invoke 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?

  The schema already describes all parameters with high coverage (75%+), so the baseline is 3. The description adds significant meaning beyond the schema by explaining the balancing requirement for legs, the correct use of idempotency_key on retries, and the distinction between direction and sign for amounts. This elevates the score above baseline.

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

  Purpose5/5

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

  The description opens with 'Post a balanced journal entry' – a specific verb and resource – and immediately states the core accounting constraint (debits equal credits across at least two legs). It further differentiates the tool by asserting it is 'the ONLY way to change a balance,' distinguishing it from sibling read/query tools and the allocate tool.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: this is the only way to change a balance, corrections must be made as reversal entries rather than edits, and retries should reuse the same idempotency_key. This informs the agent when to use the tool and how to handle failure/recovery scenarios, going beyond generic alternatives.

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