Extensiv MCP by usefulapi

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

Even though annotations already flag destructiveHint and non-idempotent, the description adds value beyond them: it warns the action cannot be undone, describes the state precondition and error behavior, and explains the internal ETag/If-Match read before the POST. This is exactly the operational context annotations can't 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?

Three tight sentences, front-loaded with the WRITE classification and fully earning their place: scope, irreversibility/precondition, then mechanics. 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?

For a destructive mutation with no output schema, the description covers reversibility, precondition, error behavior, and the ETag handshake. An agent has everything needed to attempt the call and interpret failure.

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

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

Schema coverage is 100%, so all three parameters (order_id, reason, charge) are already documented in the schema. The description restates them (transaction id, reason, optional fee) but adds little syntax or semantics 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?

The description opens with a specific verb and resource ('WRITE: cancel one order by transaction id') and names the exact required inputs, so an agent can immediately distinguish it from extensiv_get_order or extensiv_list_orders. The scope 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?

It clearly states the precondition (the order must be in a state the warehouse can still cancel, otherwise Extensiv errors) and that the tool first reads the order for its ETag. It doesn't name a sibling alternative, but for a terminal cancel action there is plausibly none.

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

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

Annotations already declare idempotentHint=false and openWorldHint=true, but the description makes the consequence concrete (calling twice creates two orders) and supplies a remediation step, plus the Extensiv-side requirement that billing_code, carrier and mode be present. It stops short of covering permissions, failure behavior, or what a successful response contains, so it is strong but not exhaustive.

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

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

Front-loaded with WRITE and the operation, followed by risk, prerequisites, and endpoint in descending priority — an agent can act on the first sentence. The semicolon-chained clause structure is dense and slightly run-on, but no sentence is filler.

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

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

For an 11-parameter nested write with no output schema, the description covers the risky parts well: non-idempotency, required Extensiv fields, and the dependency graph to sibling lookup tools. The main omission is the return value (e.g. the created order id or reference), which an agent needs to confirm success or chain to extensiv_get_order.

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 earns above that by mapping parameters to their sources (customer_id, facility_id, SKU list, carrier/billing_code/mode from extensiv_list_carriers), which the schema only partially repeats. Optional fields such as notes, shipping_notes and account are left to the schema, which is reasonable given full coverage.

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 an explicit mode marker ("WRITE:") and a specific verb+resource: submit a new outbound order for a customer and facility, with the physical consequence (warehouse picks and ships). This is clearly distinguishable from read siblings like extensiv_list_orders and from extensiv_cancel_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?

Names the exact prerequisite lookups: ids from extensiv_list_customers, extensiv_list_facilities, SKUs from extensiv_list_items, and billing_code/carrier/mode from extensiv_list_carriers. It also prescribes a pre-call check against extensiv_list_orders for the reference_num, which is an explicit when-to-use/guard condition rather than implied usage.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds the endpoint and names the returned data categories (company info, contacts, settings), which is useful because there is no output schema, but it omits error behavior (e.g., unknown id) and any rate/permission notes.

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

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

Two short sentences with the identifying scope front-loaded and zero filler. Nothing could be removed without losing information.

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

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

For a one-parameter read tool with full annotations, the description covers what it fetches and what comes back (company info, contacts, settings), which compensates for the absent output schema. Only minor gaps remain around error/no-match behavior.

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

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

Schema coverage is 100% and the single parameter is well documented in the schema, including the pattern and where to obtain the id. The description adds no parameter-level meaning beyond restating 'by customer id', so baseline 3 applies.

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

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

States a specific verb and resource ('One customer by customer id') plus the payload contents (company info, contacts, settings), which clearly separates it from extensiv_list_customers. It doesn't explicitly contrast with the sibling list tool, so it stops short of 5.

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

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

The 'by customer id' phrasing implies single-record lookup versus listing, and the schema points to extensiv_list_customers as the id source. However, the description never states when to use this over the list tool or what to do if 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.

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 context: which fields come back (status, ship-to, routing) and that lines only appear with detail=OrderItems.

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 plus the endpoint, front-loaded with the resource and the required id. No filler, and the most actionable fact (detail=OrderItems) is placed before the endpoint rather than 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 no output schema, the description carries the return-value burden and does sketch the return shape and detail-driven expansion. It is complete for a simple read call, though the itemdetail dimension of the response is never acknowledged.

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, but the description adds cross-tool meaning by defining order_id as the transaction id produced by extensiv_list_orders and by calling out the OrderItems detail value that gates line data. The itemdetail parameter is not mentioned in the description, leaving a small gap.

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 order by its transaction id') plus the underlying endpoint GET /orders/{transaction_id}. It also distinguishes itself from the sibling list tool by pointing at extensiv_list_orders as the source of the 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?

