unleashed-software

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

Annotations only carry destructiveHint=true (a questionable fit for a create), so the description must carry the behavioral load. It usefully discloses that CustomerCode must be unique and is immutable after creation, but says nothing about what the call returns, how uniqueness violations surface, or side effects.

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 zero filler: the action first, then the key constraint, then the API mapping. Every sentence earns its place.

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

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

For a 12-parameter mutation with no output schema and only a single annotation, the description covers the essentials but leaves gaps: no return value, no error/uniqueness-failure behavior, and no permission context. Adequate but not complete.

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

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

Schema description coverage is 100%, so all 12 parameters including the required customerCode/customerName are already documented. The description's only parameter-level note (CustomerCode uniqueness/immutability) largely duplicates the schema description, adding no new syntax or format detail.

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 ('Create a new customer') and identifies the underlying API call (POST /Customers). This cleanly distinguishes it from siblings like unleashed_create_product and unleashed_create_sales_order by resource.

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 the get/list customer tools, no mention of prerequisites or permissions, and no exclusions. The uniqueness constraint on CustomerCode is stated but framed as a data rule, not usage guidance.

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

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

Annotations only declare destructiveHint=true, leaving the description to disclose mutation behavior. It hints at duplicate-rejection via 'ProductCode must be unique', but says nothing about required permissions, error behavior, or what happens to unspecified fields. With thin annotation coverage and no output schema, the description carries most of the burden and mostly abstains.

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 fragments, front-loaded with the core action before constraints and endpoint. No filler, though the endpoint note is arguably redundant to an MCP 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?

For an 11-parameter mutation tool with no output schema and only a destructiveHint annotation, the description is minimal: it omits which fields are required, what the response contains, and any error/auth context. Adequate only because the schema fully documents the parameters.

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 all 11 parameters are already documented in the schema. The description adds only the uniqueness constraint on productCode, which the schema itself does not state — a small but genuine increment over structured data, matching the baseline 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 verb and resource ('Create a new product') that clearly separates it from sibling creation tools like unleashed_create_customer and unleashed_create_sales_order. It does not explicitly name alternatives, but the resource noun alone disambiguates.

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

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

No guidance on when to use this versus other create tools, nor on prerequisites such as whether the product's group/supplier must already exist. The uniqueness note on ProductCode is a constraint, not usage routing.

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?

Goes well beyond the sparse annotations by disclosing that no stock is reserved, nothing is posted to accounting, and that computed totals must satisfy Unleashed's validation equation. It also cites the underlying endpoint (POST /SalesOrders), which helps an agent reason about side effects. Minor tension with the destructiveHint=true annotation, since the text emphasizes that nothing is committed or altered.

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 purpose and status, followed by the non-obvious side-effect disclaimers, then the validation math, then the endpoint. Dense but every sentence carries information; the validation-formula sentence is a bit heavy but earns its place for avoiding 400s.

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-parameter mutation tool with no output schema, the description supplies the missing behavioral layer: draft/parked semantics, no stock or accounting side effects, and the computed-field requirements needed to pass validation. It does not cover error cases (e.g., unknown customer/warehouse codes, duplicate order numbers) or auth expectations, keeping it short of a 5.

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 all 11 parameters with formats and defaults. The description adds the totals/validation relationship (SubTotal, TaxTotal, Total) but does not elaborate on any individual parameter semantics, so baseline 3 applies.

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

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

States a specific verb (Create) and resource (DRAFT sales order) plus its exact resulting status (Parked), which immediately distinguishes it from the read/list siblings and from the other create tools (customer, product). An agent knows exactly what entity this produces without opening the 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?

Explains the operative context: this produces a parked draft that reserves no stock and posts nothing to accounting, and that a person places or completes it later in Unleashed. It effectively tells the agent this is not the tool for finalizing an order, but it names no sibling alternative and gives no explicit when-not conditions.

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

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

readOnlyHint=true already declares this as a safe read. The description adds value beyond the annotation by disclosing the exact payload shape and the endpoint/cost framing (a cheap validation call), which is behavior an agent can act on. It stops short of describing error behavior when credentials are wrong.

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

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

Three short sentences, front-loaded with the action and payload, followed by the motivating use case and the raw endpoint. Every sentence earns its place 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 carries the burden of describing the return values, and it does so (name, base currency, default tax rate). For a zero-parameter read tool, nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. There is nothing parameter-related for the description to clarify or omit.

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 ("Fetch the Unleashed company these credentials belong to") and enumerates the returned fields (name, base currency, default tax rate). No sibling tool covers the company resource, so an agent can place it without ambiguity.

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 explicit usage context — "a cheap way to confirm the API id, key and signature are right" — which tells the agent when this is worth calling (credential/connectivity validation). It does not name a competing alternative, but none of the siblings overlap with this purpose, so the gap is minor.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful context by enumerating what the response contains (addresses, currency, payment terms, credit limit) and naming the underlying endpoint, which helps an agent know what it gets back.

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?

