Unleashed Software MCP by usefulapi

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

Annotations only supply destructiveHint=true and a title, so the description's note that CustomerCode must be unique and cannot be changed later is genuinely useful behavioral context. However, it stops there: no mention of required permissions, duplicate-handling behavior, or what happens on a code collision.

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 brief sentences, front-loaded with the action and followed by the one non-obvious constraint. Nothing is padded, though the trailing "Unleashed: POST /Customers" line is endpoint trivia with marginal value to an 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 a 12-parameter mutation tool with no output schema, the description omits what a successful call returns (e.g., the created customer identifier) and any error/duplicate semantics. The uniqueness warning partially covers the riskiest aspect, leaving it 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% across all 12 parameters, so the schema already carries the heavy lifting and the baseline is 3. The description restates the customerCode immutability rule that the schema already states, adding no new parameter-level 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?

The description gives a specific verb and resource ("Create a new customer") and the name plus endpoint line make it trivially separable from siblings like unleashed_create_product or unleashed_create_sales_order. It does not explicitly compare itself to any sibling, but differentiation 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?

There is no guidance on when to use this versus unleashed_get_customer or unleashed_list_customers, nor any prerequisite such as required lookup of existing codes or duplicate-checking workflow. The only implied usage is the name itself.

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 supply destructiveHint=true; the description adds the genuinely useful constraint that ProductCode must be unique, plus the underlying endpoint. However it omits auth requirements, duplicate-code behavior, and error outcomes, so it adds moderate value 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?

Three short, front-loaded sentences that carry no filler, with the uniqueness constraint placed prominently. The API-endpoint sentence is only marginally useful but not wasteful.

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 covers the core action but says nothing about the response, error/conflict handling, or optional-field behavior. It is minimally adequate given the schema does the parameter heavy lifting.

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 each of the 11 parameters is already documented in the schema (including 'Unique product code (SKU)'). The description's uniqueness note about ProductCode overlaps the schema and it adds no new parameter-level meaning, 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 ('Create') and resource ('a new product'), which naturally distinguishes it from the create-customer and create-sales-order siblings. It is clear but does not explicitly call out its relationship to the other create 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?

There is no guidance on when to use this versus alternatives such as unleashed_get_product (existence check) or an update path, and no prerequisites or conditions are stated. Usage is only implied by the verb 'Create'.

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 supply destructiveHint=true; the description carries and adds substantial behavioral context beyond that: the order reserves no stock and posts nothing to accounting, totals/taxes are server-computed, and the arithmetic identity Unleashed's validation enforces. This is exactly the side-effect and validation disclosure an agent needs for a write 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?

Three sentences, front-loaded with the single most important fact (creates a DRAFT/Parked order). The dense middle sentence earns its length by defining computed fields and the validation invariant; the trailing endpoint reference is short and 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?

For an 11-parameter write tool with no output schema and only a destructiveHint annotation, the description covers behavior, side effects, and validation well. The remaining gap is that it never indicates what the call returns (e.g. the generated order number/ID), which an agent would need for a follow-up step.

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 11 parameters are already documented and the baseline is 3. The description adds genuinely useful context that the SubTotal/TaxTotal/Total fields are computed and need not be supplied, but it does not clarify any individual input parameter 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 (Create) and resource (sales order) plus the exact resulting state (DRAFT, status Parked), which is more than a generic 'create' and cleanly separates it from the get_/list_ siblings. An agent knows exactly what object will exist after the call and in what state.

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 text explains the workflow context — the order is parked and 'a person places or completes it in Unleashed' — which implies this is the first step of a two-step human-in-the-loop process. However, it never names an alternative tool or states an explicit when-to-use/when-not condition (e.g. vs. quotes or a direct invoice path), so guidance 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, so safety is covered. The description adds meaningful context beyond that: the exact returned fields, the low-cost nature of the call, and its credential-check purpose. It does not describe error behavior when credentials are invalid, but the extra disclosure exceeds the annotation baseline.

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 efficient sentences plus the endpoint reference: what it returns first, why to call it second, raw API mapping last. Every clause carries information and the most important content is front-loaded.

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

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

For a zero-parameter read tool with no output schema, the description compensates by naming the returned fields (name, base currency, default tax rate), plus the endpoint and purpose. An agent has everything needed to call and interpret it.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate or document beyond the empty 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 (fetch), resource (the Unleashed company these credentials belong to), and even enumerates the returned fields (name, base currency, default tax rate). It is unambiguous against siblings like unleashed_get_customer or unleashed_get_product because it is the only company-level tool, and it maps to a concrete endpoint (GET /Companies).

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?

