Laudus MCP by usefulapi

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description's only added behavioral content is the concrete endpoint paths for each layout; it says nothing about result size, pagination, or permission requirements for a report that could return a large account tree.

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 dense sentence that front-loads the resource and then the layout variants and endpoints. Nothing is wasted, though the endpoint URLs arguably serve the implementing agent more than the selecting agent.

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 7 optional parameters, no output schema, and a report that has meaningful return structure, the description is thin. It never says what the response contains (account hierarchy vs totals) despite distinguishing two layouts, and leaves several filter parameters unexplained.

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 only 57%, and the description only touches layout and date, which the schema already documents. Three parameters (cost_center_id, show_accounts_with_zero_balance, show_only_accounts_with_activity) have no description anywhere, so the text doesn't compensate for the coverage gap.

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 (balance sheet / balance general) and names the two layout variants plus their endpoints, so an agent can identify it as a financial report distinct from, say, list_accounts or general_ledger. It doesn't explicitly differentiate itself from the sibling laudus_profit_and_loss, but the resource is named concretely enough to be 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: 'as of a date' and the choice of standard vs totals layouts. There is no guidance on when to prefer this over laudus_profit_and_loss, laudus_general_ledger, or laudus_purchase_ledger, and no statement of prerequisites or which layout suits which need.

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 write, non-idempotent, non-destructive, open-world. The description adds meaningful context beyond that: the id is server-assigned, no side effects like sending documents occur, and the server may demand fields beyond those supplied and will reply with a validation message. Only the shape/format of that error response is left implicit.

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?

Four short clauses, front-loaded with the 'WRITE:' marker for quick risk triage, then behavior, then precondition, then failure mode. No redundant restatement of the title or 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 an 11-param write tool with no output schema, the description covers the critical unknowns: server-assigned id, no sending side effects, possible extra required fields, and error behavior. Field-level detail is left to the schema, which is a fair split, though more guidance on which fields Laudus typically demands would help.

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 only 55% across 11 params, so the description should compensate more. It does highlight RUT (vat_id) as the dedup key, which is the most important semantic, but it does not explain that name is the only required field or clarify the remaining undocumented 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?

States a specific verb and resource (creates a customer in Laudus) and immediately scopes it against confusable siblings by clarifying that the record is not an invoice and sends nothing. Also clarifies id assignment, so an agent knows not to supply one.

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?