Implicitly routes the agent through extensiv_list_orders to obtain the transaction id, which is clear usage context. It does not state exclusions or when a different sibling (e.g. list_orders) would be preferable, so it stops short of an explicit when/when-not.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds only the raw HTTP path; it says nothing about behavior on an unknown transaction id (empty vs error), auth requirements, or what a receiver record contains.

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

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

Two short sentences, front-loaded with the purpose. The endpoint sentence is arguably redundant with the annotations and schema, but it costs little and adds a retrieval anchor.

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 one-parameter read tool with full schema coverage and clear annotations needs little prose, so this is close to adequate. However, there is no output schema and the description never indicates what a receiver response looks like, leaving the return shape entirely undisclosed.

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 parameter itself documents its source ('from extensiv_list_receivers'). The description echoes 'by its transaction id' but adds no format or constraint detail beyond the schema's pattern. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb+resource ('One receiver by its transaction id') and the underlying endpoint, so an agent immediately understands this is a single-record lookup keyed on transaction id. The singular framing implicitly separates it from extensiv_list_receivers, though the sibling is never named.

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

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

No explicit when-to-use statement, no prerequisites, and no mention of the obvious alternative (extensiv_list_receivers) for retrieving multiple receivers. The agent must infer from the singular phrasing that this is the single-item counterpart.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the concrete endpoint GET /properties/carriers, which confirms a static reference lookup, but says nothing about response size, caching, or stability of the carrier list. Useful but modest value on top of annotations.

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

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

One front-loaded sentence stating the resource, the contents, and the consumer use, followed by the endpoint. No filler and nothing requiring the reader to hold context across sentences.

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 zero parameters, no output schema, and annotations carrying the safety profile, the description covers everything needed to call it correctly: what it returns, what those values feed into, and the underlying route. Nothing an agent needs is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly makes no parameter claims that could mislead.

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) plus resource (carriers) and an enumeration of the payload: shipment services/modes and billing codes. An agent can immediately distinguish this from extensiv_list_facilities or extensiv_list_items because the description names the exact domain objects returned.

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 clause 'the values an order's routingInfo and billingCode must use' tells the agent this is a prerequisite lookup before extensiv_create_order, which is real usage context. It stops short of naming the sibling or stating exclusions, so it is clear context without explicit alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered structurally. The description adds the underlying GET endpoint, but says nothing beyond what the schema implies about pagination iteration across pages or result volume.

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

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

Two compact sentences with the resource definition front-loaded and the endpoint trailing as supporting detail. Nothing is redundant or padded.

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

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

For a simple zero-required-parameter list endpoint with full schema documentation and annotations covering the safety profile, the description is sufficient to invoke the tool. The only gap is lack of explicit routing relative to get_customer, which is a minor omission rather than a blocker.

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 rql, sort, pgnum and pgsiz each documented including examples and defaults, so the schema carries parameter semantics fully. The description contributes no additional parameter guidance, which is acceptable at this coverage but is the baseline, not added value.

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

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

States a specific verb (list) and resource (customers), and disambiguates the domain term with a parenthetical ('the companies whose goods it stores') plus the backing endpoint GET /customers. It reads clearly against the singular sibling extensiv_get_customer, though it never names that sibling explicitly.

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

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

Usage is only implied: a plural 'list' tool contrasted with get_customer suggests bulk enumeration versus single-record lookup, but the description never states when to use this over extensiv_get_customer or that ids returned here feed that tool. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by saying what comes back (ids and properties) and why the ids matter, but says nothing about pagination, result size, or error behavior for what is an open-world remote 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?

One sentence plus the endpoint, with the resource and return shape front-loaded and the dependency note in parentheses. Every clause carries information an agent uses.

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 trivial read-only list tool with no parameters and no output schema, the description covers what it returns and when to reach for it. The only meaningful omission is whether the facility list is paginated or complete, which matters for a list endpoint.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The description correctly implies a single unfiltered call rather than suggesting any optional filters exist.

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 warehouse's facilities') plus the payload ('ids and properties'), and pins the underlying endpoint GET /properties/facilities. An agent can tell this apart from extensiv_list_orders or extensiv_list_receivers without opening a 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 parenthetical 'facility ids are needed for orders, stock details and receivers' tells the agent this is a prerequisite lookup to run before those follow-on calls. It gives clear context but does not state exclusions or name alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and the shape of a returned line (location, lot, quantities), but says nothing about volume, pagination behavior, or ordering — modest added context on top of annotations.

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

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

Front-loaded with what the resource is, followed by the filter example and endpoint — three compact fragments, no filler. Slightly fragmentary rather than fully sentence-structured, but nothing is wasted.

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

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