"A cheap way to confirm the API id, key and signature are right" gives a clear calling context: credential validation. There are no sibling alternatives to route between, and no explicit when-not-to-use guidance, so it falls just 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?

Annotations already declare readOnlyHint=true, so the safe read nature is covered. The description adds the upstream endpoint mapping and a preview of returned fields, but says nothing about auth requirements, error behavior for a missing/invalid Guid, or rate limits. Modest added value on top of 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?

One sentence, front-loaded with the action and identifier, followed by the field inventory and endpoint. No padding 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 partially compensates by listing the main fields returned, and annotations cover the read-only safety profile. Missing only error/not-found behavior, which is minor for a single-Guid lookup.

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 parameter carries its own description plus a Guid regex pattern, so the schema does the heavy lifting. The description's 'by Guid' adds only a light restatement, matching the baseline for fully documented 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 and resource ('Fetch a single customer by Guid') and enumerates the returned field groups (contact details, addresses, currency, payment terms, credit limit). The 'single ... by Guid' phrasing implicitly separates it from unleashed_list_customers, but 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?

Usage is only implied: 'by Guid' signals you need a known identifier rather than search criteria, which nudges the agent toward this tool over unleashed_list_customers. There is no explicit statement of when to prefer this over the list endpoint or what to do when the Guid is unknown.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's job is lighter. It contributes the names of the fields returned (prices, units, stock alert levels, group, brand, supplier) and the backing endpoint GET /Products/{productGuid}, which is genuinely useful since no output schema exists. It does not mention not-found behavior or auth/rate-limit constraints, 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?

Two compact clauses, with the operation and its identifier front-loaded and the payload enumeration and endpoint trailing. No filler sentences; every phrase 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-parameter read with no output schema, the description supplies the missing return-shape information via its field list, which is the main thing an agent would otherwise lack. The only omission is error/not-found handling, which is minor for this tool class.

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 productGuid parameter is already documented with a UUID pattern, so the baseline is 3. 'By Guid' in the description merely restates the schema and adds no format or sourcing guidance (e.g., how to obtain the GUID).

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') plus the payload scope (prices, units, stock alert levels, group, brand, supplier). The singular 'single product' plus the GUID key cleanly separates it from unleashed_list_products and unleashed_get_product_stock without needing to open another 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?

Usage is implied by 'by Guid' — you call it when you already have a product GUID — but the description never states when to prefer this over unleashed_list_products or unleashed_get_product_stock, and offers no exclusions or prerequisites.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is the underlying endpoint (GET /StockOnHand/{productGuid}[/AllWarehouses]) and the note that allWarehouses expands the breakdown. It does not describe pagination, error behavior for unknown GUIDs, or the response shape beyond the totals/per-warehouse split.

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 plus the endpoint reference; the primary mode is front-loaded and no sentence is 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?

Adequate for a read-only, fully documented single-resource query. The description hints at the return structure (totals vs. per-warehouse), though with no output schema a brief note on the fields returned would make it airtight.

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. The description reinforces the allWarehouses toggle and its effect on the result shape, which is a small addition over the schema's own wording.

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 on hand for one product') and scopes it to a single product, which cleanly distinguishes it from the sibling unleashed_list_stock_on_hand. The two output modes (totals vs. per-warehouse) are named up front.

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 framing 'The direct answer to how many do we have and where?' communicates the use case clearly, and 'one product' implies the list variant is for the other case. It stops short of explicitly naming unleashed_list_stock_on_hand as the alternative for multi-product queries.

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 useful return-shape context (lines, supplier, totals), but says nothing about error behavior for an invalid/unknown Guid, auth requirements, or rate limits, so it does not go far beyond the annotation baseline.

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 zero filler: the primary capability and scope are front-loaded, and the endpoint reference is appended compactly. Every clause 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 simple single-resource read tool with annotations covering safety and a fully documented parameter, the description is nearly complete; it even summarizes the return payload despite no output schema. Minor omission: no note on behavior when the Guid does not resolve.

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

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

With a single parameter and 100% schema description coverage, the schema already fully documents orderGuid including its Guid format pattern. The description only restates 'by Guid,' adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Fetch), resource (purchase order), scope (single, by Guid), and names the returned contents (lines, supplier, totals). The word 'single' plus the required Guid makes it unambiguous versus the sibling unleashed_list_purchase_orders without opening either 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?