One efficient sentence that front-loads the operation and lookup key, followed by the field list and endpoint. No filler or 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?

With no output schema, the description usefully summarizes the returned fields, and the single input param is fully specified. It is nearly complete; only the not-found/error behavior and any field-format caveats are absent.

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

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

Schema description coverage is 100% and the single customerGuid parameter includes a format pattern, so the schema fully documents the input. The description only restates that lookup is by Guid, adding no syntax or format detail beyond the schema — baseline 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 verb ('Fetch'), resource ('a single customer'), and key ('by Guid'), and enumerates the payload fields (contact details, addresses, currency, payment terms, credit limit). This clearly distinguishes it from list_customers and the create/get siblings.

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

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

The 'by Guid' scoping implies this is for retrieving one known customer, but there is no explicit when-to-use guidance or reference to the alternative list_customers for browsing/filtering. Usage is inferable but not stated.

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

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

readOnlyHint=true already establishes this is a safe read. The description adds the underlying REST endpoint (GET /Products/{productGuid}) and the shape of returned data, which is useful context, but discloses no auth requirements, rate limits, or error behavior. Against annotations that already carry the safety profile, this is adequate but not rich.

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 action front-loaded and no wasted words. Every clause earns its place by naming the lookup key and the returned fields.

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's enumeration of returned fields (prices, units, stock alert levels, group, brand, supplier) usefully compensates. For a one-parameter read tool whose safety is covered by annotations, this is close to complete, though it could note the sibling read variant.

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

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

Schema description coverage is 100% for the single productGuid parameter, so the schema already explains it fully. The description's phrase 'by Guid' adds no syntax or format detail beyond that. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Fetch a single product by Guid') and enumerates the salient fields returned (prices, units, stock alert levels, group, brand, supplier). The word 'single' implicitly distinguishes it from list_products, but no sibling such as get_product_stock or list_products is named, so differentiation is left 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 description makes clear you call this with a Guid, implying the lookup use case, but gives no explicit when-to-use guidance and never contrasts it with alternatives like get_product_stock for stock-only queries or list_products for browsing. 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, and this is plainly a GET, so the safety profile is covered. The description adds the endpoint path and the totals-vs-per-warehouse duality but says nothing about pagination, permissions, or what happens with an unknown productGuid, which is the remaining burden for a 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 tight sentences: the scope and mode-selection fact comes first, the intent framing and endpoint second. No filler, nothing redundant with the title.

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 four-parameter read with full schema coverage and no output schema, the description conveys mode selection and return shape ('totals, or broken down per warehouse') well. It leaves date-filtering semantics to the schema, which is acceptable here.

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 productGuid, asAtDate, allWarehouses, and warehouseCode are all already documented in the schema, including the 'ignored with allWarehouses' caveat. The description's mention of allWarehouses=true adds emphasis but no information beyond the schema, so the baseline 3 is correct.

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 ('stock on hand for one product') and scopes it to a single product, which distinguishes it from the sibling list_stock_on_hand. It also names the underlying endpoint, so the agent knows exactly what is being fetched.

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 a clear usage frame ('the direct answer to how many do we have and where?') and explains the allWarehouses toggle that selects between the totals and per-warehouse views. It does not explicitly name list_stock_on_hand as the multi-product alternative or state when not to use this tool, so it falls short of a 5.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds useful context that the response includes lines, supplier and totals, but says nothing about auth, errors, or behavior for a non-existent Guid. With annotations covering the safety profile, a 3 fits.

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

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

Two compact sentences with the core purpose front-loaded and no filler; the trailing API endpoint reference is mildly redundant but harmless for an agent familiar with the Unleashed API.

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-resource read with a fully documented 1-parameter schema and read-only annotation, the description covers what is needed and even sketches the return payload since no output schema exists. Minor gaps (error/not-found behavior) remain.

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

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

Schema description coverage is 100% and the single orderGuid parameter is fully documented in the schema. The description only restates 'by Guid' and adds no format or semantic detail beyond the schema's pattern and description, so the baseline 3 applies.

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

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

States a specific verb ('Fetch') and resource ('purchase order') and adds scope details (by Guid, with lines, supplier and totals). 'Single' implicitly differentiates it from the list_purchase_orders sibling, though the sibling is never named explicitly.

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

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