With no output schema, the description carries some burden for describing returns; it partially discharges this by listing line fields, but gives no sense of result volume, default ordering, or paging behavior (left to the schema). Adequate but thin for a list endpoint with no return schema.

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

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

Schema description coverage is 100%, so rql, pgnum, and pgsiz are fully documented in the schema. The description's rql example (`itemIdentifier.sku==SF-Box-DG`) is a domain-specific illustration not in the schema, but it does not explain semantics the schema lacks. 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 concrete resource ('inventory detail lines') and names the fields they carry (location, lot, quantities), plus the underlying endpoint GET /inventory. It does not explicitly distinguish itself from close siblings such as extensiv_list_stock_details or extensiv_list_stock_summaries, so an 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?

The description gives a filtering recipe with a concrete rql example, which implies how the tool is used, but it never says when to choose it over the inventory-adjacent siblings (stock details vs stock summaries) or whether filters are optional. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the fields returned and the underlying endpoint, but says nothing about pagination behavior or result size limits beyond the schema.

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

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

Two tight sentences: the primary scope and returned fields come first, followed by the filtering capability and endpoint. Every element earns its place with no redundancy.

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

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

There is no output schema, but the description compensates by enumerating the returned fields (item ids, descriptions, units), and pagination is fully covered by the schema. An agent has enough to call it correctly, though a note on the parent-child relationship to other listing tools would complete 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 100% and all five parameters are documented in the schema, so the schema carries the semantics. The description's rql example (`sku==ABC-1`) adds a concrete filter hint but is a different example than the schema's, providing marginal extra value rather than new meaning.

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

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

States a specific verb and resource ('List the items (SKUs) of one customer') and names the returned fields (item ids, descriptions, units). It doesn't explicitly distinguish itself from the similar sibling extensiv_list_receiver_items, so it stops short of full differentiation.

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

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

Implies usage through the rql filter example and the required customer_id context, giving an agent a sense of when this tool applies. However, there is no explicit when-to-use versus alternatives guidance or exclusion criteria relative to sibling listing tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new context: that orders carry ship-to name, address and contact details (personal data), and that detail=OrderItems expands line items — useful for a read tool whose payload includes PII.

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, all front-loaded: filtering mechanism first, then the detail option, then the data-sensitivity note. No sentence is redundant with the schema 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 read-only list tool with full schema coverage and no output schema, the description covers purpose, filtering, expansion, and a notable PII warning. Minor gaps: no mention of pagination behavior or result shape, though the schema's pgnum/pgsiz descriptions partially compensate.

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 parameters are fully documented in the schema and baseline is 3. The description reinforces the rql parameter with an example and flags the detail expansion, but adds little beyond what the schema's own examples and enums already 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?

States a specific verb and resource ('List outbound orders') plus the underlying endpoint 'GET /orders', with the filtering mechanism named. It does not explicitly distinguish itself from siblings such as extensiv_get_order or extensiv_list_purchase_orders, so the reader must infer the difference from the verb alone.

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

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

Provides concrete RQL examples and a hint about when to add detail=OrderItems, which implies how to use the tool. However, it never says when to choose this over extensiv_get_order or extensiv_list_purchase_orders, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint path (GET /inventory/pos) and confirms filtering/sorting, but says nothing about pagination behavior or result limits beyond what the schema states.

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

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

Three short sentences, front-loaded with the purpose and with the endpoint last. 'Sort with sort' is slightly tautological but the whole thing is tight 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?

A read-only list tool with fully documented parameters and clear annotations; an agent has what it needs to call it correctly. Only the absence of output-format or pagination hints (beyond schema text) keeps it from a 5.

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

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

Schema description coverage is 100%, including RQL syntax examples and pagination guidance, so the schema carries the parameter burden. The description merely names rql and sort without adding semantics; baseline 3 applies.

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

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

States a specific verb and resource ('List inbound purchase orders per customer'), which is clear enough to distinguish from siblings like extensiv_list_orders or extensiv_list_receivers. It doesn't explicitly name an alternative, 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?

There is no guidance on when to use this versus extensiv_list_orders, extensiv_get_order, or the receiver tools. 'Filter with rql, sort with sort' is parameter instruction, not usage context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds little beyond restating a GET endpoint path: it says nothing about pagination, result volume for receivers with many lines, or how the detail level changes payload size, which is the one behavior an agent would want to know here.

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

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

Two short sentences, front-loaded with the resource and followed by the endpoint. Nothing is padded, though the endpoint echo is arguably the least useful of the two sentences.

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 with full schema coverage and read-only annotations, this is close to sufficient: an agent can call it correctly. What is missing is the sibling routing and any hint about output shape or size, which matters because there is no output schema.

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

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