Usage is implied by the phrase 'Fetch a single purchase order by Guid,' which tells the agent this is the right call when a Guid is known. However, it never states when NOT to use it or names unleashed_list_purchase_orders as the alternative for browsing, so guidance is implied rather than explicit.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds useful context by naming the returned components (lines, totals, customer, warehouse) and the underlying endpoint, but says nothing about not-found behavior, pagination, or auth/tenant requirements.

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

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

One front-loaded sentence plus a compact endpoint reference; nothing is wasted. The endpoint string is mild redundancy with the tool name but aids traceability, so it just misses a 5.

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

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

There is no output schema, so the description must hint at the return shape, and it does by listing lines, totals, customer and warehouse. It stops short of describing the serialBatch toggled fields or error responses, leaving a small but 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% (both orderGuid and serialBatch are documented in the schema, including the Guid pattern), so the schema carries parameter meaning. The description names the Guid key but adds no syntax or format detail and never mentions serialBatch, 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 (Fetch) and resource (a single sales order) and names the identifying key (Guid), plus what comes back. 'Single' cleanly distinguishes it from the sibling list_sales_orders without the agent opening either 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 word 'single' implies this is the by-id retrieval path versus the list_* siblings, but there is no explicit when-to-use/when-not statement, no mention of list_sales_orders as the alternative, and no note about what happens if the Guid is unknown.

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

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

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description adds the filterable scope but says nothing beyond annotations about pagination behavior, ordering defaults, or response shape beyond what the schema details already provide.

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 immediately followed by filters. The trailing API route reference is minor filler but not wasteful, so it is slightly below a perfect score.

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

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

For a read-only list tool whose annotations cover the safety profile and whose schema fully documents all parameters, the description supplies enough to call it correctly. No output schema exists, but a list of customers needs little return-value explanation, so coverage is nearly 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 the schema already documents all 8 parameters with types, ranges, and patterns. The description's mention of code/name-prefix, currency, and date filters only restates what the schema carries, meeting the baseline 3 without adding 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 (List) and resource (customers) plus its filter capabilities, clearly distinct from siblings like unleashed_get_customer (single) and unleashed_create_customer (write). It does not explicitly name an alternative, 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?

The phrase 'optionally filtered by...' implies the retrieval use case, but there is no explicit when-to-use guidance, no conditions for choosing this over list_products or a get_ variant, and no exclusions. 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, so the safety profile is covered. The description adds only the underlying endpoint ('GET /Invoices/{page}'), which is not meaningful behavioral context - no note on pagination limits, result ordering, or auth.

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 clauses with the filter scope front-loaded and no filler. The endpoint parenthetical is of marginal value 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 read-only list tool with full schema coverage the description is serviceable, but with no output schema it omits any indication of what a response contains or how paging is surfaced, leaving a small gap an agent would have to discover empirically.

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 filter parameter is already documented in the schema with format and semantics (e.g. invoiceNumber overriding other filters). The description merely summarizes the filter categories, adding no meaning beyond the schema. 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 sales invoices') and enumerates the filter dimensions, which is enough to separate it from list_sales_orders or list_sales_quotes. It does not explicitly name a sibling it is not, 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?

The filter list hints at how to narrow results, but there is no statement of when to use this tool versus the other list/get tools, and no preconditions. An agent must infer the use case entirely.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying REST endpoint (GET /ProductGroups/{page}), which hints at server-side pagination, but says nothing about how to iterate pages, result ordering, or rate limits. Modest value on top of 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?

A single front-loaded sentence with no filler: resource, returned fields, domain meaning, and endpoint are all packed in without a wasted 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 simple two-param read tool with no output schema, the description usefully names the returned fields and the domain concept, covering the main gap. It stops short of pagination/iteration guidance, which is the only remaining omission.

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 page and pageSize are fully documented in the schema with bounds and defaults. The description's '{page}' in the endpoint adds no syntax or meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('List product groups') and immediately clarifies scope with the returned fields (name, Guid, parent group) and the domain concept ('the category tree products are filed under'). This distinguishes it cleanly from siblings like unleashed_list_products and unleashed_get_product.

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 use case (browsing the product category tree) but never states when to prefer this over unleashed_list_products or unleashed_get_product, nor any prerequisites. Usage is inferable from context rather than explicit.

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

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

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description adds the underlying endpoint ('GET /Products/{page}') which hints at page-based retrieval, but it discloses nothing beyond that about pagination, default page size, or filtering aggregation, leaving meaningful behavioral context unstated.

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 front-loaded sentences with zero filler: the purpose and all filter dimensions come first, followed by a compact endpoint reference. Every clause carries information and nothing is 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 read-only list tool with fully documented parameters and safety covered by annotations, the description supplies enough to call it correctly. The absence of any return-shape or pagination guidance beyond the endpoint is a minor gap, but no output schema exists so some burden remains.

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 16 parameters in detail (e.g. 'Only products whose code starts with this', 'subgroups excluded'). The description merely restates the filter categories, adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List products') and enumerates the dimensions it can filter on, so an agent knows exactly what it retrieves. It does not differentiate from siblings like unleashed_get_product (single product) or unleashed_list_stock_on_hand, which is the only thing keeping it from a 5.

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

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