Gives an explicit prerequisite workflow: check laudus_list_customers for the RUT first to avoid duplicates. It doesn't name an alternative creation path or say when not to create, but the dedup guidance is concrete and actionable.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and the returned concepts (credit limit and used amount), but does not disclose auth requirements, error behavior, or whether a missing customer returns an error versus empty data.

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 sentences and front-loads the return-value concept. It is efficient with no wasted prose, though the endpoint sentence is less valuable to an agent than a usage or parameter detail would be.

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 appropriately names what is returned: the credit limit and used amount. However, for a tool whose only parameter is undocumented in both schema and description, and with no guidance on customer-id format or error behavior, it is only minimally 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 0% for the single customer_id parameter, so the description carries the burden of explaining it. The path template {id} hints that a customer identifier is required, but the description never names or explains the parameter, its format, or its relationship to customer records.

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 specifies the resource (a customer's credit limit) and adds useful scope by stating it also returns how much of the limit is used. It is more than a title restatement because of that added return-value detail and the endpoint, though it lacks an explicit verb and does not directly distinguish itself from siblings like laudus_get_customer or laudus_customer_pending_invoices.

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

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

It provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The endpoint and name imply it is used to retrieve credit-limit data, but the agent must infer that 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds only the underlying GET endpoints, which confirms read semantics but says nothing about pagination, result size, or whether partially paid invoices count as pending.

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, front-loaded sentences with the purpose first and the scoping rule second. The endpoint URLs are the weakest element – useful for orientation but partially redundant filler for an agent that invokes by tool name.

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 one-parameter read tool with annotations this is nearly sufficient, but with no output schema the description should at least sketch what a pending invoice record contains (amount, due date, currency) or how 'pending' is defined. That gap leaves an agent guessing about the return payload.

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 parameter's own description already says 'omit for every customer'. The description repeats that same fact plus the positive constraint, so it adds no semantics 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 resource and qualifier: 'Unpaid sales invoices (accounts receivable)'. That distinguishes it well from the sibling laudus_list_sales_invoices, but the differentiation is implied by the word 'Unpaid' rather than called out 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?

Explains the customer_id scoping choice ('Give customer_id for one customer, or leave it out for all customers'), which is usage of the parameter rather than guidance on when to pick this tool over laudus_list_sales_invoices or laudus_balance_sheet. No exclusions or alternatives are named, so usage is only implied.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the endpoint path; it says nothing about pagination defaults, whether results are ordered, or how range expansion behaves. With annotations carrying the safety burden, a baseline-plus score 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?

Two compact fragments that front-load the resource and scope. Very little waste, though the endpoint path is arguably redundant with MCP mechanics.

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 an 8-parameter reporting tool with no output schema, the description is thin: it omits what a 'movement' row contains and never mentions book_id, cost_center_id, or paging behavior. Adequate to start a call 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 coverage is 50%, and the description's mention of 'an account or a range of account numbers, for a date range' adds meaning for account_number_from/to and date_from/to. But book_id and cost_center_id are undocumented in both the description and the schema, and limit/offset only appear in the schema. Partial compensation justifies a 3.

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 (general ledger / libro mayor movements), scope (an account or account-number range), and filter (date range), plus the backing endpoint. It distinguishes itself reasonably from laudus_purchase_ledger by naming the general ledger, though it does not explicitly contrast with that sibling.

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 instead of laudus_purchase_ledger, laudus_get_journal_entry, or laudus_profit_and_loss — the closest alternatives in the sibling list. The only implied usage is the bare mention of account and date scope.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by enumerating the fields the response includes (addresses, contact data, credit limit, category, salesman, price list), which is valuable precisely because no output schema exists.

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 front-loaded sentence plus endpoint, with zero filler. Every clause earns its place by either naming the resource or specifying the payload.

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 no output schema, listing the returned fields is the right compensating move. Still missing for an agent to invoke reliably: how to source the customer_id, and behavior when the id does not exist (empty result vs. error).

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 parameter exists and schema description coverage is 0%, so the description must carry the burden. "by id" clarifies that customer_id is a customer identifier, but it adds no format, source, or validity guidance beyond that.

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

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

States a specific verb and resource ("Get a customer") and enumerates the data returned (addresses, contact data, credit limit, category, salesman, price list). It is clear what the tool does, but it does not contrast itself with the sibling laudus_list_customers (bulk listing) or clarify that this is the single-record fetch.

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?

"by id" implies the tool requires a known customer identifier, which implicitly distinguishes it from list-style siblings. However, there is no explicit when-to-use rule, no mention of where to obtain the id (e.g., laudus_list_customers), and no note on what happens for an unknown 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds that the response includes the journal lines and names the REST endpoint, but says nothing about permissions, error behavior, or whether lines are paginated.

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, both front-loaded and waste-free, with the resource and return shape stated first and the endpoint as a compact second clause.

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

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

For a single-parameter read tool with no output schema, the description is nearly complete: it states what is fetched and that lines are included. An explicit mention of the error case (missing id) or the id source would make it fully 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?

Only one parameter (journal_entry_id) with 0% schema description coverage, so the schema gives no format guidance beyond integer > 0. The description conveys 'by id' and the endpoint path, but does not clarify what IDs are valid or where to obtain them.

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: retrieve an accounting journal entry (comprobante) with its lines by id, plus the endpoint. This clearly distinguishes it from the laudus_list_journal_entries sibling, though it doesn't name 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?

Usage is only implied: 'by id' signals this is the single-record fetch as opposed to a listing. There is no explicit when-to-use/when-not statement or direct pointer to laudus_list_journal_entries for lookups.

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, openWorldHint and destructiveHint, so the safety profile is covered. The description contributes the REST endpoint and the list of returned fields, but says nothing about error behavior for a missing id or rate limits, so it adds only modest 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 sentences, front-loaded with the purpose and followed by the endpoint. Nothing is redundant or padded.

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 single-parameter read with no output schema, the description states the resource, the lookup key, and the returned fields. Only minor gaps remain, such as not-found behavior.

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 carry parameter meaning. It repeats 'by id' and the path template, which matches the sole parameter, but adds no constraints or format details beyond what the schema's integer type already conveys.

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

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

Names a specific verb and resource ('Get a product') and enumerates the payload fields, which lets an agent tell it apart from list_products. It stops short of naming the sibling alternatives explicitly, but 'by id' does the differentiation work.

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 versus laudus_list_products or laudus_get_product_stock, nor any prerequisite guidance. The 'by id' phrasing only implies the usage condition.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the concrete endpoint paths and the interaction where lot/warehouse filters are ignored under by_warehouse, but says nothing about return shape, pagination, or precision of stock 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?

A single dense sentence with the primary scope front-loaded, followed by the mode that changes behavior and the backing endpoints. Nothing is padded or 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 query tool with no output schema, the description should indicate what comes back (e.g., quantity/unit per warehouse or lot). It covers inputs and endpoints but leaves the result contract entirely unspecified, which is a meaningful gap.

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

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

Schema description coverage is 80%, so most parameters are already documented in the schema. The description restates the date, warehouse, lot and by_warehouse behavior without adding syntax, defaults, or edge cases beyond what the schema provides; 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+resource ('Stock of one product') and the two supported modes (single warehouse/lot vs. per-warehouse breakdown), including the underlying endpoints. An agent can distinguish it from laudus_list_stock or laudus_product_kardex without opening a schema.

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 clarifies how the by_warehouse flag changes behavior, which implicitly guides usage, but it never says when to prefer this tool over laudus_list_stock or laudus_product_kardex, nor any exclusions or prerequisites. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the response includes invoice lines and identifies the underlying GET endpoint, but it does not mention error behavior, permissions, or not-found handling.

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 sentences with no wasted text and front-loads the core action and return content. The endpoint detail is secondary but compact.

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 single-record read tool with annotations covering safety, the description is mostly adequate and states that invoice lines are included. However, it omits usage guidance versus list tools and does not describe failure behavior, leaving some contextual gaps.

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

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

There is one required parameter, purchase_invoice_id, and schema description coverage is 0%. The description says 'by id' and shows the endpoint path, which weakly identifies the parameter, but it does not add format, validation, or identifier context beyond the schema property name and type.

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 and resource: get a purchase invoice by id, including its lines. It also gives the endpoint, making the operation clear. It does not explicitly distinguish itself from sibling list/read tools such as laudus_list_purchase_invoices or laudus_get_purchase_order.

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 phrase 'by id' implies the tool should be used when a purchase invoice id is already known, but there is no explicit guidance on when to use this versus list_purchase_invoices or related retrieval tools. No prerequisites, alternatives, or exclusions are mentioned.

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

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

Annotations already declare readOnly, non-destructive and open-world, so the safety profile is covered. The description's only added behavior is that the response includes order lines, which is genuinely useful but thin; nothing about errors or missing ids.

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 REST path is marginally useful for agents familiar with the API but borderline redundant against the tool name.

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 does well to mention that lines are returned. However, for a single-resource fetch it omits what happens on an unknown id and gives no sense of response shape beyond 'lines'.

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 0%, so the description must carry parameter meaning, and it only says 'by id'. The parameter name purchase_order_id plus required/positive-integer constraints make the intent inferable, but no format or source of the id is clarified.

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 a purchase order') plus a scope detail ('with its lines'). The singular 'by id' framing implicitly separates it from laudus_list_purchase_orders, but the sibling is never named.

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 id' suggests it is for fetching one known order, so listing tools are the alternative when the id is unknown. No explicit when-to-use or when-not-to-use guidance is given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the response shape (lines, taxes, totals) and the underlying endpoint, which tells the agent this is a full-detail fetch rather than a summary.

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 action and resource, with the response content and endpoint as the only added detail. 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 one-parameter read tool with no output schema, the description does the key work of indicating what comes back (lines, taxes, totals). The main missing piece is guidance on sourcing the id, but overall it is sufficient to call 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% and the single parameter's schema only constrains type (integer or string, length limits) without explaining meaning. The description says 'by id' but does not clarify that the id may be numeric or string, nor how to source it, so it fails to compensate for the coverage gap.

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 (Get) and resource (sales invoice) and clarifies it returns the full document with lines, taxes and totals by id. This implicitly distinguishes it from laudus_list_sales_invoices, though it 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?

'by id' implies you need a known identifier, so the usage context is inferable, but there is no explicit statement about when to use this versus laudus_list_sales_invoices, nor where to obtain the id. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the response includes line items and exposes the underlying REST route, but says nothing about not-found behavior, permissions, or payload shape beyond 'lines'.

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 verb+resource and the key 'with its lines' detail. Nothing is redundant and no padding is present.

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 one-parameter lookup with annotations covering safety, the description is close to sufficient, and 'with its lines' partially compensates for the missing output schema. Still, with no output schema the agent gets no sense of the response structure or error behavior.

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

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

There is a single parameter at 0% schema description coverage, so the schema gives no help. The description's 'by id' hints that sales_order_id identifies the order, but it adds no constraints (positive integer, source of the id, what happens with an unknown id).

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 a sales order') and adds meaningful scope: retrieval by id, including the order's lines. It implicitly contrasts with list-oriented siblings like laudus_list_sales_orders ('by id' = single record), but 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 only implied: an agent can infer this is the tool to call when it has a specific sales order id. There is no explicit statement of when to prefer it over laudus_list_sales_orders or laudus_pending_sales_orders, and no prerequisites or failure conditions 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds useful context by noting the response includes the quote's lines and the underlying endpoint, but it does not describe error behavior or whether the full quote is always returned.

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 wasted words. The core action and scope are stated immediately, and the endpoint is a compact technical afterthought.

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 single-record retrieval with one parameter and rich annotations, the description is nearly complete. It explains the return content ('with its lines') and endpoint, though it could mention behavior when the id is not found.

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% for the single sales_quote_id parameter, so the description carries the burden of explaining it. 'By id' is vague and merely restates the parameter name; it adds no format or semantic detail beyond what the schema already provides (integer, positive).

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 and resource ('Get a sales quote') and adds scope ('with its lines by id'), which distinguishes it from a list operation. However, it does not explicitly name the sibling list tool or state that this is the single-record lookup counterpart, leaving that differentiation implicit.

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 phrase 'by id' implies you need an identifier, but there is no explicit guidance on when to use this tool versus laudus_list_sales_quotes or other get_* siblings. It offers no alternatives or exclusions, so the agent must infer usage 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the raw endpoint path (GET /purchases/suppliers/{id}), which gives no behavioral context beyond that - no not-found behavior, no auth/permission notes.

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 action. The endpoint path in the second sentence is low value for an agent but costs little.

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 one-parameter read tool with annotations and no output schema, this is minimally sufficient to call correctly. What the response contains and failure behavior for a bad id are left unstated.

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% for the single parameter, so the description carries the burden. 'By id' merely restates what the property name supplier_id already conveys, adding no format, range, or sourcing guidance (e.g. where to obtain the id).

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 a supplier by id'), which clearly separates it from the list-style siblings such as laudus_list_suppliers. It never names that sibling explicitly, so the differentiation is inferable 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?

The phrase 'by id' implies you must already hold a supplier identifier, but there is no guidance on when to use this versus laudus_list_suppliers, no prerequisites, and no note about what happens with an unknown 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?

Annotations already establish that this is a safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds useful operational context: default page size of 25, maximum of 200 rows, and the exact offset formula for fetching the next page. It does not cover auth, rate limits, or return shape, but those gaps are modest given the annotations.

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

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

The description is three tight sentences, front-loaded with the main purpose and then paging details. Every sentence adds information: scope, field-name convention, paging rule, and endpoint.

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 covers purpose, page-size limits, and continuation logic. It does not describe the response envelope or whether a total count is returned, which is a minor gap for an agent that needs to know when to stop paging.

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 limit, fields, filter, offset, and order_by in detail. The description adds domain-specific meaning by naming account field examples (accountId, accountNumber, name) that are not present in the schema, helping an agent understand the Laudus data model.

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 and resource: "List the chart of accounts (plan de cuentas)". It also enumerates capabilities (filters, sorting, field selection, paging), making it clearly distinct from sibling tools such as laudus_list_journal_entries or laudus_list_customers.

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 paging instructions, but the description gives no explicit guidance on when to use this tool versus alternatives like laudus_balance_sheet or laudus_general_ledger. It explains how to page, not when this list endpoint is the right choice.

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 readOnly=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds useful behavior beyond that: default/max page size and the pagination formula, plus the data model field naming convention.

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?

Front-loaded with the core action and then mechanics; four sentences with little waste. Slightly dense but every part carries information an agent needs.

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, but the description names example return fields and paging semantics, and the schema fully documents filter/order/fields. Complete enough to call correctly, with only minor gaps in describing the response envelope.

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% (baseline 3), and the description adds value beyond it: concrete field examples (costCenterId, name, code) and the explicit offset = offset + limit paging rule for the offset/limit params.

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 (cost centers) with a Spanish alias for disambiguation, and the endpoint POST /purchases/costcenters/list makes the operation unambiguous against the many get_* and list_* 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?

Explains when/how to page: 'When a page is full, ask for the next one with offset = offset + limit.' Clear usage context, though it does not explicitly name alternatives for filtered single-record lookups versus list_* 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data; the description re-states read semantics via the GET endpoint but adds nothing new. It does not say what a contact record contains, whether results can be empty, or if pagination applies.

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 fragments with no wasted words. The only weakness is that the first fragment is incomplete as a sentence, but the brevity is appropriate for a simple single-parameter read tool.

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 one required parameter and annotations covering safety, the description is still too thin: it never says what contacts are returned or whether the list is paged, and with no output schema the agent has no other source for return 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 0%, so the description carries the burden. It does clarify that the single id refers to a customer and appears in the URL path, but it omits any detail on expected format, validation, or error behavior for invalid ids.

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 identifies the resource (a customer's contact people) but is a noun fragment rather than stating the verb 'list'; the retrieval semantics only come from the appended 'GET /sales/customers/{id}/contacts' endpoint. It does distinguish this tool from siblings like laudus_get_customer or laudus_list_customers by naming contacts specifically, but the purpose is left partly implicit.

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 related ones (e.g., getting the customer record itself), nor any prerequisites such as needing a valid customer_id. The agent must infer usage entirely from the name and endpoint.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: default and maximum page size, the pagination loop, and the Laudus data-model field naming convention. It doesn't discuss return shape or error behavior, keeping it short of a 5.

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 tight sentences: capability summary first, then field naming, then pagination mechanics. It is front-loaded and every sentence carries actionable information with 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?

With no output schema, the description covers what an agent needs to construct and page calls correctly, including limit bounds and field syntax. The main omission is what a response record looks like, which weakens but does not break completeness.

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 baseline is 3, but the description earns a bump by giving concrete field examples (customerCategory.name, salesman.name) and restating the offset+limit pagination contract, adding meaning the schema alone wouldn't make obvious.

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') and enumerates the capabilities it supports: filters, sorting, field selection, paging. It is clearly distinguishable from retrieval tools like laudus_get_customer, but it never names sibling list tools or get_customer explicitly, so differentiation relies on inference.

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 pagination instruction ('When a page is full, ask for the next one with offset = offset + limit') is genuine usage guidance and is useful. However, there is no statement on when to prefer this tool over laudus_get_customer or laudus_list_customer_contacts, 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds beyond that: the 25-row default, the 200-row ceiling, the POST endpoint, and the fact that field names follow the Laudus data model — all behavioral facts an agent needs before constructing a call.

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

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

Four dense sentences, each carrying distinct information: capability scope, paging limits, field vocabulary, pagination mechanics, endpoint. Front-loaded with the purpose and 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?

Complete for a read-only filtered-list tool: paging, limits, field naming and endpoint are all present, and no output schema exists so return-shape explanation is not strictly required. The remaining gap is any hint of what a journal entry row contains or how AND-combined filters behave in practice.

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 3 is the baseline, but the description earns above that by supplying concrete domain field paths (journalEntryId, journalEntryNumber, lines.account.accountNumber, lines.debit, lines.credit) that the generic schema examples ('customer.name, items.quantity') do not provide. That is the one thing an agent cannot infer from the schema alone.

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 accounting journal entries (comprobantes)') plus the four capabilities it exposes: filters, sorting, field selection and paging. It does not explicitly distinguish itself from laudus_get_journal_entry or the ledger siblings, though the list/get naming split makes the distinction inferable.

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 concrete operational guidance for paging ('when a page is full, ask for the next one with offset = offset + limit'), which is real usage instruction. However it says nothing about when to choose this over laudus_general_ledger, laudus_purchase_ledger or laudus_get_journal_entry — the alternatives an agent would most plausibly confuse it with.

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 this as a non-destructive, read-only, open-world list operation, so the description only needs operational context. It adds that pages default to 25 rows and cap at 200 and spells out the continuation rule, plus the underlying POST endpoint, which is genuinely useful beyond the annotations. It stops short of saying what the response envelope contains (rows array, total count) or any auth/rate constraints.

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?

Four tight sentences, front-loaded with purpose before the field-model and paging details. The 25/200 restatement duplicates the schema and could be trimmed, but nothing is extraneous enough to hurt.

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 a fully documented schema, the operational essentials (paging, field naming) are present. With no output schema, however, the agent is left guessing at the response shape (row array, totals, error cases), which is the main 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?

Schema coverage is 100%, so the baseline is 3, but the description adds value the schema cannot: it names the Laudus data model and gives concrete field names (productCategoryId, name, fullPath), clarifying what 'field' means in filters, ordering, and projection. It restates the default and max page size already in the schema, which is mild redundancy rather than added meaning.

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?

It states a specific verb and resource ('List product categories') and enumerates the capabilities (filters, sorting, field selection, paging) that distinguish it from a plain get. It does not explicitly distinguish itself from the nearby laudus_list_products sibling, so the agent must infer the products-vs-categories split from the name alone.

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 filter/sort/paging capabilities, and the pagination sentence tells the agent how to continue ('offset = offset + limit'). There is no explicit when-to-use or when-not-to-use versus laudus_list_products or laudus_get_product, so the boundary with siblings is left 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered and the description correctly does not restate it. It adds real behavioral context instead: paging mechanics, the 25/200 row envelope, and the fact that field names follow the Laudus data model. It omits anything about total counts, cost of wide filters, or what a full versus partial page implies beyond the paging hint.

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

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

Three sentences, front-loaded with purpose, then fields, then paging. Slight redundancy: the "rows 25 by default, at most 200" restates limit's schema description verbatim, and the endpoint path at the end is useful but unglamorous. No padding beyond that.

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 still gives an agent the field vocabulary it needs to construct fields and filter arguments, which is the main unknown for this tool. What is missing is the return envelope: whether the response carries a total count, and what an empty or truncated page looks like, which matters for the loop it describes.

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 baseline is 3 without extra meaning. The description earns above baseline by enumerating concrete valid field names (productId, sku, productCategory.name, unitOfMeasure, unitPrice, stockable, discontinued), which the schema cannot supply because fields is an open string array, plus a worked offset example that maps to the actual arithmetic.

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+resource and even clarifies scope ("products and services (the item master)"), which tells an agent this is the master-data listing, not stock or categories. It never names the sibling it must not be confused with, however: laudus_get_product (single record), laudus_list_product_categories and laudus_get_product_stock all sit adjacent and go unmentioned.

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 pagination guidance ("when a page is full, ask for the next one with offset = offset + limit") is a genuinely useful usage rule. But there is no statement of when to prefer this over laudus_get_product for a single lookup, nor of when listing is the wrong approach, so usage is only implied.

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, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds value beyond that: default 25 rows / hard cap of 200, the paging contract, and the underlying endpoint (POST /purchases/invoices/list – a read done via POST, which the annotation clarifies). It does not describe the response payload.

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?

Four tight sentences, front-loaded with purpose and capability, then field-naming convention, then pagination mechanics. No filler, though the endpoint string adds little for an agent that cannot make raw HTTP calls.

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 carries return-shape burden, and it only implies rows come back without saying whether a total count or cursor is included. Pagination and field-naming guidance are solid, but an agent still can't predict the response envelope.

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 baseline is 3, but the description earns more by naming the Laudus field model with concrete examples (purchaseInvoiceId, docNumber, supplier.name, totals.total) that apply directly to fields/filter/order_by. It also repeats the paging derivation without restating the limit/offset bounds already in the schema.

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

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

States a specific verb+resource ('List purchase invoices (facturas de compra)') plus the capability set (filters, sorting, field selection, paging). The list-vs-get distinction against laudus_get_purchase_invoice is implicit rather than stated, so it stops short of full sibling differentiation.

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?

Gives one concrete procedural guideline ('When a page is full, ask for the next one with offset = offset + limit'), which is real usage guidance. It never says when to prefer this over laudus_get_purchase_invoice or laudus_purchase_ledger, and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds non-obvious operational facts: default page size of 25, a hard cap of 200 rows, and the POST /purchases/orders/list transport. It does not describe error behavior or ordering guarantees, but adds meaningful context beyond the annotations.

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

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

Four short sentences, front-loaded with purpose then capabilities then paging mechanics then field syntax. Dense but everything earns its place; the row-limit fact is stated twice (prose and schema), a minor redundancy.

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

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

For a 5-parameter, all-optional list tool with no output schema, it covers selection, projection, sorting, paging and the entity field vocabulary. It stops short of describing the response envelope (total counts, result wrapper), which matters without an output schema, but an agent has enough to 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?

Schema coverage is 100%, so the baseline is 3; the description goes further by naming the Laudus field-naming convention and concrete dotted paths (purchaseOrderId, supplier.name, items.product.sku, items.quantity) that an agent would not know from the generic schema strings alone. The only overlap is the repeated limit/paging rule.

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 orders') plus the supported capabilities (filters, sorting, field selection, paging) and the Spanish alias 'ordenes de compra'. The plural 'List' implicitly distinguishes it from laudus_get_purchase_order, 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?

It gives an actionable pagination rule ('When a page is full, ask for the next one with offset = offset + limit'), which is real usage guidance. However, it never states when to use this versus laudus_get_purchase_order or the adjacent list tools (sales orders, purchase invoices), leaving retrieval-vs-search selection 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?

Annotations already declare readOnly/openWorld/non-destructive, so safety is covered. The description adds behavior the annotations do not: default page size of 25, a hard cap of 200 rows, the offset-advance pattern, and the underlying endpoint POST /sales/invoices/list — all useful for planning calls.

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 tight sentences, front-loaded with the scope and pagination rule, then the field-naming detail. The field enumeration is long but earns its space because field names are otherwise unknown; nothing is redundant 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 list tool with a fully documented schema and no output schema, the description covers scope, paging semantics, and field vocabulary. The only remaining gap is that it does not characterize the shape of returned rows, though the field examples implicitly do so.

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 baseline is 3, but the description goes further by enumerating concrete Laudus field names (salesInvoiceId, docType.name, customer.VATId, totals.net, items.product.sku) that an agent would otherwise have to guess. That is genuine added meaning beyond the schema's generic nested-name hint.

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 and scopes it to include electronic tax documents ('facturas, notas de credito'), which is meaningful in a Latin American ERP context. It does not explicitly contrast itself with the single-record sibling laudus_get_sales_invoice, but the 'List' verb and plural resource make the distinction legible.

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 concrete operational guidance for pagination ('When a page is full, ask for the next one with offset = offset + limit'), which is real usage help. However it never states when to reach for this tool rather than laudus_get_sales_invoice or laudus_sales_invoice_receipts, so selection guidance is left implicit.

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, openWorldHint=true and destructiveHint=false, so safety is covered structurally. The description adds real value beyond that: default page size (25), a hard cap (200), the field-naming convention of the Laudus data model, and the underlying POST /sales/salesmen/list endpoint. It does not say whether a total count or cursor is returned.

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

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

Three sentences, front-loaded with purpose, then the paging rule, then the field-naming and endpoint details. The page-size figures lightly duplicate the schema but are cheap and reinforce the paging logic.

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 carries the burden of explaining the response, and it never says what a result row looks like or whether a total/has-more indicator is returned — the reader must infer that from the paging instruction. For a read-only list tool with fully documented parameters this is adequate but leaves a real gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns above baseline by adding the field-naming model with concrete examples (salesmanId, name), which tells the agent what strings are legal in `fields`, `filter` and `order_by` — context the schema itself leaves abstract.

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+resource ("List salespeople (vendedores)") and enumerates the capabilities: filters, sorting, field selection and paging. No sibling lists salespeople, so the resource alone disambiguates it from laudus_list_customers, laudus_list_suppliers and the other list_* 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?

Gives concrete operating guidance for paging: "When a page is full, ask for the next one with offset = offset + limit." That is actionable when-to-use advice. It stops short of explicit exclusions or pointing to an alternative tool, but there is no competing tool for this resource.

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

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

Annotations already establish this as a safe, read-only, open-world read. The description adds genuine beyond-schema context: default page size of 25, hard cap of 200, and the concrete offset-advance formula for pagination, which is exactly the behavioral detail an agent needs to loop pages correctly.

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 dense sentences, zero filler: capability and paging limits first, then the field-name model with examples, then the pagination recipe, then the endpoint. Everything is front-loaded and actionable.

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 would ideally hint at the response envelope (rows array, total count, has-more indicator), but field selection plus the offset/limit recipe covers what an agent needs to call it correctly. Slight gap on what a 'full page' response actually 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 the baseline is 3, but the description adds real domain value by naming actual Laudus data-model field paths (salesOrderId, issuedDate, dueDate, items.product.sku) that an agent could not derive from the schema alone, offsetting the high coverage.

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 even gives the Spanish domain term 'pedidos de venta' plus the endpoint path. It does not, however, distinguish itself from close siblings such as laudus_pending_sales_orders or laudus_get_sales_order, 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?

Usage is implied by the listing/paging language, but there is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives like pending_sales_orders (a filtered view) or get_sales_order (single record).

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description adds value beyond that with the default page size (25), the 200-row ceiling, the page-full/offset handoff rule, and the underlying POST /sales/quotes/list endpoint. It does not describe the shape of a returned quote record, which is the main remaining 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?

Three tight sentences, front-loaded with the capability statement followed by the field-naming rule and paging rule. Minor redundancy: the offset = offset + limit instruction repeats wording already in the offset parameter 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 filtered list tool with full schema coverage and read-only annotations, this covers the practical needs: defaults, caps, pagination, and field addressing. The only missing piece is any indication of what the returned quote objects contain, which matters somewhat since there is no 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 100%, so the baseline is 3; the description earns extra credit by naming concrete Laudus data-model field paths (salesQuoteId, issuedDate, customer.name, items.product.sku, items.quantity) that the schema only illustrates generically. It reinforces the row limits and offset semantics without contradicting 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?

States a specific verb (list) and resource (sales quotes / cotizaciones) plus the supported capabilities: filters, sorting, field selection and paging. An agent can distinguish this from laudus_get_sales_quote by the plural listing and paging vocabulary, 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?

Gives concrete operational guidance on paging ('When a page is full, ask for the next one with offset = offset + limit') and defaults, which is genuinely useful. However, it never says when to use this versus laudus_list_sales_orders or laudus_get_sales_quote, so the selection guidance is only implied.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds useful behavioral context beyond annotations: default page size 25, maximum 200, next-page logic (offset + limit), and the POST endpoint for a read operation. It does not describe rate limits or authentication, but those are secondary for a read-only 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?

The description is four sentences, front-loaded with the core purpose and capabilities, then paging and field naming. Every sentence adds value, and there is no redundant fluff.

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 no output schema, the description covers paging behavior, default/max limits, field naming conventions, and the endpoint. It does not explain the response shape, but given the absence of an output schema, this is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds concrete field-name examples (receiptId, receiptType, issuedDate, dueDate) that are not present in the schema and help agents construct filters, field selections, and ordering. The paging formula is also restated helpfully.

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 resource 'customer payments received (cobros)', and it enumerates capabilities (filters, sorting, field selection, paging). It does not explicitly distinguish this tool from close siblings like laudus_sales_invoice_receipts, 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?

Usage is implied by the resource name and the paging instructions, but there is no explicit guidance on when to use this tool versus alternatives such as laudus_list_sales_invoices or laudus_sales_invoice_receipts. No exclusions or prerequisites are stated.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds genuinely useful behavior beyond them: the result set may be large and should be narrowed, and the as-of date defaults to today. It stops short of describing pagination or ordering, which matters for a call flagged as potentially large.

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 compact sentences with the scope front-loaded, then the size warning, then the endpoint path. Nothing is redundant and no sentence needs re-reading.

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 never indicates what a stock record contains (quantity, warehouse breakdown, product fields), so an agent cannot anticipate the response shape. For a tool explicitly flagged as possibly large, the absence of any volume/pagination expectation is a notable gap.

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

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

Schema coverage is only 33% – only date_to is documented in the schema – so the description carries the burden for warehouse_id and product_category_id, and it does name both meanings. However it leaves ambiguity about whether the two filters can be combined ("one warehouse or one product category") and gives no hint that these are internal IDs sourced from laudus_list_warehouses / laudus_list_product_categories.

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 the verb and resource precisely ("Stock of every product") plus the two scoping dimensions and an optional as-of date. The scope word "every" implicitly separates it from the sibling laudus_get_product_stock, but it 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?

"Can be large: filter by warehouse or category" is real guidance on how to keep the call tractable, which implies the intended usage pattern. It does not say when to prefer this over laudus_get_product_stock or how to obtain warehouse/category IDs, so selection between siblings is left 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?

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the description adds value rather than repeating it: default page size 25, hard cap of 200, the paging continuation formula, and the notable fact that this read is issued as POST /purchases/suppliers/list. It does not describe the response shape, which is a minor gap 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 to three tight sentences with the core scope and defaults front-loaded and no filler. It is short and every sentence carries 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 rich five-parameter list tool with full schema coverage and read-only annotations, defaults, pagination and field naming are all covered. Remaining gaps are behavioral nuances an agent may need, such as response ordering guarantees, whether filters on unknown fields error or are ignored, and what the returned records look 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 the schema already documents limit, fields, filter, offset and order_by, making 3 the baseline; the description adds no syntax or format detail beyond the paging rule. It does supply example field names from the Laudus data model, but that sits closer to domain guidance than parameter semantics.

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 suppliers (proveedores)') and enumerates its capabilities: filters, sorting, field selection, paging. It is clearly distinguishable from laudus_get_supplier by plurality, though it never explicitly names the sibling.

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?

Gives operational when-to guidance for paging ('When a page is full, ask for the next one with offset = offset + limit') which is genuinely actionable. It offers no guidance on when to choose this over laudus_get_supplier for a single record or over other list tools, so tool selection is left to inference 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds behavior beyond that: default page size of 25, a hard cap of 200, and the explicit next-page rule (offset = offset + limit), which prevents the common pagination error. It does not describe the response envelope, which keeps it from a 5.

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 tight sentences, front-loaded with purpose, then fields, then paging, and every sentence carries actionable content. The trailing POST path is slightly redundant but arguably useful for debugging.

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 compensates by naming example return fields and giving the pagination loop. For a 5-parameter, fully documented list tool that is sufficient; only the shape of the result envelope and total-count behavior remain unstated.

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 baseline is 3; the description earns extra by naming the Laudus data-model field identifiers (warehouseId, name, city), which is the one thing the schema cannot tell the agent when supplying filter/fields/order_by values. It still omits operator and date-format details that matter for filtering.

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 and resource ("List warehouses (bodegas)") and immediately enumerates the supported capabilities: filters, sorting, field selection and paging. It is unambiguous against the sibling list_* tools because no other sibling targets warehouses, but it never explicitly names or contrasts 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?

Use is implied by the name and the enumeration of capabilities, and the pagination sentence gives operational guidance for continuing a listing. However, there is no statement of when to use this rather than a sibling (e.g. get_product_stock or list_stock) and no preconditions 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, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that only IDs are returned and defines the pending condition, but it omits pagination, limits, or default behavior when no filters are supplied.

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 returned resource and followed by the optional filtering behavior. The endpoint reference adds API context without bloating the definition.

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 list tool with no output schema, the description covers the return type (IDs), the pending scope, and the available filters. It could be strengthened by clarifying pagination or what happens when no filters are provided, but it is largely complete.

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

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

The description maps all three parameters conceptually: customer_id filters to one customer, and due_date_from/due_date_to form a due-date range. The schema documents the date formats, and the description adds useful semantic context for the otherwise undocumented customer_id parameter.

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 resource and scope: sales orders not yet delivered, returning their IDs. It is distinguishable from general sales-order listing because of the pending/delivered condition, though it does not explicitly name its closest sibling, laudus_list_sales_orders.

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

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

It indicates that customer and due-date filters are optional, implying use when pending orders are needed for one customer or a date window. It does not state when to use this instead of laudus_list_sales_orders or laudus_get_sales_order.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful scoping constraints (single product, optional date and warehouse) but says nothing about return format, ordering, or pagination behavior of the movement 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 tight sentence with the resource and scope front-loaded and zero padding. It is terse but appropriately sized for a simple read tool.

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 GET read tool with no output schema, the description covers what is fetched and the available filters, but leaves the shape of the kardex response (entry fields, ordering, pagination) entirely unstated. Adequate but with clear gaps.

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 carry the burden. It maps roles to all three parameters (product_id = 'one product', date_to = 'to a date', warehouse_id = 'one warehouse'), but gives no format details, date semantics (inclusive cutoff, timezone), or whether warehouse_id is an internal id or code.

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 resource (stock movements/kardex of one product) and an endpoint, so an agent knows it retrieves movement history rather than a stock snapshot. It does not explicitly differentiate itself from closely related siblings like laudus_get_product_stock or laudus_list_stock, leaving that comparison to inference.

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 phrase 'optionally to a date and for one warehouse' implies how to narrow results, but there is no explicit when-to-use guidance versus laudus_get_product_stock or laudus_list_stock. An agent must infer that this returns movement history rather than current 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds nothing beyond that — no note on default book behavior, whether dates are inclusive, or what an empty period returns — which is a meaningful omission for an open-world 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?

Two short, front-loaded sentences with no filler. It is efficient, though the endpoint reference adds little for an agent that cannot call raw HTTP.

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 7 optional parameters, low schema coverage, no output schema, and no description of the returned report structure or default behaviors, the definition leaves an agent under-informed about how to filter correctly and what to expect back.

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 only 29% across 7 parameters; book_id and show_levels are documented in the schema, but date_from, date_to, cost_center_id, show_accounts_with_zero_balance, and show_only_accounts_with_activity are undocumented. The description only restates the date-range idea and does not compensate for the gap, e.g. by explaining date format or filter semantics.

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 the specific resource (profit and loss statement / estado de resultados) and the scoping dimension (a date range), plus the underlying endpoint. It is clear what the tool returns, though it does not explicitly contrast itself with the sibling balance_sheet or general_ledger reports.

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 versus laudus_balance_sheet, laudus_general_ledger, or laudus_sales_report, nor any mention of prerequisites such as needing a book or period. The agent must infer the use case 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the API path, but omits genuinely useful behavior: both parameters are optional (required=0), yet nothing says whether omitting year/month defaults to the current period or what the ledger returns.

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 resource and period scope front-loaded, so an agent gets the essentials immediately. The raw endpoint string is marginal filler but not harmful.

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 and no annotations covering return content, the description should tell the agent what the ledger contains (invoice lines, totals, tax columns) and how the optional period parameters resolve. Neither is present, leaving the agent guessing about results and defaults.

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 carries the burden, but it only restates that a year and month exist. It does not explain optionality — the schema marks zero required parameters, leaving default/omission behavior undocumented — nor what unit or effect each parameter has beyond the integer ranges the schema already constrains.

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 resource (the purchases ledger / libro de compras) scoped to a year and month, with the underlying endpoint given for traceability. It does not explicitly distinguish itself from close siblings like laudus_general_ledger or laudus_list_purchase_invoices, 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?

There is no guidance on when to prefer this ledger over laudus_general_ledger, laudus_list_purchase_invoices, or laudus_profit_and_loss, and no note on prerequisites or typical use cases. Usage is only implied by the resource 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful context by naming the returned business objects (cobros) and the underlying GET endpoint, but it does not add auth, pagination, or error behavior details.

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 wasted text, and the key purpose is front-loaded before the endpoint detail.

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, one-parameter retrieval tool with annotations present, the definition is minimally adequate. However, without an output schema, it could do more to explain what the returned receipts contain or how they relate to list_sales_receipts.

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% for the single required parameter. The description implies the parameter is a sales invoice identifier via the endpoint path, but it does not explain accepted formats or constraints beyond what the schema already shows.

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 resource and relationship: customer payments applied to one sales invoice, plus the underlying endpoint. It is clearly distinguishable from sibling tools like laudus_list_sales_receipts, though it does not explicitly call out the distinction.

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

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

It does not say when to use this tool versus alternatives such as laudus_list_sales_receipts or laudus_get_sales_invoice. The use case is only implied by the description and parameter 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the GET endpoint, which confirms a pure read, but says nothing about aggregation semantics (what a 'total' includes, whether date_from defaults, pagination, or result shape). Some added value, but well short of full behavioral disclosure.

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

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

A single dense sentence that front-loads the operation and result type, then the grouping options, then the filters, then the endpoint. The twelve-value enumeration is verbose but directly encodes what the agent must pass, so it earns its place; only minor trimming is possible.

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 7 parameters at 14% description coverage and no output schema, the description leaves important gaps: the return shape of the aggregated report is undisclosed, the filter parameters are only gestured at, and there is no indication of date-range behavior. It is not sufficient to call this tool confidently without inspecting 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 only 14% of 7 parameters, so the description must carry the load and largely does not. It enumerates the group_by values (already present in the enum) and mentions 'date range and optional filters' generically, without explaining how date_from/date_to are bounded or that product_id/customer_id/salesman_id/branch_id act as restrictive filters and how they combine.

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 ('Invoiced sales totals') plus the full enumeration of valid groupings and the backing endpoint GET /reports/sales/invoices/{group}. This clearly separates it from the sibling list tools (e.g. laudus_list_sales_invoices) which return individual records rather than aggregates.

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 usage context (aggregated reporting over a date range with optional filters), but never states when to choose this over siblings like laudus_profit_and_loss or laudus_list_sales_invoices, nor any prerequisites or exclusions. Usage is inferable but not guided.

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