Schema description coverage is 100%, so both parameters (including the comma-delimited detail enum) are already documented in the schema. The phrase 'with item details' loosely gestures at the detail parameter but adds no semantics beyond what the schema states; baseline 3 applies.

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

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

Names the specific resource (line items belonging to one receiver) and adds that item detail is included, which distinguishes it from extensiv_get_receiver (header data) and extensiv_list_receivers (the receiver list itself). No verb is stated explicitly, but the title supplies 'List' and the identity of the call is unambiguous.

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

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

There is no when-to-use guidance and no mention of the natural alternatives (extensiv_get_receiver for receiver header data, extensiv_list_receivers to obtain the id). The only routing hint, receiver_id coming from extensiv_list_receivers, lives in the schema rather than the description.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the HTTP endpoint and the detail-level cost hint, but says nothing about pagination behavior, result caps, or what a receiver record contains; it also doesn't note that openWorldHint implies remote data that may be large.

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

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

Two short sentences with the resource and its disambiguation front-loaded, followed by the endpoint. Slight waste in repeating the exact RQL example already present in the schema, and the trailing bare URL is terse to the point of being unlabeled.

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?

Five optional parameters, all fully described in the schema, no nested objects, no output schema, and read-only annotations. The description plus schema gives an agent everything needed to construct a call; only the shape of the returned receiver list is left implicit, which is acceptable given no output schema exists.

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

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

Schema description coverage is 100% — rql, pgnum, pgsiz, detail and itemdetail are all documented with examples and bounds in the schema itself. The description's RQL example is a verbatim duplicate of the schema's and the detail hint restates the enum, so it adds no meaning beyond structured fields. Baseline 3 applies.

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

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

States a specific verb and resource ("List inbound receivers") and disambiguates the domain term with the gloss "receipts of goods", plus the underlying endpoint GET /inventory/receivers. It also implicitly separates receiver-level from line-level data by pointing to detail=ReceiveItems, though it never names the sibling extensiv_list_receiver_items that actually serves lines.

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?

"Use detail=ReceiveItems for the lines" is the only usage cue, and it is a parameter hint rather than a when-to-use rule. There is no statement of when to prefer this over extensiv_get_receiver, extensiv_list_receiver_items, or extensiv_list_purchase_orders, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about result granularity (per receive item, lot/serial/track-by breakdown) but says nothing about permissions, result volume, or pagination behavior beyond what the schema documents.

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

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

Three short sentences, front-loaded with scope before the identifier requirement and the endpoint. Nothing is padded, though the raw endpoint reference contributes little for an agent that already has the tool name.

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 characterizes the return shape as per-receive-item breakdown with lot/serial track-by values, and the schema fully covers parameters and paging. Only the absence of guidance versus the stock-summaries sibling leaves a real gap.

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

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

Schema coverage is 100% and the schema already documents all four parameters including pagination semantics and the facility_id source (extensiv_list_facilities). The description only restates that both ids are required, adding no meaning beyond the schema's required list.

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 scope: all inventory for one customer in one facility, broken out by receive item with lot/serial track-by values. That is clearly distinct from order/carrier siblings, though it never names the closest alternative, extensiv_list_stock_summaries, so an agent must infer the detail-vs-summary split itself.

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?

'Both ids are required' gives a prerequisite, but there is no explicit when-to-use or when-not-to-use guidance and no mention of extensiv_list_stock_summaries or extensiv_list_inventory as the alternatives for summary-level data. Usage is only implied by the described granularity.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered structurally. The description adds that results are per-item/per-facility totals split into on-hand, allocated and available buckets, which is genuinely useful context, but says nothing about volume, pagination behavior, or account/facility scoping.

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

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

Two short sentences, front-loaded with what the payload contains before the filtering hint. The trailing 'GET /inventory/stocksummaries' is largely redundant for an agent but is cheap, so the description is efficient without being optimal.

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 roughly what it needs to by naming the three quantity fields returned. Pagination is fully handled by the schema (pgnum/pgsiz with guidance), so the only real omission is how this differs from the closely named sibling list_stock_details.

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 each parameter is well documented in the schema, so the baseline is 3. The description adds a concrete filter example (`ItemId==123`) that differs slightly from the schema's `ReadOnly.CustomerIdentifier.id` example, offering a small amount of extra signal but no syntax or semantics beyond the schema.

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

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

States a specific resource and what it contains ('Inventory totals per item and facility (on hand, allocated, available)'), which is more informative than the title alone. It does not distinguish itself from the close sibling extensiv_list_stock_details or extensiv_list_inventory, 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?

'Filter with rql, for example `ItemId==123` or a customer filter' gives a hint on how to narrow results, but there is no statement of when to reach for this tool versus extensiv_list_stock_details or extensiv_list_inventory, nor any exclusions or prerequisites. Usage is implied rather than guided.

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