The phrase 'by Guid' implies it should be used when a specific order identifier is known, but there is no explicit when-to-use guidance or routing against list_purchase_orders / unleashed_get_sales_order. Usage must be inferred.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the payload shape (lines, totals, customer, warehouse) and the underlying endpoint, but says nothing about auth scope, rate limits, or whether missing Guids error vs. return empty.

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 with the essential lookup key front-loaded and the endpoint reference trailing. No filler; every clause 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 single-resource read with no output schema, the description usefully enumerates the returned content and the read-only annotation covers safety. Only the error/empty-result behavior is left unaddressed, which 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 description coverage is 100%, so both orderGuid (with pattern) and serialBatch are already documented in the schema. The description only restates the Guid lookup and the returned fields, adding no syntax the schema lacks. Baseline 3 is appropriate.

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

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

States a specific verb (Fetch) and resource (a single sales order) and pins the lookup key (by Guid), plus enumerates what comes back (lines, totals, customer, warehouse). The word 'single' contrasts with the plural list_sales_orders sibling, 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?

Usage is implied: fetch one order when you already have its Guid. There is no explicit when-to-use/when-not guidance, no mention of when to prefer list_sales_orders (e.g., when the Guid is unknown), and no stated prerequisites.

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

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

readOnlyHint=true already establishes the safe read-only profile, so the description's burden is lower. It adds that results are page-based via 'GET /Customers/{page}' and that filters exist, but says nothing about pagination size, total counts, or result shape.

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 with the core action and filter set front-loaded, and the endpoint reference placed last. Nothing wastes space.

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 list tool with no output schema, the description covers the essentials but omits return shape and pagination semantics that would help an agent interpret results. It is adequate but leaves 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 100%, so all 8 parameters are already documented in the schema. The description paraphrases a subset of filters (code, name prefix, currency, modification date) without adding syntax or format details beyond what the schema provides, so the baseline 3 applies.

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

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

States a clear verb (List) and resource (customers) and names the filterable fields, so an agent understands it retrieves multiple customers. It does not explicitly distinguish itself from the sibling unleashed_get_customer, though 'List' vs 'get' is reasonably self-evident.

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 mentions that filtering is optional but gives no guidance on when to use this list tool versus unleashed_get_customer for a single record. There are no exclusions or prerequisites stated; 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's remaining burden is pagination/return behavior. It adds only the raw API endpoint (GET /Invoices/{page}); it says nothing about paging defaults, result ordering, or how multiple filters combine, which the schema only partially covers.

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

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

Two short sentences, with the purpose and filter scope front-loaded. The trailing endpoint reference is mildly useful but is essentially redundant metadata that slightly dilutes the sentence.

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 the essentials: what is returned, the filter axes, and pagination. It omits only secondary details such as default page size, which the schema already supplies.

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%, with 9 parameters fully documented including defaults and the invoiceNumber override behavior. The description merely recaps the same filter categories, adding no format, default, or combination semantics beyond the schema.

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

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

States a specific verb+resource (list sales invoices) and enumerates the filter dimensions, so the agent knows it is a filtered collection read. It does not explicitly distinguish itself from siblings like unleashed_list_sales_orders or unleashed_list_sales_quotes, relying on the resource name to do that 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 when-to-use or when-not-to-use guidance, no mention of when to prefer a filtered list versus a direct lookup, and no prerequisites. The agent must infer usage entirely from the tool name and filter list.

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

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

Annotations already declare readOnlyHint=true, so the safe-read nature is covered structurally. The description adds the underlying endpoint (GET /ProductGroups/{page}), implying pagination, but does not describe pagination behavior, total counts, or traversal of the tree beyond what the schema's page/pageSize already imply.

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 compact sentence front-loads the resource, the returned fields, and the domain meaning, then appends the endpoint. No filler or 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?

With only two optional parameters, no output schema, and a readOnly annotation, the description covers the essentials and even names the returned fields (name, Guid, parent group), compensating for the absent output schema. Only minor gap is any hint about pagination depth or tree shaping.

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 both parameters (page, pageSize) are fully documented in the schema itself. The description adds no parameter detail beyond referencing the page path segment, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List product groups') and then clarifies the domain role ('the category tree products are filed under'), which meaningfully distinguishes it from the sibling unleashed_list_products. An agent can tell what this returns without opening the 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 implies the tool is used to browse the product category hierarchy but never states when to use it versus alternatives (e.g., list_products for items vs this for categories). No prerequisites, no exclusions, no sibling routing.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description carries a lighter burden. It adds the underlying endpoint (GET /Products/{page}), implying pagination, but says nothing about page-size limits, default 200, rate limits, or return format. Adequate but not rich.

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 naming the resource first, followed by a compact endpoint reference. No wasted words, though the trailing API endpoint note is lower value than the filter summary.

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 16-parameter tool with high schema coverage the core is covered, but there is no output schema and the description does not describe the shape of the returned list or pagination semantics beyond the '{page}' endpoint hint. Minor gaps remain, but nothing critical for correct invocation.

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

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

