MCP server for SkuVault — products, inventory, sales, purchase orders and stock adjustments.
Scored across 22 tools
Most tools target distinct resources or actions, and the descriptions clearly distinguish endpoints. However, several quantity-oriented reads (available, item, by-location, warehouse, product) and three sales reads overlap conceptually, so an agent must read descriptions carefully to choose correctly.
All tools share the `skuvault_` prefix and follow a snake_case verb_noun pattern, with get/list vs add/remove/set used predictably. Minor abbreviation variance (`list_po_receives` vs `list_purchase_orders`) is not enough to break the pattern.
At 22 tools, the set is above the typical 3-15 range, but SkuVault's domain is broad: inventory, products, warehouses, purchase orders, sales, and reference data. Each tool maps to a distinct endpoint, so the count is slightly heavy but reasonable.
Read coverage is broad, and core stock adjustments are present via add/remove/set quantity. However, the surface is read-heavy and lacks writes for products, kits, purchase orders/receiving, sales/fulfillment, and reference data; notably, stock writes require a pre-existing reason but no tool lists available reasons.
WRITE: add quantity of a product to a warehouse location (a transaction in SkuVault's history; every call adds again, so do not retry blindly). The transaction reason must already exist in SkuVault. Serialized or lotted products need serial numbers / a scanned lot code. Moderate throttling (10/min). POST /inventory/addItem.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Product SKU (give sku or code). | |
| code | No | Product code (give sku or code). | |
| note | No | Transaction note. | |
| reason | Yes | Transaction reason; must already exist in SkuVault. | |
| lot_code | No | Lot number (ScannedCode); required when adding to a lotted product. | |
| quantity | Yes | Quantity to add (a positive whole number). | |
| warehouse_id | Yes | SkuVault warehouse id (an integer; see skuvault_list_warehouses). | |
| location_code | Yes | Location the quantity is added to. | |
| serial_numbers | No | Serial numbers, as many as the quantity; only for serialized products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the non-idempotent consequence ('every call adds again, so do not retry blindly'), the moderate rate limit (10/min), the precondition that the reason must pre-exist, and the underlying POST /inventory/addItem endpoint. This directly reinforces idempotentHint=false and openWorldHint=true with operative detail an agent can act on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the WRITE marker and the core action, then the retry hazard, then preconditions and throttle. No sentence is redundant and nothing important is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation with no output schema, the description covers action, hazards, preconditions and throttling. The only gap is that it never says what comes back (e.g., a transaction reference) after a successful add, which would help an agent confirm the write.
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 baseline is 3; the description earns an extra point by tying parameters to product type — serialized products need serial_numbers and lotted products need a scanned lot_code — which frames those fields as conditional requirements rather than optional fields. It adds no syntax or format detail beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'add quantity of a product to a warehouse location' — and immediately labels it 'WRITE', making the mutation direction unmistakable. Against siblings like skuvault_remove_stock and skuvault_set_stock_quantity, the additive semantics ('every call adds again') make clear this is incremental rather than absolute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete preconditions (reason must already exist, serial numbers or lot code needed for serialized/lotted products) and a retry warning. It stops short of explicitly contrasting with skuvault_set_stock_quantity for cases where an absolute quantity is wanted, leaving that routing to inference from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sellable (available) quantity per SKU across all warehouses, with last-modified time. Use modified_after to see only what changed. Heavy throttling (5/min). POST /inventory/getAvailableQuantities.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-5000 (default 1000). | |
| modified_after | No | Only quantities modified at or after this time. | |
| modified_before | No | Only quantities modified before this time. | |
| expand_alternate_skus | No | List alternate SKUs inside their primary row instead of as separate rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description earns extra credit for disclosing the severe 5/min throttle, which materially affects how an agent should sequence calls, and it names the underlying endpoint.
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, zero waste, with the payload shape front-loaded and the throttling constraint placed prominently after it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does state what comes back (quantity per SKU plus last-modified time) and warns about rate limits. It stops short of describing the response envelope or how pagination cursors (next.page/next.skip) are surfaced, which matters for a heavily paginated read.
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 pagination semantics (page/skip/limit/page_size) are already fully documented in structured fields. The description only adds the intent behind modified_after; it says nothing about modified_before or expand_alternate_skus beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: sellable quantity per SKU across all warehouses, plus last-modified time. That scope implicitly separates it from sibling get_warehouse_quantities and get_inventory_by_location, 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?
One concrete usage hint is given ('Use modified_after to see only what changed'), which tells the agent how to do incremental sync. There is no guidance on when to prefer this over get_item_quantities or get_warehouse_quantities, so selection among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where each product is stored: per SKU (or code) the locations with warehouse code, quantity and whether the location is a reserve location. Filter by SKUs or by codes (not both). Heavy throttling (5/min). POST /inventory/getInventoryByLocation.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| skus | No | Only these SKUs. | |
| codes | No | Only these product codes (the reply is then keyed by code). | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: heavy throttling at 5/min, the underlying POST endpoint, and that code-based replies are keyed by code. It stops short of describing response shape beyond the field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the return shape, then the constraints, then the endpoint. Dense and nearly waste-free, though the terse phrasing ('per SKU (or code) the locations with...') is slightly harder to parse than a plainer sentence would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, six-optional-param tool with no output schema, this covers the essentials: what comes back, the mutually exclusive filters, pagination pointers (in schema), and the throttling ceiling. Missing only explicit sibling differentiation and any note on empty/unmatched results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by stating skus and codes are mutually exclusive and that the result keying changes with codes — semantics the schema's per-field text does not convey.
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 returns, per SKU or code, the locations where each product is stored with warehouse code, quantity, and reserve flag. That's a precise picture of the payload. However, it does not distinguish itself from close siblings like get_warehouse_quantities or get_item_quantities, leaving the agent to infer the difference.
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 supplies one real usage constraint ('Filter by SKUs or by codes (not both)') and a throttling warning, which helps avoid a 429. But it never says when to pick this over the near-identical sibling quantity tools, so selection remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Product quantities per SKU: total on hand, available, held, pending and picked. Filter by product codes or modification time. Heavy throttling (5/min). POST /inventory/getItemQuantities.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| codes | No | Only these product codes. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| modified_after | No | Only inventory modified at or after this time. | |
| modified_before | No | Only inventory modified before this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive), and the description adds genuinely new operational context: heavy throttling at 5 requests per minute and the underlying POST /inventory/getItemQuantities endpoint. It omits whether results are paged/windowed in a human-readable way, but the throttling warning alone is high-value for planning calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses: returned fields, filtering, then operational constraints. No filler, and the most decision-relevant information (what you get, how to filter) 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?
Seven optional parameters, all schema-documented, and no output schema — the description compensates by naming the returned quantity fields. Rate limiting and the vendor endpoint are covered; only explicit guidance on the windowing/pagination flow is missing, and the schema already explains that.
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/skip/limit/page_size and the modified_after/modified_before bounds are already fully documented. The description only restates the codes and modification-time filters at a high level, adding no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and enumerates exactly which quantity fields are returned (on hand, available, held, pending, picked), which tells an agent more than the name alone. It does not distinguish itself from close siblings like get_available_quantities or get_warehouse_quantities, so the agent must infer the difference.
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?
"Filter by product codes or modification time" implies how to narrow results, but there is no statement of when to prefer this over get_available_quantities, get_warehouse_quantities, or get_inventory_by_location. Usage is inferable but not routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One product (not a kit) by SKU or by code: details plus all quantities (on hand, available, pending, picked, incoming, in stock). Give exactly one of sku or code. Light throttling (20/min). POST /products/getProduct.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Product SKU. | |
| code | No | Product code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new operational context the annotations cannot convey: a 20/min throttle and the underlying POST /products/getProduct endpoint. Return payload is summarized but not fully detailed, which is acceptable given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded fragments: what it returns, the parameter constraint, then the throttle and endpoint. No filler, and the most decision-relevant information comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full annotation coverage and no output schema, the description covers scope, selection constraint, return contents, rate limits, and transport. An agent has everything needed to call it correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but 'Give exactly one of sku or code' adds a mutual-exclusivity/one-required constraint that the schema does not express (required list is empty and there is no oneOf). That is real semantic value beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('one product by SKU or code') and enumerates exactly what comes back (details plus on hand, available, pending, picked, incoming, in stock). The parenthetical '(not a kit)' plus 'one product' cleanly separates it from skuvault_list_products and skuvault_list_kits without the agent needing to open any 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?
Gives clear selection context: use this for a single product, and explicitly excludes kits, which routes the agent elsewhere. It does not name a specific sibling alternative (e.g. skuvault_get_item_quantities for quantities only), so it falls short of a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SKUs and quantities held in one warehouse. Get the warehouse id from skuvault_list_warehouses. Heavy throttling (5/min). POST /inventory/getWarehouseItemQuantities.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| warehouse_id | Yes | SkuVault warehouse id (an integer; see skuvault_list_warehouses). | |
| modified_after | No | Only quantities modified at or after this time. | |
| modified_before | No | Only quantities modified before this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The throttling disclosure (5/min) is genuinely valuable and is not derivable from the annotations, which only cover read-only/non-destructive behavior. The raw endpoint path also aids debugging. It does not warn about the paged-window result shape, which is the main behavioral surprise for callers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the resource and scope, with the critical throttling warning before the endpoint. The telegraphic noun-phrase opener is slightly elliptical but wastes nothing.
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 7-parameter read tool with no output schema, the description never indicates what a result entry looks like (SKU plus per-warehouse quantity fields) or how the paged window behaves across calls. Pagination is covered by the schema, but the response shape is undocumented anywhere.
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%: pagination fields, page_size defaults, and the warehouse_id origin are all already documented in the schema. The description only repeats the warehouse_id lookup hint, adding no syntax or format detail beyond what structured data provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the resource precisely (SKUs and quantities) and the scope (one warehouse), which separates it from the multi-location sibling tools. It stops short of explicitly naming a sibling such as get_item_quantities or get_available_quantities, so the boundary is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete prerequisite — fetch warehouse_id via skuvault_list_warehouses — which is real usage guidance. However, there is no statement of when to prefer this over the several other quantity-reading siblings in the list, so an agent must infer the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the brands created in SkuVault (Name, IsEnabled), 1,000 per page. Heavy throttling (5/min). POST /products/getBrands.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description earns credit for adding non-obvious traits: a hard throttle of 5 requests/minute and a page size of 1,000. The endpoint disclosure (POST /products/getBrands) is useful context for a read that uses POST, though it doesn't state auth requirements or total-count behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the resource and returned fields, then tacks on the two operational facts that matter (rate limit, page size). Nothing is padded and nothing essential is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only three optional, fully described parameters and a read-only annotation set, the description covers what an agent needs: what is returned, how large pages are, and the throttling constraint. It falls short only on credential/setup expectations and on reconciling the page-size figure with the schema's page/window model.
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 page/skip/limit semantics and their chaining rules are already documented, making 3 the baseline. The description's '1,000 per page' adds mild framing but sits slightly at odds with the schema's 'limit 1-500' and 'pages hold 1,000-10,000 rows', which the description does not reconcile.
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 ('List the brands created in SkuVault') and even enumerates the returned fields (Name, IsEnabled). The resource is unambiguous against siblings like skuvault_list_classifications or skuvault_list_suppliers, so an agent can pick it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the resource name — there is no statement of when to choose this over alternatives (e.g., to resolve brand IDs before filtering products) or any prerequisite/credential guidance. The operational note about throttling helps the agent plan calls but does not tell it when this tool is the right one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List product classifications and their named attributes, 1,000 per page. Heavy throttling (5/min). POST /products/getClassifications.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and non-destructive profile, so the bar is lower. The description still adds genuinely useful operational context beyond the annotations: a rate limit of 5/min, a 1,000-per-page size, and the underlying endpoint. It stops short of describing the response shape or what 'named attributes' look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource and packs pagination, throttling, and endpoint with no filler. 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?
With no output schema, the description still gives the pagination model and rate limit an agent needs to call it safely. It would be fully complete with a brief note on the return shape or how to iterate pages beyond the schema's next.page hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully documented in the schema, including how to use next.page and next.skip. The description adds only the '1,000 per page' sizing hint, which the schema partially restates. Baseline 3 is appropriate since 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+resource ('List product classifications and their named attributes'), which is clearly distinct from sibling list tools like skuvault_list_brands or skuvault_list_products. It doesn't explicitly name a contrast sibling, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource - an agent would infer this is for enumerating classification taxonomy. However, there is no explicit when-to-use guidance, no mention of prerequisites, and no routing to or from alternatives such as skuvault_list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the enabled sales-channel accounts (Amazon, ChannelAdvisor, Shopify...): Id, LongId, Name and Type. Severe throttling (1/min). POST /integration/getIntegrations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing a severe rate limit (1/min) — critical for an agent planning call sequences — plus the underlying POST /integration/getIntegrations endpoint. It also clarifies that only enabled accounts are returned, a filtering behavior the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads purpose, then return fields, then the throttling constraint, then the endpoint. Every clause carries distinct operational value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields (Id, LongId, Name, Type), and it flags the rate limit that governs how an agent should schedule the call. Nothing material is missing for a zero-arg 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?
The tool takes no parameters at all, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not pretend otherwise or invent inputs.
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 a precisely scoped resource (enabled sales-channel accounts) and even enumerates the fields returned. It is unambiguous against the sibling set, which contains no other integration/channel-listing tool, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, but the zero-parameter read-only nature and the 'enabled' qualifier make the intended usage self-evident. Implied usage only — an agent knows what it gets, not why it would prefer this over another call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List kits with their component lines, optional available quantity and cost. Needs a modified-time window (defaults to all time). The page size is not documented: keep following next until a page comes back empty. Heavy throttling (5/min). POST /products/getKits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| skus | No | Only these kit SKUs. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| include_cost | No | Also return the kit cost (default false). | |
| modified_after | No | Only kits modified at or after this time (default: all time). | |
| modified_before | No | Only kits modified before this time (default: now). | |
| include_available_quantity | No | Also compute the available quantity of each kit (default false: it is 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context the annotations cannot carry: heavy throttling at 5/min, an undocumented page size, and the instruction to follow `next` until an empty page. Annotations only declare this a safe read, so this operational detail is the description's real contribution; the return envelope shape is the main thing left out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with what is returned, then constraint, then pagination, then rate limit and endpoint. Nothing is repeated from the schema and nothing 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?
With 8 optional params and no output schema, the description covers the returned fields, pagination termination, and throttling, which are the things an agent would otherwise get wrong. It could still say what the response envelope looks like alongside `next`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter is described there, including next.page/next.skip. The description adds only the end condition for pagination (stop on an empty page), which the schema does not state, so it is a modest supplement over an already self-documenting 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?
Opens with a specific verb plus resource ('List kits') and enumerates what each record carries (component lines, optional available quantity and cost), which separates it from list_products. It never names a sibling explicitly, so an agent must still infer the kit-vs-product boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States a precondition ('Needs a modified-time window') but immediately undercuts it with '(defaults to all time)', leaving the agent unsure whether a window is mandatory. No when-not or alternative tool is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the locations in enabled warehouses with warehouse, location code, parent location/container and total quantity. Heavy throttling (5/min). POST /inventory/getLocations.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive safety profile, and the description adds two genuinely valuable facts beyond them: a hard throttle of 5 requests/minute and the fact that disabled warehouses are excluded from results. It does not describe the pagination envelope or response shape, but the throttling disclosure meaningfully changes how an agent should pace calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: contents of the response first, then the operational caveat and endpoint. No filler, and the throttling warning is placed where it will be read before the call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and annotations, the description supplies purpose, content, scope restriction, and rate limit. Only the pagination/multi-page behavior is left to the schema, which is acceptable since no output schema exists to carry 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?
Schema description coverage is 100%, and the skip/limit descriptions already explain the vendor-page windowing and the next.skip chaining. The description adds nothing about the parameters, so this sits at the baseline where the schema does all 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?
Specific verb (list) + resource (locations) with the returned fields enumerated (warehouse, location code, parent location/container, total quantity) and the underlying endpoint cited. The 'enabled warehouses' scope implicitly separates it from the inventory-quantity siblings like get_inventory_by_location, 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 scope: it returns locations in enabled warehouses, so it is the discovery call before quantity lookups. There is no explicit statement of when to prefer this over skuvault_list_warehouses or skuvault_get_inventory_by_location, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase-order receiving history: what was received (SKU, quantity, location, user, dates) followed by quantity corrections. Filter by warehouse codes, PO numbers or received time. Heavy throttling (5/min). POST /purchaseorders/getReceivesHistory.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| po_numbers | No | Only receives for these PO numbers. | |
| received_after | No | Only receives after this time. | |
| received_before | No | Only receives before this time. | |
| warehouse_codes | No | Only receives into these warehouse codes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely new context the annotations lack — a hard rate limit of 5 requests/minute and the underlying endpoint (POST /purchaseorders/getReceivesHistory). It stops short of explaining auth requirements or how the 'quantity corrections' section is keyed, but the throttle disclosure is exactly the kind of operational detail an agent needs before paginating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences: purpose and payload first, filters second, operational constraint and endpoint last. No filler, and the most decision-relevant facts 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?
With no output schema, the description usefully sketches the return content, and pagination semantics live in the schema. What's missing is any guidance on result ordering, expected volume, or whether the corrections section can be excluded — modest gaps for an 8-parameter read tool with a throttled, open-world backend.
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 includes pagination chaining guidance (`next.page`/`next.skip`), so the schema does the heavy lifting. The description only restates the filter dimensions already documented in the properties, adding no syntax or format detail beyond them — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource (purchase-order receiving history) and even outlines the payload shape — SKU, quantity, location, user, dates plus quantity corrections — which cleanly separates it from skuvault_list_purchase_orders. An agent can tell what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the available filters (warehouse codes, PO numbers, received time), which implies when the tool is useful, but it never states when to prefer it over sibling inventory/PO tools or what the trade-offs are. The 5/min throttle hints that bulk/exploratory use is discouraged, but only implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products (not kits) with description, cost, prices, brand, supplier, classification, reorder point and quantities (on hand, available, pending, picked, incoming...). Filter by SKU or code, or by modification time. Alternate SKUs come back as separate rows (IsAlternateSKU) unless you filter. Heavy throttling (5/min). POST /products/getProducts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| skus | No | Only these SKUs. | |
| codes | No | Only these product codes. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| modified_after | No | Only products modified at or after this time. | |
| modified_before | No | Only products modified before this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new operational context: heavy throttling at 5/min, and the gotcha that alternate SKUs return as duplicate-looking rows flagged IsAlternateSKU. It doesn't discuss how pagination interacts with the 1,000-10,000 row vendor pages beyond what the schema says, but that's a minor gap given 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?
Front-loaded with the core action and returned fields, then filtering, then caveats and limits — a sensible order with little waste. The parenthetical quantity list ('on hand, available, pending, picked, incoming...') is slightly loose but informative.
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 usefully carries the return-field inventory and the alternate-SKU row behavior. Combined with the fully documented 8-parameter schema, an agent has enough to call it correctly, though the 5/min throttle combined with page/skip/limit pagination could warrant a note on efficient paging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3; the description earns above that by explaining the semantic consequence of filtering — that alternate SKUs are separate rows unless a sku/code filter is supplied — which an agent cannot infer from the schema alone. Filter dimensions (SKU, code, modification time) are summarized but not given format details for the date strings.
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 (products), enumerates the returned fields, and explicitly excludes kits, which differentiates it from the skuvault_list_kits sibling without opening a schema. The endpoint (POST /products/getProducts) anchors it further.
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 practical usage signals (filter by SKU/code or modification time; alternate SKUs appear as separate rows unless filtered) and warns about throttling, so usage is implied clearly. However, it never states when to prefer this over skuvault_get_product for a single item or skuvault_get_available_quantities for stock-only queries, so no explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List purchase orders with supplier, dates, status, payment status, costs and line items (SKU, quantity, received quantity). By default completed POs are left out: set status Completed to see them. Specific PO numbers override the date and status filters. 10,000 per page. Heavy throttling (5/min). POST /purchaseorders/getPOs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| status | No | PO status (default: everything except Completed). | |
| po_numbers | No | Only these PO numbers; ignores dates and status. | |
| modified_after | No | Only POs modified at or after this time. | |
| modified_before | No | Only POs modified before this time. | |
| include_products | No | Also return incoming product details in a separate array. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, and the description adds operational context the schema cannot: heavy throttling at 5 requests/minute, a 10,000-row page size, the underlying POST /purchaseorders/getPOs endpoint, and the non-obvious default that Completed POs are omitted. That is exactly the hidden-behavior disclosure an agent needs before planning a paged scan.
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?
Five short sentences, zero filler, and the return payload is front-loaded before the filtering caveats and the operational limits. Every sentence carries a distinct, actionable fact.
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, 8 optional parameters, and an unfamiliar vendor API, the description still covers what comes back, the exclude-by-default trap, filter precedence, pagination scale, and rate limits. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns above that by documenting a cross-parameter interaction the schema does not state: specific PO numbers override the date and status filters. The remaining pagination and default-status semantics are already in the schema, so 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("List purchase orders") and enumerates the fields returned: supplier, dates, status, payment status, costs, and line items with SKU/quantity/received quantity. It does not explicitly differentiate itself from the sibling skuvault_list_po_receives, which is the one ambiguity an agent could stumble on, 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?
Gives concrete calling conditions: completed POs are excluded by default and require setting status to Completed, and po_numbers overrides the date and status filters. That is real when-to-use guidance. It stops short of naming an alternative tool for the adjacent job (e.g. po receives), so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sales (orders) that are ReadyToShip (default) or Pending, or look up specific sales by order id (then status is ignored): items, kits, shipping and contact info, totals. Not paged by the vendor. Heavy throttling (5/min). POST /sales/getSales.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| status | No | Sale status (default ReadyToShip). | |
| order_ids | No | Specific order ids; overrides status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: 'Not paged by the vendor,' 'Heavy throttling (5/min),' and the underlying POST endpoint. These are operationally critical details an agent could not infer from readOnlyHint/openWorldHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary operation and statuses, followed by the lookup override, returned fields, pagination caveat, throttling warning, and endpoint. Every fragment carries operational value with no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description enumerates the key returned data. Combined with explicit throttling, pagination behavior, endpoint details, and mode distinctions, an agent has everything needed 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 coverage is 100%, so the baseline is 3. The description still adds meaning by clarifying that order_ids overrides status and that vendor pagination is absent, which contextualizes why skip/limit exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List sales (orders)'), enumerates the two selectable statuses, and distinguishes a lookup-by-order-id mode where status is ignored. It also names the data returned (items, kits, shipping, contact info, totals), making it clearly identifiable among sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the two operating modes clearly: status-based listing with ReadyToShip as the default, or order_ids lookup with status ignored. It does not explicitly name sibling alternatives such as skuvault_list_sales_by_date, so it stops short of the full when/when-not/alternatives rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sales within a date range, by sale date or by last-modified date: items, kits, fulfillment/processed quantities, shipping, contact info and totals. The date range may span at most 7 days. The most common way to pull orders. Heavy throttling (5/min). POST /sales/getSalesByDate.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End of the interval (inclusive); at most 7 days after `from`. | |
| from | Yes | Start of the interval (inclusive). | |
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| date_field | No | Filter on the sale date (Sale) or on the last-modified date (Modified). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply the safety profile (readOnly, openWorld, non-destructive); the description adds genuinely load-bearing behavior: a hard 7-day maximum date span, heavy throttling at 5 requests/minute, the underlying POST /sales/getSalesByDate endpoint, and the shape of what comes back. The rate-limit disclosure in particular materially changes how an agent should plan calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with zero filler: payload contents, date-field modes, the 7-day limit, usage signal, throttle, and endpoint. The scoping constraint and payload listing are front-loaded where the agent will see them first.
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 7-parameter read with no output schema, the description carries the return-value burden well by enumerating the returned data, and it covers the two riskiest operational facts (7-day cap, 5/min throttle); pagination mechanics are handled by the schema. The remaining gap is sibling disambiguation, which is a usage concern rather than missing behavioral 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 every parameter including page/skip/limit/page_size and the date_field enum is already documented in the schema, establishing the baseline of 3. The description adds only a light restatement of the two date_field modes and the 7-day span, which the schema already states verbatim on `to`.
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 ('Sales within a date range') and enumerates the payload fields returned (items, kits, fulfillment quantities, shipping, contact info, totals), which goes well beyond restating the title. It does not, however, explicitly distinguish itself from the sibling tools skuvault_list_sales or skuvault_list_sold_items, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'The most common way to pull orders' implies a default/primary use, and the 7-day window is stated as a hard constraint. But there is no explicit when-to-use/when-not guidance and no mention of when to prefer skuvault_list_sales or skuvault_list_sold_items instead, leaving the selection among three similar siblings to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Items sold in a date range: date, SKU, quantity and total price per line, optionally breaking kits into components and including transfer sales. The date range may span at most 14 days. Heavy throttling (5/min). POST /sales/getSoldItems.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date/time (UTC); at most 14 days after `from`. | |
| from | Yes | Start date/time (UTC). | |
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| break_down_kits | No | Show kit components instead of the kit (SkuVault default true). | |
| include_transfer_sales | No | Include transfer sales (SkuVault default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), yet the description adds real operational context: a hard 14-day span cap and heavy throttling at 5 requests/min, plus the underlying endpoint. It stops short of describing pagination semantics or result ordering, which the schema partially covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: returned fields first, then the hard constraint, then the operational throttle and endpoint. Every sentence carries information the agent needs and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by naming the returned line fields, and it flags the two operational gotchas (date span, throttle). The remaining gap is sibling disambiguation against list_sales/list_sales_by_date, which matters given how many list_* tools exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; all seven parameters are already documented in the schema, including paging defaults and kit/transfer-sale defaults. The description only restates the kit breakdown and transfer-sale options and the 14-day constraint, adding little beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (items sold) and enumerates the returned line fields (date, SKU, quantity, total price), so the agent knows exactly what this returns. It does not distinguish itself from siblings like skuvault_list_sales or skuvault_list_sales_by_date, which look overlapping.
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 14-day date-range framing and the throttling note, but there is no explicit 'use this when...' guidance and no mention of when to prefer skuvault_list_sales or skuvault_list_sales_by_date. The agent must infer the choice from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the suppliers in the account (Name, IsEnabled), 10,000 per page. Heavy throttling (5/min). POST /products/getSuppliers.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely useful operational context beyond them: a hard rate limit of 5 requests/minute and a 10,000-row page size that drives pagination behavior. It stops short of describing what to do on throttle errors or how the returned payload is shaped, keeping it below 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?
One dense sentence that front-loads the resource, then layers return fields, page capacity, rate limit and endpoint. Nothing is repeated or wasted; each clause carries distinct 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 3-parameter read-only list tool with full schema coverage and no output schema, the description supplies what matters: what fields come back, page size, and the harsh rate limit that shapes call pacing. Only minor gaps remain (no note on empty results or error handling on throttling).
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 paging semantics (page/skip/limit and passing next.page / next.skip) are already fully documented in the schema. The description's '10,000 per page' supports the mental model that limit is a window into a large vendor page, but adds no syntax or constraints beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the suppliers in the account'), plus the fields returned (Name, IsEnabled), page capacity and the underlying endpoint. An agent can immediately tell this apart from siblings like skuvault_list_brands or skuvault_list_classifications without opening any 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 resource name (use when you need the supplier list), and the throttling note warns the agent to pace calls, but there is no explicit when-to-use/when-not guidance or pointer to an alternative for narrower lookups. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory transaction history (adds, removes, picks, creates) with user, SKU, quantity before/after, location, reason, note and the sale it belongs to. The date range may span at most 7 days. Filter by user email, warehouse id, type, reasons or sale id. Heavy throttling (5/min). POST /inventory/getTransactions.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the range (default now). At most 7 days after `from`. | |
| from | Yes | Start of the range. | |
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. | |
| skip | No | Items to skip inside the vendor page (default 0). Pass `next.skip` from the previous reply. | |
| type | No | Transaction type (default All). | |
| limit | No | How many items to return from the vendor page, 1-500 (default 50). SkuVault pages hold 1,000-10,000 rows, so a window is shown. | |
| reasons | No | Only these transaction reasons. | |
| sale_id | No | Only transactions against this sale id. | |
| page_size | No | Vendor page size, 1000-10000 (default 1000). | |
| user_email | No | Only this user's transactions (case-sensitive email). | |
| warehouse_id | No | Only this warehouse (the Id from skuvault_list_warehouses). | |
| exclude_reasons | No | Leave out these transaction reasons. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-derivable behavior: a hard 7-day maximum range and heavy throttling at 5 requests/minute, both of which change call pacing. Output shape is only partly described, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: what it returns, the hard constraint, then filters, throttle and endpoint. Dense and waste-free, though the filter enumeration and the trailing endpoint path carry little value for an agent that already has the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter read tool with no output schema, the description covers return fields, the range cap, filter dimensions and rate limits. What's missing is pagination behavior explanation and any note that results are paginated windows, though the schema covers both adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 7-day rule, page/skip chaining, limit windowing and warehouse id sourcing all already in the schema. The description's filter list restates the same fields without adding format or semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (inventory transaction history) and enumerates what each record contains (user, SKU, quantity before/after, location, reason, note, sale). This clearly distinguishes it from the sibling quantity/stock tools, which report current state rather than movement history.
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 as a history/audit tool implies when to reach for it, and the 7-day window plus filter list implies it's a scoped query rather than a bulk export. But no sibling is named and there is no explicit 'use this instead of X when...' guidance, leaving the agent to infer the split from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the regular warehouses (Id and Code). The numeric Id is what the stock tools and skuvault_list_transactions need. SkuVault throttles this call to 1 per minute. POST /inventory/getWarehouses.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Vendor page number, starting at 0 (default 0). Pass `next.page` from the previous reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only/safe, and the description adds value on top: SkuVault throttles this call to 1 per minute, which is operationally critical and not in any structured field. It also discloses the exact endpoint, reinforcing it is a query despite the POST verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying a distinct payload: what it returns, why the Id matters, and the rate limit. Front-loaded and zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description names the returned fields (Id and Code) and surfaces the throttling constraint, which is the main correctness risk. Minor gap: nothing about multi-page behavior or how many warehouses typically return.
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 page parameter is fully documented in-schema including the next.page paging convention. The description adds nothing about paging, 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 the regular warehouses") plus the returned fields (Id and Code), so the agent knows exactly what it gets. The word "regular" hints at a distinction from location-style tools (skuvault_list_locations), but it never names that sibling, so differentiation is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete reason to call it: the numeric Id is required by the stock tools and skuvault_list_transactions, which is real when-to-use guidance. It stops short of stating when not to use it or which sibling to prefer for location/who-data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: remove quantity of a product from a warehouse location (a transaction in SkuVault's history; every call removes again, so do not retry blindly). The transaction reason must already exist in SkuVault. Serialized products need serial numbers. Moderate throttling (10/min). POST /inventory/removeItem.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Product SKU (give sku or code). | |
| code | No | Product code (give sku or code). | |
| reason | Yes | Transaction reason; must already exist in SkuVault. | |
| quantity | Yes | Quantity to remove (a positive whole number). | |
| warehouse_id | Yes | SkuVault warehouse id (an integer; see skuvault_list_warehouses). | |
| location_code | Yes | Location the quantity is removed from. | |
| serial_numbers | No | Serial numbers, as many as the quantity; only for serialized products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/non-idempotent, but the description goes well beyond them: it explains that the removal is written as a transaction in SkuVault's history, that repeat calls remove again, warns against blind retries, and discloses a 10/min throttle plus the underlying endpoint. This is exactly the mutation risk context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, mutation semantics and the retry hazard front-loaded, then prerequisites, throttling and endpoint. No filler and nothing buried at the end that an agent needs first.
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 7-parameter destructive mutation with no output schema, the description covers non-idempotency, prerequisites, throughput limits and the underlying route. An agent has everything needed to invoke it correctly and avoid duplicate removals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including reason ('must already exist') and serial_numbers ('only for serialized products') is already documented structurally. The description restates those same points rather than adding new semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('remove quantity of a product from a warehouse location') and the 'WRITE:' prefix instantly marks it as a mutation. It is plainly the inverse of skuvault_add_stock, but it never names that sibling explicitly, so differentiation comes from inference rather than a stated contrast.
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?
'do not retry blindly' and 'the transaction reason must already exist' give real operating context, and serialized products needing serial numbers is a clear precondition. However, it never says when to choose this over skuvault_set_stock_quantity (absolute set) or add_stock, and offers no explicit exclusions, 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.
WRITE: set the exact quantity of a product at one warehouse location, overwriting what is there (running it again with the same values changes nothing more). Use skuvault_get_inventory_by_location first to see the current quantity. Moderate throttling (10/min). POST /inventory/setItemQuantity.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Product SKU (give sku or code). | |
| code | No | Product code (give sku or code). | |
| quantity | Yes | The new quantity at that location (0 or more). | |
| warehouse_id | Yes | SkuVault warehouse id (an integer; see skuvault_list_warehouses). | |
| location_code | Yes | Location whose quantity is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds valuable context beyond annotations: overwrite behavior, an idempotency clarification, a moderate throttling limit of 10/min, and the underlying POST endpoint. It does not describe auth requirements or return behavior, but with annotations present those gaps are less severe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences, front-loaded with the WRITE label and primary action. Every element earns its place: overwrite semantics, prerequisite read, throttling, and endpoint. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, destructive overwrite behavior, idempotency, a useful prerequisite, throttling, and the endpoint. No output schema exists, so explaining return values is unnecessary. It is nearly complete, with only a minor gap around explicitly routing between this and the add/remove siblings.
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 five parameters. The description reinforces that quantity is exact and scoped to one warehouse location, but it does not add syntax, format, or selection guidance beyond what the schema provides. Baseline 3 is appropriate when the schema carries parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: set the exact quantity of a product at one warehouse location, with the explicit overwrite scope. The overwrite wording distinguishes it from additive siblings like skuvault_add_stock and skuvault_remove_stock without needing to open their schemas.
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?
Recommends using skuvault_get_inventory_by_location first to see the current quantity, which is useful workflow guidance. However, it does not explicitly state when to choose this tool over skuvault_add_stock or skuvault_remove_stock, nor does it include exclusions or when-not-to-use guidance.
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.
skuvault_add_stockskuvault_get_available_quantitiesskuvault_get_inventory_by_locationskuvault_get_item_quantitiesskuvault_get_productskuvault_get_warehouse_quantitiesskuvault_list_brandsskuvault_list_classificationsskuvault_list_integrationsskuvault_list_kitsskuvault_list_locationsskuvault_list_po_receivesskuvault_list_productsskuvault_list_purchase_ordersskuvault_list_salesskuvault_list_sales_by_dateskuvault_list_sold_itemsskuvault_list_suppliersskuvault_list_transactionsskuvault_list_warehousesskuvault_remove_stockskuvault_set_stock_quantityMCP server for MarketTime — wholesale orders, customers, catalog and shipment tracking.
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
MCP server for Flex on the Job: inventory, jobs, customers, invoices, purchasing, sales orders.
Hosted MCP server for OTTO Market, Kaufland and Mirakl sellers: orders, stock, listings and ads.
Add one secure layer between your agents and this server.
