Read Infoplus warehouses, item stock, order status and inbound shipment notices.
Scored across 10 tools
Each of the five resource families has a clear get-by-identifier tool and a distinct search/list tool, and the descriptions explicitly distinguish ID lookup from filtered page reads. No two tools appear to perform the same operation.
All names follow the infoplus_ + verb + resource pattern, with get_* for identifier reads and search_* for filtered page reads. The only minor deviation is the noun mismatch between get_inventory_detail and search_inventory, but the convention remains predictable.
Ten tools is well-scoped: five core resources, each with a get and a search operation. Each tool earns its place, and the set avoids unnecessary duplication.
The read-only surface covers get and search for ASNs, inventory, items, orders, and warehouses, but lacks any write or lifecycle operations such as create, update, receive, allocate, or ship. Other Infoplus resources are also absent, so agents needing WMS actions will hit dead ends.
Read selected advance shipping notices and up to 100 receipt lines by its Infoplus numeric record ID. Does not modify, allocate, receive or ship stock.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Infoplus numeric record ID from a search result, as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations by clarifying that it does not modify, allocate, receive, or ship stock, and by disclosing the 'up to 100 receipt lines' return scope.
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 tightly written sentences with no wasted language. The core operation and record-ID lookup are front-loaded, followed by the important non-mutation boundary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with rich annotations but no output schema, the description gives enough context to understand the operation and return scope. It could be slightly more complete by clarifying that exactly one ASN is returned for the given ID and what happens when no record matches.
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 schema already explains that record_id is an Infoplus numeric record ID from a search result, as a string. The description repeats the numeric-ID concept but adds no syntax or format details 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?
The description states a specific verb and resource: read an Infoplus advance shipping notice and up to 100 receipt lines by numeric record ID. It is clear what the tool does, though it does not explicitly name or route to the sibling search tool, and the plural 'notices' is slightly ambiguous for a lookup by one ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying the lookup is by Infoplus numeric record ID, and the schema notes the ID comes from a search result. However, it does not explicitly say when to use this tool versus infoplus_search_asns or state prerequisites for obtaining the ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read selected stock quantities, lots and warehouse location IDs by its Infoplus numeric record ID. Does not modify, allocate, receive or ship stock.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Infoplus numeric record ID from a search result, as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the negation 'Does not modify, allocate, receive or ship stock' largely restates them, though it adds useful domain-specific framing. It does not cover behavior for invalid or missing IDs, or the implications of openWorldHint=true (live Infoplus data, possible latency or auth failures).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler. The positive capability statement comes first and the negative scope clarification follows, which is the right ordering.
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 one parameter, full schema coverage, and no output schema, the description carries the return-value burden well by naming the fields returned (quantities, lots, location IDs). Nothing an agent needs in order to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single record_id parameter is fully documented with a pattern and provenance note ('from a search result'). The description repeats the 'numeric record ID' concept without adding format, sourcing, or error semantics beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Read) and resource (inventory detail) and enumerates the returned content: stock quantities, lots, warehouse location IDs. The phrase 'by its Infoplus numeric record ID' implicitly separates it from the search_* siblings, 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: an agent can infer this is the lookup-by-ID counterpart to infoplus_search_inventory, since the tool requires a record ID from a prior search. There is no explicit statement of when to prefer this over the search tool or what to do when the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read selected item SKU, status, packaging and reorder metadata by its Infoplus numeric record ID. Does not modify, allocate, receive or ship stock.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Infoplus numeric record ID from a search result, as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description's 'does not modify, allocate, receive or ship stock' adds domain-specific reassurance about inventory side effects, but says nothing about behavior on a missing/invalid ID or about the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the capability and the returned fields are front-loaded before the scope disclaimer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple single-parameter read tool with full annotations and complete schema coverage, and the description lists what comes back. Only gap is the absence of any note about lookup failure or how to obtain the ID, which matters slightly 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?
Only one parameter, and the schema fully documents it at 100% coverage including the numeric pattern and that it comes from a search result. The description echoes 'Infoplus numeric record ID' without adding format, sourcing, or error semantics beyond the schema — baseline 3 for schema-covered params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (Infoplus item) and enumerates the fields returned — SKU, status, packaging, reorder metadata — keyed by numeric record ID. The 'by its Infoplus numeric record ID' framing implicitly separates it from infoplus_search_items, 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: the agent must infer that this tool applies once a record ID is known, and the ID's provenance ('from a search result') lives in the schema, not the description. The negative clause rules out stock actions but never names infoplus_search_items as the way to obtain an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read selected order status, amounts and up to 100 line items by its Infoplus order number (decimal suffixes are supported). Does not modify, allocate, receive or ship stock.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Infoplus orderNo from a search result, as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, but the description adds real context beyond them: a cap of 100 line items and an explicit statement that it does not allocate, receive, or ship stock. That negative scope matters because it rules out side effects an agent might expect from an order 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?
Two sentences, both front-loaded: the capability first, then the exclusion. No filler, no restating of the title or annotations.
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 with no output schema, the description covers the key input, the rough return content, the line-item cap, and the absence of stock side effects. The word 'selected' leaves ambiguous which fields come back, though that is a minor gap given the tool's simplicity.
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 already documents record_id as the orderNo from a search result, so the schema does most of the work. The description still adds value by noting decimal suffixes are supported, which explains the intent behind the schema's regex pattern rather than repeating it.
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 (read an order) plus scope: status, amounts, and up to 100 line items, keyed by order number. The single-record, by-orderNo framing clearly separates it from the sibling search_orders without needing to name it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its Infoplus order number' implies the caller must already have an orderNo from a prior search, and the schema confirms that source. However, there is no explicit when-to-use/when-not or named alternative such as infoplus_search_orders for callers who lack an orderNo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read selected warehouse logistics metadata by its Infoplus numeric record ID. Does not modify, allocate, receive or ship stock.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Infoplus numeric record ID from a search result, as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds a domain-specific non-mutation assurance about stock operations, but does not explain missing-record behavior, return shape, or auth/rate-limit considerations.
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 the core action front-loaded. The second sentence is a compact safety clarification and does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read tool with full schema coverage and annotations covering safety and idempotency. The description is sufficient for invocation, though it could say slightly more about what warehouse metadata 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 sole record_id parameter is already documented as a numeric Infoplus record ID from a search result. The description restates that it is by numeric record ID but adds no syntax or semantic 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?
The description states a specific verb and resource: read warehouse logistics metadata by Infoplus numeric record ID. It distinguishes lookup by ID from broader search-style siblings, though it does not explicitly name search_warehouses as the alternative.
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 mention of a numeric record ID from a search result, which suggests this tool is used after locating a warehouse. However, the description does not explicitly say when to use this versus search_warehouses or other get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of advance shipping notices and up to 100 receipt lines. Optional Infoplus filter and sort expressions. A full_page result may have a following page; request the next page to check. Reads only; no automatic pagination or retries. Pace calls within the API user's 3/second and site-wide 10/second limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Infoplus sort expression using a documented resource field. | |
| limit | No | ||
| filter | No | Infoplus filter expression, for example status eq "On Order" for orders. Use fields from the resource's API reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond them: no automatic pagination, no retries, and concrete rate-limit ceilings. It omits what happens when page exceeds available data, but the added operational context is substantial.
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 what is returned before any operational caveats. Each sentence carries distinct information (scope, expressions, paging, rate limits) with no filler, though the phrase 'up to 100 receipt lines' is slightly ambiguous against the limit parameter.
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 conveys return shape (a page of ASNs plus receipt lines), the full_page continuation signal, and the absence of automatic retries or pagination. For a read-only search tool with four optional parameters, that covers everything an agent needs before calling 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 coverage is 50%: sort and filter already carry their own descriptions, and the prose adds only the 'optional Infoplus filter and sort expressions' framing. The page and limit parameters are undocumented in both schema and description, so defaults and paging arithmetic remain unstated. Baseline 3 fits when the schema does half 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?
The description gives a concrete verb and resource ('Read one page of advance shipping notices') plus the scope of included receipt lines, which is far more than the title alone. It does not explicitly contrast itself with infoplus_get_asn, so the single-record vs. paged-list distinction is left implicit for the agent to infer from 'search' vs 'get'.
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 states the operational conditions clearly: request the next page when a result is full_page, and pace calls within 3/second per user and 10/second site-wide. It stops short of naming infoplus_get_asn as the alternative when a single known ASN is wanted, so the routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of stock quantities, lots and warehouse location IDs. Optional Infoplus filter and sort expressions. A full_page result may have a following page; request the next page to check. Reads only; no automatic pagination or retries. Pace calls within the API user's 3/second and site-wide 10/second limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Infoplus sort expression using a documented resource field. | |
| limit | No | ||
| filter | No | Infoplus filter expression, for example status eq "On Order" for orders. Use fields from the resource's API reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: no automatic pagination or retries, the need to request the next page when full_page is returned, and concrete per-user (3/s) and site-wide (10/s) rate limits. This is exactly the operational detail an agent needs to call it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each carrying a distinct fact (what's returned, filter/sort availability, pagination behavior, rate limits) with the payload front-loaded. 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 does the work of explaining the result shape (page contents, full_page continuation) and the operational envelope. Only the page/limit parameter meanings are left implicit for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% and the description only restates that filter/sort are 'Infoplus expressions' without adding syntax or field guidance beyond the schema's own description and example. Page and limit are undocumented in both places, though their names, defaults and bounds are self-explanatory.
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 precise verb and resource plus the returned dimensions: stock quantities, lots, warehouse location IDs. It is clearly a paged search, distinct from infoplus_get_inventory_detail, though it never names that sibling to cement the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'Optional Infoplus filter and sort expressions' and the pagination note, and warns about rate limits, but never states when to choose this search over infoplus_get_inventory_detail or the other search_* siblings. No explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of item SKU, status, packaging and reorder metadata. Optional Infoplus filter and sort expressions. A full_page result may have a following page; request the next page to check. Reads only; no automatic pagination or retries. Pace calls within the API user's 3/second and site-wide 10/second limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Infoplus sort expression using a documented resource field. | |
| limit | No | ||
| filter | No | Infoplus filter expression, for example status eq "On Order" for orders. Use fields from the resource's API reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: no automatic pagination or retries, a full_page signal for continuation, and concrete rate ceilings of 3/second per user and 10/second site-wide. Only the response shape is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with what is read, then pagination, then rate pacing. No filler. Slightly dense telegraphic style, but every sentence carries a distinct fact an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, zero-required, read-only search tool with no output schema, the description covers scope, continuation behavior, and throttling. The main residual gap is that it never characterizes the returned record set beyond a field list, leaving an agent to infer result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 50% schema coverage, only sort and filter carry schema descriptions; page and limit are bare. The description mentions 'optional Infoplus filter and sort expressions' and the page-continuation mechanic, which partially compensates for the page parameter but adds nothing about page numbering, defaults, or limits beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with field scope: 'Read one page of item SKU, status, packaging and reorder metadata.' This clearly separates it from the get_* siblings (get_item = single record, search_items = paged list). It stops short of naming any sibling explicitly, which keeps it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies list/paged retrieval and warns that 'a full_page result may have a following page; request the next page to check,' which is real usage guidance. But it never states when to reach for this versus infoplus_get_item or infoplus_search_inventory, so sibling selection is left to inference from the names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of order status, amounts and up to 100 line items. Optional Infoplus filter and sort expressions. A full_page result may have a following page; request the next page to check. Reads only; no automatic pagination or retries. Pace calls within the API user's 3/second and site-wide 10/second limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Infoplus sort expression using a documented resource field. | |
| limit | No | ||
| filter | No | Infoplus filter expression, for example status eq "On Order" for orders. Use fields from the resource's API reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds non-obvious behavior: no automatic pagination, no retries, the full_page next-page signal, and concrete rate limits of 3/second per API user and 10/second site-wide. That is real added value beyond the structured fields, short only of error/failure 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?
Four short sentences, front-loaded with what is returned, followed by filtering, pagination and pacing. No wasted clauses, though the page-continuation sentence is worded a little awkwardly and could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and four parameters, the description does the necessary work by naming the returned fields (status, amounts, line items) and the full_page pagination signal. It is close to complete; only the semantics of the page parameter and the shape of an empty result remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: filter and sort are documented in the schema, while page and limit carry no descriptions there. The description lightly compensates by framing the call as "one page" and tying it to a 100-item ceiling, but it never explains page semantics or that limit caps orders returned, and "up to 100 line items" is slightly ambiguous against the schema's limit maximum of 100.
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 ("Read one page of order status, amounts and up to 100 line items") and pins the scope to a single page, which separates it from an unbounded search. It does not explicitly distinguish itself from the sibling infoplus_get_order, so an agent must infer which to use for a single known order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational usage guidance for pagination ("A full_page result may have a following page; request the next page to check") and rate pacing, which is genuinely useful. However, it never names alternatives or states when-not to use it versus infoplus_get_order or the other infoplus_search_* tools, so the selection decision is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of warehouse logistics metadata. Optional Infoplus filter and sort expressions. A full_page result may have a following page; request the next page to check. Reads only; no automatic pagination or retries. Pace calls within the API user's 3/second and site-wide 10/second limits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Infoplus sort expression using a documented resource field. | |
| limit | No | ||
| filter | No | Infoplus filter expression, for example status eq "On Order" for orders. Use fields from the resource's API reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it warns that no automatic pagination or retries occur, explains that a full_page result may require another request, and states the API user and site-wide rate limits. Read-only safety is already covered by annotations, so this is strong supplemental 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?
The description is four compact sentences and front-loads the core operation before pagination and rate-limit details. Every sentence contributes useful operational context with no repetition.
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 search tool with no output schema, the description covers pagination and rate limits but does not describe the returned warehouse record shape or how this tool relates to infoplus_get_warehouse. It is adequate for invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%. The description mentions filter and sort expressions and implies page-based paging, but it does not explain page or limit semantics, defaults, or ranges. It adds some meaning for paging and expressions but leaves important parameter behavior to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: reading one page of warehouse logistics metadata. It separates itself from a single-record get by emphasizing paged search with optional filter/sort expressions. It does not explicitly name the sibling get_warehouse alternative, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for paged warehouse searches with optional Infoplus filter/sort expressions, but it does not say when to use this instead of infoplus_get_warehouse or the other search siblings. The pagination and rate-limit notes help operationally but are not explicit routing 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.
infoplus_get_asninfoplus_get_inventory_detailinfoplus_get_iteminfoplus_get_orderinfoplus_get_warehouseinfoplus_search_asnsinfoplus_search_inventoryinfoplus_search_itemsinfoplus_search_ordersinfoplus_search_warehousesRead SalesBinder customers, inventory, warehouse locations, invoices and sales orders.
Read Rackbeat products, location stock, sales orders and customer summaries.
Read Linnworks inventory, stock and orders; set stock levels and add order notes.
Read Finale Inventory products, stock, orders and shipments; create draft purchase orders.
Add one secure layer between your agents and this server.