Schema description coverage is 100%, so all 16 parameters (including pageSize defaults, productCode prefix semantics, and subgroup exclusion for productGroup) are already documented in the schema. The description only paraphrases the filter categories and adds no syntax or format detail beyond what the schema provides. Baseline 3 is correct.

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

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

States a specific verb and resource ('List products') and enumerates the filter dimensions (code/description search, prefix, group, brand, barcode, modification date), so an agent can tell it apart from siblings like unleashed_get_product or unleashed_list_product_groups. It stops short of explicitly naming alternatives, but the verb+resource pairing is unambiguous.

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

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

The description says the tool lists products with optional filters but gives no when-to-use vs when-not guidance and names no alternative. The distinction from unleashed_get_product (single-product fetch) and the other list_* siblings is left entirely 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the underlying endpoint, GET /PurchaseOrders/{page}, which reinforces the read-only and paginated nature, but it does not disclose rate limits, authentication requirements, or pagination behavior beyond the schema's page parameter.

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

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

Two tightly written sentences with no filler. The core operation is front-loaded, followed by filter scope and the API endpoint, all of which earn their place.

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

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

For a 12-parameter list tool with no output schema, the description is reasonably complete: it covers the operation, filter scope, and endpoint. The main omission is that return shape and pagination totals are not described, but the schema covers pagination inputs and the annotations cover safety.

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

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

Schema description coverage is 100%, so all 12 parameters are already documented in the schema. The description names several filter categories but does not add syntax, defaults, or filtering behavior beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: 'List purchase orders.' It also names the filter dimensions, so the agent can immediately distinguish this from sibling list tools for sales orders, products, and 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 'List purchase orders, filtered by...' but the description does not state when to use this versus unleashed_get_purchase_order for a single order, nor does it mention prerequisites such as authentication or required permissions. It gives adequate context for a list operation but stops short of explicit alternative guidance.

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

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

Annotations only declare readOnlyHint=true, so the description carries the rest. It adds real value by disclosing that deleted orders are excluded and by citing the underlying endpoint GET /SalesOrders/{page}. The phrase 'unless asked for' is slightly ambiguous since no schema parameter exposes a deleted-inclusion flag, which tempers the score.

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

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

Three short sentences with no filler: purpose and filters lead, behavioral caveat follows, and the API reference closes. Every clause earns its place and nothing is buried.

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 14 fully documented parameters, a read-only annotation, and no output schema, the description supplies enough for correct invocation. It does not cover pagination behavior or result shape, but that is already handled by the schema and the read-only hint.

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

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

Schema description coverage is 100%, so every one of the 14 parameters is already documented in the schema. The description summarizes filter categories but adds no syntax, precedence, or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (List) and resource (sales orders) and specifies the available filter dimensions, so the agent knows exactly what the tool returns. It does not explicitly distinguish itself from the singular sibling unleashed_get_sales_order, but the 'List' framing plus filter enumeration makes the scope clear.

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 usage by listing filter dimensions (status, customer, order number, warehouse, date range), which tells the agent what this tool is for. However, it gives no explicit when-to-use vs when-to-use-get_sales_order routing or prerequisites.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's remaining burden is light. It adds the paginated endpoint path (GET /SalesQuotes/{page}), signaling pagination exists, but says nothing about page-size defaults (only the schema does), rate limits, or response shape.

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 tool's purpose and filters before the endpoint detail; nothing is padded. The trailing 'Unleashed: GET /SalesQuotes/{page}' is marginally redundant but does convey the pagination mechanism.

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

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

For a read-only list tool with 8 optional, fully documented parameters, the description covers purpose, filter dimensions, and pagination. It is nearly complete; it does not explain pagination limits or result ordering, but with no output schema and a strong 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 description coverage is 100%, so every parameter is already documented in structured form, and per the rubric the baseline is 3. The description's filter enumeration maps cleanly onto the parameters but adds no syntax, format, or precedence detail beyond what the schema provides (e.g., the quoteNumber override is only in the schema).

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

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