'optionally searched by code/description or filtered by...' implies when the filter parameters are applicable, which is adequate context. However there is no explicit when-to-use/when-not guidance or pointer to the sibling alternative (get_product for a single item), 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?

The readOnlyHint annotation already declares this a safe read, lowering the bar. The description adds the underlying endpoint (GET /PurchaseOrders/{page}), confirming a paginated read, but says nothing about defaults, rate limits, or result shape beyond what the schema shows.

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 sentence plus a compact endpoint reference, front-loading the action and its filters with no filler. The endpoint notation is slightly terse but earns its place by grounding the tool in the actual 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 12-parameter, 0-required read-only list tool with no output schema and a readOnlyHint, the description adequately conveys scope and filterability. The only mild gap is the absence of any note on pagination behavior or expected volume, which the schema partially covers.

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 12 parameters including formats, ranges, and status values. The description restates the filterable fields at a high level without adding syntax or semantics beyond the schema, which is the expected baseline.

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

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

The description states a specific verb and resource ('List purchase orders') and enumerates the filter dimensions, which is clear. It does not explicitly differentiate itself from the sibling unleashed_get_purchase_order, though 'list' vs 'get' is largely 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?

Usage is implied by 'list ... filtered by', so an agent can infer this is the bulk/browse retrieval path. However, there is no explicit when-to-use guidance, no mention of when to prefer unleashed_get_purchase_order for a single record, 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?

Annotations only declare readOnlyHint=true, so the description adds real value by disclosing that deleted orders are excluded by default and by citing the underlying paginated endpoint GET /SalesOrders/{page}. It does not describe rate limits, page limits, or result volume, 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?

Two compact sentences, front-loaded with purpose then filters, followed by the API mapping. Nothing is wasted, though the trailing 'unless asked for' clause is unexplained and slightly undermines the crispness.

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 14-parameter, fully-schema-documented read-only list tool with no output schema, the description covers scope, filtering, and default exclusion of deleted records. The main omission is any hint about pagination defaults or result-set size, which the endpoint reference only partially compensates for.

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 with format and range details. The description only mirrors the filter categories at a high level and adds no syntax or interaction semantics (e.g. how orderNumber overrides other filters) beyond what the schema states.

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

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

States a specific verb and resource ('List sales orders') and enumerates the filterable dimensions (status, customer, order number, warehouse, date range), which clearly separates it from the singular get_sales_order sibling. It stops short of explicitly naming the alternative tools like unleashed_get_sales_order or unleashed_list_sales_quotes.

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 filter enumeration implies when the tool is appropriate, and the exclusion of deleted orders gives useful context. However, no alternatives are named and no when-not guidance is given; 'unless asked for' is also ambiguous because no parameter in the schema lets the caller request deleted orders.

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 is a safe read, and the description adds nothing behavioral beyond that: no mention of pagination behavior, default page size, result caps, or response shape. The endpoint note 'GET /SalesQuotes/{page}' merely restates the page parameter already documented in the 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?

A single front-loaded sentence with the resource first and its filters second, followed by a short endpoint reference. No padding or redundancy in the prose, though the endpoint fragment is marginal value.

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 a read-only annotation and full schema coverage, the description covers selection well. However, there is no output schema, so nothing anywhere describes the returned quote records or pagination envelope, which is the remaining gap.

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

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

Schema description coverage is 100%, so all eight parameters are already documented (including the non-obvious 'quoteNumber overrides other filters'). The description's filter list is broader but less precise than the schema, so it adds no meaning beyond what the schema provides.

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

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

States a specific verb and resource ('List sales quotes') and enumerates the filter dimensions (status, customer, quote number, date range), so an agent knows exactly what the tool returns. It does not explicitly contrast itself with close siblings like unleashed_list_sales_orders or unleashed_list_invoices, leaving that distinction to the resource 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?

