Kledo MCP by usefulapi

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

readOnlyHint already declares this a safe read, so the description's contribution is the scoping word 'every' (no filtering, all accounts) and the endpoint reference. It says nothing about ordering, pagination, or whether multi-currency balances are included — modest added context beyond 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 short sentences, purpose front-loaded, endpoint detail second. Nothing wasted and nothing repeated from the title alone.

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?

A simple no-parameter read with no output schema; stating scope and endpoint is nearly sufficient. A brief note on what each balance entry contains (or that results are unfiltered/unpaginated) would close the remaining 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?

Zero parameters, so the baseline of 4 applies; the description correctly conveys that the call takes no filtering input by saying 'every' account.

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?

States a specific verb and resource: 'Get the balance of every cash and bank account', plus the underlying endpoint. It is distinguishable from kledo_list_bank_transactions (transactions, not balances) and kledo_list_accounts (accounts, not balances), though it doesn't name those siblings explicitly.

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 only implied by the resource name; there is no statement of when to prefer this over kledo_list_accounts or kledo_report_cash_flow, and no prerequisites or exclusions. An agent can infer intent but must decide among siblings on its own.

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?

readOnlyHint=true already establishes the safety profile, so the description only needs to add context. It does disclose the shape of the returned record (address, phone, email, stats) and the underlying endpoint, but says nothing about behavior for a missing/invalid id or what 'stats' actually contains.

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 short sentences, front-loaded with the resource and returned fields. The API endpoint reference is borderline filler for an agent but is compact and aids mapping to Kledo docs.

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 carries the burden of describing the return value; it names the top-level fields but leaves 'stats' opaque and gives no error semantics. Adequate for a simple single-record fetch, but not 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?

Schema description coverage is 100%, so 'Record id.' and '1 = include stats.' are already documented in the schema. The description's '(optionally) stats' merely restates the include_stats parameter without adding meaning such as which statistics are returned or their cost.

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?

States a specific verb and resource ('Get one contact') and enumerates the fields returned plus the optional stats flag. It implicitly contrasts with kledo_list_contacts by specifying a single record, but never names the sibling list tool explicitly.

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 only usage hint is the parenthetical '(optionally) stats'. There is no statement of when to reach for this tool versus kledo_list_contacts, nor any precondition such as needing a known contact id.

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?

readOnlyHint=true already covers the safety profile, so the description's added value is the disclosure that the response is a denormalized aggregate including line items, payments and contact — non-obvious and important for planning. The REST endpoint adds a small amount of traceability. No pagination or error/not-found behavior is mentioned, but little is needed for a read-only single-record fetch.

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, front-loaded with what is returned before the API detail. The endpoint sentence is borderline redundant but cheap and aids debugging; nothing else is wasted.

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 carries the burden of describing return values, and it does list the embedded resources an agent will receive. For a one-parameter read-only tool this is close to complete; only error/empty behavior is left unspecified.

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 coverage is 100% and there is only one parameter, so the schema already documents 'Record id.' The description adds only that the id is the invoice id via the /finance/invoices/{id} path, which is marginal beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Get one sales invoice') and enumerates what the record includes (line items, payments, contact). The word 'one' implicitly separates it from kledo_list_invoices and the 'sales' qualifier from kledo_get_purchase_invoice, but neither sibling is named explicitly.

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 only implied: 'Get one' signals a single-record lookup by id, which is enough to infer that a list/search call is a different tool. There is no explicit when-to-use, no prerequisite, and no mention of kledo_list_invoices as the alternative when the id is unknown.

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=true, so the safety profile is covered. The description adds genuine value by disclosing that the response includes prices and settings and by naming the underlying endpoint (GET /finance/products/{id}), but says nothing about not-found behavior or auth requirements.

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

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

Two short sentences, front-loaded with the capability and followed by the endpoint reference. Nothing is redundant or padding.

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-record GET with one fully documented required parameter, the description covers purpose, the resource returned, and the API mapping. No output schema exists, and 'prices and settings' gives a partial sense of the return shape, so only minor gaps (error/empty cases) remain.

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 coverage is 100% and the single 'id' parameter is documented as 'Record id.' The description adds no format guidance (e.g., whether string or integer ids are preferred despite the anyOf) so it performs at the baseline for a fully documented 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?

