trial-balance

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

Beyond the annotations (which indicate non-read-only and non-destructive), the description adds useful behavioral context: 'Nothing is written back' clarifies that source stores are untouched, and 'Free: 3 periods a month' reveals a usage constraint. It does not contradict annotations, and while it doesn't detail idempotency or error semantics, it provides meaningful extra information.

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

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

The description is exceptionally concise—three short sentences that front-load the core action, then add the no-write-back clarification and the free-tier limit. Every sentence earns its place with no redundancy.

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

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

For a build-oriented tool with no output schema, the description covers the essential context: input sources, scope, registration, and a usage limit. It could mention what happens on re-runs or the output format, but given the complexity and existing schema documentation, it is adequately complete.

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

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

The schema descriptions already fully document the parameters (100% coverage), so the baseline is 3. The description reinforces the currency constraint with 'ONE currency' and aligns with the schema's note that currencies are never added together, but it adds no new semantic detail beyond that.

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

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

The description clearly states the tool's purpose: deriving the double-entry ledger for a single period in ONE currency from specific source stores and registering it. It distinguishes itself from siblings by emphasizing that it registers the ledger (not merely reports or exports) and that it's singular currency, which is a unique trait.

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

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

The description provides context about the tool's scope (one period, one currency) and a free-tier limit, but it does not explicitly state when to use this tool versus sibling tools like ledger_report or ledger_export_csv. The phrase 'register it' implies a build action, but no direct comparison is given.

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

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

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds genuinely useful behavioral context: the output is a download link valid for one hour and the CSV has one row per leg. It also signals the Pro-only nature of the tool without contradicting the annotations.

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

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

Two sentences carry the essential information with no filler: format, granularity, link expiry, Pro status, and the alternative. The most important action and constraints are front-loaded, and the alternative guidance is compactly placed at the end.

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

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

Given the fully documented parameters, comprehensive safety annotations, and helpful pointer to ledger_lines for field semantics, the description is complete enough for an agent to select and invoke the tool correctly. The only slight terseness is the term 'leg,' but it is a domain term and not needed for successful invocation.

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

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

Schema description coverage is 100%, so the schema fully documents parameters, date formats, inclusivity, prefix filtering, and currency behavior. The description mostly adds output-format context, not parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Return'), the resource ('the period's ledger lines'), the format ('RFC 4180 CSV'), and a structural detail ('one row per leg'). It also distinguishes itself from ledger_lines by noting it only reformats the same fields as CSV columns, making the tool's scope unmistakable.

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

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

The description explicitly names the alternative tool (ledger_lines), notes that it returns the same fields free and unlimited, and positions this tool as merely a CSV layout. This gives an agent a clear condition for choosing between export and the sibling data-access tool.

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

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

Annotations provide no safety profile (all hints false), so the description carries the burden. It adds useful behavioral context: each line carries debit/credit/bank_ref, the response includes totals, and filtered totals are explicitly warned not to balance. However, it does not disclose the response format, pagination behavior, or side effects, and the ambiguous 'Free.' adds little clarity.

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

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

The description is concise and front-loaded with the verb and resource, packing filters and return-field information into two dense sentences. The final standalone sentence 'Free.' is cryptic and does not earn its place, preventing a perfect score.

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

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

For a 9-parameter tool with no output schema and no annotations, the description covers the core listing behavior and main return values. It leaves gaps: no statement about response structure or pagination, no clarification of how required from/to relate to optional since/until, and no caveats about limit or currency beyond what the schema already states.

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

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

The input schema already documents all 9 parameters with descriptions and constraints, so schema coverage is 100% and the baseline is 3. The description only groups parameters into categories (account, source server, source_id, date) and adds no syntax, formatting, or semantic detail beyond what the schema already provides.

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

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

The description opens with the specific verb 'List' and resource 'ledger lines', and enumerates filter dimensions (account, source server, source_id, date) and returned fields (debit, credit, bank_ref, totals). It is clear and detailed, but it never explicitly distinguishes itself from sibling tools like ledger_report or ledger_export_csv.

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

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

There is no guidance on when to use this tool versus alternatives such as ledger_report, ledger_export_csv, or trial_balance. The use case is only implied by the verb and filter list; no alternatives or exclusion conditions are mentioned.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations: it requires a 'built period,' returns account-by-account totals, and includes memos and exceptions. This meaningfully clarifies what the tool will and won't do.

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

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

The description is compact and front-loaded with the core report contents, then adds a useful pointer to ledger_lines. The phrasing 'Pro; ledger_lines gives the lines free' is slightly awkward but does not waste words.

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

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

Despite having no output schema, the description enumerates the main report fields and prerequisites. It could be more explicit about what 'built period' means and what happens if the period is not built, but the essentials for selecting and invoking the tool are present.

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

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

Schema description coverage is 100%, so the schema already documents from, to, and currency thoroughly. The description does not add parameter-specific semantics, but with full schema coverage, this is an acceptable baseline.

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

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