The filter list implies the retrieval context (pull quotes narrowed by status/customer/number/date), but there is no explicit when-to-use statement, no prerequisites, and no guidance on choosing this over list_sales_orders. 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds content-level context (each adjustment carries reason, status and lines) and cites the underlying endpoint, but says nothing about paging behavior, result volume, or auth requirements beyond what the schema implies.

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 well-formed sentence front-loads the resource, its subtypes, returned fields and filters. The trailing endpoint reference is short and mildly redundant but not disruptive.

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 endpoint with no output schema, the description tells the agent what each record contains and which filters apply, which is close to sufficient. It stops short of describing pagination semantics 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 already documented (including format, ranges and defaults). The description's 'filtered by warehouse, product or date' merely restates three of them and does not explain modifiedSince or the pagination pair. 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 and resource, and the parenthetical '(write-offs, recounts, corrections)' plus 'reason, status and lines' makes clear which record type this covers, implicitly separating it from unleashed_list_stock_on_hand. However, it never names a sibling tool, so the differentiation from the other list_* endpoints must be inferred.

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?

'filtered by warehouse, product or date' implies when the tool is useful, but there is no explicit when-to-use statement, no exclusions, and no pointer to an alternative such as list_stock_on_hand. Usage is only inferable.

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

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

readOnlyHint=true already covers the safety profile, and the description adds meaningful context beyond that: the exact fields returned (QtyOnHand, AllocatedQty, AvailableQty, OnPurchase, AvgCost) and the underlying GET /StockOnHand/{page} call. It omits auth/permission needs and rate-limit 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?

A single sentence that front-loads the core purpose and returned fields, then appends the optional filters and the REST endpoint. It is dense but every clause carries information; the em-dash field list is slightly list-heavy but earns its place given no output 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?

With no output schema, enumerating the returned quantity fields is the right compensating detail, and the endpoint reference implies pagination. Nine params at 100% schema coverage means the description does not need to repeat them; what's missing is only guidance on result size 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?

Schema description coverage is 100% — all nine parameters are documented in the schema, including the asAtDate pattern and pageSize default. The description only restates the warehouse and as-at-date filters, adding no syntax or default detail beyond the schema, so the baseline 3 applies.

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

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

Specific verb + resource ('List stock on hand per product') with an enumeration of the returned quantity fields, so the agent knows exactly what data comes back. It doesn't explicitly differentiate from the nearby siblings unleashed_get_product_stock or unleashed_list_stock_adjustments, 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?

'optionally for one warehouse or as at a past date' signals the two main filtering modes, which is useful implied guidance. However there is no explicit when-to-use-this-vs-a-sibling statement and no exclusions, so usage remains inferred 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the underlying endpoint (GET /Suppliers/{page}) and clarifies that code/email matches are prefix-based, but says nothing about pagination behavior or result volume beyond what the schema already states.

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 action and its optional filters, followed by the API path. No filler or redundancy; every clause 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?

A simple read-only list tool with five fully described optional parameters and a readOnly annotation; the definition covers what is needed to invoke it correctly. It omits return-shape and pagination notes, though no output schema exists and page/pageSize are documented in the schema.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including defaults and prefix semantics. The description restates the three filters without adding format, syntax, or edge-case detail, which is the expected baseline when the schema does the work.

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') plus the supported filter dimensions, so the agent knows exactly what it retrieves. It does not differentiate itself from sibling list tools (e.g. unleashed_list_customers, unleashed_list_products), but the resource name is unambiguous.

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

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

The description says the filters are optional and names them, which implies usage for filtered lookup. It provides no when-to-use/when-not guidance and does not point to any alternative sibling tool for supplier lookup, so routing 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 safe-read profile is covered. The description adds the raw endpoint (GET /Warehouses/{page}) but says nothing about pagination behavior, default page size behavior, or result ordering beyond what the schema already documents.

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

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

Two short sentences, zero filler, with the returned-field list front-loaded and the practical note about warehouse codes second. Nothing could be removed without losing information.

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

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

With no output schema, the description usefully enumerates the returned fields and explains the downstream role of warehouse codes. What is missing is only minor: pagination semantics and whether obsolete warehouses are excluded by default are left entirely to the schema.

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

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

Schema description coverage is 100%, so all six parameters (page, pageSize, modifiedSince, warehouseCode, warehouseName, includeObsolete) are already documented in the schema. The description adds no parameter syntax, defaults, or interaction details, so baseline 3 applies.

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

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

States a specific verb and resource ('List warehouses') and enumerates the fields returned (code, name, default flag, address), so an agent knows what it gets. It does not explicitly distinguish itself from siblings, though no sibling overlaps with warehouse listing, so the risk of confusion is low.

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 the reason to call it—resolving warehouse codes for use in other calls—but never states when to prefer it or what the alternative would be. Usage is implied, not spelled out.

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