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

No annotations are present, so the description carries the behavioral burden. It does disclose a meaningful limitation: as_of_date is informational only and does not currently filter. However, it does not explicitly state whether the operation is read-only, or mention auth or other side-effect concerns.

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: one clear purpose sentence followed by a minimal Args block. Every line earns its place with no repetition or filler.

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 tool with only two optional parameters and an existing output schema, the description covers purpose, grouping approach, and the important date limitation. Return values are not described, but the output schema handles that. The main gap is the absence of explicit guidance on choosing between this and sibling financial-report tools.

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?

With 0% schema description coverage, the Args section fully compensates: company explains the default behavior, and as_of_date explains ISO format and the informational-only caveat. This adds real semantic meaning well beyond the bare null/string 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 opens with a specific verb and resource: 'Get a simplified Balance Sheet', and adds detail about grouping asset and liability ledgers by Tally primary group. It clearly states what the tool does, though it does not explicitly differentiate it from financial siblings like get_trial_balance.

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?

Usage is mostly implied by the Balance Sheet resource and the 'simplified' framing. There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The as_of_date caveat ('Currently informational only') provides some expectation-setting but not tool-selection guidance.

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?

With no annotations, the description carries the burden of behavioral disclosure. It adds some useful context such as 'Exact ledger name as it appears in TallyPrime' and 'If omitted, uses the configured default' for company, but it does not describe behaviors like whether from/to dates form an inclusive range or what happens when dates are omitted.

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

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

The description is compact and well-structured: a one-sentence summary followed by a clear Args list with no filler. Every line adds needed parameter detail, and the most important scoping 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?

For a read-oriented tool with an output schema, the description covers the essential invocation details: exact ledger name, company fallback, and date formats. The only notable gap is ambiguity around whether both date bounds are needed together)Skip, but the individual optional markers and the output schema mitigate this.

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 0%, so the description must compensate. It does by giving each parameter meaningful guidance: exact ledger name, company default behavior, and ISO format for optional dates. This adds real value beyond the bare schema types and defaults.

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 verb and resource: 'Get a ledger's master details plus its transactions (vouchers) in a date range.' This clearly distinguishes it from siblings like get_voucher and search_vouchers by emphasizing the ledger-level aggregation and date-range scoping.

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 explains required inputs but gives no explicit guidance on when to choose this tool over alternatives. It does not mention that search_vouchers should be used for voucher-level search, or that list_ledgers lists available ledgers, leaving usage routing to inference.

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?