States a specific verb and resource ('Get one product or service') and clarifies scope with 'one', which implicitly separates it from the sibling kledo_list_products. The added note that it returns prices and settings makes the purpose concrete, though no sibling is named explicitly.

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 singular 'one product' plus a required id implies this is for retrieving a known record rather than browsing, which implicitly routes bulk lookups to kledo_list_products. However, it never states when to use this instead of the list tool, and gives no prerequisites or 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds only the underlying endpoint (GET /finance/purchaseInvoices/{id}) and the fact that line items are included in the response; it says nothing about pagination, error behavior, or permissions, but with annotations in place that is not a major gap.

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 short sentences with the purpose front-loaded; nothing is bloated. The second sentence, the raw API path, is supplemental mapping information rather than description of the tool's own behavior, keeping it just short of a 5.

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 one required parameter fully documented in schema, readOnly annotations, and no output schema, the description is nearly sufficient; the mention of line items covers the return shape at a high level. An agent could call it correctly with no further information, though return-field detail and id-format expectations are absent.

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% for the single 'id' parameter, so the schema already documents it. The description only restates that the id goes in the path; it adds no format guidance (e.g., numeric vs string id conventions allowed by the anyOf 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?

States a specific verb and resource: 'Get one purchase invoice', and adds scope detail ('with its line items') that says what comes back. It does not name the sibling kledo_list_purchase_invoices or otherwise explicitly distinguish itself from the list variant, so it falls short of a 5.

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

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

The singular 'Get one' implies retrieval of a single record by id, but there is no explicit statement of when to use this vs kledo_list_purchase_invoices or the sibling kledo_get_invoice. No prerequisites or failure conditions (e.g., unknown id) 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?

readOnlyHint=true already declares the safety profile, so the description needn't restate that it is a read. It adds the concrete endpoint (GET /finance/accounts), which is useful confirmatory context, but says nothing about pagination defaults, result ordering, or cost of requesting balances.

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 short sentences with the core capability front-loaded and zero filler; the API endpoint is a compact, useful addendum rather than padding.

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 read-only, fully schema-documented list tool with annotations covering safety, this is nearly complete. The only residual gap is that, with no output schema, the description does not sketch what an account record or balance value looks like.

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 all four parameters (page, search, per_page, include_balance) are already documented in the schema. The description's "optionally with balances" reinforces include_balance but adds no syntax or behavioral detail beyond the schema, making baseline 3 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?

States a specific verb and resource ("List accounts of the chart of accounts") plus an optional capability (balances), which is enough to distinguish it from report tools like kledo_report_trial_balance. It does not, however, explicitly contrast itself with kledo_get_bank_balances or the report siblings, so an agent must infer the boundary.

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 explicit when-to-use or when-not guidance and no named alternative. The phrase "optionally with balances" hints at the include_balance parameter but does not tell an agent when to prefer this list over kledo_get_bank_balances or a balance-related report.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the useful scope detail that all three transaction directions are returned, but says nothing about pagination behavior, result ordering, or default result size (beyond the schema's page/per_page).

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 compact sentences, front-loaded with the purpose and ending with the concrete API endpoint. No filler; every element 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?

For a filtered list tool with no output schema, the description plus full schema coverage gives an agent enough to call it correctly. It could mention return shape or paging expectations, but that is a minor gap given the 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 100%, so every parameter (page, per_page, search, date_from, date_to, bank_account_id) is already documented in the schema. The description adds no parameter-level detail such as date-range interaction or how search matches, so baseline 3 applies.

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?

States a specific verb 'List' and resource 'bank transactions', and the parenthetical enumerates the three subtypes (money in, money out, transfers), which sharpens the resource. It does not explicitly differentiate from the nearest sibling, kledo_get_bank_balances (balances vs. transactions), but the resource is unambiguous on its own.

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 implied by the resource name and the transaction-type list, but there is no explicit when-to-use or when-not guidance and no named alternative. An agent must infer that this is the tool for enumerating transactions rather than balances.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's added value is the endpoint mapping and the note that stats are only included on request. It does not disclose pagination behavior (page/per_page defaults, max 100) or the return shape, which would matter for a 9-param listing tool.

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

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

Two short sentences with zero padding: purpose first, endpoint second. Nothing is repeated or wasted, and the key qualifier about stats 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 9 optional parameters and no output schema, the description should say more about what a result looks like and how paging works. Annotations cover the read-only safety profile and the schema covers every parameter, so the definition is workable, but the return-value and pagination gaps keep it at minimum viable.

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% and each parameter carries its own description, so the schema does the heavy lifting. The description only reinforces the include_stats semantics ('receivable/payable totals when requested') and adds no syntax, defaults, or interplay between name/search/type_id filters.

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?

States a specific verb and resource ('List customers, vendors and other contacts') plus the underlying endpoint GET /finance/contacts, so an agent knows exactly what it retrieves. It implicitly separates from the singular kledo_get_contact by framing this as a list with optional totals, but never names that sibling explicitly.

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 only usage signal is 'when requested' attached to receivable/payable totals, which loosely hints at the include_stats flag. There is no explicit when-to-use guidance, no exclusions, and no pointer to kledo_get_contact for single-record lookups or to the report tools for aggregate aging figures.

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 readOnlyHint annotation already establishes this is a safe read, and the description supplements it with the concrete HTTP route (GET /finance/expenses), which is mildly useful context. It says nothing about pagination defaults, result volume, rate limits, or what an expense record contains, so it stays at the minimum-viable level given annotation coverage.

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

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

Two short, front-loaded sentences with no filler; the resource name and the endpoint are each stated once. The endpoint citation earns its place mainly for traceability, though it is not operationally essential.

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 nine optional parameters, no required fields, and no output schema, the description is complete enough to call the tool but omits any hint of the response shape or pagination semantics, which an agent must guess at since no output schema exists.

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 all nine parameters including enums and date patterns are already documented in the schema. The description adds no extra semantics such as interaction between search and date filters, so the baseline of 3 applies.

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?

States a specific verb plus resource ('List recorded expenses') and even adds the Indonesian term 'biaya' and the backing endpoint, so the operation is unmistakable. It does not, however, distinguish itself from any sibling list tools or explain how expenses differ from, say, purchase invoices, which matters in a family of near-identical list endpoints.

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 when-to-use or when-not guidance, no mention of pagination expectations, and no pointer to alternatives. Usage is only implicitly inferable from the name, and a caller gets no help deciding between filtering by status_id versus searching free text.

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?

readOnlyHint=true already establishes this is a safe read, and the description adds useful context by enumerating the fields returned (important since there is no output schema) and the underlying endpoint. It says nothing about pagination behavior despite page/per_page parameters, nor about auth or result limits.

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 short sentences, front-loaded with the resource and returned fields, with the endpoint last as supporting context. No wasted words, though the filter sentence partially duplicates schema 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 13-parameter read-only list tool with no output schema, the description covers what it returns and what it can filter on, and gives the endpoint for reference. The main gap is pagination semantics, but the schema's page/per_page descriptions largely compensate.

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 all 13 parameters are already documented in the schema; the description only restates that due-date and amount filters exist. It adds no syntax, defaults, or interaction detail (e.g., how status_id comma lists or date range pairing work) beyond what the schema states.

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 gives a specific verb and resource ("List sales invoices") plus the payload it returns (contact, dates, amounts, status), which separates it from kledo_get_invoice on naming alone. It does not explicitly name the sibling it is not, so differentiation is implicit rather than stated.

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?

Mentions that due-date and amount filters are supported, which implies browsing/filtering use, but never says when to use this versus kledo_get_invoice or kledo_list_purchase_invoices. Usage must be inferred from the name and filter mentions.

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?

readOnlyHint=true already declares the safe-read profile, so the bar is lower. The description adds the upstream endpoint and flags that per-warehouse quantities are opt-in, which is genuinely useful. It says nothing about pagination defaults or result envelope, leaving the main behavioral question for an 8-param list tool unanswered.

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 short sentences with zero filler: capability first, endpoint second. The optional-stock behavior is front-loaded rather than buried, and nothing is repeated.

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-only list tool with 8 fully documented parameters and annotations covering the safety profile, the description covers what the tool returns (products/services with prices, optional warehouse quantities) well enough to call correctly. The absence of any note on pagination or result shape is a minor residual gap given no output schema exists.

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 coverage is 100%, so the schema already documents page, search, sort_by, order_by, per_page, stock_status, search_column and include_warehouse_qty thoroughly, including enum values. The description only restates the include_warehouse_qty behavior ("optionally with stock per warehouse"), adding marginal meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ("List products and services") and adds what the records carry ("with prices"), and the endpoint path confirms the finance/products domain. It implicitly distinguishes itself from the singular kledo_get_product sibling, though it never names it.

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 only implied by the verb "List" – an agent can infer this is the bulk-retrieval counterpart to kledo_get_product. There is no explicit statement of when to prefer this over the getter, nor any prerequisite or exclusion 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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It contributes the endpoint path and hints at returned fields ("amounts and status"), but says nothing about pagination limits (per_page max 100), default ordering, or total-count behavior, which matter for an 11-parameter paged 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?

Two short sentences, zero padding, with the resource and its vendor-bill gloss front-loaded before the endpoint reference. Nothing here is redundant with the title alone.

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 rich schema covers all 11 optional filters, so the agent can construct a call. However, with no output schema the description should say more about what comes back (record fields, pagination envelope), and the "with amounts and status" phrase is too thin to carry that burden.

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 every parameter including the date ranges, comma-separated status_id, and the sort_by/order_by enums is already documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ("List purchase invoices") and adds the disambiguating gloss "(vendor bills)", which separates it from the sales-invoice sibling kledo_list_invoices. It also names the backing endpoint. It stops short of explicitly naming the sibling it replaces, so it is clear but not fully differentiated.

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 statement of when to use this list tool versus kledo_get_purchase_invoice for a single record, or versus the report tools that also cover payables. The listing intent is only implied by the verb "List".

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=true, so the safety profile is covered, and the description adds only the REST endpoint mapping. It says nothing about pagination behavior, result ordering defaults, or what a returned quote record contains — for a 9-parameter list tool that is a meaningful gap.

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

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

Two short sentences with no waste, and the purpose is front-loaded before the endpoint detail. Terseness is close to under-specification here, which keeps it off a 5.

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?

No output schema exists, so the description was the only place to explain the shape of returned quote records, pagination metadata, or how the date_from/date_to and status_id filters combine. None of that is present, leaving the agent to call blind on return values.

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 all nine parameters are already documented in the schema. The description adds no filtering semantics beyond the schema, which is the correct baseline-3 case where the schema carries the burden.

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?

States a specific verb and resource ('List sales quotes') plus the Indonesian alias 'penawaran', which is genuinely useful in this domain. It is clearly distinct from siblings like kledo_list_sales_orders and kledo_list_invoices, though it never says so explicitly.

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 on when to use this versus kledo_get_invoice or kledo_list_sales_orders, and no prerequisites or exclusions. The agent must infer usage purely from the name.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's only real contribution is the endpoint mapping. It says nothing about default sort order, pagination behavior, whether all statuses are returned by default, or result shape — meaningful gaps for a list tool with no output 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?

Two short sentences with no filler, and the identity of the tool is front-loaded. The economy is good, though the second sentence carries almost no decision-relevant 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?

With nine optional filters, no output schema, and no required parameters, the description leaves the agent guessing about default behavior and return contents. It is far too thin for a listing tool whose filtering semantics matter to callers.

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%, and the schema documents all nine parameters including enums for sort_by/order_by and format patterns for dates, so the baseline of 3 applies. The description adds no semantics beyond that, such as how search interacts with the date filters.

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?

States a specific verb and resource ('List sales orders') and pins it to the underlying endpoint (GET /finance/orders), so the agent knows exactly what is being fetched. It does not differentiate from sibling list tools such as kledo_list_invoices or kledo_list_quotes, which is the only thing keeping it from a 5.

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 the other listing or reporting siblings, and no preconditions or exclusions are given. The agent must infer usage entirely from the name.

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?

readOnlyHint=true already establishes this as a safe read. The description adds the age-grouping behavior and the API mapping, but says nothing about pagination behavior, sorting, or what the aging buckets look like, and the schema exposes page/per_page that go unmentioned.

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 terse sentences with the core purpose front-loaded and the endpoint as a secondary detail. No 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 read-only report the safety profile and parameters are covered, but with no output schema the description should hint at the aging bucket structure or returned fields. As written an agent knows what the tool conceptually returns but not its shape.

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 all three parameters (date, page, per_page) are fully documented in-schema. The description adds no parameter semantics beyond the schema, so the baseline 3 applies.

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?

States a specific resource ('unpaid vendor bills') and transformation ('grouped by age'), plus the underlying endpoint. 'Vendor bills' implicitly distinguishes it from the aged receivable sibling, though it never names that alternative explicitly.

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 implied by the report nature and the 'unpaid vendor bills' scope, but there is no explicit when-to-use guidance, no mention of the aged-receivable alternative, and no note on defaults or prerequisites.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds no behavioral context beyond that — no default as-of date, no aging-bucket structure, no pagination behavior. The endpoint string is implementation trivia rather than agent-facing behavior.

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 compact sentences with the purpose front-loaded and no padding. The API endpoint line is low value for an agent but costs almost nothing in length.

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 should hint at the return shape (aging buckets, totals, per-customer rows), which it omits. For a simple three-optional-parameter read-only report it is minimally adequate but leaves the agent guessing about output structure.

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 date, page, and per_page are already fully documented with format and bounds. The description adds nothing about parameters, which is acceptable given the schema baseline but earns no credit above it.

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?

States a specific resource and scope: unpaid customer invoices grouped by age, which implicitly distinguishes it from the payable counterpart in the sibling list. It is clear but never explicitly names kledo_report_aged_payable as the contrasting tool.

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 on when to choose this over kledo_report_aged_payable, kledo_list_invoices, or the other financial reports. The only extra line is a raw API endpoint, which does not help an agent decide when to invoke 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?

readOnlyHint=true already covers the safety profile, but the description adds nothing beyond that — no indication of what the report contains (assets/liabilities/equity sections, comparative periods, currency) and no output schema exists to fill the gap. The endpoint path is the only added context.

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 short, front-loaded clauses with no filler; the resource and date scope lead. Slightly terse given the gaps it leaves, but nothing is wasted.

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 report tool with no output schema, the description should say at least what the response contains or how it is shaped. It covers the input and endpoint but leaves the agent guessing about return structure.

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?

Only one optional parameter with 100% schema description coverage, so the schema already documents the yyyy-mm-dd format. The description's 'as of a date' merely echoes the schema, which is the expected 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?

States a specific verb (report retrieval) and resource (balance sheet / neraca) with the as-of date scope. It doesn't explicitly distinguish itself from sibling reports like trial balance or profit & loss, but the name is unambiguous.

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 only implied by the report name; there is no explicit guidance on when to choose a balance sheet over kledo_report_trial_balance or kledo_report_profit_loss, and no prerequisites or excluded cases are stated.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying endpoint (GET /reportings/cashFlow), which is mild context, but says nothing about defaults for the optional date range or the shape/aggregation of the returned statement.

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 short sentences, front-loaded with the purpose; nothing is padded. The trailing API-endpoint sentence is compact but adds little for an agent that cannot call HTTP directly.

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 could say what the statement returns or whether the period defaults when dates are omitted. As written, an agent knows what the tool is but not what to expect back or how omitted params behave.

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 all three parameters (method, date_from, date_to) are already documented in the schema. The description only echoes the method enum and adds no date-format or default-period semantics, so baseline 3 applies.

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?

States a specific verb and resource ("Cash flow statement for a period") plus the supported methods, which separates it from report siblings such as profit_loss and balance_sheet. It does not explicitly name or contrast those siblings, so it stops short of a 5.

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

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

No guidance on when to pick this report over the other report tools, and no guidance on choosing direct vs indirect or on what happens when the period is omitted (0 required params). The agent must infer all of this.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds nothing beyond that except the raw API endpoint. It does not state what happens when year/month are omitted (all parameters are optional), nor whether a default period is applied, nor anything about the shape or timeliness of the figures.

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 short sentences, with the substantive content (which metrics) front-loaded. The trailing API endpoint reference is mildly useful for API-aware agents but is the least essential of the two 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?

There is no output schema, so the description partially compensates by listing the returned metrics, which is helpful. However, for a tool whose two parameters are both optional, the description never says what period is used by default or whether both must be supplied together — a meaningful gap 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?

Schema description coverage is 100% and both parameters (year, month with a 1-12 pattern) are already documented there, so the baseline of 3 applies. The description's 'for a month' reinforces the period semantics but adds no format, default, or behavior detail beyond 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 names the specific resource (executive summary) and enumerates the metrics it returns — revenue, cost, cash, receivables — for a stated granularity (a month). It is clear it aggregates financials, separating it from the transactional siblings like kledo_list_invoices, though it does not explicitly differentiate itself from the other kledo_report_* tools.

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 only implied: 'for a month' signals the expected period granularity. There is no statement of when to pick this over kledo_report_profit_loss, kledo_report_cash_flow, or kledo_report_balance_sheet, which cover overlapping financials, and no prerequisites or exclusions are 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?

readOnlyHint=true already tells the agent this is a safe read, and the GET endpoint path mildly corroborates it. Beyond that the description discloses nothing: no note that all three parameters are optional and what defaults apply, no return shape, no pagination, no currency/consolidation behavior. For a reporting tool with no output schema, that is a thin disclosure.

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 short sentences, front-loaded with the resource name and its Indonesian synonym, with the endpoint as supporting detail. Nothing is wasted, but the extreme brevity leaves obvious gaps rather than being tightly optimized.

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 zero required parameters and no output schema, the description needed to explain what the returned P&L contains (line items, totals, period labeling) and what the defaults are when parameters are omitted. It does neither, so an agent cannot predict the response at all.

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 enum values (monthly/yearly/quarters/custom) and the yyyy-mm-dd date formats are already documented. The description adds nothing beyond the phrase 'for a period'; in particular it does not explain how 'type' interacts with the date range or what happens when dates are omitted.

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?

Names a specific resource — the profit and loss (laba rugi) report over a period — and even cites the backing endpoint GET /reportings/profitLoss. That is enough to distinguish it from sibling financial reports like balance sheet, cash flow and trial balance, though the distinction rests on the report name alone rather than any statement of how it differs.

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 explicit when-to-use guidance, no prerequisites, and no mention of the alternative reports in the sibling set (executive summary, trial balance, cash flow). The only usage signal is implicit in 'for a period', leaving the agent to infer that date_from/date_to drive the report.

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?

readOnlyHint=true already covers the safety profile, so the description carries a reduced burden, but it adds essentially nothing beyond the endpoint string. It doesn't say what the report contains, whether it includes accounts with zero balances, or how it is scoped.

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 short sentences with no filler and the purpose front-loaded. Nothing is padded or redundant.

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 two-parameter read-only report with full schema coverage, the definition is enough to call the tool, but with no output schema the description should hint at the shape of the returned report (account rows, debit/credit totals) and does not.

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 coverage is 100%, so both date parameters are fully documented in the schema; the description's 'for a period' adds only a notional mapping. Baseline 3 applies when the schema does the heavy lifting.

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-resource pair, 'Trial balance for a period,' which is concrete enough to know what the tool returns. It doesn't differentiate from sibling reports like kledo_report_balance_sheet or kledo_report_profit_loss, but the resource is named precisely.

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 on when to choose this report over the other six report siblings. The only usage context is 'for a period,' which is implied by the date_from/date_to parameters anyway.

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