Read-only access to your Order41 wholesale data. Look up orders, carts, products, drops and contacts, with their custom tags, straight from Claude, ChatGPT or Cursor. Order41 is a B2B ordering platform for fashion and action-sports brands, their sales agencies and retail buyers. Sign in with your Order41 account; you only see what your role allows.
Scored across 14 tools
Each tool targets a distinct resource+action: get vs list for carts/orders, and label-value tools are scoped per entity. Minor overlap exists between listCartLabelValues (which mentions both carts and orders) and listProductLabelValues vs listDropProductLabelValues, but descriptions clarify these.
Strong, predictable camelCase verb_noun pattern throughout (getCart, listX). The lone outlier is upcase, a single-word utility tool, which is a minor deviation from the otherwise uniform convention.
14 tools is well-scoped for a commerce/catalog domain and each list/get tool earns its place. The count is slightly inflated by upcase, a non-domain testing utility.
The surface is entirely read-only: it offers get/list for carts, orders, contacts, products, and drops but no create, update, or delete operations anywhere. This leaves significant lifecycle gaps that would cause agent failures for any write task.
Retrieves comprehensive details for a specific shopping cart. Includes the cart's metadata and all associated products with their full product data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The cart ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It usefully discloses the response scope (cart metadata plus full product data for every associated product), which signals potentially large payloads, but says nothing about read-only nature, permissions, pagination, or behavior when the cart ID does not exist.
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 action front-loaded and no preamble. The second sentence slightly overlaps the first ('all associated products with their full product data'), a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing what is returned, which is exactly the information an agent needs. Missing only edge-case behavior (missing/invalid cart ID) for a simple one-parameter read tool.
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% for the single 'id' parameter, so the schema already documents it fully. The description adds no format, range, or sourcing detail 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?
States a specific verb ('Retrieves') and resource ('a specific shopping cart') and clarifies the payload scope (metadata plus associated products). It is clearly distinguishable from listCarts by the singular, ID-addressed framing, though it never names the 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?
'For a specific shopping cart' implies the caller must already hold a cart ID, but there is no explicit when-to-use statement and no guidance on choosing this over listCarts or getOrder. 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.
Retrieves comprehensive details for a specific customer order. Includes order metadata and the full list of products in the order with their detailed information.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The order ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the return payload (order metadata and full product list with details), which is valuable since no output schema exists, and 'Retrieves' implies read-only. It does not cover error behavior or permission requirements, so transparency is good but not exhaustive.
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 no wasted words. The second sentence efficiently specifies return content. Appropriate size for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, complete schema coverage for the required ID, and no output schema, the description is nearly complete. It states purpose and high-level return composition, though it omits error or not-found behavior. Score 4 reflects a small 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?
The single 'id' parameter has 100% schema description coverage, so the baseline is 3. The description adds no syntax or format meaning beyond the schema; it only restates 'specific customer order'. The schema already 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 ('Retrieves') and resource ('customer order') with scope ('specific') and return content. However, it does not explicitly name sibling alternatives like listOrders or getCart, so sibling differentiation is implicit rather than explicit. Clear but not fully distinguishing.
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 explicit when-to-use, when-not-to-use, or alternative guidance is provided. Usage is implied by 'specific customer order' (use when you have an order ID and need details), but an agent must infer it. This is the minimum viable implied-usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists custom label values (tags) associated with carts or orders. Helps in identifying specific categories or custom attributes assigned to transactional records.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | No | Filter by cart ID [id1,id2,...] | |
| order_id | No | Filter by order ID [id1,id2,...] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it does not meet it. It implies a read ('Lists') but says nothing about pagination, result limits, whether filters combine with AND/OR, or authentication needs. The '(tags)' clarification is the only genuinely added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core action front-loaded in the first. The second sentence is mild filler that mostly restates the purpose, but the overall footprint is tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter list tool with no output schema, the definition is minimally adequate: it names the resource and the two filter dimensions. It leaves the agent without any indication of what the returned values look like or how filtering by cart vs order interacts, which is a real gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both optional filters (cart_id, order_id, each as an ID array) are already documented in the schema. The description only implies the cart-vs-order filtering dimension without adding format or combination semantics, 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+resource: lists custom label values (tags) attached to carts or orders. This is specific and the parenthetical '(tags)' disambiguates what a label value is. It does not explicitly differentiate itself from sibling label-value tools such as listContactLabelValues or listDropLabelValues, but the cart/order scope is stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The second sentence ('Helps in identifying...') restates the purpose rather than telling an agent when to reach for this tool versus listCarts, getCart, or the other list*LabelValues siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists and filters shopping carts. Useful for finding specific carts by buyer, supplier, or associated drop, and for browsing recent cart activity.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by cart ID [id1,id2,...] | |
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | Yes | Query to filter carts by drop, season, supplier, or buyer | |
| offset | No | The number of items to skip (offset) for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether the operation is read-only, whether authentication or special permissions are required, how pagination behaves, or what the response shape looks like beyond the name implying retrieval.
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 core purpose and followed by useful usage context. There is no filler, repetition, or unnecessary exposition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list/filter tool with 100% schema coverage and no output schema, the description gives enough to understand the resource and typical use cases. It omits any explicit read-only or pagination note, but the schema covers pagination and the list semantics imply read 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%, so the schema already documents all four parameters including filters and pagination. The description mentions buyer, supplier, and drop as filter dimensions but adds no syntax, format, or combination semantics beyond what the schema provides, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Lists') and resource ('shopping carts'), and adds filtering scope. It does not explicitly distinguish itself from the sibling getCart, which retrieves a single cart, so it falls short of the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage contexts: finding specific carts by buyer, supplier, or drop, and browsing recent cart activity. It does not state when not to use it or name getCart as the alternative for single-cart lookups, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists custom label values (tags) associated with contacts. Useful for filtering or identifying contacts based on custom organizational categories.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | Filter by contact ID [id1,id2,...] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says what the tool lists. It does not state that it is a read-only operation, whether results are paginated, what authentication or permissions are required, or how the required contact_id filter affects the output.
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 consists of two tight sentences with no wasted words. The core purpose is front-loaded, and the use case follows naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description is adequate but misses a key detail: it does not mention that contact_id is required and acts as a filter, so an agent relying on the description alone might assume it lists all label values. It also omits any return-format or pagination context.
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 single contact_id parameter is fully documented in the schema. The description adds no additional meaning about the parameter, making the baseline score of 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 clear verb ('Lists') and resource ('custom label values (tags) associated with contacts'), making the tool's function immediately clear. It does not explicitly differentiate itself from siblings like listContacts or listCartLabelValues beyond the resource noun, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers a use case ('Useful for filtering or identifying contacts...'), which implies when the tool might be helpful. However, it provides no guidance on when to choose this over alternatives such as listContacts, nor does it mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists and filters contacts (buyers or suppliers). Use this to find specific users in the system by their name, email, or company.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by contact ID [id1,id2,...] | |
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | No | Query to filter contacts by name or email | |
| offset | No | The number of items to skip (offset) for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it adds essentially nothing: no statement about pagination defaults, result size, permissions, or ordering. The only operational detail (limit/offset) lives in the schema, not the description, leaving the tool's runtime behavior undisclosed.
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 capability statement front-loaded ahead of the usage hint, and no filler beyond a mild 'in the system'. It is appropriately sized for a simple list tool, though it is thin rather than dense.
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 no output schema, the description covers the essentials of what it returns conceptually. It omits pagination behavior, default ordering, and any differentiation from sibling list endpoints, leaving gaps an agent would need to fill by trial.
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 id, first, query, and offset, putting this at the baseline. The description adds no syntax or format detail beyond the schema, and its mention of filtering 'by ... company' is not reflected in the query parameter description ('name or email'), a minor inconsistency rather than an enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Lists and filters contacts') and even clarifies the entity's real-world meaning ('buyers or suppliers'), so an agent knows the domain. It does not, however, distinguish itself from the closely named sibling listContactLabelValues, which an agent could easily confuse with contact listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an implied use case ('find specific users ... by their name, email, or company'), which maps onto the query parameter, so there is some when-to-use guidance. But it names no alternatives or exclusions, and with a sibling like listContactLabelValues in the set, the boundaries of this tool versus related list operations remain unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists custom label values (tags) associated with sales drops. Useful for categorizing drops by season, region, or other custom identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| drop_id | Yes | Filter by dropID [id1,id2,...] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Lists' implies a read-only operation, but the description does not disclose auth requirements, pagination, rate limits, or return behavior beyond the resource name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. The second sentence adds useful context without waste, though it is somewhat generic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a fully described parameter, the description is minimally adequate. It lacks sibling differentiation and behavioral details, and because there is no output schema, it could say more about what is returned.
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 `drop_id` is fully documented in the schema as 'Filter by dropID [id1,id2,...]'. The description adds no additional meaning or format details beyond that 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?
Clear verb and resource: 'Lists custom label values (tags) associated with sales drops.' An agent can understand the operation. However, it does not distinguish itself from sibling tools such as listDropProductLabelValues or listProductLabelValues, which follow the same pattern.
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 a use case ('Useful for categorizing drops by season, region, or other custom identifiers'), but gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists custom label values (tags) specifically for products within a particular drop. Useful for finding drop-specific product attributes like "Hot Item" or "Limited Edition".
| Name | Required | Description | Default |
|---|---|---|---|
| drop_id | Yes | Filter by drop ID | |
| product_id | Yes | Filter by productID [id1,id2,...] | |
| maybe_empty | No | If true, may return empty list based on settings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Lists' implies a read operation, which is the main signal available, but nothing is said about permissions, pagination, or what happens when no labels exist (the odd maybe_empty parameter is left unexplained). For a simple list tool this is tolerable 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?
Two short sentences with the core purpose front-loaded and zero padding. The example values in the second sentence add a little discoverability, though they are close to restating the first 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?
With no output schema, the description gives no hint of the return shape (e.g., a list of label strings vs. objects), and it leaves the behavior of maybe_empty unexplained. For a three-parameter read tool with clear required filters it is adequate but has visible 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 the schema already documents drop_id, product_id, and maybe_empty; the baseline is 3. The description adds only loose meaning ('products within a particular drop' maps to the two required filters) and does not clarify the confusing maybe_empty semantics 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?
Clear specific verb+resource: lists custom label values (tags) scoped to products within a particular drop. The phrase 'products within a particular drop' effectively distinguishes it from the sibling listProductLabelValues (all products) and listDropLabelValues (all entities in a drop), but neither sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful for finding drop-specific product attributes like "Hot Item" or "Limited Edition"' implies a usage context, but there is no explicit when-to-use/when-not framing and no guidance steering the agent to or away from the neighboring listProductLabelValues and listDropLabelValues tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all products associated with a specific drop. Useful for browsing the inventory of a particular sales event (drop).
| Name | Required | Description | Default |
|---|---|---|---|
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | No | Query to filter products by name or SKU | |
| offset | No | The number of items to skip (offset) for pagination. | |
| drop_id | Yes | ID of the drop to list products from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Lists' conveys a read-only, non-mutating operation, which is meaningful. However, it does not disclose authentication needs, whether results are paginated (the schema implies it via first/offset), or the return shape, leaving real gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with the core action. The second sentence largely restates the first ('browsing the inventory of a particular sales event' vs 'products associated with a specific drop'), so it does not fully earn 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 read-only listing tool with fully documented parameters and no output schema, the description is nearly sufficient. The main minor gap is not mentioning that the result set is paginated, which the agent can infer from 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 drop_id, first, offset, and query in detail. The description adds nothing about parameters beyond the drop scoping, which is the baseline 3 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 ('Lists') and resource ('products associated with a specific drop'), which clearly scopes it apart from the sibling listProducts (all products). It does not name the sibling explicitly, so it stops short of 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?
'Useful for browsing the inventory of a particular sales event (drop)' implies a browsing context but gives no when/when-not guidance and does not point to listProducts or listDropProductLabelValues as alternatives. 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.
Lists and filters sales drops (events). Use this to find active or past drops, or to search for drops by name and season.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by drop ID [id1,id2,...] | |
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | No | Query to filter drops by name | |
| offset | No | The number of items to skip (offset) for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only implies a read-only list via 'Lists' and does not disclose pagination behavior, default limits, return shape, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted text. The primary purpose and usage guidance are 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 simple read-only list tool with full parameter schema coverage, the description covers the core purpose and basic usage. However, with no annotations and no output schema, it should do more to explain return behavior or pagination defaults, and the unsupported 'season' mention leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so id, first, query, and offset are already documented in the schema. The description mentions searching by 'name and season,' but the schema only documents query as filtering by name and has no season parameter, so this adds little and risks misleading the agent.
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: it lists and filters sales drops (events). It clarifies that drops are events, which helps distinguish the resource, but it does not name or differentiate against siblings such as listDropProducts or listDropLabelValues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage contexts: finding active or past drops, or searching by name and season. It does not explicitly say when not to use it or name an alternative tool for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists and filters customer orders. Useful for tracking order statuses, finding specific orders by customer name, or listing orders from a particular drop.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by order ID [id1,id2,...] | |
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | No | Query to filter orders by ID, buyer, or drop | |
| offset | No | The number of items to skip (offset) for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, mention permissions, pagination behavior, rate limits, or anything about side effects, so an agent cannot infer safety or operational constraints from the text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core purpose front-loaded. Every sentence earns its place by first stating the function and then offering practical filtering scenarios.
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 list tool with no annotations and no output schema, the description is minimally adequate. It explains what the tool does and why it is useful, but it omits behavioral context such as read-only nature or pagination expectations that would help an agent invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already well documented in the schema. The description adds no parameter-specific syntax or meaning 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: 'Lists and filters customer orders.' This clearly separates it from getOrder by emphasizing bulk listing and filtering, but it does not explicitly name or differentiate itself from sibling list tools such as listCarts or listDrops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides three concrete use cases: tracking order statuses, finding by customer name, and listing by drop. However, it does not say when to prefer this tool over alternatives like getOrder or other list tools, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists custom label values (tags) associated with products in the master catalog. Useful for finding product categories, materials, or other custom attributes across the catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Filter by productID [id1,id2,...] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Lists' implies a read operation, but nothing is said about permissions, pagination, response shape, or how results are scoped when product_id is supplied. For a tool with zero annotation coverage this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and no filler. Nothing is wasted, though the second sentence is more marketing-flavored than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description is minimally adequate, but it omits what the returned values look like (e.g., distinct tag strings) and the required nature of the product_id filter. An agent would still have to inspect the schema to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter product_id is documented in the schema itself. The description adds no meaning beyond that—it never mentions that product_id is required or how the array filter behaves—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: it lists custom label values (tags) attached to products. The phrase 'in the master catalog' implicitly distinguishes it from the drop-product sibling listDropProductLabelValues, but no sibling is ever 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?
The second sentence offers a use case ('finding product categories, materials, or other custom attributes') but gives no when-to-use versus alternatives guidance, no prerequisites, and never mentions the sibling tools that also list label values. An agent must infer routing on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists and filters the master product catalog. Use this to search for products by name, SKU, or custom fields across all drops and seasons.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by product ID [id1,id2,...] | |
| first | No | The number of items to return (limit). Use this with 'offset' to browse through results. Maximum is 100. | |
| query | No | Query to filter products by name, SKU, or custom ID | |
| offset | No | The number of items to skip (offset) for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses scope (all drops/seasons, master catalog), which signals a read-oriented, broad listing, but says nothing about permissions, result limits, default ordering, or read-only status beyond the word 'lists'.
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 core action and scoped by the second. No filler, no repetition of schema or title content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should ideally convey more about what comes back and any listing constraints (default result count, ordering). It covers purpose, scope, and filter fields adequately, but leaves return behavior entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (id, first, query, offset) are already fully documented in the schema, including the pagination pairing and the 100 maximum. The description's mention of name/SKU/custom fields merely echoes the query parameter, adding no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('lists and filters the master product catalog') and adds a scope qualifier ('across all drops and seasons') that implicitly separates it from the sibling listDropProducts. It stops short of naming that sibling outright, so the distinction must still 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?
The second sentence gives a usage scenario (search by name, SKU, or custom fields) and a scope ('across all drops and seasons'), which implies when to reach for this tool. However, it never names listDropProducts or listProductLabelValues as alternatives, so the agent must guess which catalog-listing tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A utility tool that converts the provided text to all uppercase characters. Mainly used for testing and demonstrating tool integration.
| Name | Required | Description | Default |
|---|---|---|---|
| str | Yes | The text to convert to uppercase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. For a pure string transformation it effectively conveys there are no side effects, but it never states that explicitly, nor does it cover edge cases such as non-string input or whether the result is returned versus mutated.
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 operation before the usage note. The opening 'A utility tool that' is the only real waste; everything else earns its place for a tool this small.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive utility with a fully documented schema and no output schema, the description supplies essentially everything an agent needs to call it correctly. The only omission is what the tool returns (the uppercased string), which is inferable but not stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('The text to convert to uppercase'), so the schema already does the work. The phrase 'the provided text' adds no syntax, format, or constraint information beyond what the schema states; 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?
The description names a specific verb and resource: 'converts the provided text to all uppercase characters.' That is unambiguous and trivially distinguishable from the e-commerce siblings (getCart, listOrders, etc.). The only deduction is that 'A utility tool that' is filler framing rather than added precision.
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?
'Mainly used for testing and demonstrating tool integration' implies a usage context, so the agent gets a weak signal about when this is appropriate. It names no alternative, no when-not condition, and gives no reason to prefer this over a sibling for any real task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
getCartgetOrderlistCartLabelValueslistCartslistContactLabelValueslistContactslistDropLabelValueslistDropProductLabelValueslistDropProductslistDropslistOrderslistProductLabelValueslistProductsupcaseQuery 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Read your events, sales, orders and attendees from your AI assistant. OAuth sign-in, read only.
Read-only access to your VortexIQ store data: audits, KPIs, alerts, Brand DNA, reports, Ask VIQ.
Query your books, company data, business health, and ship invoices from your AI assistant.
Add one secure layer between your agents and this server.