No annotations are provided, so the description carries the full burden of disclosing behaviors. It states that 'as_of_date' is 'informational only' and points to docs, which is a positive disclosure of a limitation. However, it does not reveal what the tool returns (e.g., a list of ledgers with balances? only those with non-zero balances?), the format of output, or any side effects (though it's likely read-only). The behavior beyond that is opaque.

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, with the first sentence giving the core function, followed by a compact parameter list. It avoids redundancy and front-loads the key purpose. Minor point: the 'Args' section repeats parameter names, but it's standard and adds useful details. No wasted sentences.

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 that there are only two optional parameters and the tool is relatively simple, the description covers the essential purpose and parameter semantics. However, there is an output schema that could clarify return values, but the description doesn't detail what the output contains (e.g., does it return a list of balances?). Also, without annotations, the description should explain if there are any prerequisites (e.g., company must be set) or effects, which are missing.

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 0%, so the description must compensate. It explains that 'company' defaults to the configured default and 'as_of_date' is informational only, which adds value beyond the schema's bare 'Company' and 'As Of Date' titles. However, it doesn't elaborate on the format of 'as_of_date' (though it says ISO format) or what 'informational only' implies for the result. The description provides some semantic context but not comprehensive.

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 resource ('outstanding payables') and the specific condition ('ledgers under 'Sundry Creditors' with a non-zero balance owed by the company'). This distinguishes it from the sibling get_receivables, which likely handles amounts owed to the company, and from other financial reports like get_trial_balance or get_balance_sheet, which are broader. The verb 'Get' is specific and the scope is well-defined.

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 does not explicitly state when to use this tool versus alternatives. It doesn't mention that get_receivables is for amounts owed to the company, nor does it clarify when to use get_trial_balance versus get_payables. The context of 'outstanding payables' implies a use case for checking unpaid liabilities, but there is no explicit guidance on selection among siblings.

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?

With no annotations, the description carries the behavioral disclosure burden. It reveals the report is 'simplified' and grouped by standard primary ledger groups, and it documents the default company behavior. It does not describe edge cases, period inclusivity, or a read-only/safety posture, but this is partially mitigated by the tool being a report.

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: one sentence stating the tool's function and a short Args block covering exactly the three parameters. Every line contributes necessary information without redundant or vague content.

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 simple three-parameter report tool with an output schema, the description covers the core behavior and all input semantics sufficiently. It is only slightly incomplete because it does not explicitly position the tool relative to similar financial report siblings.

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 has zero descriptions, so the description fully compensates by explaining all three parameters: company name with configured default, ISO-format start date, and ISO-format end date. This adds real meaning beyond the nullable schema fields.

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 ('Get a simplified Profit & Loss statement') and adds distinguishing detail about grouping income and expense ledgers by Tally primary group. It clearly identifies the report type, though it does not explicitly contrast it with siblings.

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 purpose implies when the tool should be used: when a simplified P&L for a company and date range is needed. However, it provides no explicit guidance about when to prefer this over siblings like get_trial_balance or get_balance_sheet, and it states no exclusions.

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?

With no annotations provided, the description carries the behavioral burden. It discloses what counts as outstanding and, importantly, reveals that as_of_date is 'informational only'—a non-obvious trait that prevents an agent from assuming date filtering. It does not cover auth or pagination, but for a simple read tool the core behavior 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.

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

The description is compact and well-structured: one clear purpose sentence followed by two documented parameter lines. There is no filler or repetition, and the most important caveat is placed directly beside the relevant parameter.

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 tool has only two optional parameters and an output schema, so the return shape does not need to be explained. All parameters are described, the purpose is precise, and the only external pointer is a docs reference for a caveat that is also summarized inline. An agent has enough 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?

Schema description coverage is 0%, so the description must compensate. It does: company is explained with its default fallback behavior, and as_of_date is given an ISO format plus the crucial caveat that it is currently informational only. Both parameters receive meaning the schema entirely lacks.

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 a specific verb and resource: 'Get outstanding receivables' and then precisely defines the scope as ledgers under 'Sundry Debtors' with a non-zero balance owed to the company. This makes it immediately distinguishable from siblings like get_payables.

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 definition gives clear context for when to use the tool: when outstanding receivables under Sundry Debtors are needed. It does not explicitly name alternatives or exclusions, but the precise scope and the sibling set make the intended use obvious.

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?

With no annotations, the description carries the disclosure burden. It discloses that from_date is informational and that company falls back to a configured default. It does not mention permissions, side effects, or return format, but for a read operation these are less critical. The info-only caveat is valuable behavioral context, so a 3 is appropriate.

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

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

The description is two sentences plus a compact Args block. It front-loads the main purpose and packs parameter semantics into a structured list with no fluff. Every sentence and field earns its place.

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 that an output schema exists, the return format is covered elsewhere. The description clarifies the aggregate nature, the default company behavior, and the informational status of from_date, which are key to correct invocation. It lacks prerequisites or edge-case handling, but for a simple read tool with optional params, this is sufficient.

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 0%, so the description must explain parameters. It does so thoroughly: company gets a default-behavior explanation, from_date gets an ISO format plus an informational-only caveat, and to_date gets an ISO format. This adds meaning well beyond the bare schema, which only lists names and types.

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 verb ('Get') and resource ('aggregate stock summary across all items for a company'). It clearly differentiates from siblings like list_stock_items by emphasizing 'aggregate' and 'across all items', making its scope unambiguous. This is a precise, non-tautological purpose statement.

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 the tool is for when an aggregate summary is needed, and it provides a usage note that from_date is informational only. However, it does not explicitly contrast with list_stock_items or other alternatives, nor does it state exclusions. The guidance is adequate but not explicit.

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?

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: closing balances reflect TallyPrime's current ledger state rather than a point-in-time reconstruction, and points to docs/tools.md for more. It also states the output structure (debit/credit columns, totals). It could add more about permissions or side effects, but for a read-only report tool this is solid.

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: the core purpose is in the first sentence, followed by a concise parameter list. Every sentence earns its place, and the caveat is clearly flagged.

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 tool has an output schema and only three optional parameters, the description covers the essential behavior and parameter semantics. The main gap is not explicitly stating when to prefer this over get_ledger or get_profit_and_loss, but the scope is clear enough for an agent to select 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?

Schema description coverage is 0%, so the description must compensate. It does: it explains the company parameter's default behavior and gives format and caveats for from_date and to_date. It doesn't detail exact date handling beyond the caveat, but it adds meaningful semantics beyond the bare 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 states a specific verb ('Get') and resource ('a trial balance'), and precisely defines the scope: every ledger with a non-zero closing balance, split into debit/credit columns, with totals. This clearly distinguishes it from sibling tools like get_ledger or get_profit_and_loss.

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 explains the role of each date parameter and explicitly warns that dates are informational only, which is important usage context. It does not explicitly name alternatives or when-not-to-use, but the clear scope and sibling list make the intended use evident.

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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that company is optional and falls back to the configured default, but it does not mention not-found behavior, error handling, or permissions. For a simple read operation this is adequate but not fully transparent.

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 short and front-loaded with the core purpose, followed by a compact parameter list. Every sentence contributes meaningful information, and there is no redundant or vague filler.

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 tool is a simple single-voucher getter with an output schema, the description covers the essential invocation details. The only minor gap is the lack of explicit guidance on when to use this tool versus search_vouchers, but this does not block correct usage.

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 0%, but the description fully compensates by explaining both parameters: voucher_identifier is defined as the voucher number as it appears in TallyPrime, and company is documented with its default behavior. This adds real meaning beyond the bare 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: 'Get a single voucher by its voucher number.' It clearly distinguishes itself from sibling search_vouchers by emphasizing a single exact lookup rather than a search operation.

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 the tool should be used when a specific voucher number is known, but it does not explicitly state when to prefer this over search_vouchers or other alternatives. The usage context is inferable but not directly articulated.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It states it lists companies but doesn't explicitly confirm read-only behavior, require authentication, or describe potential side effects (none expected). It also omits details about error conditions or what 'loaded/available' means beyond a simple list.

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?

A single, concise sentence that states the action and resource without any filler. It is efficiently structured and front-loaded with the key 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 simple no-parameter list tool, the description is adequate but lacks context about connection requirements, possible empty results, or output structure. Since an output schema exists, the return format is covered, but the description does not mention any operational context or limitations.

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 tool has zero parameters, so the schema is fully covered. The description adds no parameter information, but the baseline for 0 params is 4, which 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 'List' and the resource 'companies' within TallyPrime, making the tool's purpose unambiguous. It differentiates from siblings by naming the specific resource (companies) and its context (loaded/available).

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios where this tool is preferred over other listing tools (e.g., list_ledgers, list_stock_items) or any prerequisites like an active connection. The agent is left to infer usage from the name alone.

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

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 reveal important behaviors: the default company fallback and the case-insensitive substring search. However, it does not explicitly state that the operation is read-only or has no side effects, which is a meaningful behavioral trait for an agent to know. Given that the tool name implies a read operation, the omission is not severe, but the description could be more explicit about the 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 concise: two sentences for the purpose and a clearly formatted argument list. The core purpose is front-loaded, and every sentence adds value. There is no fluff or repetition, and the argument explanations are structured and easy to parse.

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 tool's simplicity (two optional parameters, a listing operation, and an output schema that presumably documents the return structure), the description covers everything an agent needs to invoke it correctly. It explains the default company behavior, the search filter, and the fields returned. No critical information is missing, and the presence of an output schema means return values are documented elsewhere.

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 provides zero description coverage, so the description must fully compensate. It does: both parameters (company and search) are explained with their semantics, including the default behavior of company and the case-insensitive substring matching of search. This adds significant meaning beyond the bare schema and leaves no ambiguity about what each parameter does.

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 lists ledger accounts and specifies the fields returned (group, opening balance, closing balance). The verb 'List' combined with the resource 'ledger accounts' is specific and distinct from the sibling get_ledger, which suggests a singular lookup. This gives an agent an unambiguous understanding of what the tool does.

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

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

The description provides clear context on how to use the tool, including the optional company parameter with its default behavior and the search filter semantics. It does not explicitly mention alternatives or when not to use it, but the purpose of listing all ledgers is self-evident and distinguishes it from singular operations like get_ledger. No exclusions are needed beyond what the name and purpose imply.

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?

There are no annotations, so the description carries the burden of disclosing behavior. It signals a read operation via 'List', states what the response contains, and documents parameter behavior such as the configured-default company and case-insensitive substring search. It does not discuss auth, rate limits, or pagination, but these are not critical for this simple read tool.

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 short, purposeful sections: a one-sentence purpose statement followed by the parameter details. It is front-loaded and contains no filler or redundant restatement of the schema.

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 simple list tool with two optional parameters and an output schema, the description provides enough to invoke it correctly. The only minor gaps are the absence of explicit sibling differentiation and any mention of pagination or result size, though neither is essential for correct 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?

The schema has 0% description coverage, yet the description explains both parameters fully: company defaults to the configured company when omitted, and search is an optional case-insensitive substring filter on item names. This adds meaningful semantics beyond the raw 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 clearly states a specific verb ('List') and resource ('stock (inventory) items') and specifies the associated data ('opening/closing quantity and value'). It is unambiguous about what the tool returns, but it does not explicitly differentiate from siblings such as get_stock_summary.

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 use case is implied: call this when you need stock items with quantities and values. The Args section explains parameter behavior, but it does not provide explicit when-to-use versus alternatives or any exclusions, leaving the agent to infer routing from the tool name alone.

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

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

With no annotations, the description carries the behavioral burden. It discloses matching semantics (exact for voucher_type, substring for ledger and search_term), defaults (company and limit), and optionality of all parameters. It does not contradict any annotation and adds meaningful behavioral detail beyond the bare schema.

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 moderately long but well-structured, with the purpose in the first line followed by a clear Args block. Every line conveys useful information without redundancy. It could be slightly more concise, but the structure is efficient and scannable.

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 tool has an output schema, so return values need no explanation. The description covers purpose, all parameters, defaults, and matching behavior, which is sufficient for an agent to invoke it correctly. It does not discuss error cases or ordering, but these are not critical for a search tool given the output schema.

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 0%, so the description must fully explain parameters. It does so thoroughly: each parameter's purpose, format (ISO dates), matching behavior, and default are stated. This far exceeds what the schema provides, making parameter semantics explicit and actionable.

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 searches accounting vouchers (invoices, receipts, payments, journals) and lists the filtering criteria (date range, type, party ledger, free-text). This distinguishes it from siblings like get_voucher (which presumably fetches a single voucher) and financial reports like get_trial_balance.

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 this tool is for searching/filtering vouchers, but it does not explicitly compare with siblings (e.g., 'use get_voucher to retrieve a specific voucher by ID'). It lacks explicit when-to-use vs when-not-to-use guidance, relying on the tool name and parameter list to convey context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly frames the operation as a read-only diagnostic probe ('Check whether... running and reachable... responded with valid data'), implying no side effects or mutations. While it does not detail timeout behavior or auth requirements, the stated behavior is sufficient for a simple connection test.

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. The first sentence states the core purpose in a front-loaded manner, and the second sentence adds actionable guidance. Every word earns its place.

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?

This is a low-complexity tool with no parameters and an output schema present, so the description does not need to explain return values. It sufficiently covers what the tool does and when to use it, giving an agent all the information needed to select and invoke 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 tool has zero parameters, so there are no parameter semantics to clarify. The baseline for 0 params is 4, and the description appropriately avoids inventing parameter details that do not exist.

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 ('Check') and explicitly names the target resource (TallyPrime connection at the configured host/port) and the criterion (running, reachable, valid response). This clearly differentiates the tool from sibling data-retrieval tools like get_voucher or get_balance_sheet, which serve entirely different purposes.

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 explicit guidance on when to use the tool: 'Use this first if any other tool call fails unexpectedly.' This provides a clear usage context. It does not mention exclusions or alternative connection-testing tools, but none exist among the siblings, so a 4 is warranted.

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