The description clearly states the tool's job: report a built period account by account, listing debits, credits, movement, closing balance, purchase commitments, and exceptions. It also distinguishes itself from ledger_lines by noting that ledger_lines provides the line-level detail.

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

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

The description gives clear context for what the report covers and points to ledger_lines as the tool that 'gives the lines free,' signaling when to choose the sibling instead. It does not enumerate all sibling tools, but the main alternative is covered.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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

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

The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.

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

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

For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.

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

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

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.

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

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

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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

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

The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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

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

Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.

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

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

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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

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

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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

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

The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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

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

The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state 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.

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

Annotations say the tool is not read-only, and the description goes further by explicitly warning that the non-dry_run call stores a snapshot and that a later call compares drift against it. This makes the write side effect and the preview escape hatch unmistakable.

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

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

The first sentence packs the core behavior efficiently, and the dry_run caveat is useful and short. The standalone 'Pro.' is cryptic and unexplained, which keeps this from a perfect conciseness score.

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

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

With no output schema, the description usefully previews that the call returns exceptions, a trial balance, and bank reconciliation, and it explains the snapshot/drift model. Minor gaps include the lack of a named follow-up tool for drift reporting and no elaboration of what 'Pro.' means operationally.

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

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

Input schema coverage is 100%, so the schema already documents month, dry_run, and currency. The description adds no new parameter meaning beyond restating that dry_run writes nothing, which the schema already conveys.

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

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

The description names a specific action on a specific resource: it lists unposted/unbalanced items plus trial balance and bank reconciliation, then stores the close as a snapshot. The snapshot/drift behavior is distinctive enough to separate month_close from siblings like trial_balance or period_delete.

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

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

The description implies a month-end closing workflow (list exceptions, then store a baseline) and clarifies dry_run as a no-write preview, but it never explicitly names alternatives or states when month_close should be chosen over trial_balance or period_delete. The 'Pro.' tag hints at an access restriction without specifying requirements.

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

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

Annotations already declare destructiveHint=true, but the description adds critical context: the refund of a free-tier slot and the refusal condition based on closed month snapshots. This goes beyond the annotation by explaining what is destroyed (the built period) and when the operation is blocked, which is valuable for an agent.

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

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

Three sentences with high information density: the action, the side-effect, and a key constraint are all included without redundancy. It is front-loaded with the primary purpose and then details constraints, making it easy for an agent to parse quickly.

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

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

For a destructive tool with a simple parameter set and no output schema, the description covers essential behavior: what is deleted, the refund, and the refusal condition. It might lack explicit mention of idempotency or partial failures, but annotations already hint at non-idempotency, and the constraints are well-covered, so minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not describe parameters in detail, but the schema descriptions for 'from' and 'to' are clear. The 'currency' parameter's conditional necessity is only in the schema, not the description, but the schema covers it well, so no penalty.

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

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

The description states a clear verb ('Delete') and resource ('one built period'), and explicitly distinguishes its side-effect ('give its free-tier slot back') and its scope ('No sibling book is touched'). This uniquely identifies the tool among siblings like ledger_build or month_close.

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

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

It clearly indicates when the tool will refuse (when a closed month's snapshot covers the period) and names the month, which informs an agent of a limitation. However, it does not explicitly contrast with when to use other tools, such as month_close for closing, but the scope statement ('No sibling book is touched') helps differentiate.

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

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

The description adds useful behavioral context beyond the annotations: it explains the minor-unit comparison and what happens when the trial balance does not tie. But annotations are all false/empty and the description does not clarify whether the tool is strictly read-only, whether it can mutate ledger data, or what the success path returns, leaving the side-effect profile to inference.

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

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

Two tightly written sentences lead with the core computation and follow with the important exceptional behavior. The phrase 'Free and unlimited' is the only minor extra, but it is short, relevant, and does not dilute the front-loaded meaning.

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

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

The description clearly gives the period scope and the failure-mode output, which matters because there is no output schema. However, it does not describe the success return shape, the exact format of the named entries/source documents, or error behavior, so an agent must guess what the tool emits when the ledger actually balances.

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

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

The input schema already documents all three parameters with 100% coverage, including the currency 'never added together' rule. The description's mention of 'period' and 'minor unit' loosely maps to from/to and currency but adds no new parameter-level syntax or constraints, so baseline 3 is appropriate.

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

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

The description states a specific operation — total debits and credits for a period and prove they equal the minor unit — plus a distinctive failure behavior: naming unbalanced entries and their source documents. This clearly distinguishes trial_balance from generic report siblings like ledger_report or month_close.

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

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

The description implies use for period-end balance verification ('for a period') and describes the conditional diagnostic behavior when totals do not agree. However, it does not explicitly say when to prefer this over sibling tools such as ledger_report or month_close, nor does it state any when-not-to-use conditions.

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