The description states a specific verb (List) and resource (sales quotes) and enumerates the filter axes (status, customer, quote number, date range). It is clear against siblings but never explicitly differentiates itself from the other list tools such as unleashed_list_sales_orders or unleashed_list_invoices, relying on the resource noun 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 list, which tells the agent what kinds of queries this tool serves, but there is no explicit when-to-use statement, no prerequisites, and no routing guidance versus sibling list/read tools. It is the minimum viable level of guidance.

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

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

readOnlyHint=true already tells the agent this is a safe read. Beyond that, the description discloses the shape of the returned records (reason, status, lines) and the underlying REST route GET /StockAdjustments/{page}, which is genuinely useful given no output schema exists. It stops short of describing pagination semantics or rate limits.

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

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

Two sentences, no filler. The purpose and record contents are front-loaded, and the endpoint reference is a compact trailing 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 list tool with full schema coverage and no output schema, the description supplies the missing return-content context and identifies the filter dimensions. Only minor gaps remain, such as any hint about default page size behavior or result ordering.

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

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

Schema description coverage is 100%, so all six parameters are documented in the schema itself, including patterns, ranges and defaults. The description only echoes the filterable dimensions (warehouse, product, date) without adding syntax or format detail beyond the schema — the baseline 3 for fully-covered schemas.

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 (stock adjustments), then defines what qualifies with concrete examples — write-offs, recounts, corrections — and the filterable dimensions. This clearly separates it from the close sibling unleashed_list_stock_on_hand, which reports holdings rather than adjustment transactions.

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 when the tool is useful by naming the filter axes (warehouse, product, date), but it never states when to prefer this over list_stock_on_hand or any other sibling, nor any prerequisites. 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.

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by naming returned stock fields and showing the GET /StockOnHand/{page} endpoint, implying pagination, though it does not cover auth, rate limits, or the full response envelope.

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 a single compact sentence that front-loads the core operation and returned fields, then adds optional scoping and the API endpoint. Every clause contributes useful information without waste.

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 lists representative returned fields. With all input parameters documented at 100% coverage, the definition is largely complete for a read-only listing tool, though it stops short of fully describing pagination or response metadata.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the input schema. The description reinforces warehouse and date filtering but adds no parameter syntax or format details beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: list stock on hand per product, and names the key returned quantities. It clearly distinguishes stock-on-hand listing from broader product listing, though it does not explicitly contrast with the sibling get_product_stock tool.

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

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

It indicates optional filtering by warehouse or historical date, which implies when these parameters are useful. However, it provides no explicit guidance on when to choose this tool over alternatives such as get_product_stock or list_stock_adjustments.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the endpoint path and clarifies that filter matching is prefix-based, but says nothing about pagination behavior, result limits, or response shape beyond what the schema supplies.

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 with no redundancy; the core action is front-loaded and the endpoint reference is a compact trailing 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 five-parameter, zero-required read tool with no output schema and read-only annotations, the description covers what the tool does and how to filter. It could note default paging/return behavior, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so every one of the five parameters is already documented with its own constraints. The description restates three of them at a high level without adding syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('List suppliers') and enumerates the available filter dimensions, plus the backing endpoint GET /Suppliers/{page}. The unique entity (suppliers) inherently distinguishes it from the many list_* siblings, though no sibling is 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?

It implies usage via 'optionally filtered by code prefix, contact email prefix or modification date', so an agent can infer the filter conditions, but there is no explicit when-to-use, when-not-to-use, or routing to an alternative tool.

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

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

The readOnlyHint=true annotation already establishes this as a safe read, so the description's burden is lighter. It adds the underlying endpoint (GET /Warehouses/{page}) but says nothing about pagination termination, ordering, or how obsolete records affect results beyond the schema's own description of includeObsolete.

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, no filler, with the returned-field summary front-loaded. The trailing API endpoint note is marginal value but doesn't bloat 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?

With no output schema, the description usefully enumerates the returned fields (code, name, default flag, address) that the agent cannot otherwise discover, and the schema fully covers inputs. The only gap is the absence of guidance on filter combinations for incremental retrieval.

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

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

Schema description coverage is 100%, so all six parameters (page, pageSize, modifiedSince, warehouseCode, warehouseName, includeObsolete) are already self-documented. The description adds no parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('List warehouses') and enumerates the returned fields (code, name, default flag, address), so the agent knows exactly what it gets back. It is clearly distinct from sibling list_* tools by resource, though it doesn't name an alternative the way the calibration's top example does.

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

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

'Warehouse codes are what other tools filter by' implies this is a reference/lookup tool used to obtain codes for downstream filtering, which is useful implied usage. However, there is no explicit when-to-use vs. when-not, and no mention of combining with the modifiedSince or includeObsolete filters for incremental sync.

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