Amazon Selling Central MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation1/5
The tool set is riddled with overlapping and duplicate operations across legacy, versioned, and regional variants, such as Shipping vs ShippingLegacy, CatalogItems vs CatalogItems20201201, and Replenishment vs Replenishment20221107. All descriptions share the identical boilerplate 'Catalog entry. Runs in your Kuudo deployment, not here,' so they provide no functional distinction. An agent would have extreme difficulty selecting the correct tool.
Naming Consistency2/5
Most tools follow a Domain_actionName pattern, but the action portion is inconsistent: some are camelCase verbs (getRates, createShipment), some are PascalCase (GetAttributes, CreateAmazonMotors), and some are noun-like phrases (oneClickShipment, directPurchaseShipment). Domain prefixes also include version suffixes, making the overall naming scheme feel fragmented and inconsistent.
Tool Count1/5
303 tools is an extreme and inappropriate count for an MCP server, far beyond any reasonable navigable surface. This appears to be an uncurated dump of an entire API catalog rather than a focused, purpose-built tool set.
Completeness3/5
The server covers a broad range of Amazon SP-API domains including orders, listings, fulfillment, reports, feeds, shipping, messaging, and more, with many CRUD/lifecycle operations present. However, the massive duplication of legacy and versioned APIs and some missing modern operations create notable gaps and dead ends for agents.
Average 3/5 across 246 of 303 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Purchase shipping labels' and 'Runs in your Kuudo deployment, not here.' It does not disclose side effects, costs, rate limits, required setup, idempotency, or the meaning of 'Catalog entry'. For a purchasing operation, the lack of behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified rather than efficiently structured. 'Catalog entry' is confusing filler, and the front-loaded location note wastes the first sentence on something that does not help select or invoke the tool. The meaningful action 'Purchase shipping labels' is present but no supporting structure exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a purchasing tool with no output schema, no annotations, no parameter documentation, and no guidance among many similar siblings. The description is far too thin: it does not state what inputs are needed, what the response contains, how this differs from Shipping_purchaseShipment or ShippingLegacy_purchaseLabels, or what 'Runs in your Kuudo deployment' means operationally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with additionalProperties true, so there are zero defined parameters. With 0 parameters, the baseline is 4 and the description does not need to explain parameters. However, additionalProperties true means callers might pass arbitrary properties, and the description gives no hint about what those could be.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Catalog entry. Runs in your Kuudo deployment, not here. Purchase shipping labels.' It does state the action 'purchase shipping labels' but the 'Catalog entry' phrasing is vague and it doesn't differentiate from the many related shipping purchase siblings like Shipping_purchaseShipment, Shipping_directPurchaseShipment, or ShippingLegacy_purchaseLabels. The tool name already implies purchasing a shipment, so the description adds little beyond a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 tool versus the numerous sibling tools such as Shipping_purchaseShipment, Shipping_directPurchaseShipment, ShippingLegacy_purchaseLabels, etc. The only usage note is 'Runs in your Kuudo deployment, not here', which is a location constraint but not a usage guideline. The description does not explain prerequisites, when not to use it, or which alternative to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals a deployment constraint but does not explain what that means for invocation, whether the operation is read-only, what data it returns, or whether credentials/permissions are needed. The description is too thin to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of filler, but it is poorly structured: the unhelpful 'Catalog entry' comes first, the confusing deployment note comes second, and the actual purpose appears last. The first two sentences do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no input schema details and no output schema, the description needed to be self-sufficient. It fails to explain how to identify the order, what fields of buyer information are returned, or what 'not here' operationally means. The caveat may even imply the tool is not callable in the current environment, further reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, yet the description says 'the order that you specify,' implying an order identifier parameter that is not defined anywhere. It gives no parameter name, type, format, or location, so an agent cannot determine how to pass the order. The baseline for zero parameters is not met because the description introduces an unresolved input expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Returns buyer information for the order that you specify' provides a verb, resource, and object, so the basic purpose is understandable. However, 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are vague and do not clarify what 'buyer information' includes or how this differs from sibling Orders_getOrderItemsBuyerInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as Orders_getOrder, Orders_getOrderItems, or Orders_getOrderItemsBuyerInfo. The deployment note is environmental context, not a usage criterion, so an agent cannot choose this tool over its siblings confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose a notable trait: the operation executes remotely in the Kuudo deployment rather than in the current environment. However, it does not mention side effects such as persistent package creation, required permissions, idempotency, or expected outcomes, leaving substantial behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Catalog entry.' is a wasted fragment that does not explain anything. 'Runs in your Kuudo deployment, not here' is behaviorally relevant but placed without context. The final clause is the only actionable part, so the structure is only partially effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation-like operation with no annotations, an empty schema, and no output schema, this description is insufficiently complete. It leaves out how to identify the shipment, what package details are required, what the response looks like, and whether there are side effects. The only useful contextual addition is the remote-execution note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and sets additionalProperties:true, so there are no parameter names or types to rely on. The description's 'Provide details about the packages in the specified shipment' gives a general hint that the input should include package information and a shipment reference, which adds slight value, but it still falls short of describing the actual free-form body needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description never states that the tool creates packages; instead it says 'Provide details about the packages in the specified shipment,' which reads as input instructions rather than a description of the operation. 'Catalog entry' is ambiguous and adds no action-oriented clarity. It does not distinguish this tool from sibling tools like updatePackage or updatePackageStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives in the sibling list. The note that the operation 'runs in your Kuudo deployment, not here' is an operational caveat, not a usage guideline. There are no mentions of prerequisites, exclusions, or conditions that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions that the operation 'runs in your Kuudo deployment, not here,' which is cryptic and potentially misleading, but it does not explain side effects, permissions, idempotency, or execution context. A patch operation's behavior is largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: it opens with an unclear noun phrase and an ambiguous deployment statement before reaching the actual action. The main point is buried at the end, and the extra sentences do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema, no output schema, and no annotations, the description is far too sparse. An agent cannot determine required inputs, expected output, or how this tool fits with the numerous sibling listings tools, making successful invocation unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so there are no declared parameters and no schema-level guidance. The description provides no parameter information, such as sellerId, SKU, marketplaceIds, or the patch document, leaving the agent without any clue what to include in the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Partially update (patch) a listings item for a selling partner.' This clearly distinguishes it from full updates (putListingsItem). However, it does not differentiate it from the sibling ListingsItems_patchListingsItem, and the opening 'Catalog entry' and deployment note are confusing and unnecessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the unversioned patchListingsItem, the putListingsItem sibling, or other listings operations. The word 'partially update' weakly implies a use case, but no alternatives, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses an execution-location trait ('Runs in your Kuudo deployment, not here') but says nothing about side effects, required permissions, data scope, return shape, or whether this is a read-only operation. For a getter, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but the first sentence 'Catalog entry.' is cryptic and the second sentence is meta-context. The functional sentence is concise, but the overall structure wastes some space on ambiguous framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly incomplete for a tool with no annotations, no output schema, an empty input schema, and a large sibling list. It fails to explain what attributes are, how to request them, what response to expect, or how this differs from related Messaging and Orders tools. An agent would be guessing to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, and the description does not name any parameter such as an order ID despite saying the attributes are 'related to an order.' An agent gets no guidance on what properties to pass, and the open schema makes this omission more harmful rather than less.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns 'attributes related to an order,' which identifies a verb and resource but remains vague about what attributes are included or what 'order' means in this context. The opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add meta-information but do not sharpen the functional purpose. It does not distinguish this tool from the many Messaging and Orders sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Messaging_getMessagingActionsForOrder or Orders_getOrder. The note that it runs in 'your Kuudo deployment, not here' hints that it may not be directly invocable in the current environment, but it does not explain when or how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the tool runs in a Kuudo deployment rather than the current environment, but it does not describe side effects, required permissions, failure modes, or what 'create a reservation' actually changes. The behavioral disclosure is minimal and vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but its structure is poor: the actual purpose 'Create a reservation' appears only at the end, behind two cryptic filler sentences ('Catalog entry' and the deployment note). Every word is not earning its place, and the message is muddled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-reservation tool with no annotations, no output schema, and an effectively empty input schema, the description is severely incomplete. It fails to explain required inputs, return values, side effects, or any operational context an agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with additionalProperties true, meaning parameters are effectively accepted but completely undocumented. Despite being a creation operation that must require reservation details, the description provides no parameter names, formats, or examples. With zero defined parameters and an open schema, the description is expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ends with 'Create a reservation,' which is a clear verb+resource statement and distinguishes this tool from siblings like Services_cancelReservation and Services_updateReservation. However, the opening 'Catalog entry' is confusing and could be read as a placeholder rather than a real operation, and no detail is given about what kind of reservation is created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many reservation-related siblings. There are no conditions, prerequisites, or alternative tool references. 'Runs in your Kuudo deployment, not here' is a location note, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention the sandbox scope and that the tool makes a request, but it omits side effects, permissions, idempotency, and what happens after the request. The phrase 'Runs in your Kuudo deployment, not here' could also mislead an agent about whether invocation is possible in the current environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not bloated, but the first two sentences are ambiguous ('Catalog entry' and 'Runs in your Kuudo deployment, not here'), and the third sentence repeats the sandbox concept twice. It is concise but not well-structured for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating operation with no annotations, no output schema, and an empty input schema. The description does not explain how to specify the quantity, what the response will be, or whether the tool is actually callable here. An agent is left with too many unresolved questions to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes zero properties, yet the description refers to 'desired amount of quantity' without saying how that quantity should be supplied. With additionalProperties: true, arbitrary input is allowed, but the description does not provide the parameter names, shapes, or formats needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and target: it 'Requests that Amazon add items to the Sandbox Inventory.' However, the opening phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' make it unclear whether this tool actually executes when called, and it does not distinguish itself from sibling tools like FbaInventory_createInventoryItem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as FbaInventory_createInventoryItem or FbaInventory_getInventorySummaries. The only contextual clue is the deployment location, which is not a clear usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool runs in the user's Kuundo deployment rather than here, which is useful, but it does not state whether this is read-only, what authentication is required, or what side effects may occur. 'Catalog entry' is also unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly concise, but 'Catalog entry' is an unclear and expendable opening. The sentence about running in the Kuundo deployment is relevant but phrased informally. Overall, the structure is acceptable but not tightly purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential invocation details: how to specify the destination, what kind of information is returned, what 'Catalog entry' means, and when this tool should be used. With no output schema and no annotations, the description is not sufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties but allows additionalProperties, while the description says 'the destination that you specify.' This implies a destination parameter exists, but the description never names it or explains its format. The schema cannot guide invocation, so the description fails to bridge that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool 'Returns information about the destination that you specify,' which gives a clear verb and resource. However, the phrase 'Catalog entry' adds confusion, and the description does not differentiate this from the sibling tool Notifications_getDestinations beyond the singular form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Notifications_getDestinations or Notifications_createDestination. The note about running in the user's Kuundo deployment is contextual but does not explain selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It notes this is a catalog entry and runs remotely ('not here'), but it fails to state whether this is a read-only operation, what authentication or context is needed, or what it returns. It also implies a service job id is specified while the schema defines no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with no filler, but the actual purpose statement is delayed behind the 'Catalog entry' and 'runs not here' caveats. It is compact but not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description omits essential operational details: how to supply the job id, whether slots are returned in a particular format, and whether this read has restrictions. The remote/catalog-entry caveat is useful but leaves the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared properties, yet the description references 'the service job id specified,' implying an input that does not exist in the schema. Since additionalProperties is true, an agent cannot determine the correct parameter name or format from the description, making this actively misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('appointment slots for the service associated with the service job id'), making the core operation recognizable. However, it does not explicitly distinguish itself from sibling Services_getAppointmentSlots, and the 'Catalog entry' framing muddles whether this is directly invocable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or comparison to alternatives is provided. The only usage-related note is negative ('Runs in your Kuudo deployment, not here'), which warns where it doesn't run but does not tell an agent when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a read ('Returns') and that it runs remotely ('in your Kuudo deployment, not here'), but doesn't clarify the 'Catalog entry' meaning, output format, auth requirements, or failure behavior. The vague 'not here' actually reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is brief and free of fluff, but the first two sentences ('Catalog entry. Runs in... not here.') are cryptic and delay the actual purpose. Each sentence should earn its place; these are confusing rather than clarifying.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no defined parameters, the description must provide complete context. It does not: the agent cannot tell how to specify a shipment, what response to expect, or even whether the tool can be called from this environment. The definition is inadequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, yet the description says 'for the shipment you specify,' implying a required identifier parameter. It neither names the parameter nor provides its type or format, and additionalProperties=true leaves the agent guessing. This is a critical gap that prevents correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Returns the invoice status') and a specific resource ('the shipment'). However, it doesn't differentiate from similarly named siblings like DeliveryByAmazon_getInvoiceStatus, and the introductory 'Catalog entry... not here' phrasing muddies whether the tool is actually executable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as ShipmentInvoicing_getShipmentDetails, DeliveryByAmazon_getInvoiceStatus, or Invoices_getInvoice. 'Runs in your Kuudo deployment, not here' hints at a remote execution context but doesn't tell the agent when or whether to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds only a vague execution-environment note ('Runs in your Kuudo deployment, not here') and does not disclose output format, side effects, idempotency, permissions, or whether reprinting consumes or modifies anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry' is unhelpful filler and the key action is buried in a grammatically broken final sentence. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description needed to explain what a collection form is, how the agent should invoke or identify it, what response to expect, and how reprint differs from generate. None of that is present, so the tool cannot be invoked reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the description is not required to explain parameters. However, with additionalProperties set to true, the description could have clarified whether arbitrary inputs are expected in practice; still, the baseline for zero parameters is solid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a resource ('collection form') and an approximate action ('reprint'), but the opening 'Catalog entry' and the deployment note obscure rather than clarify purpose. It does not distinguish this operation from the sibling Shipping_generateCollectionForm or Shipping_getCollectionFormHistory, so an agent cannot tell whether this retrieves an existing form or creates a new one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance and names no alternatives. 'Runs in your Kuudo deployment, not here' is an operational context note, not a selection criterion, and there is no mention of when to prefer this over generateCollectionForm or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the mutation ('Update the status') and adds an ambiguous deployment note. It does not mention permissions, allowed status transitions, side effects, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: 'Catalog entry.' and 'Runs in your Kuudo deployment, not here.' are non-helpful filler, and the actual operational instruction is buried at the end. The substantive sentence earns its place, but the rest wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and an empty input schema, this description is grossly insufficient. An agent cannot determine required arguments, allowed status values, environment semantics, or expected results, making the definition barely more useful than a stub.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is effectively empty but allows additional properties, so an agent has no reliable parameter documentation. The description does not specify the supply-source identifier or the accepted status values; it only hints at the concept of a status without giving invocation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Update the status of a supply source' names a specific verb, resource, and the aspect being changed, which distinguishes it from siblings like SupplySources_updateSupplySource. However, the preceding phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add confusion about where the operation actually executes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of SupplySources_updateSupplySource, SupplySources_archiveSupplySource, or other related supply-source tools. The deployment remark hints at an environment constraint but does not clarify selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does disclose that the tool runs in the Kuudo deployment and that it can make up to 10 inventory requests, which is useful. But it never says whether these are reads or writes, what side effects occur, how partial failures are handled, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not bloated, but 'Catalog entry.' is filler that does not earn its place. The useful information is buried after that opening phrase, so the structure is not as front-loaded as it should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an open-ended input schema, this description is incomplete. It leaves the request semantics, expected payload, response format, and operational behavior largely unspecified, so an agent cannot confidently invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero named properties but allows additional properties, so the actual payload is essentially undocumented. The description hints at a 'up to 10 requests' constraint but does not describe the shape, required fields, or batching structure of an inventory request. The zero-parameter baseline raises the score slightly, but the open additionalProperties schema shifts some burden back to the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource: 'Make up to 10 inventory requests.' However, it does not explain what an inventory request is or how this tool relates to the many inventory-related siblings, and the opening phrase 'Catalog entry' adds no operational clarity. It is clearer than a tautology but remains vague about the tool's exact role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives, no exclusions, and no reference to sibling tools. 'Runs in your Kuudo deployment, not here' is a deployment-location clue, not a usage condition. An agent gets little help deciding between this and other inventory/catalog tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain side effects and execution semantics, but it only says the tool runs remotely in the Kuudo deployment. It does not disclose whether generating the invoice mutates state, creates a document, requires authorization, or returns data, which is especially important given the 'generate' action in the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' is redundant metadata that an agent cannot act on. The actionable clause is saved for the end, after the deployment note, so the information is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no documented parameters, this description is too thin. An agent is left without a way to specify the shipment, understand the return value, or know whether the operation has side effects, and it cannot distinguish this tool from retrieveInvoice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes no formal parameters, so the description's mention of 'the shipment you specify' is the only hint about the required input. It does not say how the shipment is identified or which parameter/property to populate, and the schema's additionalProperties:true leaves the invocation contract completely open.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names an action (get invoices) and a target (the specified shipment), so it is not a tautology. However, it does not distinguish this tool from the sibling ExternalFulfillmentShipments_retrieveInvoice, and the verb 'get' conflicts with the tool name 'generateInvoice', leaving ambiguity about whether the operation retrieves or creates an invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The only contextual clue is that it runs in a Kuudo deployment, which hints at an environment requirement but does not help an agent choose between this and related invoice/shipment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing effects. It only states that it 'sets' data, implying a mutation, and adds an unclear remote-execution note; it does not mention permissions, side effects, idempotency, or required inbound-plan state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The meaningful clause is brief and front-loaded after two wasted fragments. 'Catalog entry. Runs in your Kuudo deployment, not here.' earns no place, making the entry compact but not efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity FBA inbound mutation with no annotations, no output schema, and an effectively empty input schema. One generic clause is far from enough to invoke it correctly or sequence it within the inbound-plan workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes no properties and sets additionalProperties: true, so the request payload is entirely unspecified. The description names no arguments (e.g., the inbound plan identifier or the packing data), leaving the agent unable to construct a valid call; this falls below the baseline that a documented schema would provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core phrase 'Sets packing information for an inbound plan' names a specific verb and resource and is distinguishable from sibling FulfillmentInbound packing operations like generatePackingOptions or confirmPackingOption. It loses a point for the confusing 'Catalog entry'/'runs in your Kuudo deployment, not here' preface, which obscures rather than clarifies what the tool is for, and for not explicitly differentiating it from nearby siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when this operation should be used versus FulfillmentInbound_generatePackingOptions, confirmPackingOption, or listPackingOptions, nor is there any mention of required ordering or prerequisites. The deployment note is the only contextual hint, and it is not a usable usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that regulated information is returned and that execution happens elsewhere. It does not disclose read-only behavior, response format, authorization requirements, or what 'regulated information' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, but the opening 'Catalog entry' is filler, and the environment warning is ambiguous. The core return statement is clear but could be front-loaded without the confusing prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, an agent lacks essential information: how to specify the order, what data will be returned, and what authorization is needed. The statement 'Runs in your Kuudo deployment, not here' even suggests the operation is not available in the current context. This is not safely callable based on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes no properties, so the description is the only source for the implied 'order you specify'. It does not name the order identifier or explain how the order is selected, leaving an agent to guess. The empty schema with additionalProperties: true makes this especially unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Returns regulated information for the order that you specify' names a concrete verb, resource, and object. 'Regulated information' also distinguishes it from sibling order reads like Orders_getOrder and Orders_getOrderItems. However, the prefatory 'Catalog entry' and environment remark muddy the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus sibling order-related endpoints. No alternatives are named, and no conditions or prerequisites are provided. The phrase 'Runs in your Kuudo deployment, not here' hints at an environment restriction but does not tell an agent when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It reveals that the tool executes in a different environment and returns lowest-priced offers, but it does not disclose input requirements, response shape, pagination, or side effects. The phrase 'Catalog entry' adds ambiguity rather than behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but its structure is not ideal. 'Catalog entry' is a confusing opener that adds no value, and the most useful semantic content appears only in the second sentence. It is concise but not optimally front-loaded or fully purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch pricing operation with no annotations, no declared parameters, and no output schema, the description is severely incomplete. It omits how to specify the batch, which marketplace or credentials are expected, response details, and any constraints or prerequisites. An agent cannot reliably invoke this tool based on the provided description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the description is the only source of parameter meaning. It vaguely indicates the operation involves a batch of items and ASINs, but it does not specify parameter names, formats, or how the batch is provided. This is not actionable enough for an agent to construct a correct request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear action and resource: 'Returns the lowest priced offers for a batch of items based on ASIN.' This distinguishes it from listing-offer variants by emphasizing item-level offers, though it does not explicitly name sibling tools or contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as ProductPricing_getItemOffers, ProductPricing_getListingOffersBatch, or ProductPricing_getCompetitivePricing. The only usage context is 'Runs in your Kuudo deployment, not here,' which is about environment, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only implies a mutating operation through 'Update' and adds a deployment-context remark, but it does not mention permissions, side effects, reversibility, idempotency, or what happens to the existing schedule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable, but the core action is buried after the opening 'Catalog entry' and deployment note. Some of the meta text adds context, while 'Catalog entry' itself contributes little operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, an empty input schema, and only a one-line purpose statement, this description is far too incomplete for an agent to invoke the tool reliably. It lacks required inputs, request format, behavioral effects, and result expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, so the description is the only source of parameter meaning. It mentions 'given resource' but does not specify how the resource or schedule is identified or what properties should be included in the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: 'Update the schedule of the given resource.' This conveys the core action at a high level. However, it does not differentiate this from sibling tools like Services_updateReservation or Services_rescheduleAppointmentForServiceJobByServiceJobId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related Services tools. The phrase 'Runs in your Kuudo deployment, not here' is an environmental note, not a usage criterion, and there are no exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. 'Retrieves' implies a read-only lookup and the Kuudo deployment note is an extra context clue, but the description does not disclose required credentials, failure modes, rate limits, or what the returned 'details' include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but the first sentence 'Catalog entry' is a redundant fragment that adds nothing, and the useful action is in the last part. The deployment caveat is ambiguous. This is compact but not optimally structured or fully purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and an empty input schema, so the description must supply the missing operational context. It omits how to identify the item, what response shape to expect, and when this tool is the right choice. The Kuudo note is not actionable enough to complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties and additionalProperties:true, so the description is the only source of parameter guidance. It never names the identifier (e.g., ASIN or marketplace) needed to select the catalog item, making correct invocation guesswork despite the formal zero-parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Retrieves details for an item in the Amazon catalog') with a clear resource. It is understandable on its own, though the opening 'Catalog entry' is vague and there is no differentiation from the similarly named sibling CatalogItems_getCatalogItem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives; no sibling is named and no conditions or exclusions are provided. 'Runs in your Kuudo deployment, not here' is an environmental caveat, not guidance for tool selection. An agent cannot tell whether to prefer this over the unversioned getCatalogItem or the search variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation through 'gets', but it does not state side effects, permissions, limitations, return behavior, or what 'Runs in your Kuudo deployment, not here' actually means for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the opening 'Catalog entry. Runs in your Kuudo deployment, not here.' is opaque and front-loaded before the actual operation. It adds confusion rather than clear context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for reliable invocation: it does not explain how to specify the item, what the preview contains, or what execution in the 'Kuudo deployment' means. The empty schema and absent output schema increase the need for this missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, yet the description says 'an item that you specify', implying a required identifier that is never named or structured. The additionalProperties: true leaves an agent guessing what keys to supply, so the description fails to add usable parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear operation: it gets an eligibility preview for an item the caller specifies. This is specific enough to convey the resource and action, though it does not distinguish it from similar sibling tools like Awd_checkInboundEligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and does not mention any exclusions. The phrase 'Runs in your Kuudo deployment, not here' hints at an execution context but does not help an agent decide when to select this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses only that execution happens in a 'Kuundo deployment' and that resultDocumentId may be included. It does not state read-only behavior, required authorization, error conditions, or what happens when no feed matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' adds no operational information. The remaining two sentences are reasonably concise, yet the purpose statement is buried after environment context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an effectively empty input schema, this description is insufficient: it omits the required feed identifier, does not explain the feed details structure beyond resultDocumentId, and gives no error or availability context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties with additionalProperties: true, so no parameter names or formats are provided by the schema. The description says 'for the feed that you specify' but never identifies the feed parameter (e.g., feedId) or its type/requirement, leaving the agent unable to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns feed details ... for the feed that you specify.' This conveys a single-feed fetch and can be loosely separated from list operations by the singular 'feed.' However, it does not explicitly differentiate from Feeds_getFeedDocument or Feeds_getFeeds, and the opening 'Catalog entry' adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to call this versus sibling feed tools such as Feeds_getFeeds (list) or Feeds_getFeedDocument (retrieve document contents). The line 'Runs in your Kuundo deployment, not here' hints at an environment restriction but does not state what tool to choose instead or what conditions select this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Confirms' without explaining side effects, reversibility, authorization needs, or asynchronous behavior. The phrase 'Runs in your Kuudo deployment, not here' is a cryptic execution-location note rather than a meaningful behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The final sentence is concise and gets to the core action, but the first two fragments ('Catalog entry. Runs in your Kuudo deployment, not here.') are cryptic and add questionable value. The structure is compact but wastes a little space on ambiguous metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style tool with no annotations and no output schema, the description is too sparse to support correct invocation. It fails to explain prerequisites, required inputs, expected outcome, or operational behavior, making it only minimally viable for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero properties but allows additionalProperties:true, so the input contract is effectively unspecified. The description mentions the logical objects ('packing option', 'inbound plan') but does not identify any required identifiers or how to pass them, and it does not compensate for the missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Confirms') applied to a specific resource ('the packing option for an inbound plan'), which distinguishes it from sibling confirm operations like placement, transportation, or delivery window options. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' introduces ambiguity about whether the tool is actually executable, lowering the score from 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as generatePackingOptions, listPackingOptions, or confirmPlacementOption. It does not state prerequisites, sequencing, or when not to use it, leaving the agent to infer the entire workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It at least notes that execution happens in the Kuudo deployment rather than locally, but it does not clarify side effects, required authorization, failure modes, or whether options must exist before calling. The read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the core action is placed last, after two short but somewhat confusing contextual sentences. 'Catalog entry' does little to help invocation and the deployment note, while potentially important, is not elaborated. It is not overly verbose, but it is not cleanly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description leaves too much unspecified: how the agent supplies the shipment, what the returned options look like, and how this step fits into the generate/list/confirm flow. The deployment caveat is an unusual detail but does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties yet allows additionalProperties, so no parameter names or formats are documented. The description says 'for a shipment' but never tells the agent how to identify that shipment, which is a meaningful gap when the underlying tool likely requires a shipment identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The statement 'Retrieves all delivery window options for a shipment' gives a clear verb and object, which distinguishes this from the generate/confirm delivery-window siblings. The confusing 'Catalog entry' opening and 'Runs in your Kuudo deployment' clause soften the clarity, but the core purpose is still identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus generateDeliveryWindowOptions or confirmDeliveryWindowOptions. It does not mention sequencing, prerequisites, or cases where an alternative should be chosen, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Returns delivery options' weakly implies a read-only query and names the result fields, but it does not disclose side effects, authentication requirements, error behavior, or the meaning of 'runs in your Kuudo deployment, not here.' This is too thin for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of redundancy, but it is poorly front-loaded: the useful clause about returning delivery options appears after the confusing 'Catalog entry' and deployment note. 'Catalog entry' adds little value, and the structure would be clearer if the behavioral outcome came first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an effectively open input schema, this description is not sufficient for correct invocation. It reveals the return fields and an environment hint, but misses the actual criteria/input shape, request format, and operational constraints an agent would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty except for additionalProperties:true, so an agent has no structured parameter definitions. The description says 'based on criteria that you specify' but never names, types, or formats those criteria, leaving the free-form input body entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the operation's outcome: 'Returns delivery options that include an estimated delivery date and offer expiration, based on criteria that you specify.' This is a specific verb and resource. However, it does not distinguish itself from the many FulfillmentOutbound and shipping siblings, and the opening 'Catalog entry. Runs in your Kuudo deployment, not here' adds confusion rather than clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to select this tool over alternatives such as FulfillmentOutbound_getFulfillmentPreview or Shipping_getRates. The phrase 'Runs in your Kuudo deployment, not here' is the only contextual hint, but it is ambiguous and does not function as an actionable when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. It discloses a deployment caveat, but it does not state whether the operation is read-only, whether it has side effects, what authorization is required, or what the response shape is. The verb 'Returns' implies a read operation, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is concise and front-loaded, but 'Catalog entry.' adds little value and 'not here' is vague. The description is short enough to be readable, yet it contains filler that could have been replaced with more useful operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is under-specified. It omits how to specify the feature, what feature identifiers are valid, whether getFeatures should be called first, and what the returned inventory item list contains. The deployment caveat is useful but the operational context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, but the description says 'the fulfillment feature you specify' without naming a parameter, format, or valid values. This introduces a phantom parameter that the agent cannot determine from the schema or description, making correct invocation ambiguous despite zero declared parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb ('Returns') and resource ('list of inventory items') and specifies the selection criterion ('eligible for the fulfillment feature you specify'). It is distinguishable from sibling tools like getFeatures or getFeatureSKU by focusing on inventory eligibility, though the phrase 'Catalog entry' and the deployment caveat add some noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as FulfillmentOutbound_getFeatures or FulfillmentOutbound_getFeatureSKU. It mentions deployment context ('Runs in your Kuudo deployment, not here') but not use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions that the tool returns a fulfillment order and runs in a different deployment, but it does not clarify whether the operation is read-only, what side effects may occur, what authentication is needed, or what happens when the identifier is invalid or missing. The 'Catalog entry' phrasing adds ambiguity rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it wastes its opening on 'Catalog entry' and the unclear 'Runs in your Kuudo deployment, not here.' The only substantive sentence is clear, but the surrounding filler creates confusion rather than adding value. It is not egregiously verbose, so it earns a middling score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete: it does not identify the required parameter, response shape, error behavior, or access requirements. The environment note partially explains where it runs but not how an agent should invoke it. The tool's simple purpose is stated, but the operational context an agent needs is largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared parameters and allows additionalProperties, yet the description refers to a 'specified order identifier' without naming the property, its type, requiredness, or how it should be supplied. This leaves an agent unable to construct a correct invocation despite the 100% schema coverage, because the schema itself is empty and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it returns the fulfillment order for a specified order identifier. This distinguishes it from sibling tools like listAllFulfillmentOrders, though it does not explicitly name that distinction. The prefatory 'Catalog entry' and environment note add noise but do not destroy the core purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus the many related order and fulfillment tools. 'Runs in your Kuudo deployment, not here' hints at an execution context but does not explain when a caller should select this tool or what alternatives exist. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool returns invoice data and runs in a different deployment. It does not disclose authentication needs, output format, error behavior, or whether the operation is read-only, leaving the agent to infer these important traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and easy to scan, with the core behavior stated in one sentence. The 'Catalog entry' sentence is largely filler and could be removed, but overall the text is appropriately minimal and free of significant redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that is meant to be selected and invoked, the description is incomplete. It omits how to specify the invoice, what data is returned, any required scopes or permissions, and how it relates to the many sibling invoice tools. The environmental note about Kuudo may be important but is left unexplained, leaving the agent without enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties but sets additionalProperties to true, meaning parameters are accepted but undocumented. The description mentions 'the specified invoice' but gives no parameter name, type, or format, so the agent cannot know how to identify the invoice. This is a significant gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns invoice data for a specified invoice, which matches the singular 'getInvoice' name and helps distinguish it from the plural Invoices_getInvoices. However, the opening phrase 'Catalog entry' adds little and does not reinforce the purpose, and 'specified invoice' is vague without a documented identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not explain when to call this tool versus related siblings like Invoices_getInvoices, Invoices_getInvoicesDocument, or Invoices_getInvoicesExport. The only contextual note is environmental ('Runs in your Kuudo deployment, not here'), which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says the tool 'returns details' and mentions a deployment context; it does not disclose required authorization, whether this is a read-only catalog lookup, how results are scoped, or what happens when the item is not found. The description is too thin for an agent to form correct behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but 'Catalog entry' is a fragment that adds little value. The two substantive sentences could be rearranged so the actual purpose is front-loaded, and 'Runs in your Kuudo deployment, not here' is too cryptic to earn its place without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and an empty input schema, so the description is the only source of completion. It fails to mention how to identify the item, what data will be returned, or any relationship to sibling ListingsItems tools. The description is too incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but additionalProperties is true, meaning parameters are effectively undocumented. The description does not mention sellerId, SKU, or marketplaceIds needed to identify the listings item. For a get-details tool, the absence of any parameter guidance makes it impossible for an agent to know how to invoke it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns details about a listings item for a selling partner.' This distinguishes it from mutating siblings like put, patch, and delete, though it does not explicitly differentiate from the older ListingsItems20200901 variant. 'Catalog entry' is vague filler but does not undermine the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of searchListingsItems, deleteListingsItem, patchListingsItem, putListingsItem, or the 2020-09-01 variants. The cryptic note 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not explain selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that the tool runs remotely and returns subscription information, but says nothing about authentication, required identifiers, error behavior, or response shape. The opening 'Catalog entry' is also unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the first two sentences are peripheral context rather than core semantics. The actual purpose is delayed to the final sentence, and 'Catalog entry' adds noise without earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and invocation requirements. It only vaguely says 'Returns information' and never clarifies the subscription ID parameter or distinguishes itself from the very similar getSubscription sibling. Insufficient for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties and allows additional properties, so the description is the only source of parameter meaning. It mentions a notification type but does not name the parameter, does not mention subscriptionId, and gives no formats—making correct invocation unlikely for a get-by-id operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Returns information about a subscription') and a resource ('the specified notification type'). However, it omits the 'by ID' aspect and could equally describe the sibling Notifications_getSubscription, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' is an environment note, not a selection criterion, so an agent gets no help choosing between getSubscriptionById and getSubscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects itself. It reveals the tool performs a remote update in a Kuudo deployment, but it does not state whether the status change is destructive, reversible, or what the operation returns, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the functional sentence is easy to parse. However, the first two sentence fragments ('Catalog entry' and 'Runs in your Kuudo deployment, not here') are tangential and take up a third of the text without adding tool-selection value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and no declared parameters, the description is incomplete. It leaves unresolved what input identifies the order, what confirmation statuses are valid, and what the caller receives in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The declared schema is empty but allows additionalProperties, so an agent has no reliable field names or types from the schema. The description mentions a 'specified order' but never explains how to specify it or what confirmation values are accepted, making invocation under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Updates the shipment confirmation status for a specified order.' It is less than 5 because the opener 'Catalog entry' and 'Runs in your Kuudo deployment, not here' muddy the purpose and it does not differentiate from Orders_updateShipmentStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool instead of nearby order/shipment tools such as Orders_updateShipmentStatus or the Shipping_* confirm/shipment operations. The only contextual note, 'Runs in your Kuudo deployment, not here,' gives environment information but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals mutation via 'Update' and mentions the Kuudo deployment context, but it does not describe permissions, reversibility, side effects, or idempotency. This is insufficient for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and skimmable, with no redundant expansion. However, the opening 'Catalog entry' is non-operational metadata, and the actual action is delayed to the second sentence. It could have been more effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an empty parameter schema, the description leaves critical gaps: how to specify the order, what status values are valid, return behavior, and side effects. The deployment note is useful but does not make up for the missing operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and only allows additionalProperties, so the description needed to name and format how to specify the order and shipment status. It only says 'an order that you specify,' which conveys intent but not parameter names, types, or allowed values. An agent cannot reliably construct the invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource: 'Update the shipment status for an order.' This communicates the core operation. However, it does not distinguish this tool from sibling tools like Orders_confirmShipment or Shipping_cancelShipment, which could overlap in an agent's decision space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus the many siblings. No alternatives, exclusions, or prerequisites are mentioned, so an agent cannot determine whether this is the right tool for a given shipment-status task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool cancels a report and adds the environment note; it does not disclose whether cancellation is irreversible or idempotent, whether the report must be in a cancellable state, what authorization is needed, or what response/error behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no verbose filler, but it is not front-loaded: the actual purpose sentence appears after the meta label 'Catalog entry' and the environment caveat. 'Catalog entry' reads as label noise rather than actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancel operation with no annotations, no parameter schema, and no output schema, important details are missing: how to specify the report, what a successful cancellation returns, and what side effects or constraints apply. The 'Runs in your Kuudo deployment, not here' line adds some context, but the definition remains skeletal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty except for additionalProperties:true, yet the description says 'the report that you specify,' implying an argument while never naming or formatting it. This leaves an agent unable to construct a correct invocation and does not compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence, 'Cancels the report that you specify,' gives a clear verb and resource, and it is distinguishable from the sibling cancelReportSchedule because it targets a report rather than a schedule. However, the description does not name what 'the report' is or how it is identified, and the first two sentences focus on catalog/environment context rather than purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as Reports_cancelReportSchedule or Reports_cancelFeed. The caveat 'Runs in your Kuudo deployment, not here' is environmental context, not selection guidance, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool runs in the Kuudo deployment rather than locally, which is useful context, but it does not state whether the operation is read-only, what details are returned, how filtering behaves, or what happens if no filter query is supplied. The promised 'filter query' is referenced but never defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the deployment caveat, but 'Catalog entry' is a vague phrase that adds little value. The three sentences are compact, but one sentence is mostly non-informative meta-commentary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no parameters defined, the description is too incomplete. It does not explain the filter query format, supported fields, return payload, or relationship to the closely named Services_getServiceJobByServiceJobId. The deployment note is helpful but does not make the tool safely callable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and permits additional properties, while the description refers to a 'specified filter query' without explaining its expected shape, keys, or format. Because there are no schema-defined parameters, the description needed to compensate, but it provides only a vague reference to a filter query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Gets service job details for the specified filter query.' This distinguishes it from Services_getServiceJobByServiceJobId, which retrieves by a single job ID. The 'Catalog entry' and deployment phrasing slightly muddy the statement, but the core purpose is identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as Services_getServiceJobByServiceJobId. It mentions that the tool 'runs in your Kuudo deployment, not here,' which is a useful contextual constraint, but it does not explain when a filter-query lookup is appropriate or how it differs from other service-job tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose that the tool is a 'catalog entry' and runs in 'your Kuudo deployment, not here,' which is useful but incomplete. It does not mention auth, return behavior, errors, or whether invoking it locally is expected to fail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short fragments and contains little filler. However, the ordering is not front-loaded for clarity—'Catalog entry' and 'Runs in your Kuudo deployment' precede the core action—and 'Catalog entry' adds little explanatory value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description leaves major gaps: it never explains what a successful response contains, how rates are scoped, or why the tool is only a catalog entry. An agent lacks the information to decide whether to invoke this tool or rely on Shipping_getRates. Minimal complexity does not compensate for this missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and schema-description coverage is 100%, so there are no parameters for the description to document. The 0-parameter baseline of 4 applies because no parameter semantics are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The only action statement is 'Get service rates,' which largely restates the tool name and is broad. The preceding labels 'Catalog entry' and 'Runs in your Kuudo deployment, not here' make it unclear whether this tool is actually callable and what its exact scope is. It does not differentiate from the sibling Shipping_getRates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instruction, and no alternative is named such as Shipping_getRates. 'Runs in your Kuudo deployment, not here' hints at an execution-location constraint but leaves the agent to infer that this legacy tool may not be available in the current environment. This is minimal implied guidance at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only adds the deployment-location note and states the unlink action. It does not disclose whether unlinking is destructive, requires special permissions, or has side effects on existing shipments or labels. For a mutation tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two sentences, it is short and mostly to the point. However, 'Catalog entry.' is cryptic and the ungrammatical 'This API Unlink' reads as template-generated. The deployment note is useful but could be integrated more cleanly with the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains where the code runs but omits how to target the carrier account, expected outcomes, and any prerequisites or side effects. No output schema exists, so none of that context is provided elsewhere. An agent selecting between Shipping_linkCarrierAccount and this tool would not have enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero properties but allows additionalProperties, so there is no structured parameter information. The description references a 'specified carrier account' without indicating how the account identifier should be supplied, leaving the agent guessing. This is a case where the description fails to compensate for the absent parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Unlink' with the resource 'carrier account' and target 'merchant', making the operation clear. The 'Catalog entry' and deployment note add context without obscuring the action. It does not explicitly contrast with Shipping_linkCarrierAccount, but the inverse relation is obvious from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is that the operation runs in the Kuudo deployment and not in the current environment. There are no conditions for when to use this over Shipping_linkCarrierAccount or other shipping tools, and no exclusions. An agent has to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects and constraints. It does disclose that this sends a solicitation and runs in a different deployment, but it omits whether there are ordering or eligibility restrictions, authentication requirements, repeated-solicitation rules, or outcome details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the core action is in the second sentence, but the first sentence 'Catalog entry' adds little functional value and the 'not here' phrasing is confusingly terse. It is concise but not optimally front-loaded or clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unannotated, side-effect-producing tool with no output schema, the description is incomplete. It does not specify required order parameters, preconditions, return behavior, or when this solicitation tool should be preferred over its sibling, leaving an agent without enough information to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties, yet the description refers to 'the specified order' without naming a parameter or format. AdditionalProperties=true hints that extra fields are allowed, but the agent is left without the orderId field name or any other required input, so the description fails to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: sending a solicitation to a buyer for seller feedback and a product review for an order. This clearly distinguishes it from the sibling Solicitations_getSolicitationActionsForOrder, which retrieves actions rather than sending them. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' adds ambiguity about whether this tool is directly callable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of the related Solicitations_getSolicitationActionsForOrder read tool. 'Runs in your Kuudo deployment, not here' provides deployment context but not usage decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects and runtime behavior; it only says 'Create', which implies mutation but gives no detail on permissions, idempotency, or consequences. The 'Runs in your Kuudo deployment' clause is a hint about execution context but is too opaque to count as transparent disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 13 words it is terse, but the main action is buried after two unclear clauses ('Catalog entry', 'Runs in your Kuudo deployment'). No sentence is expanded wastefully, yet the ambiguity of the first two phrases prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, an empty input schema, and no mention of required fields or return values, the description is far from complete for a create operation. The single clear clause cannot compensate for the missing invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but permits additionalProperties, so there are no documented parameters and no description-level field guidance. An agent invoking this create operation is left without any idea what body or fields to supply. This is a serious gap despite the 0-parameter count, because a 'new supply source' necessarily requires input data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ends with the explicit action 'Create a new supply source', which is a clear verb+resource statement and distinguishes this operation from sibling tools like update, archive, and get. The opening 'Catalog entry' and environment clause are ambiguous, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use creation versus update, archive, or status operations, nor are any prerequisites or preconditions stated. The only extra context is the deployment location, which does not help usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that execution happens in a Kuudo deployment rather than locally, which is useful, but it does not describe return values, authentication needs, error behavior, or how the shipment is identified. The word 'retrieve' implies read-only, but the description leaves major behavioral unknowns unresolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains only three sentences, each providing some context: catalog status, deployment location, and the operation. It is not front-loaded with the action, but it is economical and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an empty input schema, the description is not complete enough for an agent to invoke the tool correctly. It provides a deployment hint but omits the shipment identifier mechanism and expected response, leaving a significant gap between the stated operation and practical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties but allows additionalProperties. The description says 'for the shipment you specify,' implying a shipment identifier parameter, yet no parameter name, type, or format is documented. With 0 parameters, the description should compensate, but it does not explain how to specify the shipment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Retrieve invoices for the shipment you specify.' This makes the core operation understandable. However, it does not differentiate this tool from the sibling ExternalFulfillmentShipments_generateInvoice, and the 'Catalog entry... not here' framing adds ambiguity about whether the tool is actually invocable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a deployment caveat ('Runs in your Kuudo deployment, not here') but no guidance on when to choose this tool over alternatives such as ExternalFulfillmentShipments_generateInvoice or ExternalFulfillmentShipments_getShipment. There are no conditions, prerequisites, or explicit exclusion statements to help an agent select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool executes in a separate Kuundo deployment, which is useful, but it leaves out expected behavior such as return format, pagination, authentication needs, or side effects. The agent is left guessing what will happen after invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no redundant filler beyond the 'Catalog entry' phrase. The deployment context is front-loaded and the functional statement is direct. It could be criticized for being terse, but as far as conciseness, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations, no output schema, and an effectively empty input schema, so the description needed to compensate with a complete operational picture. It does not: parameter names, return shape, error conditions, and relationship to sibling finance tools are all missing. An agent cannot reliably select or invoke this tool based on this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, and the description only says 'for the given parameters' without naming or explaining any parameter. Since there is no schema property documentation, the description was the only chance to convey parameter meaning, and it fails to do so. An agent cannot know what inputs are valid or required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns transactions for the given parameters.' This provides a specific verb ('Returns') and resource ('transactions'). However, it does not differentiate this from numerous sibling tools that also list financial data, such as FinancesV0_listFinancialEvents or SellerWallet_listAccountTransactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool over alternatives. It mentions that it 'Runs in your Kuundo deployment, not here,' which hints at a deployment context, but it does not state the conditions for selecting this tool, prerequisites, or exclusions relative to similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns financial events, but it does not mention whether the operation is read-only, whether pagination applies, what authentication or prerequisites are needed, or what the environment note ('not here') means for execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and mostly free of filler. The 'Catalog entry' and 'Runs in your Kuudo deployment, not here' phrases may add relevant context, though their exact meaning is unclear. Overall, it is appropriately short for the limited information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and no parameter schema, the description needs to provide more operational context. It omits important details such as date range format, pagination behavior, response shape, and how this tool relates to the other financial-event listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, yet the description refers to a 'specified data range' without revealing how that range is passed. Since additionalProperties is true, the agent has no reliable parameter names or formats. This mismatch between description and schema undermines correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Returns financial events') and the resource ('financial events') and implies a date-range scoping that distinguishes it from the ByGroupId and ByOrderId sibling tools. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' introduces ambiguity about whether the tool is actually invokable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives almost no guidance on when to choose this tool over siblings like FinancesV0_listFinancialEventsByGroupId or FinancesV0_listFinancialEventsByOrderId. The note 'Runs in your Kuudo deployment, not here' hints at environment constraints but does not say what contexts warrant using this tool or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says the tool 'generates' options and runs in a different deployment. It does not disclose whether the operation is read-only, what side effects it may have, or what the response looks like. 'Catalog entry' adds meta-context but not actionable behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point. 'Catalog entry.' is a genre label rather than pure filler, and the actual purpose is stated clearly in one sentence. However, the placement of the environment note before the purpose slightly hurts scannability, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description is the only source of operational context. It explains the basic action but omits required input identifiers, return format, and how this step relates to the list/confirm delivery-window siblings. This is too incomplete for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with 'additionalProperties: true,' and the description refers to 'a given shipment' without specifying how to identify that shipment in the payload. Although the schema defines zero parameters, the natural reading implies at least a shipment identifier is needed, which is left undocumented. The description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action: 'Generates available delivery window options for a given shipment.' This is a specific verb and resource. However, it is prefaced by 'Catalog entry. Runs in your Kuudo deployment, not here,' which adds odd meta-context, and it does not explicitly distinguish the tool from the sibling 'listDeliveryWindowOptions.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus 'listDeliveryWindowOptions' or 'confirmDeliveryWindowOptions.' The note about running in a Kuudo deployment is a deployment constraint, not a selection criterion. The agent cannot infer prerequisites or workflow context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only states that a cancellation request is made. It does not disclose whether cancellation is guaranteed, what happens if the order is already in transit, whether the operation is idempotent, or any error/side-effect profile; the 'Runs in your Kuudo deployment, not here' remark also creates ambiguity about the actual execution environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence is filler that muddles rather than helps ('Catalog entry. Runs in your Kuudo deployment, not here.'). The useful cancellation sentence is placed after irrelevant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-like operation with no annotations and no output schema, the description is incomplete: it omits required input identifying details, expected request shape, state prerequisites, and failure behavior. The 'not here' phrasing also leaves it unclear whether this entry is actually invocable by the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes zero properties, so the description's mention of a 'specified order identifier' is the only parameter information available and is a useful signal. However, it does not name the parameter or its format, and with additionalProperties true an agent still cannot reliably know how to pass the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The second sentence identifies a specific action ('Requests that Amazon stop attempting to fulfill') and a clear resource ('the fulfillment order indicated by the specified order identifier'), which makes the cancel intent unambiguous. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here.' adds noise and does not contribute to purpose clarity, and there is no explicit comparison to sibling FulfillmentOutbound tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as updateFulfillmentOrder or getFulfillmentOrder, and no mention of prerequisites like whether the order must still be unshipped. The only hint is the verb 'cancel' and phrase 'stop attempting', which leaves usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention a batch limit of 40 and the deployment context, but it does not disclose whether the operation is read-only, what side effects may occur, what permissions are needed, or how failures in a batch are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not verbose, but the first sentence 'Catalog entry.' is essentially filler. Front-loading the deployment caveat before the behavior also buries the most actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an empty input schema and no output schema, the description needs to explain how to construct the batch request and what kind of responses to expect. It only says 'up to 40 requests defined in the request body' without describing request format, domain semantics, or response structure, leaving an agent under-equipped to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty except for additionalProperties, so the description's mention of a request body containing up to 40 batch requests is the only real parameter guidance. This adds meaningful context beyond the schema, though it still does not define the structure of an individual request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool returns a set of responses for a batched list of up to 40 requests, which gives a general sense of a batch operation. However, it never explains what the requests or responses are about beyond the tool name, and the opening 'Catalog entry' is uninformative. It also does not distinguish this batch tool from sibling batch tools like ProductPricing_getItemOffersBatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage-oriented signal is the warning that it runs in the user's Kuudo deployment rather than in the current environment. There is no guidance on when to choose this tool over alternatives, no exclusions, and no explanation of the intended request-body shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does reveal that the tool runs in the Kuudo deployment rather than locally, which is useful, but it omits side effects, prerequisites, return behavior, or whether creation is asynchronous. 'Catalog entry' further muddies the behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point. However, the opening 'Catalog entry' sentence is unhelpful filler and the most important information ('Creates a report') is placed last rather than front-loaded. The sentence about running in Kuudo is useful but the overall structure is suboptimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an open-ended additionalProperties schema, the description is incomplete. It does not explain what a report is, what parameters might be passed, what the return value is, or how the agent should interact with a tool that runs in a remote deployment. An agent would struggle to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, so there are no parameter descriptions to provide. The baseline for zero parameters is 4. The description does not need to explain parameter meaning when none exist; the additionalProperties: true field is structured information, not something the description must repeat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Creates a report'), which is clear enough on its own. However, the phrase 'Catalog entry' is cryptic and adds no purpose, and the description does not distinguish this from the closely related Reports_createReportSchedule sibling. The purpose is minimally viable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like Reports_createReportSchedule or Reports_getReport. The statement 'Runs in your Kuudo deployment, not here' hints at an environmental context but does not help an agent decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only names the operation and deployment location. It does not disclose whether completion is irreversible, what status transitions occur, whether authorization/state requirements exist, or what happens on success/failure. 'Catalog entry' adds no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its structure is poor: the purpose is placed last, after two sentence fragments ('Catalog entry.' and 'Runs in your Kuudo deployment, not here.'). The 'Catalog entry' fragment contributes no operational information. It should lead with the completion action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a zero-parameter tool, an agent needs to know the expected input location, side effects, and execution prerequisites; none are provided. The 'runs in your Kuudo deployment, not here' hint is useful but unexplained. There is no output schema or annotation to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes no properties but allows additionalProperties, and the description only says a 'service job identifier specified' must be used. It does not give the parameter name, location, or format, so an agent cannot reliably construct the call from the description alone. Some credit is given for indicating an identifier is required, but it is under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The third sentence provides a specific verb and resource: it 'Completes the service job indicated by the service job identifier specified,' which distinguishes it from get/cancel siblings. However the opening 'Catalog entry. Runs in your Kuudo deployment, not here.' obscures the primary purpose and reads more like metadata than an operational statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over cancelServiceJobByServiceJobId or getServiceJobByServiceJobId. The only context is 'Runs in your Kuudo deployment, not here,' which says where execution happens, not when it is appropriate. An agent would have to infer selection solely from the verb 'completes.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool 'gets' slots and runs in a Kuudo deployment; it does not explain output, errors, authentication, side effects, or what 'service context' means. The deployment note is a useful context signal but far too thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but 'Catalog entry' is filler that adds no actionable information. The more useful 'Runs in your Kuudo deployment, not here' caveat precedes the actual function statement, which is slightly awkward. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and a vague description, so the description must explain what the agent will receive and how to invoke the tool correctly. It fails to specify how service context is provided, what appointment slots are returned, or how this relates to sibling tools. This is inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters, so the description is not required to document parameter details. The mention of 'service context' hints at an implicit input, but additionalProperties: true leaves that open. With 100% schema coverage and no parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action and resource ('Gets appointment slots'), so an agent can roughly tell what the tool does. However, 'as per the service context specified' is vague, and the description does not distinguish this from the closely related sibling Services_getAppointmmentSlotsByJobId or the slot-capacity tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The sentence 'Runs in your Kuudo deployment, not here' is an environmental caveat, not usage guidance. The sibling list contains several similarly named slot-related tools, but none are referenced or disambiguated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that this is a catalog entry and runs in the user's Kuudo deployment rather than locally, which is useful. However, it does not describe side effects, permissions, reversibility, or what happens to the existing appointment, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler. Both sentences add information, and the key scoping detail about the service job identifier is included. It is slightly cryptic ('Catalog entry.'), but there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an effectively empty input schema, an agent needs far more information to invoke it correctly. The Kuudo deployment note is valuable context, but the missing parameter definition and lack of behavioral detail make the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists zero properties, yet the tool name and description clearly require a service job identifier. The description mentions 'the service job identifier specified' but does not specify the parameter name, type, or format, and additionalProperties:true offers no meaningful structure. The description needed to compensate for the empty schema and only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Reschedules an appointment') and identifies the target resource ('the service job indicated by the service job identifier'). It is clear enough to distinguish this as a rescheduling operation, though it does not explicitly contrast it with the closely related addAppointmentForServiceJobByServiceJobId sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as addAppointmentForServiceJobByServiceJobId, cancelServiceJobByServiceJobId, or setAppointmentFulfillmentData. The only contextual hint is that the operation runs in a Kuudo deployment rather than here, which is an execution-location caveat, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that updates appointment fulfillment data for a jobID and appointmentID, but it does not explain permissions, side effects, reversibility, or what 'fulfillment data' includes. The phrase 'Runs in your Kuudo deployment, not here' hints at a non-local execution environment but is too cryptic to be actionable and could mislead an agent about how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the phrasing is awkward and partly ambiguous: 'Catalog entry' is unexplained metadata that does not contribute to invocation correctness, and 'Runs in your Kuudo deployment, not here' is cryptic. It does front-load the verb and resource, but it spends two short sentences without conveying actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the Services domain and a mutation operation with no annotations, no output schema, and a schema with no defined properties, the description is insufficient. An agent cannot reliably determine what data is required, how to reference the job or appointment, what response to expect, or what conditions must be met, especially when compared with the many sibling appointment-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the schema and schema description coverage is 100%, so the baseline for parameter semantics is 4. The description mentions jobID and appointmentID as contextual identifiers, which adds a little semantic grounding even though they are not structured parameters. This is acceptable for a no-parameter schema, though the description could be clearer about how the IDs are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation (updates appointment fulfillment data) and identifies the key resources (jobID and appointmentID), but the function's purpose is somewhat vague since 'appointment fulfillment data' is not clearly scoped. It also does not distinguish it from other Services_* appointment tools such as assignAppointmentResources or updateReservation, and the odd note about 'Runs in your Kuudo deployment, not here' is confusing and does not clarify the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. It does not mention prerequisites, relationship to other appointment operations, or when it should be preferred over sibling tools. The only context is an unusual note that it runs in a 'Kuudo deployment' rather than here, which raises more questions than it answers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful behavioral note about running in a Kuudo deployment, but it fails to disclose side effects, reversibility, permissions, asynchronous behavior, or what happens after submission. For a consequential submit action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but the opening 'Catalog entry' adds little value and the overall text is under-specified. It is compact but not fully effective because important operational details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that submits content for review, approval, and publishing, the description lacks important context: prerequisites, required document references, response/status behavior, and clarification of what 'Runs in your Kuudo deployment, not here' means for invocation. With no annotations or output schema, these gaps are significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so there are no parameter definitions for the description to augment. The description identifies the affected object as an A+ Content document, but it does not compensate for the schema's lack of information about required identifiers or request body shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action (submits), the resource (an A+ Content document), and the workflow stage (review, approval, and publishing). It is specific enough for an agent to understand what the tool does, though it does not explicitly differentiate it from sibling AplusContent submission operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives, nor any prerequisites or exclusion criteria. The phrase 'Runs in your Kuudo deployment, not here' is an environment hint rather than actionable usage guidance, so an agent cannot determine when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and 'Returns information' implies a read-only operation. It adds a useful deployment caveat about running in Kuudo rather than here, but it does not mention error conditions, authentication expectations, or what happens when a package is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of obvious padding, but the opening 'Catalog entry' is an unhelpful label and the deployment sentence is ambiguous. The return-content sentence is useful, but the overall structure could be tighter and more actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain both invocation and expected results. It covers the return contents at a high level but omits the required input identifier, clear execution context, and any status or error behavior, leaving an agent under-equipped to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented properties and allows arbitrary additional properties, yet the description never explains how to identify which package to retrieve. A getter for a package needs some package identifier or selection context, and neither the schema nor the description provides it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as returning information about a package and enumerates the returned aspects: dimensions, weight, handover time slot, invoice, item, and status. It does not explicitly differentiate from sibling EasyShip tools, but the core function is specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related tools like EasyShip_createScheduledPackage or EasyShip_updateScheduledPackages. The note 'Runs in your Kuudo deployment, not here' hints at a deployment constraint, but it is not actionable guidance about when this call should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosure. It conveys a read-only list operation and a deployment-location detail, but it does not explain pagination, authentication, response contents, or what 'not here' actually means. The 'Catalog entry' label is undefined and adds confusion rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but not every sentence earns its place: 'Catalog entry' is unhelpful metadata, and 'Runs in your Kuudo deployment, not here' is cryptic. The core functional sentence is reasonably front-loaded and compact, but the surrounding filler reduces overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the sole source of context, yet it omits how to specify the status, what fields are returned, whether results are paginated, and what 'Kuudo deployment' means. For a list operation with an effectively empty schema, an agent cannot reliably construct a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, but the description says 'in the status you specify,' which implies a status filter without naming the parameter or accepted values. Because additionalProperties is true, an agent might try passing a status key, but nothing in the schema or description confirms how to do so. The description adds some meaning beyond the empty schema, but it leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get a list of shipments') and resource ('shipments created for the seller'), and it mentions filtering by status. This clearly distinguishes it from the singular sibling ExternalFulfillmentShipments_getShipment. The phrase 'Catalog entry' is ambiguous and slightly detracts from the otherwise clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many shipment-related siblings, nor any mention of alternatives, prerequisites, or exclusions. The only contextual hint is that it 'Runs in your Kuudo deployment, not here,' which is a runtime-location note, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It communicates that deletion is being requested, but it does not explain whether deletion is immediate or asynchronous, what permissions are needed, whether the action is reversible, or what side effects occur. The phrase 'Runs in your Kuudo deployment, not here' is ambiguous and does not meaningfully clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description wastes its opening sentences on 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' which do not help an agent invoke the tool. The meaningful action statement is buried at the end, and 'sandbox environment' is unnecessarily repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and no documented parameters, the description is far too thin. It does not explain how the target item is identified, what the request/response shape is, under what conditions deletion is allowed, or what the agent should expect after invocation. This is not enough for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero parameters and has 100% coverage, so the description is not required to explain any parameter details. Baseline for 0-parameter tools is 4. However, because additionalProperties is true, the actual input mechanism is unclear, and the description does not compensate for that ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Deletes an item') and a specific resource ('Sandbox Inventory in the sandbox environment'), so the primary purpose is recognizable. However, it does not differentiate this tool from sibling FBA Inventory tools like FbaInventory_createInventoryItem or FbaInventory_addInventory, and the opening 'Catalog entry' is confusing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Mentioning 'sandbox environment' provides some situational context, but it never tells the agent which conditions should trigger this call or what distinguishes it from related inventory operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so this description must carry the behavioral disclosure burden. It only states that the tool creates a feed and runs in a Kuudo deployment; it does not mention side effects, required permissions, asynchronous behavior, failure modes, or what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short, so there is no verbosity problem. However, 'Catalog entry' reads as filler and the core action is placed last rather than front-loaded, so the structure is mediocre.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a permissive empty input schema, the description is not complete enough for correct invocation. An agent would not know what a successful create-feed call returns, what parameters to send, or what constraints/errors apply; the one deployment sentence does not fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema nominally has no properties but sets additionalProperties=true, which leaves the input surface undocumented. The description adds no parameter guidance such as what feed-type or content information is needed, so the agent cannot determine what arguments to supply; the 100% coverage is only nominal because the property list is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Creates a feed' supplies a specific verb and resource, and the create action differentiates it from sibling tools like Feeds_getFeed, Feeds_cancelFeed, and Feeds_createFeedDocument. The opening 'Catalog entry' and deployment note add metadata rather than purpose detail, so it is clear but not maximally sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose this tool over an alternative or when not to use it. 'Runs in your Kuudo deployment, not here' describes execution location, not selection criteria, so the agent gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a read-style behavior via 'Returns' and adds an unexplained deployment qualifier, but it does not mention pagination, limits, required existence of the group, error behavior, or authentication needs. The 'Kuudo deployment, not here' phrase is ambiguous and could confuse more than clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Catalog entry' is unhelpful noise and the deployment sentence is ambiguous. The main functional statement appears last, so the structure does not front-load the purpose effectively. It is not bloated, but it is not optimally organized either.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose schema is empty and has no output schema or annotations, the description is too thin. It does not explain where the financial event group ID comes from, what the returned events look like, or what 'runs in your Kuudo deployment' means for invocation. This leaves important operational context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no documented properties, so the description adds conceptual meaning by referencing the financial event group. However, it never names or formats the groupId parameter that the tool name implies, leaving the agent guessing how to specify the group, especially with additionalProperties: true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns all financial events for the specified financial event group.' This distinguishes it from listFinancialEventGroups and partially from listFinancialEventsByOrderId, though it does not explicitly contrast with siblings and begins with the vague 'Catalog entry' phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. It does not mention alternatives such as listFinancialEvents or listFinancialEventsByOrderId, nor prerequisites like needing a group ID from listFinancialEventGroups. The phrase 'for the specified financial event group' weakly implies context but offers no practical routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It vaguely notes 'Runs in your Kuudo deployment, not here' and 'Catalog entry,' but does not clarify whether the tool is actually callable, whether it is read-only, or what constraints apply. The 'not here' remark creates ambiguity rather than resolving it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and somewhat front-loaded, but the opening fragments 'Catalog entry. Runs in your Kuudo deployment, not here' are cryptic and consume space without adding clear operational value. The substantive statement is only the final clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that needs an order reference, lacks an output schema, and has no annotations, the description is incomplete: no parameter guidance, no return details, and no pagination or scoping information. The only useful context is that it returns financial events per order.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description's mention of a 'specified order' hints that a parameter should exist but does not name or format it. With additionalProperties allowed, the agent is left to infer the orderId parameter from the tool name rather than from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Returns all financial events for the specified order.' The byOrderId scope distinguishes it from group-level or transaction-list siblings, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to select this tool over the many sibling financial-event tools, and there are no exclusions or prerequisites. The only implied usage is for retrieving financial events tied to a specific order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only partially does so. It discloses that the tool 'Runs in your Kuudo deployment, not here,' which is useful context, and 'Retrieve' implies a read-like operation. However, it does not state side effects, prerequisites, error behavior, or what 'can only be confirmed…' means, and the sentence is cut off.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: it opens with the filler phrase 'Catalog entry,' then an environment caveat, and only then the core purpose. The main sentence is incomplete, ending with an ellipsis. Every sentence should earn its place, and these do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description should clearly state what the returned preview contains, how it relates to the generate/list/confirm sibling operations, and what 'can only be confirmed' refers to. The description gives some return-content context but is truncated and lacks workflow or prerequisite information. Without an output schema or annotations, this leaves a significant gap for an agent deciding whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented parameters and 100% schema coverage, so the baseline for parameter semantics is 4. The description does not need to explain parameters that are not present, and it adds some context about what the tool returns. The 'additionalProperties: true' schema is ambiguous, but with zero required parameters this is not a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Retrieve a shipment content update preview' and indicates it summarizes shipment content changes plus transportation cost implications. This distinguishes it from sibling operations like list/generate/confirm previews, though the leading 'Catalog entry' and deployment caveat add noise. The truncated final clause prevents it from being fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as FulfillmentInbound_generateShipmentContentUpdatePreviews, FulfillmentInbound_listShipmentContentUpdatePreviews, or FulfillmentInbound_confirmShipmentContentUpdatePreview. 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not explain the intended workflow or alternatives. The agent is left to infer sequencing from the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, but it only reveals that the result is paginated and that execution is remote ('Kuudo deployment'). It does not state read-only semantics, required shipping/shipment context, auth, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it leads with the unhelpful phrase 'Catalog entry' before reaching the meaningful statement. The environment note and the purpose sentence could be combined more economically and the structure is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking annotations, an output schema, and any parameter definitions, this description is not enough to invoke the tool correctly. It does mention pagination and the Kuudo deployment, but omits how to target the shipment and what the response contains, so completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and the description adds no explicit parameter names, so it cannot document what arguments are accepted. 'In a shipment' implies a shipment identifier is needed, but neither schema nor description specifies how to provide it, so the description adds only partial semantic context. Given 0 formal params, this is near baseline but leaves the implicit shipment scope unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence identifies a specific verb ('list'), resource ('item packages in a shipment'), and pagination behavior, which helps distinguish it from sibling tools like listShipmentBoxes or listShipmentPallets. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' introduce noise and make the exact scope less crisp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over the many sibling fulfillment-inbound list operations (e.g., listShipmentBoxes, listInboundPlanItems) or what preconditions exist. 'Runs in your Kuudo deployment, not here' is an environment note, not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does reveal that the operation is a request executed in a Kuudo deployment and involves shipping items, but it does not mention side effects, prerequisites, idempotency, or that a fulfillment order record will be created in the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the opening 'Catalog entry' sentence adds little value and the core purpose is placed last. It is concise but not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Creating a fulfillment order is a complex operation with significant required data, yet the description omits payload requirements and any response/return information. The deployment note is useful, but an agent still lacks enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero named parameters and additionalProperties is true, so there is little for the description to add over the schema. However, the permissive additionalProperties are not clarified, and no hints are given about the fulfillment-order fields an agent would need to supply, leaving payload construction ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action: requesting Amazon to ship items from the seller's inventory in Amazon's fulfillment network to a destination address. This clearly identifies it as a create-outbound-fulfillment-order operation, though it does not explicitly contrast with sibling tools like updateFulfillmentOrder or createFulfillmentReturn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus related FulfillmentOutbound tools or other shipping tools. The only contextual line, 'Runs in your Kuudo deployment, not here,' concerns environment/deployment rather than when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add one useful trait (execution in a remote Kuudo deployment), but this is cryptic and does not explain implications such as whether the tool is directly callable, whether it is read-only, or what error/edge-case behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' is noise and adds no useful information. The core message is in the second sentence, which is clear but not front-loaded with the most actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description is the only source of context. It only mentions that it returns a status, without explaining what input is needed (none is specified), what the output looks like, or how the remote execution affects invocation. An agent would be unsure how to call it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and allows additional properties, which is unusual for a status lookup that logically needs a request identifier. The description does not clarify what identifies the invoice generation request or whether parameters are accepted, so it adds no value beyond the (empty) schema. The 0-parameter baseline is partially offset by this ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('status of an invoice generation request'), which clearly distinguishes it from sibling tools like Invoices_getGovernmentInvoiceDocument and Invoices_createGovernmentInvoice. However, the opening phrase 'Catalog entry' introduces ambiguity about whether this is an actual invocable tool or just a metadata placeholder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as using it after calling Invoices_createGovernmentInvoice or for polling status. The deployment note ('Runs in your Kuudo deployment, not here') gives some context but does not explain the intended workflow or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own. It indicates a remote create/full-update operation, but it does not explain that a full update may replace existing data, that authorization or prerequisites are needed, or what side effects occur beyond mutation. 'Not here' is cryptic and not actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but 'Catalog entry.' and 'Runs in your Kuudo deployment, not here.' are ambiguous and provide little clear value. The final clause carries the useful meaning, so brevity is achieved at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating API operation with no annotations, no output schema, and an empty input schema. The description does not identify required identifiers or request body, response shape, error behavior, or destructive implications, leaving an agent without enough information to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero defined properties with additionalProperties allowed, so schema coverage is nominally 100%, which sets the baseline at 3. However, the description adds no parameter meaning: it does not mention sellerId, sku, marketplaceIds, or the item body that a PUT listings item operation normally requires.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Creates a new or fully-updates an existing listings item for a selling partner.' This is a specific verb and resource, and 'fully-updates' hints at PUT semantics compared with partial-patch tools, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as ListingsItems_patchListingsItem for partial updates or ListingsItems_deleteListingsItem for removal. The line 'Runs in your Kuudo deployment, not here' is an environment note rather than a concrete selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that the tool cancels a shipment. It does not mention irreversibility, downstream side effects, authorization requirements, or what a successful or failed cancellation returns. The deployment-related sentence is ambiguous and does not clarify the actual runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The action sentence is economical, but 'Catalog entry' is filler and 'Runs in your Kuudo deployment, not here' is vague rather than informative. The useful cancellation statement is not front-loaded because two low-value clauses precede it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive cancellation tool with no annotations, no output schema, and an empty input schema, this description is under-specified. It fails to name the required identifier, does not describe expected status or error behavior, and does not distinguish itself from other cancelShipment siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, so the description's reference to a 'specified shipment identifier' is the only semantic hint about what the operation needs. However, the description never names the exact property, type, or format, leaving the agent to guess whether to send shipmentId, shipmentIdentifier, or some other key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Cancel the shipment indicated by the specified shipment identifier' uses a clear verb and resource, so the intended action is understandable. However, it does not differentiate this tool from sibling cancel-shipment tools such as Shipping_cancelShipment or ShippingLegacy_cancelShipment, and the prefatory 'Catalog entry' adds no purpose information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the other cancel-shipment alternatives, and no preconditions or conditions for cancellation are provided. 'Runs in your Kuudo deployment, not here' hints at an execution context but does not help an agent choose between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It only mentions that the tool runs in a Kuudo deployment and creates a shipment; it does not disclose side effects, required data, authorization, or whether this is truly executable here. The phrase 'Catalog entry' adds ambiguity about whether the tool actually performs an action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it opens with the ambiguous and redundant 'Catalog entry' and deployment note before stating the actual operation. The operative sentence is generic and does not add meaningful structure or actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style tool with no output schema and no annotations, the description should explain what information is needed, what side effects occur, and how this relates to the other MerchantFulfillment operations. None of that is present, leaving the definition incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares no properties but allows additional properties, so the expected payload is completely unspecified. The description adds no field names, formats, or required shipment details beyond the vague phrase 'with the information provided.' This makes it difficult for an agent to construct a correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Create a shipment with the information provided.' It is not a tautology and the core purpose is understandable. However, it does not differentiate this tool from the many sibling shipping creation/purchase tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Shipping_purchaseShipment, ShippingLegacy_createShipment, or MerchantFulfillment_getEligibleShipmentServices. The phrase 'Runs in your Kuudo deployment, not here' hints at environmental constraints but does not clearly state when the tool should or should not be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it adds little. It conveys only that the tool runs elsewhere and returns an address; it does not state whether restricted data access is required (likely for shipping addresses), error behavior, or that the operation is read-only. The 'Runs in your Kuudo deployment, not here' phrasing is ambiguous and could mislead an agent about whether the tool is actually callable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the core action is one sentence, but roughly half of it is filler: 'Catalog entry.' and 'Runs in your Kuudo deployment, not here.' These phrases do not earn their place and add confusion rather than value. A tighter description would drop the preamble and focus on the resource and input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the agent needs the description to compensate, but it does not. Critical information is missing: how to specify the order (parameter name/format), whether a restricted data token is required, and what the returned address structure looks like. The deployment note is not actionable for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters (only additionalProperties: true), so the baseline is 4. The phrase 'the order that you specify' adds the useful hint that an order identifier is required, but it does not name or format that parameter, leaving the agent to guess what input to send. Some meaning is added beyond the empty schema, but not enough to reliably construct a call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns the shipping address for the order that you specify.' This distinguishes it from nearby siblings like Orders_getOrderItems and Orders_getOrderBuyerInfo. However, the preamble 'Catalog entry. Runs in your Kuudo deployment, not here' is confusing and somewhat muddies the otherwise clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as Orders_getOrder, Orders_getOrderBuyerInfo, or the many Shipping_* tools. The only contextual note ('Runs in your Kuudo deployment, not here') is about deployment, not selection criteria, and does not help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It clarifies that the operation is a read ('Returns') and that execution happens in the Kuudo deployment, not locally. But it omits any mention of required permissions, output shape, or data scope, so the disclosure is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first phrase 'Catalog entry' is noise and the purpose statement comes last. All useful information could be condensed into one clearer statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description needs to explain what 'detailed order item information' includes and how to specify the order. It does neither, and it fails to address likely concerns such as pagination, restricted data, or relation to related Orders_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes zero properties, yet the description says 'for the order that you specify.' It never names the parameter (e.g., order ID) nor explains where the order comes from, so an agent cannot determine how to supply the required selection. This undercuts the 0-param baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Returns detailed order item information') and scope ('for the order that you specify'), so an agent can identify the resource it targets. However, it does not distinguish this from sibling tools like Orders_getOrderItemsBuyerInfo, and the opening 'Catalog entry' adds no semantic value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives such as Orders_getOrder or Orders_getOrderItemsBuyerInfo. The only extra context is environmental ('Runs in your Kuudo deployment, not here'), which is not a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention that the tool 'runs in your Kuudo deployment, not here,' which is a useful environmental clue, but it does not disclose pagination, result limits, required authorization, read-only guarantees, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the opening 'Catalog entry.' adds little value and the environmental note is placed before the actual functional statement. The main behavior is stated efficiently, but the overall structure is slightly disjointed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no annotations, and an empty input schema, the description is under-specified. It does not explain the time period parameter format, response structure, pagination behavior, or how this relates to the other Orders and Ordersv2 tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared parameters, which normally warrants a baseline of 4. However, the description refers to 'the time period that you specify' without naming any parameters or formats, and the schema allows arbitrary additional properties, leaving the agent uncertain about what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns orders filtered by a created/updated time period, which gives a specific verb and resource. However, it does not explicitly distinguish this from sibling tools like Orders_getOrders or Ordersv2_getOrder, so it loses the last point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the many order-related sibling tools. It implies a time-range search use case but does not mention alternatives, exclusions, or conditions that would help an agent choose between Ordersv2_searchOrders and Orders_getOrders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, required context, and operational behavior, but it only says the schedule is cancelled. The phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are ambiguous and do not clarify whether cancellation is destructive, reversible, or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, but 'Catalog entry' is filler and 'Runs in your Kuudo deployment, not here' is vague context that is not clearly actionable. The core action appears only in the final sentence, so the content is not well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with no annotations and no output schema, the description should explain what identifier to pass, what a successful cancellation returns, and what effects it has. None of that is present, so an agent does not have enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero properties, so the description's 'that you specify' is the only hint that a schedule identifier must be supplied. It does not name the expected parameter or its format, and with additionalProperties set to true the agent is left unsure what input to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Cancels the report schedule that you specify' identifies a specific verb and resource, so an agent can see this acts on report schedules rather than on reports or shipments. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add confusion, and the description does not explicitly distinguish it from sibling tools like Reports_cancelReport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives such as Reports_getReportSchedule, Reports_getReportSchedules, or Reports_cancelReport. The only contextual clue, 'Runs in your Kuudo deployment, not here', speaks to execution location rather than usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states it 'runs in your Kuudo deployment, not here' and returns 'information required for retrieving' contents, without explaining auth needs, execution environment implications, return shape, or any side effects. The deployment remark is vague and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and scannable, but 'Catalog entry' is unhelpful filler, and 'Runs in your Kuudo deployment, not here' is ambiguous rather than informative. It earns points for brevity, not for tightly earned content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin for an agent to call it correctly. It does not explain how to use the returned information, what parameters or path variables might be required, or how this step fits into the broader report workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters, so there is nothing the description must clarify beyond the baseline. However, additionalProperties is true, and the description does not mention expected identifiers such as a report document ID, which could matter in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Returns the information required for retrieving a report document's contents' gives a recognizable verb-object-resource, but 'Catalog entry' and 'Runs in your Kuudo deployment, not here' muddy whether the tool is actually executable in this environment. It does not distinguish itself from Reports_getReport or Reports_getReports beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool, what prerequisites exist, or how it relates to siblings like Reports_getReport, Reports_getReports, or Reports_createReport. The description implies a document-fetching role but leaves the workflow entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions filter-based retrieval and deployment location, but omits whether this is read-only, pagination behavior, permissions required, or what 'report details' actually include. There is no contradiction, but disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but the opening 'Catalog entry.' is filler that does not earn its place. The useful information is delivered in two sentences, which is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Critical context is missing: no filter keys, no output shape, no indication of whether a list or a single report is returned, and no relationship to sibling report tools. Given no output schema and no annotations, the description is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties but allows additionalProperties true, so the agent has no structured parameter definitions. The description says 'filters that you specify' without enumerating or typing them, leaving the agent to guess valid filter names. Since there are no formal parameters, the description needed to compensate but only gestures at the concept of filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns report details for reports matching user-specified filters, identifying a list/search behavior with a specific verb and resource. The plural 'reports' and 'filters' imply bulk retrieval, but it does not explicitly differentiate from sibling Reports_getReport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of Reports_getReport, Reports_getReportDocument, or Reports_createReport. The only contextual note is about execution environment, which does not help an agent choose between similar report operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says the tool 'Returns report schedule details' and 'Runs in your Kuudo deployment, not here.' It does not state whether the operation is read-only, what permissions are needed, what errors may occur, or what the returned details contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the leading 'Catalog entry.' is an unexplained fragment that does not earn its place, and the meaningful behavior appears only in the final sentence. There is no real verbosity, yet the structure is not effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema, absent annotations, and missing output schema, the description leaves too much unspecified: how to identify the report schedule, what arguments are accepted, and what the returned details look like. The deployment caveat is useful but does not compensate for the lack of an actionable invocation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties, which sets a baseline of 4, and the description does add the important notion that a report schedule must be specified. However, it never says what parameter name or value to use, and the schema's additionalProperties:true leaves the invocation contract entirely open, so an agent still cannot confidently construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence states a specific verb and resource: 'Returns report schedule details for the report schedule that you specify.' This clearly communicates a focused read operation for a single schedule, though it does not explicitly distinguish itself from the sibling Reports_getReportSchedules, so the contrast is only inferable from the name and phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance about when to use this tool instead of alternatives, and it names no sibling tools or exclusions. The phrase 'that you specify' only implies a single-schedule use case but does not say how that differs from the plural getReportSchedules or other report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation by saying 'Returns aggregated order metrics,' but it does not clarify authentication needs, rate limits, side effects, output structure, or what 'not here' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is briefly worded, which is good, but the opening 'Catalog entry' sentence is meta and adds little value. The purpose sentence is front-loaded enough, but the overall structure could be tighter and more informative in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input schema details, no annotations, and no output schema, the description must do more heavy lifting. It leaves an agent without enough context to invoke the tool correctly, omitting required parameters, input format, and response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but allows additional properties, so the description's mention of interval, granularity, and buyer type adds some meaning. However, it does not provide actual parameter names, formats, allowed values, required fields, or mention likely critical inputs like marketplace IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Returns aggregated order metrics') and identifies key dimensions (interval, granularity, buyer type). The opening 'Catalog entry' phrase is tangential, but the core purpose is still clear enough to distinguish this from most siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives, no exclusions, and no mention of related tools. The only additional context, 'Runs in your Kuudo deployment, not here,' is about execution environment, not usage decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation runs outside the current environment and that it mutates state by adding an appointment, but it says nothing about side effects, required permissions, reversibility, error behavior, or response. This is insufficient for a mutating tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry' contributes little and the main action is not front-loaded. The 'runs in your Kuudo deployment, not here' caveat is useful, but the overall structure could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It omits how to supply the service job identifier, what other inputs are needed, what response to expect, and what errors or prerequisites exist. The external-deployment caveat is the only extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, so there is little to document, but the description references a 'service job identifier specified' without naming the parameter, its location, or its format. Given additionalProperties is true, the actual invocation shape remains ambiguous, so the description only partially compensates for the incomplete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Adds an appointment to the service job indicated by the service job identifier specified.' This identifies the verb, resource, and target sufficiently to distinguish it from siblings like rescheduleAppointmentForServiceJobByServiceJobId. The opening 'Catalog entry. Runs in your Kuudo deployment, not here' creates some ambiguity, but the core purpose remains understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Services_rescheduleAppointmentForServiceJobByServiceJobId or Services_getServiceJobs. The note about running in a Kuudo deployment is an environment constraint, not usage-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only adds an environment note and a vague output-format comparison ('similar to availability records'). It does not state side effects, permissions, invocation constraints, or whether this tool can actually be called, and 'Catalog entry' creates ambiguity rather than resolving it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is very short and mostly front-loaded with the environment and output notes. The 'Catalog entry' sentence adds little value and is potentially confusing, so it does not fully earn its place, but overall there is no verbose filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must provide enough context for an agent to understand inputs, outputs, and callability. It only offers a vague 'format similar to availability records' and an unclear execution-location note, leaving out important details such as whether this is a callable operation, what range it covers, and how it returns results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero documented properties and the description adds no parameter details, but with zero parameters the baseline is 4 and there is little to document. The description does not need to compensate because there are no parameters for it to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it 'provides capacity slots', which is a verb and resource, but frames the tool as a 'Catalog entry' that 'runs in your Kuudo deployment, not here' rather than as a directly callable operation. It does not distinguish itself from the sibling Services_getFixedSlotCapacity or Services_getAppointmentSlots, and the 'range' aspect is only inferable from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of alternative tools. The phrase 'not here' vaguely suggests the operation is not executed in the current environment, but it does not give an agent a usable criterion for selecting this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the operation submits an invoice and runs in a remote Kuudo deployment, but it does not disclose side effects, idempotency, validation behavior, duplicate handling, required authorization, or what happens on success or failure. For a mutating tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of fluff, but the first two sentences, 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' are secondary context that precedes the actual purpose statement. It would be more effective to front-load 'Submits a shipment invoice document for a given shipment' and then add the environment caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, no defined parameters, and no sibling differentiation, the description is materially incomplete. An agent knows the high-level action but lacks the shipment identifier specification, expected request format, response details, and any behavioral caveats needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the description's phrase 'for a given shipment' is the only hint that a shipment identifier is relevant. Because there are zero defined parameters, the baseline is 4, but the description fails to name the expected property or its format, leaving the agent to guess how to specify the shipment. The hint adds some meaning beyond the empty schema but is not sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Submits a shipment invoice document for a given shipment.' This clearly communicates the tool's purpose and is not a mere restatement of the name. It does not explicitly differentiate from similar siblings like DeliveryByAmazon_submitInvoice or Messaging_sendInvoice, but the ShipmentInvoicing namespace plus 'shipment invoice document' provides adequate differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only an environment note ('Runs in your Kuudo deployment, not here') and no guidance on when to use this tool versus siblings such as ShipmentInvoicing_getShipmentDetails, ShipmentInvoicing_getInvoiceStatus, or DeliveryByAmazon_submitInvoice. There are no prerequisites, exclusions, or condition-based routing instructions, so an agent cannot decide when this tool is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own. It adds one useful piece of context ('Runs in your Kuudo deployment, not here') but omits whether the call is read-only, what authorization is required, what response to expect, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first token 'Catalog entry' is unnecessary and confusing, and 'return Get all' is grammatically broken. Not every sentence earns its place, and the useful information is buried after the confusing opening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description leaves important gaps: the expected return data shape, authentication/permissions, and how the merchant is determined. The deployment note helps, but the overall context is insufficient for an agent to invoke this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and full coverage, so the description is not required to document parameters. The 'for a merchant' phrase implies a merchant context, but since no parameter is exposed, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the main operation: return all carrier accounts for a merchant, which is a specific verb and resource. However, the wording 'return Get all' and the opening 'Catalog entry' add noise, and it does not explicitly differentiate from sibling carrier-account tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of alternatives like linkCarrierAccount, unlinkCarrierAccount, or getCarrierAccountFormInputs. The description only gives a deployment note and a restatement of the operation, so an agent must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does warn that this is a 'Catalog entry' running in the caller's Kuudo deployment, but it does not disclose side effects, permissions, reversibility, or what happens after purchase. For a purchasing operation, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first two fragments ('Catalog entry. Runs in your Kuudo deployment, not here.') are cryptic and delay the action statement. It is compact but not optimally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an operation with no annotations, no output schema, and a crowded sibling space, the description is too thin. It omits how the rate is provided, what the tool returns, whether it is actually invocable, and how it relates to ShippingLegacy_purchaseShipment, Shipping_purchaseShipment, and Shipping_directPurchaseShipment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares no parameters, so the description should clarify the implicit 'given rate' input. It mentions that a rate drives the purchase but never names the parameter or format, leaving the agent to guess how to supply the rate, especially since additionalProperties is true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence, 'Purchase shipping labels based on a given rate,' states a specific action and object. It is clear what the tool does in isolation, but it does not distinguish itself from sibling tools such as ShippingLegacy_purchaseShipment or Shipping_purchaseShipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over the many purchasing/shipping siblings, nor does it explain the 'Kuudo deployment' context beyond saying it runs 'not here.' There are no explicit use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that the supply source becomes inactive. It does not mention whether the action is reversible, what permissions are required, whether it is idempotent, or what the response contains. 'Runs in your Kuudo deployment, not here' is a vague and potentially confusing behavioral note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: 'Catalog entry' and 'Runs in your Kuudo deployment, not here' do not earn their place and obscure the core action. The actual purpose is buried at the end instead of being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain which supply source is archived given there are no parameters, nor does it provide enough detail for an agent to reliably invoke the operation. It lacks output expectations, side-effect depth, and any guidance about how the target resource is identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero declared parameters, so there is no parameter meaning for the description to add beyond the schema. The baseline of 4 is appropriate, though the description could have clarified that no input is needed, especially since the schema allows additionalProperties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Archive a supply source, making it inactive' clearly identifies a specific verb and resource, and states the observable outcome. However, the opening fragments 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add confusion and do not help distinguish this tool from sibling status-related tools like SupplySources_updateSupplySourceStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this over alternatives such as SupplySources_updateSupplySourceStatus or SupplySources_updateSupplySource. It provides no prerequisites, exclusions, or operational context beyond stating the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the tool 'Runs in your Kuudo deployment, not here,' which is a useful behavioral context, but it does not mention side effects, permissions, reversibility, or response behavior for a mutation operation. 'Catalog entry' adds mystery rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but the front-loaded 'Catalog entry' sentence is opaque and does little to orient the agent. The main action only appears in the final sentence, so the structure is not optimally organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, an effectively unconstrained input schema, and a sibling set that includes create/get/archive/updateStatus, the description is incomplete. It neither explains what parameters are needed nor distinguishes why this update tool exists alongside updateSupplySourceStatus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but allows additionalProperties, so the agent gets no parameter names or required fields. The description adds high-level semantic categories ('configuration and capabilities') but no concrete keys such as a supply source identifier, leaving the agent guessing what to pass despite the 0-parameter signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Update the configuration and capabilities of a supply source' provides a clear verb and resource. It is distinguishable from sibling 'updateSupplySourceStatus' because it targets configuration/capabilities rather than status, though the opening 'Catalog entry' is confusing and obscures the actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus createSupplySource, getSupplySource, archiveSupplySource, or updateSupplySourceStatus. The note about running in the Kuudo deployment describes environment context, not usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that execution happens in the user's Kuudo deployment and that an RDT is returned, but it does not clarify side effects, required permissions, failure modes, token properties, or restrictions on resources. This is a meaningful but incomplete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly readable, but 'Catalog entry' is filler and the second sentence is oddly placed. The core purpose is stated clearly, yet the front-loaded boilerplate reduces the efficiency of the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absent annotations, empty schema, and missing output schema, the description is too thin. It does not explain what a restricted resource consists of, how restricted resources should be provided, what the returned token format is, or what 'runs in your Kuudo deployment' implies for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties: true, so there are no formal parameter definitions to rely on. The description adds that the RDT is for 'one or more restricted resources that you specify,' which gives vague semantic meaning, but it does not specify parameter names, shapes, or how resources should be identified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a Restricted Data Token (RDT) for one or more specified restricted resources, which conveys the core function. It is distinguishable from the long list of Shipping, Fulfillment, and other sibling tools, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, prerequisites, or contexts where it should not be used. The phrase 'Runs in your Kuudo deployment, not here' is a signal but does not explain how that affects invocation or selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does mention that the operation runs in the Kuudo deployment rather than 'here,' which is useful, but it does not disclose side effects, required permissions, approval implications, idempotency, or what 'creates' means for the document lifecycle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly direct, but the 'Catalog entry' sentence is a useless fragment that does not earn its place. The key action is placed last, after the environment note, which is slightly suboptimal for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is too thin. It does not explain what content is required, what inputs are expected, what happens when the document is created, or how this relates to the AplusContent workflow siblings. An agent would not know how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter count is 0, so the baseline is 4. The empty schema with additionalProperties:true means the description cannot add much parameter-level meaning, and it does not attempt to. It neither repeats schema info nor contradicts it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Creates a new A+ Content document' clearly states a specific verb and resource, and it is distinct from the sibling update/search/validate/approval tools. However, the opening 'Catalog entry' fragment is cryptic and adds confusion rather than clarifying the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus AplusContent_updateContentDocument or the post-approval/validation siblings. The only contextual note is that the tool runs in the user's Kuudo deployment, which is an environment detail, not a usage condition or alternative-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses that a document may not exist ('if available') and mentions the execution environment, but it does not explain what happens when the document is missing, what authorization is needed, what exact data is returned, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but not every sentence earns its place. 'Catalog entry' is vague and 'not here' is ambiguous. The core 'Returns an A+ Content document, if available' is front-loaded enough, but the extra phrases add little precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, an empty input schema, and arbitrary additional properties allowed, the description leaves too much unspecified. An agent cannot tell how to identify the document, what request payload or parameters are expected, or what the return value looks like. The tool appears to be a minimal catalog stub.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no defined properties and the context reports zero parameters, so there are no parameter details for the description to supplement. The baseline for zero parameters is 4. However, additionalProperties is true, and the description gives no hint about what identifiers or filters might be passed, which is a latent gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation and resource: 'Returns an A+ Content document, if available.' The verb 'Returns' and object 'A+ Content document' make the basic purpose clear, and the 'if available' qualifier hints at conditional existence. However, it does not distinguish this from sibling tools like AplusContent_searchContentDocuments or the create/update variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' provides an environment cue but does not explain prerequisites, when to call this vs searchContentDocuments, or how to obtain a document identifier before invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool 'submits a request to suspend visible A+ Content,' but does not explain side effects, idempotency, confirmation behavior, or why it 'runs in your Kuudo deployment, not here.' The 'Catalog entry' phrase is also unclear and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly to the point, but two of its three sentences ('Catalog entry' and 'Runs in your Kuudo deployment, not here') add limited value and crowd out the core functional statement. The actual purpose appears only at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the operational context, prerequisites, expected input payload, or result of the suspension request. The 'runs in your Kuudo deployment, not here' statement is especially important context that is left unexplained, making the tool's actual behavior incomplete from an agent's perspective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters documented, and the description does not need to elaborate on parameter formats. This is the baseline case where the tool has no declared parameters, though the schema's additionalProperties: true is not addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Submits a request to suspend visible A+ Content.' This is enough to distinguish the tool's core purpose from sibling AplusContent operations. However, the opening 'Catalog entry' is vague and does not add to purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as postContentDocumentApprovalSubmission or other AplusContent operations. The statement 'Runs in your Kuudo deployment, not here' hints at an execution-context caveat but does not explain when or why this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states that the tool returns a list of documents and metadata, but does not disclose pagination, authorization requirements, read-only guarantees, or any side effects. The phrase 'Runs in your Kuudo deployment, not here' adds an unexplained environmental behavior rather than clarifying execution semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' contributes little and is not front-loaded with the key action. The useful behavioral sentence comes second. It is concise but not optimally structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations to compensate for the minimal prose. The description does not explain the response structure beyond 'list... including metadata,' nor does it clarify pagination, the meaning of 'selling partner,' or the significance of the 'Kuudo deployment' environment. For an agent to invoke this correctly, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to clarify. The description adds useful context by specifying that the returned documents are those 'assigned to a selling partner,' which is meaningful even with an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core function is stated with a specific verb and resource: 'Returns a list of all A+ Content documents, including metadata, that are assigned to a selling partner.' This distinguishes it from create/update/get singular content document tools among siblings. However, the opening 'Catalog entry' and the environment note 'Runs in your Kuudo deployment, not here' inject ambiguity about whether this is an executable tool or a catalog placeholder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus sibling AplusContent tools such as searchContentPublishRecords or getContentDocument. The deployment statement is a constraint, not a usage criterion, and no alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the tool mutates an existing A+ Content document and runs in a Kuudo deployment, which is useful. However, it does not disclose side effects, required permissions, reversibility, or what happens to existing content when updated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but the opening 'Catalog entry' does not earn its place and adds confusion. The deployment note and update purpose are useful, though the structure places the actual purpose after a vague label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description must be self-sufficient for an agent to call the tool correctly. It fails to mention required identifiers, marketplaces, content format, or what the response will contain. For a real update operation, this is a significant gap, though the 'not here' caveat may reduce the expectation of direct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters, so the description is not obligated to document individual parameters. The 0-parameter baseline of 4 applies. The description does imply a target document must be identified somehow, but since the schema's additionalProperties=true leaves parameters unconstrained, the description could have added useful context about expected identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Updates an existing A+ Content document.' This clearly distinguishes it from create and get operations among the AplusContent siblings. However, the opening 'Catalog entry' is vague and slightly confusing, and the deployment caveat adds ambiguity about whether this tool is actually callable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus its siblings like createContentDocument or getContentDocument. The phrase 'an existing' implies it is for updates rather than creation, and 'not here' suggests it runs elsewhere, but no alternatives or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It conveys that the operation is a validation ('Checks') and mentions the unusual deployment context, but it does not state whether the call is read-only, what the output format is, what happens if validation fails, or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the main action sentence is clear. However, the opening phrase 'Catalog entry.' adds little value and is ambiguous, and the deployment note is phrased awkwardly. There is room to tighten the structure without losing essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must supply critical context. It explains the core check and deployment environment, but it does not clarify how ASINs are provided given the empty input schema, what the response contains, or what 'valid' means operationally. An agent would likely be uncertain how to invoke and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema, the baseline is 4. The description adds conceptual context by mentioning the A+ Content document and a 'set of ASINs,' even though these are not captured as schema properties. It does not provide detailed parameter semantics because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Checks if the A+ Content document is valid for use on a set of ASINs') and the resource being validated. It is distinct from sibling AplusContent tools like create, update, get, or list operations, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' hints at an environmental precondition, but there is no explanation of scenarios, prerequisites, or when a different validation-related operation would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden for behavioral disclosure. It only says it 'retrieves' an order and 'runs in your Kuudo deployment, not here,' which is vague and potentially contradictory. There is no mention of read-only behavior, required context, errors, authentication, or what happens when this runs in a different deployment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but 'Catalog entry' is low-value noise and the order of clauses is awkward: the misleading catalog framing precedes the actual purpose. 'Runs in your Kuudo deployment, not here' may be important context but is not clearly explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is inadequate for an agent to confidently invoke it. It does not state what identifies the inbound order, what the return value looks like, or whether the tool is actually callable given the claim that it runs 'not here.' The catalog-entry framing adds ambiguity rather than resolving it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema and 100% schema coverage, the baseline is 4. The description offers no parameter detail, but none is required for a tool whose schema declares no properties. The schema's additionalProperties:true leaves room for unexpected inputs, but the description does not need to compensate for missing param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Retrieves an AWD inbound order.' This distinguishes it from the sibling Awd_getInboundShipment, which targets a shipment rather than an order. However, the opening 'Catalog entry' is confusing and slightly undermines what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or explain why an agent should choose this over Awd_listInboundShipments or Awd_getInboundShipment. The phrase 'Runs in your Kuudo deployment, not here' hints at an environment restriction but does not clarify how that should affect invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Retrieves' implies a read-only operation, and 'Runs in your Kuudo deployment, not here' hints at an environment restriction, but the description does not disclose side effects, required permissions, error behavior, authentication needs, or any result/return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but 'Catalog entry.' is a vague meta statement that does not earn its place, and the actual functional clause is placed at the end. It is compact but not cleanly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no output schema and no annotations, an agent still needs to know what identifies the shipment and what the returned data will look like. The description only gives a terse purpose and a cryptic environment note, leaving too much unspecified for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and schema description coverage is 100%, so there are no parameters the description must explain. The baseline of 4 applies due to the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Retrieves an AWD inbound shipment' gives a specific verb and resource, so the main purpose is clear. However, it does not distinguish this from sibling tools like Awd_getInbound or Awd_listInboundShipments, and the opening 'Catalog entry. Runs in your Kuudo deployment, not here.' adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description does not explain when to choose this tool over Awd_getInbound or Awd_listInboundShipments, nor does it mention prerequisites such as having an inbound shipment identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a listing operation and mentions optional filters, but it does not mention return format, pagination, required permissions, whether the filters affect outputs, or any operational constraints. The 'runs in Kuudo deployment' note is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable, but the opening 'Catalog entry' is filler that does not help an agent. The core action is delayed to the third sentence, and 'optional filters' is vague. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero defined parameters, the description leaves significant gaps: what the filters are, what fields are returned, whether pagination is needed, and how this differs from the many AWD siblings. An agent would struggle to invoke this tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters and allows additional properties. With zero parameters, the baseline is 4; the description adds that optional filters can be applied, which hints at the additionalProperties capability. However, it does not name or explain the filters, so it does not fully compensate for the schema's lack of parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb (lists), a resource (AWD inventory), and a scope (associated with a merchant, optional filters). It is clear enough to distinguish from most AWD sibling tools, though it does not explicitly name any sibling alternative. The phrase 'Catalog entry' adds little but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Apart from the environmental note 'Runs in your Kuudo deployment, not here,' there is no guidance about when to use this tool versus other AWD listing tools such as Awd_listInboundShipments. No exclusions, prerequisites, or selection conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, but it only reveals an execution-environment trait ('Runs in your Kuudo deployment, not here') whose meaning is undefined. It does not state whether the operation is read-only, whether authentication is required, whether results are paginated, or any rate-limit or side-effect considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short at three sentences, but the opening 'Catalog entry' is a tautological label that restates the tool's domain without adding information. The deployment note is placed awkwardly before the functional clause, and the structure does not clearly lead with the most decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no annotations, and an empty input schema, the description leaves too much unspecified: the meaning of 'associated information', how to construct a valid search request, pagination behavior, and what distinguishes this 20201201 version from its siblings. The agent cannot reliably select or invoke this tool based on the provided context alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents zero parameters, so the described baseline for 0 params is 4. The description adds only the notion that this is a search operation returning a list of items, implying query/filter inputs exist, but it names none of them, leaving the agent without guidance on what to pass given the schema's empty properties and additionalProperties: true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The main clause states a specific verb and resource: 'Search for and return a list of Amazon catalog items and associated information.' This is clear and actionable. However, it does not differentiate from the sibling CatalogItems_searchCatalogItems or the newer 20201201 get variant, so the version-specific purpose remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as CatalogItems_searchCatalogItems or CatalogItems20201201_getCatalogItem. The cryptic note 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not explain the selection criteria for this tool, leaving the agent to guess among several near-identical catalog siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. 'Retrieves' implies a read-only operation, but the description does not disclose required authentication, input requirements, side effects, or what 'Runs in your Kuudo deployment, not here' actually means for execution. The ambiguous 'Catalog entry.' sentence adds confusion rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but the first sentence 'Catalog entry.' is a redundant fragment that adds no value. The environment sentence may be useful but is vaguely worded. The definition would be stronger if it removed the fragment and clarified the deployment distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a get-by-identifier operation, the description does not explain how the item is specified, what identifiers are accepted, or what details are returned. This is especially important because the input schema is empty and there is no output schema or annotations to fill the gaps. The deployment note is useful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so there are no parameter semantics for the description to supplement. With 0 parameters, the baseline is 4. The description does not clarify how the target catalog item is identified, but the schema itself provides no parameter definitions either, so this is not a failure of the description to complement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Retrieves details for an item in the Amazon catalog.' This is more specific than the tool name alone and helps distinguish it from search-like siblings. However, the opening phrase 'Catalog entry.' is vague and the environment note detracts slightly from an otherwise clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as CatalogItems_searchCatalogItems or CatalogItems20201201_getCatalogItem. The phrase 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not explain the conditions under which this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It does reveal that execution happens 'in your Kuudo deployment, not here', which is useful but ambiguous. It does not state whether the operation is read-only, what authentication or permissions are needed, or how the ASIN is expected to be provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly front-loaded, with no redundant filler. However, 'Catalog entry' and the deployment note are cryptic and could be clarified or integrated better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple-looking tool with no output schema, no annotations, and no documented parameters, so the description carries the full burden. It explains what is returned at a high level but leaves out how the ASIN is passed and what the response structure is, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no properties, yet the description references a 'requested ASIN' without naming it as a parameter. Since additionalProperties is true, this creates ambiguity about where the ASIN goes. The zero-parameter baseline is 4, but the mismatch between the described ASIN input and the empty schema lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: this API returns the associated browse node for a requested ASIN. This clearly identifies the resource and result, and distinguishes it from sibling review/trend/topic tools. The phrase 'Catalog entry' is vague but does not obscure the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related tools like CatalogItems_getCatalogItem or CustomerFeedback_getBrowseNodeReturnTopics. The deployment note provides context but not a decision rule or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that execution happens remotely in the Kuudo deployment, but it does not describe side effects, permissions, asynchronous behavior, or what a successful creation returns. 'Catalog entry' adds confusion rather than behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains the essential 'Creates...' clause, but 'Catalog entry' is filler and the main action is not front-loaded. It could be reordered to lead with the behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete: it does not state what happens after a query request is created, what the response contains, or what inputs are expected. Although the schema is empty, enough ambiguity remains that an agent cannot confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters, so the baseline is 4. The description adds no parameter-specific meaning, but there are no documented parameters to explain; the empty schema plus additionalProperties:true leaves room for runtime request fields, which the description does not address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Creates a Data Kiosk query request,' which distinguishes it from sibling get/cancel operations. The opening 'Catalog entry' is ambiguous, but the final clause gives a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to choose this tool over DataKiosk_getQuery, getQueries, or cancelQuery, and it offers no prerequisites or exclusions. 'Runs in your Kuudo deployment, not here' hints at environment context but does not guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It does disclose that the tool returns retrieval information rather than the document contents themselves, which is useful, but it does not explain the nature of that information, the return format, side effects, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly readable, but 'Catalog entry.' is an unexplained meta-label that does not earn its place, and the deployment note is placed before the actual purpose. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation coverage, so the description must be self-sufficient. It fails to explain what 'the information required for retrieving a Data Kiosk document's contents' actually is, leaving an agent unsure what the return value will contain or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter semantics to document. The empty schema with additionalProperties true is slightly risky, but the description has no obligation to explain non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear objective: it returns the information needed to retrieve a Data Kiosk document's contents, which distinguishes it from the sibling query-focused DataKiosk operations. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add ambiguity about whether this tool is actually invocable or merely descriptive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. It does not mention alternatives like DataKiosk_getQuery, and the 'Runs in your Kuudo deployment, not here' note is a deployment caveat rather than a usage criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does state that the tool 'Runs in your Kuudo deployment, not here' and that it 'Returns details,' which implies a read-only listing operation. However, it does not disclose pagination behavior, output shape, authorization needs, or explicitly confirm the absence of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is structurally awkward: the vague 'Catalog entry' fragment comes first, followed by a runtime caveat, and only then the actual purpose. The core function is not front-loaded, and 'Catalog entry' adds little actionable value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing operation with no output schema and no annotations, the description is incomplete. It does not explain available filters, pagination, defaults, or what 'details' means. The runtime note is useful context, but an agent still lacks enough information to invoke the tool correctly with filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero named parameters and allows additional properties, so the only parameter-related meaning comes from 'specified filters.' This tells an agent that filters are supported but not which filter names, types, or formats are valid. The description adds conceptual value beyond the empty schema but leaves invocation details guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: returning details for Data Kiosk queries that match filters. The plural 'queries' and the resource name help distinguish it from DataKiosk_getQuery. However, it doesn't explicitly contrast with sibling tools, and the 'Catalog entry' preamble adds confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus DataKiosk_getQuery, DataKiosk_createQuery, or DataKiosk_cancelQuery. There are no prerequisites, exclusions, or alternative routing hints. Usage context is only implied by the name and the generic filter mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose the execution environment, automatic slot scheduling, and generation of shipping labels plus compliance documents. However, it says nothing about side effects, reversibility, billing, failure modes, or response content, and it is cut off mid-sentence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but incomplete, ending with 'according to the…' mid-sentence. 'Catalog entry' is at best neutral and at worst confusing, and the second sentence tries to pack multiple effects into an unbroken run-on rather than a clean, structured explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk, side-effect-producing operation with no output schema and an effectively empty input schema, this description leaves out prerequisites, limits, expected response, and error behavior. It supplies enough to recognize the operation, but not enough to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares no properties, so the description is the only source of parameter meaning; it correctly identifies amazonOrderIds as the input collection. But it gives no shape, type, nesting, or other required fields, and the empty schema with additionalProperties true leaves an agent guessing at the exact request body.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action—automatically scheduling slots and generating labels/compliance documents for all supplied amazonOrderIds—so an agent can tell this is a bulk scheduling operation. The 'Bulk' suffix plus 'all' helps distinguish it from the single createScheduledPackage sibling, but the odd 'Catalog entry' lead and truncated ending keep it short of a fully clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to prefer this tool over EasyShip_createScheduledPackage or other siblings, nor any exclusions. The only context is that it runs in the Kuudo deployment rather than here, which hints at a routing constraint but does not explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool operates in a remote Kuudo deployment and both generates and retrieves labels, but it does not explain side effects, costs, idempotency, prerequisites, or whether generation mutates shipment state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but 'Catalog entry.' is filler that does not help an agent act. The useful deployment context is placed first, yet the sentence framing is slightly disjointed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description needed to provide more operational context. It fails to specify how the shipment is identified, what the returned labels look like, or what side effects generation may have, leaving an agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds a conceptual reference to 'the shipment you specify,' but since no parameters are declared, there is little more it could meaningfully add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Generate and retrieve all shipping labels for one or more packages in the shipment you specify.' This is distinct from related label tools. However, it does not explicitly differentiate itself from sibling tools like ShippingLegacy_retrieveShippingLabel or ExternalFulfillmentShipments_retrieveInvoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' provides some environmental context but does not tell the agent when to choose this tool over alternatives. There is no mention of when not to use it or which sibling tool should be used instead for related label operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only discloses that the tool runs in a Kuudo deployment, not here. It does not explain whether this is a read-only operation, what happens when called outside that deployment, what errors to expect, or what the response contains. The environment hint is useful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences and contains no filler. However, the most important functional information is placed last, after the opaque 'Catalog entry' and 'not here' caveats, so the structure is somewhat suboptimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an empty input schema, this description leaves major gaps: how to pass the ID, what response to expect, and whether the tool is even callable in the current environment. The caveat about running in a Kuudo deployment only raises more questions about how an agent should invoke or redirect the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the schema provides no parameter information. The description adds that an ID is required ('with the ID you specify'), but it does not specify the parameter name or format. This partial guidance is helpful but leaves a key gap between the described behavior and the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Get a single shipment with the ID you specify' clearly states the verb and resource, and the singular 'a single shipment' distinguishes it from the sibling ExternalFulfillmentShipments_getShipments. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add ambiguity about whether this tool is actually invocable in the current environment, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The note 'Runs in your Kuudo deployment, not here' is a vague environmental caveat but does not tell the agent when to select this tool over any of the many shipment-related siblings, nor does it name an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses an important non-obvious trait – this is a catalog entry that runs in the user's Kuudo deployment rather than in the current environment – and states the binary confirm/reject behavior. However, with no annotations, it does not cover side effects, reversibility, permissions, or what a successful confirmation/rejection returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences keep the description brief, and the caveat is a legitimate qualifier. However, the core purpose is placed last, after the confusing 'Catalog entry' opener, so it is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations, no output schema, and no declared parameters, the description is too thin: it does not explain how to identify the shipment, what confirm vs reject means operationally, or what response to expect. The remote-execution caveat is useful but does not make the tool safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties open, and the description does not name a shipment identifier or any request field, despite saying the shipment is 'specified.' The 0-param schema gives a baseline of 3, but an agent would still be guessing how to pass the shipment reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Confirm or reject') on a clear resource ('the specified shipment'), so an agent can tell what the tool is for. It does not explicitly contrast it with any sibling tool, and the 'Catalog entry' opener adds ambiguity, but the core purpose is still identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose processShipment over related tools such as updatePackageStatus or Shipping_cancelShipment. The only usage-relevant note is that it 'runs in your Kuudo deployment, not here,' which is a caveat rather than a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It notes that the tool runs in a Kuudo deployment rather than here, which is useful, but it does not explain status values, required identifiers, side effects, permissions, or response behavior. This is thin for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but 'Catalog entry' is a weak opener and the actual purpose appears last. It is concise, yet the ordering does not front-load the action an agent needs most.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no declared parameters, the tool still needs context about which packages are affected, what status values are valid, and how the 'not here' execution model affects invocation. Sibling tools overlap enough that the lack of disambiguation makes this definition incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, so there are no parameter names or descriptions for the schema to capture. The description adds no parameter detail, but with 0 params the baseline is already 4; however, additionalProperties: true leaves input semantics vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear action verb and resource: 'Updates the status of the packages.' However, it does not distinguish this from the closely named sibling updatePackage, and 'the packages' is underspecified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' gives operational context but no guidance on when to choose this tool over alternatives like updatePackage or processShipment. No exclusions or conditions of use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the primary effect ('Cancels the feed') and the execution location ('in your Kuudo deployment, not here'), but says nothing about side effects, reversibility, required permissions, or response behavior. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the opening 'Catalog entry' is filler and the execution-location note is placed before the actual purpose. It is concise but structurally awkward, with the core operation stated last rather than front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, annotations, and a usable parameter schema. Critical details such as how to specify the feed, what success looks like, and what states allow cancellation are missing. The 'Kuudo deployment' note adds one useful context signal but does not compensate for the absent operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the schema provides no parameter meaning. The description adds only 'the feed that you specify' without naming a parameter or format. An agent is told that a feed must be identified, but not how to provide that identifier in an API call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Cancels the feed that you specify.' It clearly communicates the operation and is distinguishable from sibling Feeds tools like Feeds_createFeed, Feeds_getFeed, and Feeds_createFeedDocument because it is the cancel action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not say when cancellation is appropriate, whether feeds can only be cancelled in a certain status, or what prerequisites exist. The only usage signal is derived from the tool name itself, which the description does not meaningfully expand on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states that the tool 'runs in your Kuudo deployment, not here' and that it returns groups, but it does not clarify whether this is a read-only operation, how results are paginated or returned, or what 'catalog entry' means. The claim of a 'given date range' is also not reflected in the empty input schema, creating a behavioral inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, and the core function is contained in a single clear sentence. However, the first sentence 'Catalog entry. Runs in your Kuudo deployment, not here' is vague and does not earn its place; it raises questions without resolving them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin. It does not document date-range parameter details, response shape, pagination, or how this differs from the many similar Finances sibling tools. An agent cannot confidently select and invoke this tool correctly based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but sets additionalProperties to true, so the agent receives essentially no parameter constraints. The description adds that a date range is relevant, but it never specifies the parameter names, types, or formats. With zero defined parameters the baseline could be 4, but the unconstrained additionalProperties and missing date-range details make the description insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names a specific resource and action: 'Returns financial event groups for a given date range.' The verb+resource is identifiable and distinct enough at a surface level. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' is confusing and does not help differentiate this tool from closely related siblings like FinancesV0_listFinancialEvents or FinancesV0_listFinancialEventsByGroupId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as FinancesV0_listFinancialEvents, FinancesV0_listFinancialEventsByGroupId, or Finances_listTransactions. The mention of a date range implies one use case, but there are no exclusions, prerequisites, or decision criteria to steer an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects and prerequisites. It only says 'Confirms', which implies a state transition, and adds an execution-environment note ('Runs in your Kuudo deployment, not here'). It does not explain whether the confirmation is reversible, what state it requires, or what outcome is produced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler, with the core action, object, and scope packed into one clause. However, the purpose is not front-loaded; the 'Catalog entry... not here' caveat comes first, and the first two fragments could be combined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing confirmation operation with no output schema and no annotations, the description is incomplete: it omits prerequisites (e.g., options must already be generated/listed), the identifiers needed to target a shipment/plan/option, and the result or side effects of confirmation. The notice that it does not run in this environment further limits its usefulness to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, which normally gets a baseline of 4, but the description mentions 'chosen shipment' and 'inbound plan' without explaining how these are supplied given the empty schema. It adds domain context but creates ambiguity about whether parameters are implicit or missing, so a slight deduction applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Confirms the delivery window option') within a specific context (chosen shipment in an inbound plan), which distinguishes it from sibling list/generate delivery-window operations. The 'Catalog entry... not here' prefix introduces ambiguity about whether the tool is callable, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given beyond the implicit 'after choosing an option'; it doesn't reference generate/list delivery window options as prerequisites or name alternatives. The only guidance is the environment note that the tool runs elsewhere, which tells the agent it may not be invocable here but doesn't help select between this and sibling confirmation-type tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that the tool is a catalog entry and not executable here, and that it confirms options, but it doesn't state whether this mutates the inbound plan, requires previously generated options, or is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the environment caveat is front-loaded. It could be slightly clearer by merging 'Catalog entry' with 'Runs in your Kuudo deployment,' but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a confirmation operation that likely affects state, with no annotations, no output schema, and an unconstrained input schema, the description is too thin. It is missing prerequisites, parameter identifiers, effect on the inbound plan, and return value; only the environment warning adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The empty schema with additionalProperties:true gives an agent no parameter names. The description at least supplies the subject 'inbound plan' and 'transportation options' as concepts, but it doesn't indicate how to identify the plan or how to pass the options, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The operative sentence names a specific action ('confirms') and object ('transportation options for an inbound plan'), making the tool's function clear. It doesn't explicitly contrast with sibling confirmation tools such as confirmPackingOption or confirmPlacementOption, so it earns 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this vs listTransportationOptions, generateTransportationOptions, or the other confirm* siblings. The caveat 'Runs in your Kuudo deployment, not here' is an environment exclusion, not a usage policy, and no alternative is suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only reveals that the tool runs in a Kuudo deployment and creates a plan. It does not disclose side effects, required prerequisites, permissions, persistence behavior, or what happens on success, leaving the agent without a clear model of invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler, but the actionable statement 'Creates an inbound plan' is placed last, after the cryptic 'Catalog entry' and 'Runs in your Kuudo deployment, not here.' This is not well front-loaded for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is too thin. It does not describe expected inputs, workflow, return behavior, or prerequisites. The environment note is unexplained and may even discourage invocation, so an agent cannot confidently call this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters and has 100% schema coverage, so the baseline for zero parameters is 4. The description adds no parameter detail, but none is required by the schema. The additionalProperties:true field is a potential gap, but with no declared properties it does not significantly lower this score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a specific verb and object: 'Creates an inbound plan,' which distinguishes it from sibling list/get/update/cancel inbound-plan tools. However, the prefatory 'Catalog entry' and 'Runs in your Kuudo deployment, not here' obscure whether this tool actually executes in the current environment, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives like FulfillmentInbound_listInboundPlans, getInboundPlan, or updateInboundPlanName. The only contextual hint is the environment statement 'Runs in your Kuudo deployment, not here,' which is not a clear decision rule about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool 'Runs in your Kuudo deployment, not here' and 'Generates' options, but it does not disclose side effects, whether it mutates state, authentication needs, asynchronicity, or what happens to the generated options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point. The 'Catalog entry' and deployment-env statements are unusual but convey environment context; the core operation is stated in one clear sentence. Slight front-loading issue because the action appears after the catalog/deployment preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generate-style operation in a large FulfillmentInbound sibling cluster, the description does not explain the relationship to placement options, transportation option listing/confirmation, expected output, or prerequisite steps. The missing workflow context and undefined input make it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties but allows additionalProperties, so the description's mention of 'a given placement option' adds conceptual meaning beyond the empty schema. However, it does not specify a parameter name, type, or format, leaving the key input ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Generates available transportation options for a given placement option.' This distinguishes it from list/confirm transportation operations, though it does not explicitly name siblings and the opening 'Catalog entry' and deployment note add slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like FulfillmentInbound_listTransportationOptions or FulfillmentInbound_confirmTransportationOptions. The phrase 'for a given placement option' implies a prerequisite, but the description does not say when in the workflow to invoke it or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does imply a read-only operation with 'Retrieves,' but the statements 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are vague and leave the agent uncertain whether the tool is even callable in the current environment. It also does not disclose return format, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is good, but the first two fragments, 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' are unhelpful and potentially confusing. The core action is clear but arrives after ambiguous caveats, so not all sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no annotations and no output schema, the description should clarify the slot lifecycle and its relationship to generateSelfShipAppointmentSlots and scheduleSelfShipAppointment. The 'not here' caveat raises more questions than it answers, and no mention is made of prerequisites or what the returned list represents beyond a vague warehouse drop-off context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so parameter documentation is not needed. The baseline for a zero-parameter tool is 4, and the description adds a small amount of useful context by specifying that the slots are for dropping off a shipment at a warehouse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Retrieves a list of available self-ship appointment slots used to drop off a shipment at a warehouse.' This distinguishes it from scheduling or cancelling an appointment. However, it does not explicitly differentiate it from the sibling generateSelfShipAppointmentSlots, and the opening 'Catalog entry' phrasing adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool versus alternatives. In particular, sibling FulfillmentInbound_generateSelfShipAppointmentSlots exists, but there is no mention that slots must first be generated or that this get operation is the follow-up read. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that the operation is a paginated list and that it runs in a different deployment, which is useful context. However, it does not describe the return shape, pagination mechanism, or any read-only guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with the key functional statement near the end. The opening 'Catalog entry' is slightly redundant, but overall it wastes little space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It does not explain what item packages are, how pagination works, what the returned items look like, or what prerequisites exist, so an agent cannot confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes no properties and allows additional properties, but the description gives no parameter names or invocation details. Since the tool lists items 'in an inbound plan,' an agent still needs to know how to identify that plan, and the description does not compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it provides a paginated list of item packages in an inbound plan. This is enough to distinguish it from create/update operations, though it does not explicitly differentiate it from sibling list tools like listInboundPlanBoxes or listShipmentItems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus the many similar FulfillmentInbound list tools. The note that it runs in the Kuudo deployment and not here is an environment constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does add useful behavioral facts: the operation is a retrieval ('Retrieves'), it is paged ('a page'), and it executes in a separate 'Kuudo deployment', not locally. But it never explains authentication, required identifiers, or what happens when called outside that deployment, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first two fragments ('Catalog entry.' and 'Runs in your Kuudo deployment, not here.') are not front-loaded toward the actionable behavior and the first is nearly useless. The final sentence is concise and clear, but overall structure is not optimized for quick agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotation support, the definition needs to at least specify how the packing group is identified and whether the tool is callable from this environment. It does neither: the schema has no parameters, the description invents a 'given packing group' input, and the 'not here' note raises an availability question without resolving it. The agent cannot reliably invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares no named properties, and the description does not compensate: it refers to 'a given packing group' without ever naming a packingGroupId parameter or explaining how it is supplied. The additionalProperties:true schema leaves the agent free to guess at the input, and the description only makes this worse by implying an undocumented required input. This is far below the baseline expected for a 0-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Retrieves a page of items in a given packing group' names a specific verb and resource, and the packing-group/items phrasing helps distinguish it from sibling listPackingGroupBoxes and other FulfillmentInbound list operations. The opening 'Catalog entry' is noise and does not add purpose, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: an agent should consider this tool when it needs items belonging to a packing group. However, it mentions no alternatives, exclusion criteria, or when to prefer sibling tools such as listInboundPlanItems or listShipmentItems, and the 'Runs in your Kuudo deployment, not here' note is ambiguous about whether the agent can actually invoke it from the current environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully indicates a retrieval operation and notes that execution happens elsewhere, but it does not explain what 'Catalog entry' means, whether local invocation is a no-op, or what state must already exist for the shipment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Catalog entry.' is an unexplained fragment that does not earn its place, and the core action is not front-loaded. 'Runs in your Kuudo deployment, not here' adds context but also introduces ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation in a multi-step fulfillment workflow, the description omits prerequisites, returned data shape, and how the target shipment is identified. The reference to a Kuudo deployment is too cryptic to give the agent confidence about whether and how the tool can actually be invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties but allows additionalProperties, so parameter semantics are murky. The description adds only domain context ('for a shipment') and does not identify how the agent should specify the shipment, even though a shipment reference would be expected for this operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Retrieves all transportation options for a shipment.' This distinguishes the read operation from sibling generate/confirm transportation-option tools, though it does not name them. The opening phrase 'Catalog entry' is vague and slightly obscures the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus FulfillmentInbound_generateTransportationOptions, confirmTransportationOptions, or other list operations. 'Runs in your Kuudo deployment, not here' hints at environment constraints but does not provide selection criteria, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only says the tool 'runs in your Kuudo deployment, not here.' It does not state side effects, whether existing prep details are overwritten, required permissions, or what happens after the call, so an agent cannot anticipate the operation's real-world impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded with the core action, but the first sentence 'Catalog entry. Runs in your Kuudo deployment, not here.' is ambiguous and contributes little to operational understanding. It is concise but not optimally structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, an empty input schema, and no output schema, the description is not complete enough to guide invocation. It communicates the high-level purpose but omits how to specify MSKUs and marketplace, what prep details are expected, and what a successful call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the zero-parameter baseline is 4. The description adds useful conceptual parameter context by mentioning 'a list of MSKUs' and 'a specified marketplace,' but it stops short of providing parameter names, shapes, or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Set the preparation details for a list of MSKUs in a specified marketplace.' This is specific enough to distinguish the action from read-style siblings like FulfillmentInbound_listPrepDetails, though the term MSKUs is not expanded and the 'Catalog entry' preamble adds noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as FulfillmentInbound_listPrepDetails or other prep-related operations. The phrase 'Runs in your Kuudo deployment, not here' is a deployment constraint rather than actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does add one important behavioral trait: the tool is described as a 'Catalog entry' that 'Runs in your Kuudo deployment, not here', signaling that it may not be executable in the current context. However, it is silent on mutation semantics, permissions, side effects, and response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first two sentences ('Catalog entry' and 'Runs in your Kuudo deployment, not here') are repetitive and ambiguous metadata that is front-loaded ahead of the actual action. The purpose statement is clear but would be stronger if placed first and combined with the caveat more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no annotations, no output schema, and an empty input schema, the description lacks essential call information such as parameter structure, preconditions, and consequences. The deployment caveat is useful, but it is not sufficient for an agent to correctly invoke the tool. The definition reads more like a stub than an operational tool specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no declared properties and allows additionalProperties: true, so the description must compensate for missing parameter documentation. It names 'MSKUs' as the target, which gives a semantic hint, but it does not specify parameter names, the shape of compliance details, or required fields. The 0-parameter baseline is weakened by the open additionalProperties schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update compliance details') on a specific resource ('a list of MSKUs'), which is clear and distinguishes this from read-style siblings like FulfillmentInbound_listItemComplianceDetails. The opening 'Catalog entry' is confusing but the core purpose is still identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives, and no mention of the closely related FulfillmentInbound_listItemComplianceDetails or other compliance tools. The phrase 'Runs in your Kuudo deployment, not here' implies it may not be callable in the current environment, but it does not explain when an agent should select this tool or what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It reveals that the operation mutates a shipment's source address, but it does not disclose permissions, side effects, reversibility, validation rules, or response behavior. The environment note is not a substitute for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core functional sentence is concise and clear. However, 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are additional fragments that do not earn their place and may distract from the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations and no output schema, the description should clarify how the existing shipment is identified and what constraints apply. It does neither, and the cryptic environment note raises more questions than it answers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented properties and no required parameters, so there is little for the description to add. The baseline for zero-parameter tools is 4, and the description neither helps nor hurts parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: 'Updates the source address of an existing shipment.' This clearly identifies the resource and action. However, it does not explicitly contrast with sibling update tools like FulfillmentInbound_updateShipmentName or updateShipmentTrackingDetails, and the 'Catalog entry' prefix adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives, no prerequisites, and no mention of shipment state constraints. The note 'Runs in your Kuudo deployment, not here' may confuse an agent about whether the tool is actually invocable in this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only adds the vague statements 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' which are not fully explained. It does not disclose side effects, permissions, whether the operation is synchronous, what happens on success, or why it does not run in the current environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is not well front-loaded: the core purpose 'Creates a fulfillment return' is placed last, after the meta-commentary 'Catalog entry' and the context statement. 'Catalog entry' is arguably redundant and could be omitted, making the structure less efficient than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves a critical ambiguity: if the tool 'Runs in your Kuudo deployment, not here,' it is unclear whether an agent should invoke it at all, and if not, what it should do instead. It also provides no information about prerequisites, expected inputs despite additionalProperties, or return behavior. Even with low complexity, the execution-context statement needs elaboration to be actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter details, but none are needed for the documented schema. The additionalProperties: true flag creates mild uncertainty, yet it does not lower the score significantly because there are no formal parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Creates a fulfillment return.' The name confirms this. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' introduce ambiguity about whether this is a real callable operation, which slightly blurs the stated purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description says it 'Runs in your Kuudo deployment, not here,' which hints at a different execution context, but it does not explain selection criteria, exclusions, or how it relates to sibling tools such as FulfillmentOutbound_cancelFulfillmentOrder or ExternalFulfillmentReturns_getReturn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It discloses a notable trait—execution happens in the Kuudo deployment, not locally—but does not explain side effects, asynchronous behavior, response format, required authentication, or how to track the created export. For a mutation-like operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the purpose sentence is clear, but 'Catalog entry' is a filler that does not earn its place. The most important information—what the tool does—is placed last rather than front-loaded, and the location statement could be integrated more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-style operation with no output schema and no annotations, the description should explain how results are obtained or how to verify the export request. It only mentions the remote execution location and the creation action, leaving the agent without guidance on follow-up steps or expected return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and 0 params is a baseline 4 per the rubric. The description adds no parameter-level detail, which is acceptable because there are no documented parameters to explain. The schema's additionalProperties: true is not addressed, but the description is not expected to compensate for absent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Creates an invoice export request.' This distinguishes it from sibling tools like Invoices_getInvoicesExports and Invoices_getInvoicesExport, which are read operations. The opening 'Catalog entry' adds noise but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives environmental context ('Runs in your Kuudo deployment, not here') but does not explicitly say when to use this tool versus alternatives or when not to use it. No sibling alternatives are referenced, so the agent must infer routing from the verb 'Creates' and the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Delete' without explaining side effects, reversibility, permissions, failure modes, or what happens to associated content. The 'not here' clause is ambiguous about where execution occurs and does not substitute for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is compact and the core action is expressed in one clause, but 'Catalog entry' is a vague fragment and the action is placed last, after the ambiguous 'not here' note. It is acceptable but not a well-front-loaded definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is too thin: it omits prerequisites, side effects, expected response, and the relationship to the unversioned ListingsItems_deleteListingsItem sibling. The deployment note is the only extra context, and it is too ambiguous to make the definition complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties and zero required parameters, so there is no parameter-level documentation gap for the description to fill; the 0-parameter baseline applies. The description names the resource being operated on, and the additionalProperties:true looseness is not addressed, though no concrete params are defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete a listings item for a selling partner.' This makes the operation identifiable. However, it does not distinguish this versioned tool from the sibling ListingsItems_deleteListingsItem, and the opening 'Catalog entry' fragment adds no purpose information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when this delete operation should be chosen over ListingsItems_deleteListingsItem, getListingsItem, or other ListingsItems tools. The cryptic 'Runs in your Kuundo deployment, not here' hints at a deployment constraint but does not state a concrete usage condition or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does add meaningful traits: full replacement behavior ('fully-updates') and an execution-location caveat ('Runs in your Kuudo deployment, not here'). However, it omits side effects, permissions, idempotency, and response/error behavior, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it opens with the near-tautological 'Catalog entry' and only reaches the actionable purpose in the final sentence. It is concise without being well-structured or front-loaded with the most useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations, no output schema, an effectively empty input schema, and a large sibling tool family, three sentences are insufficient. The definition leaves an agent unable to safely invoke it or understand what a call to this stub-like tool actually returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero named properties but allows arbitrary additional properties, so this is an open parameter bag rather than a truly parameterless tool. The description names none of the likely required arguments such as sellerId, SKU, marketplaceIds, or the item body, adding no parameter-level meaning beyond 'for a selling partner.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: it 'creates a new or fully-updates an existing listings item,' which clearly identifies the operation's purpose. It does not explicitly distinguish itself from sibling operations such as ListingsItems_putListingsItem or the patch/delete variants, and the opening 'Catalog entry' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 and no named alternative tool. 'Fully-updates' implies a contrast with partial updates, and 'Runs in your Kuudo deployment, not here' is an environment constraint, but the description does not help an agent choose between this and the many closely related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It states that execution happens in the user's Kuudo deployment rather than here, which is useful, but it does not disclose the destructive consequences, authorization requirements, reversibility, or response behavior of a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, but 'Catalog entry.' is a low-value fragment that adds confusion rather than clarity. The remaining two sentences are concise, though the structural flow is choppy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It tells the user where execution happens and what action to take, but it omits how the target listing item is identified, what prerequisites exist, and what side effects or results should be expected. An agent would struggle to invoke this tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% described coverage, so the baseline for no parameters applies. The description adds nothing about parameters, but none are present to explain. It does not compensate for implicit caller-supplied parameters that may be accepted via additionalProperties, but the schema provides no such obligations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Delete a listings item for a selling partner.' This clearly identifies the action and resource. However, the opening fragment 'Catalog entry.' is confusing and does not clarify which of the several ListingsItems deletion/update siblings this tool maps to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives like ListingsItems20200901_deleteListingsItem, patchListingsItem, or putListingsItem. The phrase 'Runs in your Kuudo deployment, not here' is contextual but does not explain selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It implies a read operation by saying 'Returns' and notes the deployment environment, but it does not mention authorization needs, failure modes, side effects, or response behavior. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the structure is awkward: the actual purpose statement comes last, after the unexplained phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here.' Those fragments may carry operational context, but they are not self-explanatory and do not earn their placement ahead of the functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, no output schema, and an empty input schema allowing additional properties, the description is insufficient for reliable invocation. It does not say how to identify the item, what 'listing restrictions' data look like, or what 'not here' means operationally. The agent is left to guess critical call details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema, the baseline is 4, and the description adds a useful hint that an item must be identified. However, additionalProperties is true and no parameter names or formats are given, so the agent cannot determine what properties to pass beyond a vague reference to an item.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence explicitly states the operation: returns listing restrictions for an item in the Amazon Catalog. This makes the action and resource reasonably clear. It does not differentiate from related tools like CatalogItems_getCatalogItem or ListingsItems_getListingsItem, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The sentence about running in the Kuudo deployment addresses execution location, not usage conditions or sibling selection. An agent cannot determine prerequisites, required item identifiers, or the appropriate context for calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the side effect—sending a message to a buyer—but omits prerequisites, eligibility rules, consent requirements, whether sending is immediate or queued, and failure behavior. 'Runs in your Kuudo deployment' adds some execution context but is vague and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with the core action in the final sentence. However, 'Catalog entry' is cryptic and contributes little, while 'Runs in your Kuudo deployment, not here' is unexplained. It is compact but sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is incomplete. It provides only the basic action and an unclear execution-location note, leaving an agent without enough information about required inputs, permissions, side effects, or expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and schema description coverage is effectively complete, so there is little for the description to add; the zero-parameter baseline is 4. The description could have noted expected implicit inputs such as order identifier and message details, especially since additionalProperties is allowed, but no schema parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Sends a message to a buyer to provide details about an Amazon Motors order.' This identifies a specific verb, resource, and context that distinguishes it from generic Messaging siblings. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' muddies whether this is actually an invokable tool, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like Messaging_createUnexpectedProblem or Messaging_CreateWarranty. The phrase 'Runs in your Kuudo deployment, not here' is a location/context cue, not a when-to-use or when-not-to-use guide. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does indicate the operation is destructive by saying 'Deletes,' and it adds an odd note that the tool 'runs in your Kuudo deployment, not here.' But it does not explain irreversibility, permissions, side effects, or what executing 'not here' means for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and wastes very few words. The core action is stated near the end, after the unusual 'Catalog entry' and environment statements, but overall it is compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations, no output schema, and empty input schema, the description is too thin. It fails to explain how the destination is specified, what happens upon deletion, whether the action is reversible, or what environmental caveat 'not here' actually implies for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented properties and allows additional properties, so there is no structural parameter information. The description says 'that you specify' but never names the expected identifier or format, which is a meaningful gap. The 0-param baseline helps, but the phrase implies a required destination reference that is left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Deletes the destination that you specify.' This distinguishes it from subscription-related siblings like deleteSubscriptionById. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' adds an execution-environment caveat that muddies the clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when deleting a destination, but provides no guidance on when to use it versus alternatives, no prerequisites, and no mention of obtaining the destination identifier first. There is no when-not-to-use guidance, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says 'Returns' but does not explicitly state that the operation is read-only, nor does it mention pagination, authentication, rate limits, or response format. The 'Runs in your Kuudo deployment' note adds some context, but 'Catalog entry' is vague and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the core purpose sentence is placed last, after 'Catalog entry' and the deployment note. The phrase 'Catalog entry' does not earn its place and adds noise rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what 'information about destinations' includes, but it does not. The deployment caveat is useful, but the description omits what a destination is, the shape of the returned data, and any potential limitations or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and the description correctly makes no parameter claims. The 100% schema coverage baseline applies, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns information about all destinations, and the word 'all' distinguishes it from the singular getDestination sibling. However, the opening phrase 'Catalog entry' is confusing and the description does not define what a destination is in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives like getDestination or createDestination. The deployment note about running in Kuudo is environmental context, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add an execution-context trait by saying the tool runs in the user's Kuudo deployment rather than here, which is meaningful. But it omits other behavioral details such as required permissions, error behavior, and return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and to the point, with no redundant elaboration. The deployment note is front-loaded and the actual purpose appears in the second sentence. The cryptic 'Catalog entry.' fragment is the only structural weakness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-style tool with no annotations, no output schema, and an empty input schema, the description should clarify the required order identifier and the relationship between the catalog entry and actual invocation. It explains where the tool runs but leaves the call contract ambiguous, so an agent is not equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'the order that you specify,' but the input schema declares zero properties and only allows additionalProperties. The agent cannot determine what to pass, such as an orderId or an order object. The description does not compensate for the schema's lack of parameter definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Returns the order that you specify.' This distinguishes it from order-item, address, and buyer-info siblings. However, the 'Catalog entry' prefix adds ambiguity and the description doesn't differentiate it from Ordersv2_getOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool instead of alternatives like Orders_getOrders or Ordersv2_getOrder. The deployment note ('Runs in your Kuudo deployment, not here') is environment context, not usage selection guidance, and no exclusions or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does disclose that the tool runs in a Kuudo deployment and that it returns data, which implies a read operation, but it does not state read-only behavior, authentication needs, error behavior, or response characteristics. The disclosure is minimal and mostly environmental.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the first sentence 'Catalog entry.' is vague and does not earn its place. The remaining two sentences convey the environment and the function without excess, but the cryptic opening prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an empty parameter schema, the description leaves key invocation details unclear—especially how 'the order that you specify' is actually passed. The sibling list contains very similar Orders getter tools, yet the description does not help an agent distinguish them. The execution-environment note is useful, but overall the definition is not complete enough for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the 0-parameter baseline of 4 applies. The description's phrase 'the order that you specify' implies an order identifier is needed, but the schema provides no parameter definition, leaving some ambiguity. Still, with no parameters to document, the description adds as much as can be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Returns buyer information for the order items in the order that you specify' gives a clear verb, resource, and scope. It does not explicitly differentiate from sibling tools like Orders_getOrderBuyerInfo or Orders_getOrderItems, but the function is understandable. The opening 'Catalog entry' is cryptic and adds no purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and it names no sibling tools or exclusions. The only contextual note is where it runs ('in your Kuudo deployment, not here'), which is not usage guidance. An agent would have to infer selection from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the full behavioral burden. It discloses that this is a mutation (approve/reject) but says nothing about side effects, permissions, reversibility, or what 'Catalog entry / not here' means for actual execution, leaving the agent uncertain about invocation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at about two sentences and contains no filler. The front-loaded 'Catalog entry. Runs in your Kuudo deployment, not here' is elliptical and slightly obscures the purpose, but the overall length and wording are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description is the only source of operational detail and it omits required parameters, allowed status values, response shape, and environment consequences. It provides the gist but is not complete enough for an agent to select and invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties=true, so it provides no field names or types. The description never names an order identifier, the status parameter, or accepted values; even though the schema declares zero parameters, an agent cannot construct a call without more guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: updating (approving or rejecting) the verification status of an order containing regulated products, which clearly identifies the tool's job and distinguishes it from order status/shipment tools. The opening 'Catalog entry. Runs in your Kuudo deployment, not here' is confusing and unrelated to the core purpose, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the purpose: apply to orders with regulated products that need verification approval/rejection. The note that it runs in a different deployment is a useful warning, but the description does not name sibling alternatives or give explicit when-to-use / when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool executes in the Kuudo deployment rather than the current environment, which is a meaningful operational fact, and 'Returns' implies a non-destructive read. However, it does not clarify what 'Catalog entry' means, what data is returned, or whether any special authorization or context is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the most distinctive fact about the tool ('Runs in your Kuudo deployment, not here'). The phrase 'Catalog entry' adds ambiguity rather than signal, but overall the description wastes very few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin to allow confident invocation. It omits how to specify the order, what response shape to expect, and how this tool differs from the near-identical Orders_getOrder sibling. The deployment note is helpful but insufficient on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters but allows additional properties, and the description says 'the order that you specify,' implying an order identifier must be provided. The description does not name that parameter or explain how the order should be specified, leaving the agent to guess from the schema's open additionalProperties field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Returns the order') and the resource type, so an agent can understand this tool retrieves a single order. However, 'Catalog entry' is an unclear qualifier and the description does not differentiate this from the sibling tool Orders_getOrder, missing a chance to clarify the v2 distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the highly similar Orders_getOrder or Ordersv2_searchOrders siblings. The note 'Runs in your Kuudo deployment, not here' is a deployment constraint, but it does not explain the criteria for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says the tool 'returns' pricing information and offers an opaque deployment note. It does not mention required authorization, rate limits, failure modes, or whether additional fields such as a marketplace ID are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, but 'Catalog entry.' is filler that does not earn its place and the core behavior is only stated at the end. It is not verbose, but it is not tightly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, annotations, and formal parameters, the description leaves significant gaps: no return shape, no accepted SKU/ASIN formats, and no differentiation from the many similarly named ProductPricing siblings. It is enough for a very basic understanding but not enough to reliably select and invoke the correct tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes no properties, so the description's mention of 'seller SKU or ASIN' is the only indication of what identifiers are relevant. This adds meaningful semantic guidance beyond the empty schema, matching the 0-parameter baseline standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Returns pricing information for a seller's offer listings based on seller SKU or ASIN' names a clear verb, resource, and input basis. However, it does not distinguish this from the many similar ProductPricing siblings such as getItemOffers, getListingOffers, or getCompetitivePricing, so it is clear but not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over the closely related ProductPricing operations. The only contextual note, 'Runs in your Kuudo deployment, not here', is environmental rather than a selection or exclusion rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the tool 'runs in your Kuudo deployment, not here', which is an unusual and potentially important execution constraint, but it does not clarify side effects, read-only safety, required permissions, data availability, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the opening 'Catalog entry' is cryptic and does not clearly earn its place. The core purpose sentence is front-loaded after that, though the overall structure is slightly disorganized and under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter schema details, the description leaves significant gaps. An agent cannot tell what inputs may actually be accepted, what the returned metrics look like, whether this tool is callable at all in the current environment, or how it relates to nearby Replenishment tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared parameters, so the baseline is 4. The description adds no parameter-specific information, but that is acceptable because there are no documented parameters to explain. The odd 'additionalProperties: true' is not addressed, but the description isn't obligated to cover schema quirks when no parameters are defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's core action: 'Returns aggregated replenishment program metrics for a selling partner's offers.' This names a specific verb and resource. However, it does not explicitly differentiate from sibling tools like Replenishment_listOffers or Replenishment_getSellingPartnerMetrics, so it misses the top tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over its siblings. The phrase 'Runs in your Kuudo deployment, not here' hints at deployment context but does not explain the intended invocation scenario or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read-like behavior with 'Returns' and adds a deployment caveat, but it does not disclose output behavior, pagination, authorization needs, or what 'not here' actually means for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' is unhelpful filler and does not front-load the core function. The second sentence is concise and informative, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should provide more behavioral and return-value context. It does not describe the response shape, list vs. single result, pagination, or the practical meaning of 'Runs in your Kuudo deployment, not here.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero declared parameters, so the baseline is 4. The empty schema and 100% schema description coverage mean there are no parameter semantics for the description to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool 'Returns the details of a selling partner's replenishment program offers,' which names a specific verb, resource, and scope. It can be distinguished from sibling metric-returning tools, though the opening 'Catalog entry' is unexplained and slightly muddies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the similarly named Replenishment_listOffers or other Replenishment20221107 siblings. The deployment note 'Runs in your Kuudo deployment, not here' hints at a constraint but does not help an agent choose among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Returns' implies a read operation, but the description does not clarify side effects, authentication needs, response format, or the meaning of 'Catalog entry' and 'Runs in your Kuudo deployment, not here.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but 'Catalog entry' adds little value and the core purpose is buried after an ambiguous deployment note. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what 'the details of a selling partner's replenishment program offers' actually includes. The current description is too vague for an agent to know what response to expect or how to invoke the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to add. The empty schema already conveys that no explicit arguments are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns the details of a selling partner's replenishment program offers.' This distinguishes the operation as a read/list tool for replenishment offers, though it does not explicitly contrast it with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it should be used when replenishment offer details are needed, and the 'Runs in your Kuudo deployment, not here' line hints at environment constraints, but it does not clearly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states this creates a transaction request and mentions the Kuudo deployment, but it does not disclose side effects, authorization requirements, reversibility, idempotency, or what response to expect. For a mutation-like operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the fragment 'Catalog entry.' adds little value and could confuse an agent. The remaining sentences are compact and the core operation is stated clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an open input schema, the description is not complete enough for safe invocation. An agent is left without details on required account identifiers, amounts, request format, execution environment implications, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties, so the baseline is 4. The description adds useful high-level meaning: a transaction request moves funds from a Seller Wallet account to another customer-provided account. However, it does not provide parameter names, value formats, or required fields, and additionalProperties true leaves the request shape ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core purpose is clear: 'Create a transaction request from a Seller Wallet account to another customer-provided account.' This states a specific verb and resource and distinguishes it from the read-oriented SellerWallet siblings. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add ambiguity about whether this tool actually executes here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives like SellerWallet_createTransferSchedule or SellerWallet_listAccountTransactions. The environment caveat 'Runs in your Kuudo deployment, not here' hints at deployment context but does not tell the agent when it should or should not call this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the important caveat that the tool runs in the user's Kuudo deployment rather than in this environment, and 'Find' implies a read-only operation. However, it does not mention auth requirements, error behavior, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no fluff, and both the deployment warning and function statement are useful. The main downside is that the function statement is placed last, and 'Catalog entry' adds little on its own. Overall, it is concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get-by-identifier tool, but there is no output schema and no annotation, so the description is the only source of context. It omits the parameter name, the identifier format, and any return-value information. The deployment caveat is helpful, but the description is incomplete for a tool that is meant to be invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties but allows additionalProperties, while the description mentions looking up by 'the Amazon transaction identifier' without naming the exact parameter key. This leaves the agent unable to construct the call reliably. The description adds semantic context but fails to bridge the gap between the abstract identifier and a concrete parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Find a transaction by the Amazon transaction identifier.' This communicates the core operation unambiguously. However, it does not explicitly distinguish the tool from siblings like SellerWallet_listAccountTransactions or SellerWallet_getAccount beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as SellerWallet_listAccountTransactions or SellerWallet_getTransaction. The deployment caveat 'Runs in your Kuudo deployment, not here' is environment context, not usage guidance. No exclusions, prerequisites, or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful trait — 'Runs in your Kuudo deployment, not here' — which warns the agent about execution context. However, it does not state whether the operation is read-only, what prerequisites exist, whether it can fail, or what happens on invocation. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with little wasted text, but the structure is suboptimal: the actual purpose statement appears last, after the 'Catalog entry' and deployment-context sentences. The phrase 'Catalog entry' is vague and does not earn its place, though the deployment warning is distinctive and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain more about what a successful response contains and how the particular schedule is identified. It mentions 'particular' but not the identifier or selection mechanism. The deployment-context note is helpful, but the overall definition leaves an agent uncertain about invocation expectations and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented parameters and the schema coverage is 100%, so the description is not required to explain parameters. The baseline for 0 params is 4. The description's 'particular' hints at some implicit selection mechanism, but no parameter semantics are needed for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Find a particular Amazon Seller Wallet account transfer schedule,' which states a clear action and resource. The word 'particular' implies single-item retrieval and helps distinguish it from the sibling listTransferSchedules, though it does not explicitly name that sibling. The opening 'Catalog entry' sentence adds little to purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus listTransferSchedules, createTransferSchedule, or updateTransferSchedule. The description only implies a single-schedule lookup via 'particular,' but it never states when this tool is appropriate or when a sibling would be better. The deployment note is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention the execution context ('Runs in your Kuudo deployment, not here'), which is useful, but it does not state whether the operation is read-only, whether any side effects occur, what authentication is needed, or how transfer schedules are returned or ordered. 'Retrieve' implies a read operation, but that is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core instruction is concise and understandable, but the first sentence 'Catalog entry. Runs in your Kuudo deployment, not here.' is awkward and partially redundant with the tool being a catalog entry. The most useful action-oriented information is front-loaded only in the second sentence, so the structure could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain what the caller receives; it does not. It also omits how the target bank account is determined, whether pagination applies, and whether this is a safe read-only operation. Given the tool has no parameters and no annotations, the description is too sparse for an agent to invoke it confidently in all contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined parameters and 100% schema description coverage, so the baseline is 4. The description adds the semantic context that the schedules belong to 'a Seller Wallet bank account,' though it does not explain how that account is specified given the empty schema and additionalProperties: true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Retrieve') and a specific resource ('transfer schedules of a Seller Wallet bank account'), which aligns with the tool name and distinguishes it from account-level tools. However, the opening phrase 'Catalog entry. Runs in your Kuudo deployment, not here' adds confusion about whether the tool is actually callable, and it does not explicitly differentiate from getTransferSchedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like SellerWallet_getTransferSchedule, SellerWallet_createTransferSchedule, or SellerWallet_listAccountTransactions. The description does not state prerequisites, such as how a Seller Wallet bank account is selected or identified, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an execution environment ('not here') and implies mutation via 'update,' but it does not state effects on the schedule, required permissions, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and mostly economical, but the lead 'Catalog entry' is jargon that adds little, and the core purpose is placed last instead of front-loaded. The deployment note is useful but the structure is not ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no annotations, no output schema, and an open additionalProperties schema, this description is too thin. An agent cannot determine what payload fields are valid, what the update changes, or what a successful invocation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, so there are no parameters for the description to document; baseline 4 applies. The description adds the target of the update ('transfer schedule information'), which is all that can be said given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Update transfer schedule information.' The execution-context note and 'Catalog entry' frame the tool as a remote stub, but the action is distinct from sibling get/create/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus SellerWallet_createTransferSchedule, getTransferSchedule, or listTransferSchedules. The only context, 'Runs in your Kuudo deployment, not here,' hints at where execution occurs but not when or why to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose that this is a mutating operation ('Assigns'/'overwrite/update') and that it runs in the Kuudo deployment, but it omits prerequisites, side effects, reversibility, permissions, and response behavior. This is insufficient for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but the first two sentences ('Catalog entry.' and 'Runs in your Kuudo deployment, not here.') overlap in meaning and delay the core action. The actual purpose is only stated in the final sentence, so it is not well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool mutates appointment resource assignments, yet the description does not identify required identifiers (e.g., appointment ID, resource list), how overwrite behavior is selected, or what the caller should expect. With no output schema and no annotations, the agent is left without enough information to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties and 100% coverage baseline, so the description is not required to document parameters. It still names the semantic entities involved (resources, service job appointment), which provides moderate context. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: 'Assigns new resource(s) or overwrite/update the existing one(s) to a service job appointment.' This is a specific verb plus resource/object and helps distinguish the tool from appointment-slot or fulfillment-data siblings. The opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' slightly muddy the practical purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over siblings such as Services_addAppointmentForServiceJobByServiceJobId or Services_setAppointmentFulfillmentData. The note about running in the Kuudo deployment is context, not a usage condition or alternative-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It states the action ('Cancel a reservation') but does not explain side effects, cancellation policy, idempotency, required permissions, or what happens if the reservation is already cancelled. The unusual 'Catalog entry' and 'not here' wording adds more confusion than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is good, but it spends two of three sentences on 'Catalog entry' and 'Runs in your Kuudo deployment, not here' without clearly defining what those mean. 'Cancel a reservation' is direct and front-loaded, yet the extra phrasing feels more ambiguous than informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation operation with no annotations and no output schema, the description should clarify the reservation identifier source, execution environment, and expected outcome. This description only says 'Cancel a reservation' and then adds a confusing deployment caveat. The phrase 'Runs in your Kuudo deployment, not here' actively undermines confidence about whether the agent should invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters for the description to explain. The schema coverage is effectively 100%, and the description adds no parameter detail, which is acceptable given there is nothing to document. The 'additionalProperties: true' flag leaves slight ambiguity, but that is a schema quality issue rather than a description gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Cancel a reservation' gives a specific verb and resource, and it is distinguishable from sibling tools like Services_createReservation and Services_updateReservation. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' introduce ambiguity about whether this tool is actually invocable or just a metadata record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no clear guidance on when to use this tool versus alternatives, and it does not mention prerequisites or exclusions. 'Runs in your Kuudo deployment, not here' hints at a deployment context but does not explain how that should affect an agent's decision to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does add one non-obvious fact: this is a catalog entry that runs in the user's Kuudo deployment, not in the current environment. However, it does not disclose cancellation effects, reversibility, required permissions, idempotency, or failure behavior, so the disclosure is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and scannable, but it front-loads meta context ('Catalog entry. Runs in your Kuudo deployment, not here.') before the actual behavior, and the first two sentences are somewhat redundant. The core action could be stated more directly and compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description leaves important gaps: how the service job identifier should be provided, what a successful cancellation returns, and whether there are preconditions on the job state. The Kuudo deployment note is useful, but an agent still lacks enough detail to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no properties, so the description's mention of a 'service job identifier' is the only parameter information available. It signals that an identifier is required but does not specify the parameter's exact name, location, type, or format, leaving the agent to infer serviceJobId from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The sentence 'Cancels the service job indicated by the service job identifier specified' clearly states a specific action and resource, and it distinguishes cancellation from sibling operations such as completing or retrieving a service job. The 'Catalog entry' and environment note add context without obscuring the core purpose, though the description does not explicitly contrast it with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus related tools like Services_completeServiceJobByServiceJobId, Services_getServiceJobByServiceJobId, or Services_cancelReservation. The note 'Runs in your Kuudo deployment, not here' is an environment caveat, not a selection rule, and prerequisites such as job state or whether the job can still be cancelled are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says the tool 'Runs in your Kuudo deployment, not here,' which is ambiguous and does not explain side effects, authorization needs, reversibility, or response behavior. The phrase 'Catalog entry' makes it unclear whether the tool is even callable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Catalog entry' is filler that does not help an agent. The substantive purpose statement is placed last, and the deployment note is vague, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An agent cannot safely invoke this update tool: there is no reservation ID, no request body structure, no output description, and no annotations. The remote-execution note raises ambiguity about whether the tool runs in this environment at all. This is incomplete for an update operation with an open schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties, so the zero-parameter baseline applies; there is nothing concrete for the description to document. The schema's additionalProperties:true leaves the actual update fields unspecified, and the description gives no hints about the reservation identifier or updatable fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update a reservation.' This distinguishes it from siblings like Services_createReservation and Services_cancelReservation. However, the opening 'Catalog entry' and the deployment note add confusion and prevent a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus create or cancel reservation operations. 'Update a reservation' is only implied usage, and 'Runs in your Kuudo deployment, not here' hints at execution context but does not clarify prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says the action cancels a shipment and runs remotely in Kuudo. It omits side effects, reversibility, refund implications, permissions, and any post-cancellation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and efficient, with no wasted words. The 'Catalog entry' opener is awkward and the main action is placed last, but overall the structure is appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an effectively open input schema, this description is too thin. It lacks invocation details, expected identifiers, behavioral effects, and any differentiation from similarly named cancellation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero declared parameters, so the schema provides no parameter names. However, because additionalProperties is true, the agent still lacks guidance on how to identify the shipment to cancel, and the description does not fill that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: it 'cancels a purchased shipment,' with a specific verb and resource. However, it does not differentiate this tool from related cancellation tools in the sibling list such as ShippingLegacy_cancelShipment or MerchantFulfillment_cancelShipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. The note that it 'runs in your Kuudo deployment, not here' hints at the execution context but does not help an agent decide between this and the many other cancel-related operations available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says a claim will be created, implying mutation. It does not explain side effects, reversibility, prerequisites, response behavior, or the meaning of 'Runs in your Kuudo deployment, not here.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, which is positive, but the first two fragments, 'Catalog entry.' and 'Runs in your Kuudo deployment, not here.', are cryptic and do not earn their place. The single substantive sentence about creating a claim is clear and front-loaded enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations and no output schema, the definition omits important context such as eligibility criteria, required identifiers or request body, expected results, and error behavior. The 'Kuudo deployment' note raises an environmental concern but is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and allows additional properties, so there are no documented parameters for the description to clarify. The description adds a small amount of meaning by scoping the claim to a single eligible shipment, which is consistent with the schema, but it does not provide field-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core clause 'This API will be used to create claim for single eligible shipment' names the action (create), resource (claim), and scope (single eligible shipment), which is clear enough to identify the operation. However, the opening phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are opaque and do not help differentiate it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, and no alternative tool is mentioned. 'For single eligible shipment' hints at a precondition but does not define eligibility or explain when this tool should be chosen over other Shipping_* operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It offers one notable behavioral clue — the operation 'runs in your Kuudo deployment, not here' — which suggests it is not executed in the current environment. However, it does not disclose side effects, return values, prerequisites, authentication needs, or what 'generate the collection form' actually does beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of filler, but it is not well structured: the actual purpose appears only in the third sentence, and 'Catalog entry' plus 'Runs in your Kuudo deployment, not here' are redundant ways of indicating environment context. The grammar is also awkward ('This API Call to generate...'), which reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter operation with no output schema and no annotations, the description should still explain the expected effect and result. It only vaguely says it generates a collection form and runs elsewhere. There is no mention of how the output is returned, how it relates to Shipping_getCollectionForm, or what an agent should do after calling it. The overall picture is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters and the schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4, and nothing in the description or schema creates a need for additional parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action — 'generate the collection form' — which is clear enough as a verb+resource pairing. It does not explicitly distinguish this from the sibling Shipping_getCollectionForm, but 'generate' versus 'get' offers an implicit contrast. The phrase 'Catalog entry' adds ambiguity about whether this is a directly callable operation, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus siblings like Shipping_getCollectionForm or Shipping_getCollectionFormHistory. The statement 'Runs in your Kuudo deployment, not here' hints at a deployment context but does not clarify when an agent should invoke this operation or what conditions trigger it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('Returns') and an unusual execution context ('Runs in your Kuudo deployment, not here'), but it does not disclose auth requirements, failure behavior, return format, or whether the tool is actually callable from this environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the functional action is not front-loaded; it appears only after 'Catalog entry' and 'Runs in your Kuudo deployment, not here.' The sentences are efficient, but the order and vague opening reduce structural quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not fully prepare an agent to invoke the tool correctly. It omits the structure of the returned documents and how the package/shipment reference should be supplied, and the environment caveat leaves it unclear whether invocation is even possible here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, so there are no parameter names or types for the description to explain; the baseline for a zero-parameter tool is 4. The phrase 'package in a shipment' adds domain context, though additionalProperties: true leaves some input ambiguity unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Returns') and a concrete resource ('shipping documents associated with a package in a shipment'), which is enough to distinguish it from sibling get-type tools like Shipping_getTracking. The opening 'Catalog entry' adds context but does not obscure the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many Shipping_* alternatives. It does not mention prerequisites, exclusions, or sibling tools, leaving the agent to infer usage only from the general action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses a key operational trait ('Runs in your Kuudo deployment, not here') and implies a read-only 'Get' operation, but it does not describe side effects, required permissions, invocation results, or what happens if called in this environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and each sentence adds information: catalog status, deployment scope, and the operation. It is not bloated, though grammar issues such as 'This API Get' and the ambiguous 'unmanifested carriers' phrasing reduce polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is the sole source of context, but it leaves critical ambiguity around the resource ('carriers' vs 'shipments'), what 'with shipment locations' means, and what the tool returns. The deployment warning is helpful, but the core operation is not sufficiently specified for reliable selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters whose semantics need explaining. With 0 parameters, the baseline is 4, and the description does not need to compensate for any undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Get all unmanifested carriers with shipment locations'), but it does not clearly align with the tool name 'getUnmanifestedShipments'—'carriers' vs 'shipments' is a material mismatch. The prefatory labels 'Catalog entry' and 'Runs in your Kuudo deployment' further muddy what the operation actually does for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'Runs in your Kuudo deployment, not here' provides an explicit when-not-to-use signal for the current environment, which is useful. However, it gives no guidance on when to prefer this tool over any Shipping_* sibling or what conditions warrant calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only says the tool runs elsewhere and creates a shipment, without explaining side effects, permissions, required inputs, or what a 'catalog entry' means. The 'not here' note leaves ambiguity about whether direct invocation is even supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is generally positive, but the core action is placed last and 'Catalog entry' contributes little. It is adequate but not a model of front-loaded, high-signal writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style tool with no annotations and no output schema, this description is incomplete. An agent cannot determine whether the tool is callable, what payload to provide, or what response to expect; the 'not here' statement creates more uncertainty than it resolves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero declared parameters, so the empty schema requires little explanation and the baseline for 0 params is 4. The description adds no parameter information, but none is strictly needed, though additionalProperties:true remains unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Create a new shipment.' However, it does not differentiate this tool from siblings like ShippingLegacy_purchaseShipment or Shipping_purchaseShipment, and the phrase 'Catalog entry' adds ambiguity rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. 'Runs in your Kuudo deployment, not here' hints at an environmental restriction, but it does not explain when to invoke this tool or when to choose a sibling tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no output schema, so the description carries the full disclosure burden. It says the tool 'Returns a list' and warns 'not here,' but it does not explain side effects, permissions, failure behavior, pagination, or the operational meaning of 'Catalog entry' or 'Kuudo deployment.' The behavior is only minimally disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no filler, which is good. However, the most informative clause appears last, and the opening 'Catalog entry' plus the Kuudo disclaimer are not front-loaded as purpose. The brevity helps, but the structure does not lead with the tool's actual behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema, no annotations, and no output schema, the description should fully contextualize invocation and return semantics. It provides an environment caveat and a general idea of the result, but leaves the required document identifier unspecified, the 'Kuudo' environment unexplained, and response/error details absent. An agent cannot confidently invoke this tool from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and allows additionalProperties, so the schema itself gives the agent no way to identify the 'specified A+ Content document.' The description adds the domain concept that a document is specified and that results are conditional, but it never names or formats that input. This gap prevents a 4 despite the zero-parameter baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation: returning related ASINs for a specified A+ Content document, with an 'if available' condition. This is distinguishable from sibling A+ content mutation or search operations. However, the unexplained 'Catalog entry' and 'Kuudo deployment' phrases muddy the statement, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Runs in your Kuudo deployment, not here' clause gives some environment context and implies this tool may not be directly invocable, and 'if available' suggests a condition on use. But it does not say when to prefer this over sibling A+ tools such as searchContentDocuments or postContentDocumentAsinRelations, and it provides no explicit alternatives. The usage guidance is implied, not precise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that it runs in the user's Kuudo deployment rather than 'here' and that results are conditional ('if available'), but it does not state whether the operation is read-only, what it returns, or what side effects or prerequisites exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but 'Catalog entry.' adds little value and the phrasing is disjoint. The remote-deployment caveat is useful, yet it could be integrated more cleanly with the search behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter search tool with no output schema, the description gives a minimally adequate overview. It names the resource and flags availability and deployment context, but it does not clarify what an unpaginated, unfiltered search returns or whether the agent can actually invoke it from the current environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% description coverage, so the baseline for no parameters is 4. The description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Searches') and resource ('A+ Content publishing records'), which is enough to distinguish it from sibling AplusContent_searchContentDocuments. However, 'Catalog entry' and 'if available' introduce ambiguity about whether this is actually callable, keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus AplusContent_searchContentDocuments or other A+ Content tools. The only usage hint is 'if available', which does not help an agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does reveal that the operation runs in the Kuudo deployment rather than here and that it records a response, but it does not explain side effects, idempotency, required authorization, or what happens after recording. The 'Catalog entry' phrasing also undercuts whether invoking this tool actually executes an operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point. The main action is stated directly in the final sentence. The 'Catalog entry' phrase is somewhat redundant and adds noise, but overall the description is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations, no output schema, and no defined input parameters, so the description must do more to help an agent invoke it correctly. It explains what the tool does conceptually but not what a valid call looks like, what data to pass, or what response to expect. The remote-execution note is useful, but it is not enough to make the tool safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero formal properties, so the baseline is 4 even without parameter details in the description. However, the schema allows arbitrary additionalProperties, and the description gives no hint about what payload fields an agent should include when recording a seller's response. This still does not contradict the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Records the seller's response to a notification.' This distinguishes it from sibling tools like AppIntegrations_createNotification and AppIntegrations_deleteNotifications, which manage notifications rather than record feedback. The 'Catalog entry' opener is odd, but the core purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used after a notification has been sent, nor does it compare against AppIntegrations_createNotification or similar tools. The only contextual clue is that it runs in the user's Kuudo deployment, which is a location note rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that the operation creates a draft and executes in the Kuudo deployment, which is useful, but it does not mention side effects, required permissions, idempotency, whether the draft is immediately visible, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the opening 'Catalog entry.' is vague and adds little value. The core action is placed last rather than front-loaded, and the description mixes an environment note with the main purpose without clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an empty schema, no annotations, and no output schema, the description is too sparse. It lacks usage preconditions, parameter details, expected response semantics, and any mention of related verification or confirmation steps among the sibling Awd tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined properties and allows additional properties, so the description's mention of 'a list of packages' adds some semantic meaning. However, it does not specify parameter names, types, structure, or how the package list should be provided, leaving the agent without enough detail to construct a valid request beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action: 'Creates a draft AWD inbound order with a list of packages for inbound shipment.' This identifies the specific verb, resource, and state (draft), distinguishing it from sibling operations like Awd_confirmInbound, Awd_updateInbound, and Awd_cancelInbound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives or any prerequisites such as checking eligibility first. The phrase 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not explain operational context or sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does disclose that the tool runs in the Kuudo deployment rather than locally and that it merely 'requests' Amazon to act, hinting at a remote/async effect. But it does not say whether the request is asynchronous, what side effects occur, what success means, or what response is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, which is good, but the first fragment is not a sentence and 'Sandbox Inventory in the sandbox environment' is redundant. It is compact but structurally sloppy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description needs to explain the execution model and success/return behavior; 'Runs in your Kuudo deployment, not here' and 'requests' raise more questions than they answer. It is enough to roughly identify the tool but not to confidently invoke it and interpret the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero formal properties, so there is little to document from the schema itself. However, additionalProperties:true leaves the payload unrestricted, and the description only mentions product-details without naming required fields (e.g., seller SKU, product attributes). It therefore adds minimal practical guidance for constructing a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: it 'requests that Amazon create product-details in the Sandbox Inventory.' The 'Catalog entry.' label and sandbox scope help distinguish it from inventory-quantity operations like FbaInventory_addInventory, though it never names that sibling. The fragment 'Catalog entry.' adds only mild confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies an environment ('sandbox environment', 'Runs in your Kuudo deployment, not here'), which is useful context for selecting it over production-affecting tools. However, it does not state when to use this tool versus FbaInventory_addInventory or deleteInventoryItem, nor give exclusions or precedence. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool creates a feed document and runs in the Kuudo deployment, but does not disclose side effects, required authentication, return values, or what happens when invoked. For a create operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, using three sentences. The main action is clearly stated, and there is minimal waste. However, 'Catalog entry' is vague and not front-loaded with the most useful information; the actual purpose sentence appears after two contextual fragments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an empty input schema, the description is incomplete for a create-style tool. It does not explain the relationship to Feeds_createFeed, the required feed type parameter, the response format, or any preconditions. An agent would not have enough information to call this tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is effectively empty with zero defined properties and additionalProperties allowed, so the description adds the only semantic hint: a feed type must be specified. Since there are no formal parameters documented in the schema, the baseline is high, and the description provides at least one meaningful parameter-related clue, even if it lacks details about the parameter name or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates a feed document for the feed type that you specify.' This makes the core operation clear and distinguishes it from sibling tools like Feeds_createFeed by naming 'feed document' as the resource. However, it does not explicitly differentiate itself from related Feeds tools beyond that noun, and the opening 'Catalog entry' is cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Feeds_createFeed, Feeds_getFeedDocument, or Feeds_getFeeds. The phrase 'Runs in your Kuudo deployment, not here' gives deployment context but not selection guidance. The description does not explain the expected workflow or prerequisites, leaving an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation runs in a remote Kuundo deployment and that it returns fee estimates, but it does not explain what 'Catalog entry' means, whether the agent can actually invoke it, what side effects or prerequisites exist, or what the response looks like. This is too little context for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and the functional sentence is direct. However, the first sentence fragment 'Catalog entry' is vague, and 'Runs in your Kuundo deployment, not here' is ambiguous enough that it does not clearly earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, an empty input schema, and no output schema, the description needs to cover request format, return value, and execution context. It only vaguely addresses the request concept and leaves the invocation contract almost entirely unspecified. An agent would struggle to call this tool correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but allows additionalProperties, so the description must compensate by explaining the intended payload. It mentions a 'list of products' but gives no parameter names, structure, or formatting details for that list. Because schema coverage is technically 100% for an empty schema, the baseline is 3, and the description provides only minimal extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Returns' and the resource 'estimated fees for a list of products,' making the core operation identifiable. The plural 'list' distinguishes it in scope from the sibling tools Fees_getMyFeesEstimateForASIN and Fees_getMyFeesEstimateForSKU, though it does not name them explicitly. The opening 'Catalog entry' fragment adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a list of products' implies this tool is for bulk fee estimation, while the ASIN/SKU siblings are implied to be for single-item lookups. However, the description never explicitly states when to choose this tool over those alternatives or provides exclusions. The caveat 'Runs in your Kuundo deployment, not here' gives a location note but not actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden, but it only states that the tool cancels a slot and runs in Kuudo. It does not disclose whether cancellation is reversible, what prerequisites exist, what happens to the shipment, or what response is returned, which is important for a cancel operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler, and the cancellation action is clear. However, the cryptic 'Catalog entry' and deployment note appear before the action, making the structure slightly less front-loaded than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A cancel operation with no output schema, no annotations, and an empty schema needs more than a one-line action. The agent is left uncertain about how to identify the appointment or shipment and whether to invoke the tool at all, given the statement that it runs in the Kuudo deployment, not here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, and the baseline for zero-parameter tools is 4. The phrase 'against a shipment' implies some identifying information may be needed, but with no declared parameters, there is little explicit parameter semantics to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Cancels a self-ship appointment slot against a shipment.' This clearly distinguishes the cancellation intent from sibling operations like scheduling or generating appointment slots. The 'Catalog entry' and Kuudo note add extra context but do not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as scheduleSelfShipAppointment or generateSelfShipAppointmentSlots. The only contextual hint is that it runs in the Kuudo deployment, not here, which is an environment limitation rather than a clear usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core create action, but does not disclose side effects, permissions, idempotency, error behavior, or output. The 'Catalog entry' and 'not here' phrasing adds some context but remains vague about what actually happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with the core action in the second sentence. The opening 'Catalog entry. Runs in your Kuudo deployment, not here' is somewhat cryptic but carries deployment context, so the length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a mutation tool with no annotations and no output schema. It does not explain input requirements, label format, prerequisites, or what the caller should expect in response. The deployment caveat is mentioned but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so the zero-parameter baseline applies. The description still adds meaning by naming the logical inputs 'marketplace' and 'list of MSKUs', which are absent from the schema and are essential for understanding what the tool operates on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'creates labels for a list of MSKUs' for a given marketplace, with a specific verb and resource. It is understandable in isolation, though it does not explicitly differentiate itself from label-related siblings like FulfillmentInboundV0_getLabels or ExternalFulfillmentShipments_generateShipLabels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, and no alternative tools are named. The statement 'Runs in your Kuudo deployment, not here' hints at a deployment constraint but does not explain when the tool should or should not be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the generation action and the fact that it runs in the caller's Kuudo deployment. It does not disclose whether the operation mutates state, is asynchronous, requires prior steps, or returns an operation/reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the operational caveat before the core function. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are somewhat redundant or confusing, but the description is free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generation operation with no annotations and no output schema, the description is thin. It does not explain the relationship to listPackingOptions or confirmPackingOption, whether generation is required before listing, how results are obtained, or any prerequisites such as an existing inbound plan with packing information set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so the description has little parameter detail to add. It does identify the resource as 'the inbound plan,' but with additionalProperties: true the schema does not formally tell the agent how to pass an inboundPlanId; this is a minor gap given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Generates available packing options for the inbound plan.' This is distinguishable from the sibling listPackingOptions by the verb 'generates,' though it does not explicitly name that sibling or clarify whether this just computes vs. persists options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to invoke this tool versus listPackingOptions, confirmPackingOption, or generatePlacementOptions. The only context, 'Runs in your Kuudo deployment, not here,' speaks to deployment location, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool runs in the Kuudo deployment rather than 'here', which is mildly informative, but it does not disclose whether generation is asynchronous, has side effects, requires permissions, or how the results will be surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and avoids filler, with each sentence contributing either deployment context or the core action. It is concise, though the actual purpose statement appears last rather than being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and many related sibling tools, the description is too thin. It omits the intended workflow sequence, how to identify the inbound plan, what a successful generation produces, and when an agent should use listPlacementOptions or confirmPlacementOption instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds a minimal target context ('the inbound plan'), though it does not clarify how that plan is identified given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generates') and a specific resource ('placement options for the inbound plan'), so an agent can tell this is about producing placement options. It does not explicitly distinguish this from sibling tools like FulfillmentInbound_listPlacementOptions or confirmPlacementOption, but the 'generate' wording makes the core purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus alternatives such as listing or confirming placement options. The description says it runs in a Kuudo deployment, but it does not explain prerequisites, sequencing, or which sibling tools should be used before or after this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It does surface an important environmental fact ('Runs in your Kuundo deployment, not here') and says the tool 'initiates' rather than completes an action, but it does not disclose side effects, asynchronous behavior, return values, or required preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the most distinctive facts: catalog entry, remote execution, and initiating slot generation. Minor redundancy exists between 'Runs in your Kuundo deployment' and 'not here,' but overall there is no padding or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description leaves important operational gaps. The agent cannot tell what the tool returns, whether it is asynchronous, how it relates to getSelfShipAppointmentSlots, or what happens after the process is initiated. The environment note is useful, but the definition is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and additionalProperties is true, so there is no parameter semantics the description needs to explain. With 0 parameters, the baseline of 4 applies, and the description's silence about parameters is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Initiates the process of generating the appointment slots list') tied to a clear resource (self-ship appointment slots). It goes beyond a tautology and gives the agent a basic sense of what the tool does, though it does not explicitly contrast with the closely related FulfillmentInbound_getSelfShipAppointmentSlots sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as getSelfShipAppointmentSlots or scheduleSelfShipAppointment. The statement 'Runs in your Kuundo deployment, not here' says where it runs, not when or under what conditions it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a key operational trait—that it runs in a Kuudo deployment, not here—and implies a mutation by confirming or rescheduling an appointment, but it omits side effects, required prior state, permissions, and response behavior. This is too thin for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences and front-loads the critical environment warning before the action. The core operation is stated directly without excessive detail. Minor deduciton: 'Catalog entry' adds only marginal value and could be confusing, but on the whole the description is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero declared parameters, this appears to be a state-changing fulfillment action, and there are no annotations or output schema to fill the gaps. The description does not explain what inputs are needed, what confirms versus reschedules requires, what happens on success, or what errors could occur. An agent would struggle to invoke this correctly or safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties and allows additionalProperties, so the description does not need to restate parameter details. The phrase 'against a shipment' implies that shipment and appointment identifiers are relevant, adding some context beyond the empty schema. The baseline of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation—'confirms or resheduales a self-ship appointment slot against a shipment'—which is specific enough to distinguish this from siblings like cancelSelfShipAppointment or getSelfShipAppointmentSlots. The phrase 'Catalog entry' slightly muddies whether this is an invocable tool, 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.
Usage Guidelines2/5
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 tool versus alternatives such as cancelSelfShipAppointment or generateSelfShipAppointmentSlots. The only usage-related information is the environment caveat that it runs in a Kuudo deployment and not here, which does not help an agent decide when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral detail beyond the schema and annotations (none were provided). It is a catalog entry with no parameters, but it does not disclose environment behavior beyond "Runs in your Kuudo deployment, not here," which is helpful context but not enough. There is no mention of authentication needs, required inputs like shipment identifier or package identifier, error cases, rate limits, or response shape. With no annotations and no output schema, the description carries the full burden, and it only partially discloses the operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the most important qualifier, 'Catalog entry. Runs in your Kuudo deployment, not here.' It is a single, structured two-sentence description that avoids fluff. It loses one point because it leaves out actionable behavioral/usage details that could have been added without much length, but as far as conciseness it is well-formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no schema parameters and no output schema, the description should still tell an agent what inputs it needs conceptually (e.g., an outbound shipment/package identifier), what the response will contain, and how it relates to other tracking tools. It barely names the use case ('delivery tracking information for a package in an outbound shipment for a Multi-Channel Fulfillment order') and the 'not here' environment note, but it leaves out eligibility, prerequisites, and how to invoke it from a deployment that is 'here.' The agent has too little to safely select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and schema description coverage is 100%, so the schema itself carries no parameter semantics. With zero parameters, there is essentially nothing for the description to explain. The description does not mention any required identifiers (e.g., shipmentId or trackingId), which would normally be expected, but with an empty schema, the tool is parameterless in the schema view; the description adds modest relevant context by identifying it as a catalog entry against Kuudo deployment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb-resource pair: returns delivery tracking information for a package in an outbound shipment for an MCF order. This distinguishes it from many sibling tools because it is specifically fetches tracking details for outbound packages, not for shipping services or inbound shipments. However, it does not explicitly contrast with similar-sounding siblings like Shipping_getTracking or ShippingLegacy_getTrackingInformation, and it lacks a title, so a small incremental clarification opportunity is left unused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this tool over alternatives such as Shipping_getTracking, FulfillmentOutbound_getFulfillmentOrder, or FulfillmentInbound_updateShipmentTrackingDetails. The context "Multi-Channel Fulfillment order" implies a use case but the description does not state scenarios, exclusions, or what type of tracking needs are appropriate for this specific tool versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only says 'partially update' and mentions remote execution. It does not explain whether unspecified fields are preserved, what permissions are required, what happens if the item does not exist, or what response is returned. The Kuudo deployment note adds context but not operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly avoids waste, with the core action captured in one sentence. The leading 'Catalog entry.' fragment is marginal, and the main verb appears near the end rather than at the front, but overall it is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the input schema is empty, so the description is the only source of operational detail. It provides the operation and target but omits request body shape, required identifiers, version selection, and return behavior. An agent could know what to do in broad terms but not how to construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties: true and parameter count is 0, so there are no documented parameters to repeat. The description mentions a selling partner and a listings item but gives no format or body structure. Per the baseline rule for tools with 0 parameters, this is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Partially update (patch) a listings item for a selling partner.' This is specific enough to distinguish patch semantics from put/delete/get operations, though it does not explicitly differentiate from the similar ListingsItems20200901_patchListingsItem sibling. The opening 'Catalog entry' fragment adds little.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives like putListingsItem, deleteListingsItem, or the 20200901 patch variant. The note about running in a Kuudo deployment is environmental context, not usage direction, and no exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the execution environment and states it returns a list, but it does not disclose authentication needs, rate limits, pagination behavior, read-only guarantees, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly purposeful, with the environment caveat front-loaded. The phrase 'Catalog entry' adds only marginal value, but overall the text is compact and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not provide enough for an agent to invoke the tool confidently: there is no output schema, no parameter guidance, and no behavioral context beyond returning a list. For a search operation, essential details like search criteria, result structure, and constraints are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters, so there are no parameter semantics for the description to add beyond the schema. The baseline for a zero-parameter tool is appropriate here, though the loose additionalProperties:true means actual accepted inputs remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as searching for and returning a list of selling partner listings items with their details. It is distinct enough from get/put/patch/delete siblings, though it does not explicitly differentiate itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus sibling tools like ListingsItems_getListingsItem. The phrase 'Runs in your Kuudo deployment, not here' hints at an environment constraint but does not clarify when an agent should select this tool or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It usefully discloses that execution happens remotely ('not here') and that the operation returns a list rather than mutating, but it leaves 'Catalog entry' unexplained and does not cover auth, prerequisites, or whether the tool is callable from this environment at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three short sentences it is compact, but the front-loaded 'Catalog entry' and 'Runs in your Kuudo deployment, not here' obscure the core purpose, which only appears at the end. 'Catalog entry' is redundant or at least unexplained alongside the deployment note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description needed to clarify whether and how this tool can be invoked here, how to specify the order, and what the returned 'message types' look like. It leaves all three unclear, so an agent cannot confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties and only `additionalProperties: true`, while the description refers to 'an order that you specify.' This is an unnamed, unspecified parameter: no property name, type, or format is given, so an agent cannot know how to pass the order. The zero-parameter baseline is undermined by the description's own claim that an order input exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The sentence 'Returns a list of message types that are available for an order that you specify' states a concrete verb, resource, and scoping condition. It does not explicitly contrast with the many sibling Messaging create/send tools, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Runs in your Kuudo deployment, not here' hints at a deployment constraint, but there is no guidance about when to prefer this tool over sibling Messaging operations or any prerequisites or exclusions. The intended use case of listing available message types before sending one is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It reveals only that a message with an invoice is sent and that it runs elsewhere; it does not disclose prerequisites, side effects, recipient handling, idempotency, or expected response behavior. This is minimal for a tool that triggers an external messaging side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 18 words and the main action is stated clearly. The opening 'Catalog entry' fragment adds little, but the definition is not bloated and the key purpose is front and center.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple zero-property schema, the definition lacks enough operational context for confident invocation: no mention of required order or buyer context, message content expectations, or return behavior. The environment caveat is helpful but does not make the entry complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, so there are no parameter semantics for the description to enrich; the baseline of 4 applies. The additionalProperties: true default is not explained, but with no defined parameters this is not a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Sends a message providing the buyer an invoice,' naming the verb, object, and recipient clearly. It does not explicitly distinguish itself from sibling tools, but the purpose is understandable on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as DeliveryByAmazon_submitInvoice, ShipmentInvoicing_submitInvoice, or other Messaging_* actions. The only contextual hint, 'Runs in your Kuudo deployment, not here,' says where the tool executes, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It does note that execution happens in the Kuudo deployment, which is useful, but it omits side effects, reversibility, required permissions, and response behavior for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the key behavior is stated directly. The standalone sentence 'Catalog entry.' is low-value filler and could be removed, but the rest of the description is economical and reasonably structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema, missing output schema, and lack of annotations, the description should provide more operational detail. It names the required entity type but not concrete parameter names, invocation format, or what happens on success or failure, leaving significant room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema is empty with additionalProperties allowed, the description compensates by indicating that a subscription identifier and notification type are needed. It does not specify exact parameter names, but the tool name and wording make the intended parameters reasonably clear for a zero-property schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Deletes the subscription') and identifies the resource and selection criteria (subscription identifier and notification type), which clearly conveys the tool's function. The introductory phrases 'Catalog entry' and 'Runs in your Kuudo deployment' add context but do not directly differentiate it from siblings like Notifications_deleteDestination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives or when not to use it. The description simply states the deletion behavior, leaving the selection decision to inference from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It only says the tool 'returns' data and runs in a specific deployment, which gives minimal operational context. It does not disclose whether the operation requires special permissions, whether results are paginated, what data is returned, or how errors behave. These are meaningful gaps for a tool that accepts arbitrary extra properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the main functional sentence is front-loaded and clear. The opening phrase 'Catalog entry. Runs in your Kuudo deployment, not here.' is somewhat cryptic and could confuse an agent, but it is brief and does not obscure the core meaning. Overall the description is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema, absent output schema, and many closely related sibling tools, this description is under-specified. An agent is not told how to pass the SKU or ASIN, what the returned pricing information looks like, or when this tool is preferable to the numerous other ProductPricing tools. The 'Kuudo deployment' note is useful but does not satisfy the need for operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty but allows additional properties, so the schema provides essentially no parameter meaning. The description compensates by stating the lookup is 'based on seller SKU or ASIN,' which is the key semantic information. It does not give exact parameter names or formats, but for a tool with zero defined parameters it adds meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns competitive pricing information for a seller's offer listings based on seller SKU or ASIN.' This is specific enough to identify the core purpose. The phrase 'Catalog entry' adds little and the description does not explicitly differentiate from sibling pricing tools like getItemOffers or getListingOffers, but the core purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It mentions that it runs in the Kuudo deployment, which is an operational context, but there is no discussion of when to prefer this over getItemOffers, getListingOffers, or batch variants. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds that this is a 'Catalog entry' and runs in the Kuudo deployment rather than here, which is useful, but it omits whether the tool is directly invocable, what authentication or prerequisites apply, and what the returned capacity data looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences with no wasted filler, and it front-loads the important 'Catalog entry' classification. The two deployment-related statements could be merged, but overall the length is appropriate for the limited schema context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a sparse description for a tool with no annotations and no output schema. It names the high-level capability and remote execution environment, but it does not explain what the capacity data represents, what a caller should do with the response, or whether this tool is meant to be invoked at all from the current context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined properties and 100% schema coverage, so the description has no parameter semantics to add. The baseline for zero-parameter tools is 4, though the schema's additionalProperties: true leaves some ambiguity about whether hidden parameters could be accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it 'Provides capacity in fixed-size slots,' which identifies a clear function and differentiates it from the sibling Services_getRangeSlotCapacity by the 'fixed-size' qualifier. It is not a pure tautology, though 'provides capacity' adds only slightly more specificity than the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as Services_getRangeSlotCapacity or Services_getAppointmentSlots. The statement 'Runs in your Kuudo deployment, not here' hints at an environmental constraint but does not say when to use it or what conditions make another tool preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It adds one behavioral signal by saying the operation runs in the Kuudo deployment and not 'here,' but it is vague about side effects, authentication needs, error behavior, and the exact content of the returned details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable, but the first two sentences ('Catalog entry. Runs in your Kuudo deployment, not here.') are cryptic filler that delay the actionable purpose. It is concise but not optimally structured or front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description leaves critical gaps: how to specify the shipment and what the returned shipment details actually contain. The remote-execution note is not enough to make the tool safely and correctly invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and permits additional properties, yet the description refers to a 'specified shipment' without identifying any parameter name, type, or format. An agent cannot determine how to pass the shipment identifier, so the description fails to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific outcome: returning shipment details needed to issue an invoice. This distinguishes it from sibling tools like submitInvoice and getInvoiceStatus. However, the opening 'Catalog entry' and 'not here' clauses add ambiguity that keeps it from being a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'required to issue an invoice' implies the tool should be used to fetch shipment details before invoicing. It does not explicitly describe when to use it versus alternatives, and no exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation by saying 'Returns,' but it does not disclose authorization requirements, input needs, return format, or error behavior. 'Runs in your Kuundo deployment, not here' is a vague deployment note rather than a clear behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, using three brief sentences without excess detail. The first sentence, 'Catalog entry,' is somewhat vague and the main action is delayed, but the overall length is well controlled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description only promises generic 'tracking information.' It does not specify what shipment identifier is required, what tracking fields will be returned, or how this tool differs from sibling ShippingLegacy_getTrackingInformation. This is too thin for a tool with no structured schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties, so there are no parameter semantics for the description to enrich. The schema also sets additionalProperties to true, which is unusual, but with 0 parameters the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 tracking information for a purchased shipment.' This makes the core purpose clear. However, it does not differentiate itself from the closely related sibling ShippingLegacy_getTrackingInformation, which also appears to return tracking-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus ShippingLegacy_getTrackingInformation or any other shipping tool. The phrase 'Runs in your Kuundo deployment, not here' provides an environment caveat but does not help an agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that it runs in a separate deployment and that two operations share the name, but it omits side effects, auth requirements, idempotency, or output behavior for a mutating link operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the actual purpose is buried after 'Catalog entry' and the environment note. The meta-statements are somewhat useful but the structure could front-load the operation more effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It includes important context about the deployment location and the name collision between two API operations, which helps an agent avoid mis-invocation. However, it never explains how the carrier account is specified, what the response looks like, or whether direct invocation is intended at all.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared parameters, so the baseline is 4 and there is little to document. The description only mentions a 'specified carrier account' without indicating what parameter carries that identifier, which is a minor gap given additionalProperties is allowed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: associates/links the specified carrier account with the merchant. It is clear enough to identify the intended operation, though the 'Catalog entry' preface and lack of explicit sibling differentiation keep it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no when-to-use vs. when-not-to-use guidance, no named alternatives, and no prerequisites. The action itself weakly implies a use case, but the 'Runs in your Kuudo deployment, not here' note is confusing about whether this tool should even be invoked from the current environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses an environment-related behavior ('Runs in your Kuudo deployment, not here') but does not explain side effects, read-only nature, access requirements, or what the returned 'collection' contains. The word 'Get' implies read-only, but that is not enough given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but the opening 'Catalog entry' is a fragment that adds confusion rather than value. The core instruction 'Get the latest collection of vehicles' is clear, and the environment caveat is important. The structure is not ideal because the most meaningful action is placed after two weaker statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description gives the basic purpose and an environment qualifier. However, it lacks context about authentication, invocation from the current environment, output format, and what qualifies as 'latest.' The meaning of 'Catalog entry' is unexplained, and the deployment caveat could leave an agent unsure whether this tool should be called at all.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero parameters, so there is nothing for the description to clarify. The empty schema with additionalProperties allowed adds no meaningful parameter semantics. With no parameters, the description is not required to add parameter details, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the latest collection of vehicles.' This clearly identifies the operation and output scope. There are no sibling vehicle tools to differentiate from, so the lack of sibling comparison is not a major gap. The opening phrase 'Catalog entry' is somewhat ambiguous but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an environment caveat: 'Runs in your Kuudo deployment, not here.' This hints at where execution happens but does not clearly instruct when to use this tool versus alternatives, nor does it explain whether the tool is callable from the current environment. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does add one meaningful trait—'Runs in your Kuudo deployment, not here'—indicating remote or deferred execution rather than local invocation. However, it says nothing about required permissions, side effects beyond notification creation, idempotency, or expected response behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no fluff, but it is not well front-loaded: the core action appears only after two cryptic context sentences. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' could be merged or reordered to lead with the primary purpose. Still, every sentence adds some context, so it is reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an empty parameter schema, this description is underinformative. It does not explain what fields a notification requires, how sellers are specified, whether the operation is synchronous or asynchronous, or what success looks like. The 'Catalog entry' phrase raises more questions than it answers about how the agent should treat this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined parameters and no required properties, so the baseline for parameter semantics is 4. The description does not detail any parameters, but additionalProperties=true means an agent may pass arbitrary fields without guidance. The target mention 'for sellers in Seller Central' hints at recipient context but does not explain any payload structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a notification for sellers in Seller Central.' This clearly distinguishes it from sibling tools like AppIntegrations_deleteNotifications and AppIntegrations_recordActionFeedback. However, the opening 'Catalog entry' is ambiguous and could confuse an agent about whether this is an executable operation or merely a metadata entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no sibling alternatives are named. The 'Runs in your Kuudo deployment, not here' note gives a deployment constraint but does not help the agent choose between this and similar AppIntegrations tools. Usage is only implied through the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does add some behavioral context: it discloses that execution occurs in the user's Kuudo deployment rather than locally, and that ineligible packages are accompanied by error details. However, it does not explicitly state whether this is a read-only check, what auth or permissions are required, or whether any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short: two sentences and roughly thirty words. The deployment qualifier is front-loaded and the core function is stated directly. 'Catalog entry' is slightly cryptic, but the overall structure is efficient with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that takes package input and returns eligibility and error details, the description is incomplete. It lacks the input parameter structure, output format, and any example of how to specify packages. With no annotations and no output schema, the description needed to carry more operational and invocation detail than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero named properties with additionalProperties: true, so it provides no parameter names, types, or structure. The description says 'packages you specify' but does not explain how packages should be passed, such as the expected field name or format. This leaves the agent unable to construct a valid request confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Determines' and a clear resource ('AWD inbound order'), and states the outcome: eligibility status plus error details for ineligible packages. This makes it distinguishable from the Awd_createInbound and Awd_getInbound siblings in purpose, though it does not explicitly name or contrast any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when you need to check whether specified packages are eligible for an AWD inbound order. However, there is no explicit when-to-use guidance, prerequisite, or statement about which sibling tools to prefer or avoid. 'Runs in your Kuudo deployment, not here' is operational context, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the confirmation is reversible, what side effects it triggers, or what permissions are needed. The note 'Runs in your Kuudo deployment, not here' is unusual but does not clarify the operation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Catalog entry' is filler and 'Runs in your Kuudo deployment, not here' is vague. The most useful information is front-loaded only after two weak opening fragments, so the structure is not as clear as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-like confirm action with no annotations and no output schema, the description should explain side effects, prerequisites, and what happens on success. It only provides the target resource and DRAFT precondition, leaving the agent under-informed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and schema description coverage is 100%, so there are no parameter semantics for the description to add. Per the zero-parameter baseline, this is appropriate, though the schema's additionalProperties: true leaves some ambiguity that the description does not address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core phrase 'Confirms an AWD inbound order in DRAFT status' names a specific verb, resource, and state precondition. However, the opening 'Catalog entry' is vague, and the description does not explicitly differentiate it from related Awd_* tools like Awd_createInbound or Awd_cancelInbound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The DRAFT status condition gives some implied guidance about when this tool is appropriate. However, it does not mention alternatives, exclusions, or the workflow position of confirming an inbound order relative to other Awd tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that this is a catalog entry that runs in the Kuudo deployment rather than here, and 'Retrieves' implies read-only, but it omits output shape, pagination, and filter semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with minimal waste, and the core action is stated once. 'Catalog entry' and the deployment note are somewhat redundant but do not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema and no annotations: it does not describe the returned summary fields, pagination, or how filters are expressed. The environmental note is useful, but the invocation contract remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no parameters, yet the description mentions optional filters without naming or typing them. This adds a hint beyond the empty schema but leaves the agent without enough information to construct a filtered call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb 'Retrieves' and the resource 'inbound AWD shipments', with a merchant scope and optional filters. It clearly conveys a list/summary operation, though it does not explicitly contrast with sibling Awd_getInboundShipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as Awd_getInboundShipment or FulfillmentInbound list operations. The 'Runs in your Kuudo deployment, not here' note gives deployment context but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds only a deployment-location caveat and the basic search intent. It does not mention pagination, required query parameters, rate limits, authentication needs, or what kind of 'item-related information' is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but 'Catalog entry.' is a redundant fragment that adds little beyond the tool name. The environment warning is useful but vaguely worded, and the main search statement is clear. Overall it is compact but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A search tool that has no output schema, no documented parameters, and a nearly identical versioned sibling is under-specified. An agent cannot tell which catalog search variant to use, what inputs are required, or what the response shape will be, so the description is not complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema and 100% schema description coverage, the baseline is 4. The description is not required to document parameters, though it could have clarified that the schema allows additionalProperties and that real searches likely need marketplaceIds or keyword/identifier filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Search for a list of Amazon catalog items and item-related information.' It names a specific verb and resource, but it does not distinguish this tool from the similarly named sibling CatalogItems20201201_searchCatalogItems or the single-item getter, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Runs in your Kuudo deployment, not here' provides some contextual guidance about where execution happens. However, the description does not explicitly say when to prefer this search tool over CatalogItems20201201_searchCatalogItems, CatalogItems_getCatalogItem, or ListingsItems_searchListingsItems, and it gives no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details itself. It does mention that the tool runs in the user's Kuudo deployment rather than 'here,' and that cancellation happens, but it omits important behaviors like whether cancellation is irreversible, what happens to associated documents/results, permission requirements, or error/idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it opens with low-value filler ('Catalog entry') and a vague execution-context sentence before finally naming the action. The actual operation is not front-loaded, and at least one sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain how to obtain queryId, what cancellation means for the query lifecycle, and what response or errors to expect. The description covers only the basic action and names the parameter, leaving too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description's mention of a 'queryId parameter' is essential and adds meaning the schema cannot convey. It correctly signals that a queryId is needed, though it does not specify the value's format, source, or whether it is strictly required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Cancels') and a specific resource ('the query specified by the queryId parameter'), making the tool's purpose immediately understandable. It also distinguishes itself from sibling DataKiosk operations like createQuery, getQuery, and getQueries via the cancel action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, such as when to cancel a query as opposed to retrieving it or leaving it running. The description only restates the action and provides no context about prerequisites or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does communicate that the operation returns query details and runs in the Kuundo deployment, but it does not explicitly state read-only/no-side-effect behavior, error cases, or authentication concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the key purpose is not front-loaded: 'Catalog entry' and the deployment note appear before the actual function. The 'Catalog entry' fragment is unclear and does not clearly earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no annotations, no output schema, and an empty input schema, so the description must cover more ground. It does not explain where queryId comes from, what the returned query details contain, or how this relates to the sibling DataKiosk operations, and 'Catalog entry... not here' leaves invocation context ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description's mention of 'the queryId parameter' is the only documentation of how to invoke the tool. It adds essential meaning but still omits type, format, and requiredness information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Returns query details') and identifies the resource by the queryId, clearly implying a single-query lookup rather than a list operation. The 'Catalog entry' sentence adds noise, and there is no explicit comparison to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool over DataKiosk_getQueries, DataKiosk_getDocument, or DataKiosk_createQuery. 'Runs in your Kuundo deployment, not here' is an environment note, not a selection rule; only a weak implication that queryId must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose an important trait: 'Runs in your Kuudo deployment, not here', indicating the tool is not executed in the current context. However, for a scheduling/mutation operation, it does not mention permissions, reversibility, side effects, or failure modes, so behavioral transparency is only partially addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, placing the 'Catalog entry' and 'Runs in your Kuudo deployment, not here' context before the action. Each sentence adds some information, and there is minimal verbosity. It is efficient, though the 'Catalog entry' phrase could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and an empty input schema that still allows arbitrary properties. The description does not provide enough information for an agent to know what inputs are required or what the returned scheduled package information looks like. This is only partially adequate for a tool that an agent must select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties and permits additional properties, so there are no formal parameter definitions to augment. The description names the domain concept ('Easy Ship order') but gives no parameter names, formats, or required inputs. Since the schema is effectively empty, the description should have compensated more for the missing invocation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Schedules an Easy Ship order and returns the scheduled package information.' The 'Catalog entry' phrase adds context but is not the core purpose. It is clear enough to distinguish from the general shipping siblings, though it does not explicitly differentiate from EasyShip_createScheduledPackageBulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives like EasyShip_createScheduledPackageBulk or EasyShip_updateScheduledPackages. The note 'Runs in your Kuudo deployment, not here' gives an environment constraint but not selection criteria. An agent is left to infer when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that this is a catalog entry that runs in the caller's Kuudo deployment, not in the tool environment, and that it mutates the slot. However, it does not mention required permissions, side effects, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and every clause adds information, including the unusual deployment caveat. 'Catalog entry' is slightly cryptic and the purpose appears after the caveat, which is why it is not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations and no output schema, the description is thin: it identifies the package but not the payload shape, accepted time-slot values, response, or prerequisites. An agent could select it but would have to guess at invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares no properties and allows additional properties, so the description's mention of 'specified scheduledPackageId' is the only documentation of the parameter. It adds semantic meaning but omits type, format, requiredness, and any time-slot arguments needed to perform the update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Updates') and resource ('time slot for handing over the package indicated by scheduledPackageId'), making the operation clear and distinct from EasyShip_getScheduledPackage and EasyShip_createScheduledPackage. It does not explicitly contrast with siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this over alternatives, prerequisites, or when not to use it. The only operational note is that it runs in the Kuudo deployment rather than here, which is a deployment caveat, not a usage-versus-alternative guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral disclosure burden. It does disclose that the tool is a 'Catalog entry' that runs in the Kuudo deployment rather than here, and 'Retrieve' signals a read-style operation. But it omits expected response content, authentication prerequisites, and remote-call mechanics, which is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short with three sentences and no filler; the deployment warning is useful. The main weakness is that the actionable instruction ('Retrieve the return item...') comes last, after lower-priority catalog/environment context, so it is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool, the description would be adequate if the ID parameter were documented, but the empty schema leaves a critical invocation gap. There is also no output schema, no mention of return shape, and no connection to the sibling listReturns operation, so the agent is not fully equipped to select and call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero properties while allowing additionalProperties, yet the description references 'the specified ID' without giving its parameter name, type, location, or requiredness. This is the only semantic hint about how to invoke the tool correctly, and it is insufficient for constructing a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the action verb 'Retrieve' with a specific object ('the return item') and a scoping criterion ('with the specified ID'), so the operation is identifiable. It does not explicitly differentiate from sibling tools like ExternalFulfillmentReturns_listReturns, but the ID-based retrieval language makes the core purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need a specific return item by ID. It also offers an environment qualifier, 'Runs in your Kuudo deployment, not here,' which suggests it is not directly executable in the current environment. However, it does not explicitly state when to prefer this over listReturns or provide exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the operation cancels a plan and runs in a Kuundo deployment rather than locally, but it does not state whether cancellation is irreversible, what happens to associated shipments or items, or what response or errors to expect. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the first two fragments are cryptic and 'Catalog entry' adds little functional value. The main action appears last, after an execution-context note that is not explained. A cleaner, front-loaded sentence like 'Cancels an Inbound Plan. Runs in your Kuundo deployment, not here.' would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with no annotations and no output schema, this description is too thin. It omits prerequisites, side effects, reversibility, and any pointer to related tools such as listInboundPlans or getInboundPlan. An agent cannot fully judge the consequences of invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and 100% description coverage, so the baseline is 4. The description adds no parameter-level detail, but none is required. The odd 'additionalProperties: true' is not clarified, though with no documented parameters this is a minor omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Cancels an Inbound Plan' names a specific verb and resource, and the resource distinguishes it from siblings like cancelSelfShipAppointment or cancelShipment. However, the ambiguous preamble 'Catalog entry. Runs in your Kuundo deployment, not here.' muddies the purpose and might confuse an agent about whether this tool is actually callable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer 'use when you need to cancel an Inbound Plan.' There is no explicit guidance about when not to use it, what prerequisites exist, or which alternative tools should be considered. The 'not here' phrase provides some execution-context caution but no actionable routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the disclosure burden. It does state the core effect: confirming a preview and accepting transportation cost changes. However, it omits whether this is final/irreversible, what prerequisites exist, and any downstream consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, but the opening phrase 'Catalog entry.' is a vague fragment that delays the actual purpose. The core action appears in the second sentence, which is less effective than leading with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should provide more operational context. It mentions the environment and the high-level action, but it does not explain when to call it, what inputs are expected (even if none), or what happens after confirmation. The large sibling set makes this omission more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and has 100% coverage, so the description is not required to add parameter semantics. The baseline for zero parameters is 4, and the description does not need to compensate for missing schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Confirm' and 'accept' and names the resource 'shipment content update preview' and 'transportation cost'. It is clearly distinct from the get/generate preview siblings, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance. The phrase 'Runs in your Kuudo deployment, not here' is an environment constraint, but it does not explain when to choose this tool over related siblings like confirmTransportationOptions or how it fits into the preview-generation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add value by revealing pagination behavior and the unusual deployment context (runs in Kuudo, not here). However, it does not disclose return format, error behavior, authentication needs, or side-effect profile, though the stakes are lower for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the purpose sentence is efficient. However, 'Catalog entry' is largely redundant with 'Runs in your Kuudo deployment, not here,' so not every sentence fully earns its place. Still, the critical information is front-loaded and there is no bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an empty schema, no annotations, and no output schema, the description must do substantially more. It covers the basic purpose and pagination but leaves out how to identify which inbound plan, what pagination parameters to pass, and whether the deployment caveat means the agent should not invoke it at all. The ambiguous runtime statement raises more questions than it answers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is empty with additionalProperties: true, so the baseline of 4 for zero parameters applies. However, the description implies the tool requires an inbound plan identifier ('in an inbound plan') and pagination controls, yet documents neither. An agent would have to guess parameter names entirely, and the description fails to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Provides a paginated list of box packages in an inbound plan.' This distinguishes it from sibling list tools by resource type (items, pallets, shipment boxes, packing group boxes), though it doesn't name them. The 'Catalog entry. Runs in your Kuudo deployment, not here' preamble muddies the clarity somewhat, but the core purpose remains identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like FulfillmentInbound_listShipmentBoxes, FulfillmentInbound_listPackingGroupBoxes, or FulfillmentInbound_listInboundPlanItems. The 'Runs in your Kuudo deployment, not here' note ambiguously implies the tool may not be invocable in this environment but provides no direction on what to do instead, leaving the agent without usable routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description does disclose non-obvious traits: it runs in the user's Kuudo deployment rather than the current environment, and it returns only minimal information. However, it does not confirm read-only behavior, pagination, or expected success/failure behavior, so the description only partially carries the behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short for a zero-parameter tool, but it does not front-load the purpose. 'Catalog entry.' is a vague fragment, and the deployment note interrupts the actual functional statement, making the structure less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits what 'minimal information' includes, whether results are paginated, and when to prefer this plan-level list over the many sibling plan/shipment list tools. With no output schema and no annotations, the description needed to carry more contextual weight than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers that fully, so the description has nothing meaningful to add about parameter meanings. With an empty parameter list, the baseline of 4 is appropriate because the schema already documents everything needed for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as listing inbound plans with minimal information, so the resource and verb are explicit. It does not explicitly contrast itself with siblings like listInboundPlanItems or getInboundPlan, and the 'Catalog entry' phrase adds no functional clarity, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as listInboundPlanItems, listInboundPlanBoxes, or getInboundPlan. The only contextual hint, 'Runs in your Kuudo deployment, not here,' concerns environment availability rather than selection criteria, so an agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It adds an environmental trait and 'List' implies read-only behavior, but it does not disclose authentication needs, rate limits, pagination, response contents, or side effects. This is too thin for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it leads with the vague 'Catalog entry' phrase before stating the actual action, so it is not well front-loaded. Every word is not clearly purposeful; 'Catalogue entry' adds little and the deployment note is ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify what the compliance details response contains, what implicit context is needed, and what 'Kuudo deployment' actually means. These gaps leave an agent unable to confidently invoke or interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero defined parameters, the baseline is 4 and the description need not document a parameter schema. It adds domain context by mentioning MSKUs and a marketplace, which helps an agent understand the subject matter even though no parameter names or formats are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear resource ('inbound compliance details for MSKUs in a given marketplace'), making the core purpose understandable. However, the preamble 'Catalog entry' and 'Runs in your Kuudo deployment, not here' adds confusion and does not explicitly distinguish this from related FulfillmentInbound tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Runs in your Kuudo deployment, not here' gives an explicit environment exclusion and implies the tool is only callable in a different deployment. It does not name alternatives or explain when to prefer this tool over siblings like FulfillmentInbound_updateItemComplianceDetails, so the guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a notable behavioral trait: the tool runs in the caller's Kuudo deployment rather than in the current environment, and 'Retrieves' implies read-only behavior. However, it does not explain what a packing option contains, what the response looks like, or what prerequisites apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of filler, but 'Catalog entry' is an unclear label and the actual purpose is delayed until the third sentence. Placing the retrieval statement first and then adding the deployment caveat would make the structure clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list operation, the description captures the core purpose. But with no output schema and no annotations, it leaves open the shape of the returned packing options, the prerequisite relationship to an inbound plan, and the practical meaning of 'runs in your Kuudo deployment, not here.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so any parameter guidance from the description would add significant value. 'For an inbound plan' implies the call needs an inbound-plan context, but no parameter name, type, or required-ness is provided, leaving the agent unsure how to supply it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement is clear: 'Retrieves a list of all packing options for an inbound plan' names a specific verb, resource, and scope, and it distinguishes the tool from siblings like generatePackingOptions or confirmPackingOption. The opening 'Catalog entry' and deployment caveat create some ambiguity about whether this is an executable operation, so it does not reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus generating, confirming, or listing other packing-related resources. 'Runs in your Kuudo deployment, not here' hints at an environment limitation, but it does not name alternatives, prerequisites, or a selection condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does indicate that this is a list-style read operation and that it runs in a different deployment ('not here'), which is useful context. However, it does not mention prerequisites, authentication needs, required inbound-plan identification, or what the list response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly scannable, but the first sentence 'Catalog entry' is vague and does not earn its place. The core purpose is stated only in the final sentence, so the structure is not ideally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation, no-output-schema tool, the description is too thin. It never explains how the agent identifies the inbound plan, whether placement options must first be generated, or what kind of data will be returned. The deployment caveat is useful but does not make the tool fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 'additionalProperties: true', so there are no defined parameters for the description to clarify. The phrase 'for an inbound plan' adds a small amount of conceptual context, and with 0 params the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it 'Provides a list of all placement options for an inbound plan.' This is clearly a list operation and distinguishable from generate/confirm placement options, though it does not explicitly call out those siblings. The opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' adds some ambiguity about whether the tool is actually callable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus FulfillmentInbound_generatePlacementOptions, confirmPlacementOption, or listInboundPlans. The only context is that it runs in the Kuudo deployment rather than here, which is an execution-location note, not a when-to-use explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does add useful context: the tool runs in the Kuudo deployment, not locally, and MSKUs with certain characters need encoding. However, it does not disclose authentication requirements, side effects, or return behavior; 'Get' implies read-only but that is left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly to the point, with no redundant elaboration. The opening 'Catalog entry.' is cryptic and not clearly necessary, but the rest of the description is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an empty schema, no output schema, no annotations, and a large sibling toolset, the description is materially incomplete. It tells the agent what the tool does conceptually but not how to construct a valid request or interpret the response. The deployment note and encoding caveat are helpful but fill only a small portion of the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with additionalProperties allowed, so there are no documented parameter names. The description adds core semantics by mentioning a list of MSKUs and a specified marketplace, plus the encoding note, but it never tells the agent how to pass those values or what parameter names to use. This is useful but not fully actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get preparation details for a list of MSKUs in a specified marketplace.' This is a specific verb and resource combination. It does not explicitly differentiate from sibling tools like setPrepDetails or getPrepInstructions, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance or comparison to alternatives. The phrase 'Runs in your Kuudo deployment, not here' is an environment caveat rather than usage direction. An agent receives no help choosing this over FulfillmentInboundV0_getPrepInstructions or FulfillmentInbound_setPrepDetails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose that this is a read-style operation returning a list. It also surfaces the unusual deployment constraint that it runs in Kuudo, not here. But it leaves out pagination, error behavior, and any return-structure details, and 'Catalog entry' is ambiguous about whether the tool is actually invocable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences and front-loads the important deployment caveat. The phrase 'Catalog entry' adds little and is somewhat confusing, but overall the text is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an empty input schema, the description leaves major gaps: parameter names, pagination behavior, and differentiation from similarly named sibling tools. The deployment caveat is helpful, but the definition is not complete enough for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties: true, so the description is the only source of parameter meaning. It usefully introduces the notion of a specified inbound shipment or a time window, but it never gives parameter names, types, or formats, making it hard for an agent to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete read operation: it returns inbound shipment items, scoped either by shipment or by update time frame. However, the odd 'Catalog entry' opening and the lack of any distinction from the similarly named sibling FulfillmentInboundV0_getShipmentItemsByShipmentId keep it from being a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an environmental exclusion ('Runs in your Kuudo deployment, not here') but does not actually say when to use this tool versus its alternatives, such as FulfillmentInboundV0_getShipmentItemsByShipmentId or FulfillmentInbound_listShipmentItems. It also gives no conditions for choosing the shipment-based mode versus the time-frame mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add an important transparency signal: the tool runs in the user's Kuudo deployment, not in the current environment. However, it does not disclose authentication needs, failure behavior, or whether the returned list has pagination or other traversal requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with no filler beyond the slightly redundant 'Catalog entry' label. The execution environment warning is valuable and included early. It earns its place overall, though the first sentence could be merged or removed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no output schema and no annotations, so the description alone must provide enough context for correct use. It does not document the required input parameter, the structure of the returned items, or how the 'not here' execution model affects invocation. An agent cannot confidently call or route to this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and permissive, so any parameter meaning must come from the description text. The phrase 'specified inbound shipment' hints that a shipment identifier is required, but it never names `shipmentId` or explains how to pass it. This adds slight value beyond the empty schema but is not enough for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear action and resource: 'Returns a list of items in a specified inbound shipment.' It is specific enough to identify the basic purpose, but it does not distinguish this tool from sibling tools like FulfillmentInboundV0_getShipmentItems or FulfillmentInbound_listShipmentItems, and the opening 'Catalog entry' adds mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus the many sibling tools that also deal with inbound shipment items. The environment note ('Runs in your Kuudo deployment, not here') explains where execution happens, but not when the agent should choose this tool or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself, but it only states the return shape and the deployment caveat. It does not explicitly confirm that this is a read-only operation, mention authentication requirements, or explain side effects. The 'not here' statement is useful but insufficient for full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the key facts: deployment context and return value. No sentence is wasted, though 'Catalog entry' is somewhat vague and could be removed or clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description need not be extensive. It does explain the main return value, which helps an agent know what to expect. However, it lacks any reference to related invoice tools, usage context, or what an invoiceDocumentUrl represents, leaving some gaps for a zero-context agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there are no parameter semantics for the description to explain. Per the rubric, zero parameters warrants a baseline of 4, and the description doesn't need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Returns an invoiceDocument object containing an invoiceDocumentUrl.' This is clear enough to identify what the tool does. However, it does not differentiate itself from closely named siblings like Invoices_getInvoicesDocument or Invoices_getGovernmentInvoiceStatus, and the opening 'Catalog entry' adds ambiguity rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It mentions 'Runs in your Kuudo deployment, not here,' which is an environment caveat, but it does not specify conditions, exclusions, or which sibling tools to prefer. There is no actionable usage recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the execution environment ('Runs in your Kuudo deployment, not here') and implies a read-only retrieval operation via 'Returns invoice details.' However, it does not mention side effects, permissions, rate limits, pagination, or output format, leaving the agent with only partial behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easily scannable, but it is not optimally structured. The opening phrase 'Catalog entry' is filler that adds no actionable information, and the core purpose appears only in the second sentence. Removing the filler and front-loading the actual behavior would improve the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema, lack of output schema, and absence of annotations, the description leaves too much unspecified. It does not identify which filters are available, what the returned invoice details look like, whether results are paginated, or how this tool differs from Invoices_getInvoice and the related invoice document/export tools. In a sibling set this large, the description is insufficient for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties but allows additionalProperties, so the schema itself provides no parameter information. The description adds meaning by stating that the tool accepts 'filters that you specify,' which tells the agent the call will include free-form filter parameters. It does not enumerate those filters, but the zero-parameter baseline makes this acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns invoice details for the invoices that match the filters that you specify.' It clearly conveys the plural, filter-based lookup behavior and implies a contrast with the singular sibling Invoices_getInvoice, though it does not explicitly name that sibling. The phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add noise but do not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus its many siblings. The only conditional note, 'Runs in your Kuudo deployment, not here,' addresses execution environment rather than tool selection. With siblings like Invoices_getInvoice, Invoices_getInvoicesDocument, and Invoices_createInvoicesExport, an agent needs explicit direction such as 'use getInvoice for a single invoice' or 'use getInvoicesDocument to download the document.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It does disclose the return value ('ID and URL') and the notable fact that it runs remotely ('in your Kuudo deployment, not here'). However, it omits any details about required context, permissions, URL semantics, or likely side effects, leaving the behavioral picture incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact and contains no verbose filler, but it opens with the cryptic 'Catalog entry' and puts the core function last. The structure could be improved by front-loading the return behavior and adding a brief sibling qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too thin for a tool with no output schema and several close sibling tools. It does not explain which document is returned, how the document ID relates to other invoice endpoints, or what the returned URL is actually for. The 'Kuudo deployment' remark is opaque and does not resolve these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters and schema description coverage is 100%, so there is little for the description to add about parameters. The description correctly avoids inventing parameter details. The schema's 'additionalProperties: true' is unexplained, but the zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action and resource: it 'returns the invoice document's ID and URL.' This is more than a tautology and distinguishes the tool as a retrieval operation for invoice documents. However, it does not explicitly differentiate from the sibling tool Invoices_getGovernmentInvoiceDocument or clarify what an 'invoice document' is relative to an invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. The phrase 'Runs in your Kuudo deployment, not here' is a deployment caveat, not a usage recommendation, and it does not help the agent choose between this tool and related siblings like Invoices_getInvoice or Invoices_getGovernmentInvoiceDocument.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It does disclose that this is a read-like operation ('Gets a list') and that it 'Runs in your Kuudo deployment, not here,' which is an unusual and important execution-context warning. However, it fails to explain prerequisites, expected output, or what 'additional seller inputs' means, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no large amounts of filler, so it is reasonably concise. However, it is not front-loaded: the core purpose sentence comes last, after the vague 'Catalog entry' and environment warning. It could be reorganized to state the action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a rich sibling context, the description is too thin. It never explains what 'additional seller inputs' are, how the ship method is identified, or how this tool fits into the Merchant Fulfillment workflow. An agent would likely struggle to decide when and how to use it, especially with similar shipping-related tools present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero documented parameters and 100% schema coverage, there is no parameter burden for the description to carry. The schema is empty, so the baseline of 4 applies. The description does not need to explain parameter semantics because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: 'Gets a list of additional seller inputs required for a ship method.' This is specific enough to convey the basic purpose. However, it does not distinguish this from the overlapping sibling Shipping_getAdditionalInputs, and the opening phrase 'Catalog entry' adds no functional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' hints that the tool may not be callable in the current context, but it does not say when to invoke it or what to use instead. Sibling Shipping_getAdditionalInputs appears to be a close alternative and is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It helpfully discloses that this is a 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' which signals non-executability in the current context. However, it does not clarify side effects, permissions, or what precisely the returned offers contain, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the critical 'not here' caveat. The fragment 'Catalog entry.' is somewhat vague, but overall the text is efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema and lack of an output schema, the description should provide enough context for correct invocation, but it does not. The 'not here' caveat is useful, yet the missing request-detail specification and lack of sibling differentiation leave the definition incomplete for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, so there is little to document, but additionalProperties: true suggests arbitrary parameters are accepted. The description references 'specified shipment request details' without enumerating what those details are, so an agent cannot construct a valid request from the definition alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns a list of shipping service offers that satisfy the specified shipment request details.' This distinguishes it as a read/query operation within the MerchantFulfillment domain, though it does not explicitly differentiate it from sibling tools like Shipping_getRates or MerchantFulfillment_createShipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' hints that it may not be invocable in the current environment, but it does not name an alternative or provide a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does convey a read-only intent with 'Returns' and mentions an unusual execution context ('Runs in your Kuudo deployment, not here'). However, it omits required inputs, authorization needs, and failure behavior, and the 'Catalog entry' phrasing is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the first sentence is vague and wastes the prime position on 'Catalog entry' rather than the actual purpose. The useful functional statement comes only after a confusing environment note, so the structure is not ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no parameter schema, and no annotation context. The description explains what the tool returns at a high level but not how the agent should identify the shipment, what inputs to provide, or what response shape to expect. An agent cannot reliably invoke this tool correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties allowed, so there are zero documented parameters and nothing for the description to clarify beyond that. The description implies that an existing shipment must be identified, but does not name shipmentId. Per the 0-parameter baseline, the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns the shipment information for an existing shipment.' This clearly indicates a read-only lookup. However, it does not explicitly differentiate itself from sibling getShipment tools like ShippingLegacy_getShipment or FulfillmentInbound_getShipment, and the 'Catalog entry' opener adds confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as Shipping_getTracking, ShippingLegacy_getShipment, or FulfillmentInbound_getShipment. The phrase 'Runs in your Kuudo deployment, not here' hints that the tool may not be invocable in the current context, but it never states when to use or avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does disclose a message-sending side effect, but it does not mention required authorization/order context, whether the action is reversible, or what result the caller can expect. The 'Runs in your Kuudo deployment, not here.' line adds execution context but not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the second sentence conveys the actual action, but the opening 'Catalog entry.' is filler and the deployment note is placed before the purpose. While not bloated, the ordering weakens the definition's usefulness for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely needs some context such as which customer/order and what service details to confirm, but neither the schema nor the description provides that; the schema is empty and the description only names the general scenario. With no annotations and no output schema, an agent lacks enough information to invoke the tool with correct inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so there are no parameter semantics for the description to clarify; the 0-param baseline is 4. The description does not add parameter detail, but 'additionalProperties: true' might allow arbitrary inputs, and the description would be stronger if it warned about or named expected inputs. Still, no schema-described parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the core action ('Sends a message to contact a Home Service customer') and the resource/domain ('Home Service', 'service call'), which distinguishes it from sibling messaging tools like createConfirmOrderDetails or createConfirmDeliveryDetails. However, the first sentence 'Catalog entry. Runs in your Kuudo deployment, not here.' is a meta-comment rather than a functional statement, so it is not a fully crisp 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: use this for arranging a service call or gathering pre-service information. It does not explicitly name alternatives, exclusions, or conditions such as 'use confirmCustomizationDetails instead when ...', so the guidance is present but not explicit about sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It adds one useful behavioral fact—execution happens in the user's Kuudo deployment, not the current environment—which hints at remote or asynchronous operation. However, it does not disclose side effects, persistence, required permissions, or return behavior for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not verbose, which is good. However, the first sentence 'Catalog entry' is filler that contributes no actionable meaning, and the primary functional statement appears last rather than being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and minimal description, an agent is left without key information: what a destination resource consists of, what inputs may be supplied despite additionalProperties: true, and what the expected result or response is. The environment caveat is useful but insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero defined parameters, so the baseline is 4. The description does not need to document parameter specifics, though the schema allows additionalProperties: true, and the description gives no hint about what payload fields might be expected for creating a destination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Creates a destination resource') and the purpose ('to receive notifications'), so an agent can identify the tool's basic function. However, it does not explicitly distinguish this from similar sibling tools like Notifications_createSubscription, and the opening phrase 'Catalog entry' adds ambiguity rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives, such as Notifications_createSubscription or Notifications_getDestinations. The statement 'Runs in your Kuudo deployment, not here' provides environment context but does not explain selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add some useful context: the tool runs in a Kuudo deployment, not in the current environment, and the response includes featured buying options. However, it does not state whether the operation is read-only, requires authentication, has side effects, or how it behaves beyond returning a summary response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of redundant detail, but the first sentence fragments 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are cryptic and take up space without clearly supporting the invocation decision. The more useful functional information is front-loaded in the second sentence, but overall structure is somewhat disjointed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to explain both inputs and return behavior more completely. It mentions the ASIN/marketplaceId combination but leaves how to supply them ambiguous, and it does not describe the response structure beyond 'competitive summary response.' The environment statement is also too vague to tell the agent whether this tool is callable at all.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with no documented parameters, so the baseline is 4. The description adds meaning by naming the key inputs (ASIN and marketplaceId) even though they are absent from the schema. It does not explain how to pass them given the empty schema, but for a zero-parameter schema this is still valuable semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a return action: it returns the competitive summary response with featured buying options for a specific ASIN and marketplaceId combination. The verb and resource are clear, and the phrase about featured buying options helps distinguish it from generic pricing tools. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' introduces ambiguity about whether this tool actually executes in the current environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus closely related siblings like ProductPricing_getCompetitivePricing or ProductPricing20220501_getFeaturedOfferExpectedPriceBatch. The statement 'Runs in your Kuudo deployment, not here' hints at environment constraints but does not explain when the agent should or should not invoke it. There are no explicit alternatives or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the return concept ('lowest priced offers'), the batch scope, and the unusual runtime context ('Runs in your Kuudo deployment, not here'). But it omits side effects, auth needs, rate limits, batch limits, or what 'not here' means operationally, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the 'Catalog entry' sentence contributes no useful information and makes the structure feel like a truncated auto-generated label. The core return statement is clear, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema with additionalProperties true and no output schema, the description should explain how to specify the SKU batch and what the response will look like. It only says 'by SKU' and 'returns offers,' leaving the agent to guess the actual request shape and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters with additionalProperties true, so the 0-parameter baseline of 4 applies. The description adds the relevant semantic concept 'by SKU,' which is helpful even though it does not specify payload formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Returns the lowest priced offers for a batch of listings by SKU.' This clearly communicates the tool's core purpose and the 'batch' wording distinguishes it from the singular ProductPricing_getListingOffers. However, the opening 'Catalog entry' fragment is vague and does no work, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' hints at an execution environment, but it does not explain when to choose this tool over alternatives such as ProductPricing_getItemOffersBatch or ProductPricing_getListingOffers. There is no explicit when-to-use, when-not-to-use, or alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It indicates the tool runs in the Kuudo deployment, which is useful context, but it does not state side effects, return shape, pagination, or any limitations. 'Catalog entry' is cryptic and adds little. For a parameterless search operation, more explicit behavioral disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence 'Catalog entry.' is vague and does not earn its place. The second sentence contains the core meaning. The environment note is useful but phrased ambiguously ('not here' is unclear). Overall it is compact but could be restructured to front-load the actual search behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what the returned list looks like, what 'definitions available' means, and what environment constraints apply. It does none of this beyond the Kuudo note. For a parameterless tool it is minimally viable, but an agent lacks enough context about the result format and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to clarify. The description correctly does not invent parameter details. The baseline score of 4 applies because the description cannot add meaning where no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search for and return a list') and resource ('Amazon product types that have definitions available'). It is clearly a search/list operation and distinguishes itself from sibling ProductType_getDefinitionsProductType, which implies retrieving definitions for a single type. The opening 'Catalog entry' is vague but does not undermine the core verb+resource clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when the agent needs a list of Amazon product types that have definitions. However, it does not explicitly state when to prefer this over getDefinitionsProductType, nor does it mention any exclusions or prerequisites. The phrase 'Runs in your Kuudo deployment, not here' gives environment context but not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does add operational context by calling this a catalog entry and stating it runs in a Kuudo deployment rather than here, and 'returns' implies a read-only operation. However, it omits details about authentication, side effects, data scope, and how the metrics are aggregated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly efficient, but 'Catalog entry' and 'Runs in your Kuudo deployment, not here' partly overlap and the main purpose sentence is placed last. It is compact rather than optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the returned metrics contain and how this tool relates to the similarly named Replenishment20221107_listOfferMetrics. It does not provide enough context to disambiguate the version or the exact return shape, leaving a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero named or required parameters, so the schema is already exhaustive and the description has no parameter semantics to clarify. The empty schema with additionalProperties allowed creates no expectation that the description must explain arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Returns aggregated replenishment program metrics for a selling partner's offers' provides a clear verb, resource, and scope. It does not, however, differentiate this versionless tool from the sibling Replenishment20221107_listOfferMetrics or from Replenishment_listOffers, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over Replenishment20221107_listOfferMetrics or Replenishment_listOffers. 'Runs in your Kuudo deployment, not here' is a deployment constraint rather than a selection rule, so the agent is left without alternative-based direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the core behavior (returns details, possibly including reportDocumentId) and an unusual environment trait (runs in Kuudo deployment, not here), but it does not state auth requirements, error behavior, or other operational effects. For a read-oriented getter this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with no redundant elaboration. The front-loaded 'Catalog entry' is slightly cryptic, but the rest is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description must provide enough to invoke it correctly, but it leaves the report identifier parameter undefined and provides no return structure beyond reportDocumentId. The deployment caveat is useful but the missing invocation detail is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero properties, yet the description says the tool acts on 'the report that you specify,' implying an input that is never named. additionalProperties:true does not tell an agent what key to use for the report identifier, so the description fails to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as returning report details for a specified report and highlights the reportDocumentId field, which helps distinguish it from document-content retrieval siblings like Reports_getReportDocument. The opening 'Catalog entry' and deployment note add some ambiguity about whether this is directly callable, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some usage context—'Runs in your Kuudo deployment, not here'—which signals that the tool is not meant to be invoked in the current environment. However, it offers no explicit when-to-use guidance or naming of alternatives such as Reports_getReportDocument or Reports_getReports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does note that the operation runs in a Kuudo deployment rather than here, and that it creates a schedule request, but it omits financial side effects, required authorization, idempotency, or response behavior. For a financial mutation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded with the important deployment caveat. The phrase 'Catalog entry.' is nearly redundant with 'Runs in your Kuudo deployment, not here.', but the overall wording is efficient and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial create operation with no annotations, no output schema, and an open input schema, the description is not complete enough for safe invocation. It gives a useful high-level purpose and deployment context, but it does not define required inputs, what happens when the schedule is created, or what the caller should expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and allows additional properties, so the description adds some conceptual meaning by mentioning source and destination accounts. However, it does not name the actual parameter keys, value formats, or which fields are required, leaving invocation details largely guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and a specific resource ('transfer schedule request'), and adds source/destination context: from a Seller Wallet account to another customer-provided account. This makes it distinguishable from SellerWallet list/get/update/delete schedule siblings, though it does not explicitly name an alternative tool to differentiate against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this tool when a transfer schedule request needs to be created. However, the description does not state when not to use it, or how it compares to related tools like SellerWallet_createTransaction or SellerWallet_getTransferPreview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Retrieve' implies a read-only operation and 'potential fees' suggests no actual charges are applied, which are useful hints. The explicit statement that it 'Runs in your Kuudo deployment, not here' is also a significant behavioral disclosure. However, the description does not clarify what 'Catalog entry' means, what the returned list contains, or whether authentication or account context is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and avoids unnecessary length, but the ordering is weak: the core purpose sentence comes last, after the confusing 'Catalog entry' label and the deployment note. The first two sentences may be contextually meaningful, but they are not clearly connected to how an agent should invoke the tool, so the structure is only adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should provide more detail about the expected result, the meaning of 'transaction', and whether the tool is directly invocable in this MCP environment. The deployment note is helpful, but it creates ambiguity rather than resolving it, and the absence of any return-structure or usage-context information leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined properties, so there are no parameter semantics to document. The baseline for a zero-parameter tool applies, and the description does not need to explain inputs. The empty schema and the description do not conflict.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a specific and intelligible purpose: 'Retrieve a list of potential fees on a transaction.' This clearly identifies the resource ('potential fees') and action ('retrieve'), and it differentiates the tool from sibling SellerWallet tools that manage accounts, balances, transactions, and transfer schedules. However, the opening phrases 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add confusion about whether this is actually an invocable tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus any alternative, such as before creating a transaction or prior to setting up a transfer schedule. 'Runs in your Kuudo deployment, not here' is deployment context, not usage guidance; it does not tell the agent when to select this tool or which sibling to prefer. The agent is left to infer the appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does disclose an important behavioral trait: the tool runs in the user's Kuudo deployment, not in the current environment. But it does not mention read-only semantics, authentication needs, output format, or whether 'Catalog entry' means it is only a placeholder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the opening 'Catalog entry' is vague and adds little value. The most useful information appears in the final clause, so the structure is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no sibling differentiation, this description leaves the agent unsure what the tool returns, how it differs from related SellerWallet tools, and whether 'Catalog entry' means the tool is actually invocable. More context is needed for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is fully covered, so there are no parameter semantics for the description to add. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Get Seller Wallet accounts for a seller' names a clear verb and resource. However, it does not explicitly differentiate itself from sibling tools like SellerWallet_getAccount or SellerWallet_listAccountBalances, and the 'Catalog entry' wording adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as SellerWallet_getAccount or SellerWallet_listAccountBalances. The only contextual note, 'Runs in your Kuudo deployment, not here,' explains environment location rather than usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; 'Retrieve' makes clear this is a read operation intended to list transactions. It also adds the 'Runs in your Kuudo deployment, not here' execution context, but it doesn't disclose pagination, filtering behavior, or whether a bank account must already exist or be accessible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and scannable in three sentences, with the key action clearly stated. 'Catalog entry' is arguably filler, but the overall size is appropriate and the meaning is not buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, no pagination/filter guidance, an implied but unspecified account identifier, and numerous SellerWallet siblings, the description leaves too much to inference. An agent cannot tell the return shape, limits, or required account scope from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, so the 'given Seller Wallet bank account' phrase is the only semantic guidance, but it doesn't name or format the required identifier. The description adds meaning beyond the empty schema but is not actionable enough to fully compensate for the mismatch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence uses a specific verb ('Retrieve') and a clear resource ('list of transactions for a given Seller Wallet bank account'), which distinguishes it from getTransaction, getAccount, and listAccountBalances. The opening 'Catalog entry. Runs in your Kuudo deployment, not here.' is not purpose-related and slightly muddles the message, but the main action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose this over SellerWallet_getTransaction or SellerWallet_listAccountBalances, and no exclusions or alternative routing. The only contextual hint is the 'Kuudo deployment' execution note, which says nothing about use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: the operation runs in the user's Kuudo deployment rather than in the current environment, which is non-obvious and useful. It also implies a side effect by saying 'Creates'. However, with no annotations and no output schema, it does not explain whether authentication is needed, what the response contains, or whether the creation is synchronous, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of verbosity, which is good. However, 'Catalog entry' is a fragment that adds no meaning and distracts from the actual purpose. The key action 'Creates an upload destination' is placed last, so the description is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotated safety profile, no output schema, and no parameter definitions, the description alone must prepare the agent to invoke the tool correctly. It does not explain what an upload destination is, what the caller should do with the result, or how this tool relates to the very similar 'Uploads_createUploadDestinationForResource'. The 'Kuudo deployment' note hints at an important environmental detail but stops short of explaining its consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no defined parameters, so the baseline is 4. The description does not need to elaborate on parameter meanings because there are none specified. However, additionalProperties is true, which technically allows arbitrary properties, but the context indicates zero parameters, so this is not a major issue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Creates an upload destination' clearly states the verb and resource, giving the agent a basic understanding of the operation. However, 'Catalog entry' is cryptic and 'Runs in your Kuudo deployment, not here' adds environmental context but does not clarify what the tool is for. It is specific enough to distinguish the core action, but the odd preamble prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The sibling 'Uploads_createUploadDestinationForResource' appears to perform a very similar task, yet the description does not mention it or explain how these tools differ. The 'Runs in your Kuudo deployment, not here' line implies a deployment consideration but leaves the actual selection criteria entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only says the tool cancels a shipment and runs elsewhere, but it does not explain side effects, required permissions, reversibility, idempotency, or what happens to linked records. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the essential operational warning before stating the action. No sentence is outright redundant, though the separate 'Catalog entry' and 'not here' clauses could be merged without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a cancellation operation with no annotations, no output schema, and no parameter definition in the schema. The description does not disclose the response shape, failure behavior, prerequisites, or how to supply shipmentId. Given the legacy routing warning, the agent can guess intent but cannot safely construct or invoke the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no properties, so the description's mention of 'shipmentId' is the only signal that such a parameter exists and identifies the shipment. This adds meaning beyond the empty schema, but it omits the parameter's type, format, requiredness, and how it should be passed — a notable deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb and resource: 'Cancel a shipment by the given shipmentId.' This is specific enough to understand the tool's core purpose. However, it does not distinguish itself from the sibling Shipping_cancelShipment, and the 'Catalog entry' preamble slightly muddles the clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' provides some usage context by warning that the tool is not intended for direct invocation in this environment. However, it gives no explicit comparison to Shipping_cancelShipment or any other alternative, and it never states when a caller should choose this legacy tool over its modern sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only adds an unclear deployment caveat ('Runs in your Kuudo deployment, not here') and the word 'Retrieve' to imply a read operation. It does not disclose output format, error behavior, idempotence, authentication, or rate-limit characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly scannable, but the opening 'Catalog entry.' is filler and the deployment caveat is vague. The substantive purpose appears only in the final sentence rather than being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, an open input schema, and many nearby shipping label/document tools, the description is too thin. It names the identifiers but leaves the agent to guess exact parameters, the runtime return value, and how this tool differs from sibling label/document retrieval operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the description's mention of 'the shipment id and tracking id' is essential and adds real meaning beyond the schema. It stops short of specifying exact key names, formats, or which identifier is required, but for an open schema this is a useful baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Retrieve shipping label' using shipment id and tracking id. It does not, however, contrast with sibling label/document retrieval tools such as Shipping_getShipmentDocuments or ExternalFulfillmentShipments_generateShipLabels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: call this when a shipping label must be retrieved and you have shipment/tracking identifiers. There is no explicit when-not-to-use guidance, no prerequisites, and no reference to alternative Shipping* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that this is a purchasing action, executes in a remote Kuundo deployment, and returns details and documents. However, it omits important behavioral context such as financial charge, irreversibility, prerequisite steps like obtaining rates, and authentication expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point, but the opening 'Catalog entry.' is non-informative filler and occupies the front-loaded position without adding value. The remaining sentences are efficient, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an agent trying to invoke this tool correctly: no input payload guidance, no differentiation from similar purchase tools, no side-effect warnings, and no output structure. The empty schema with additionalProperties true makes the missing payload context especially problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters and allows additionalProperties, so the schema provides no field-level guidance. With 0 parameters, the baseline is 4, and the description is not required to enumerate parameters, though a note about expected purchase payload fields would be helpful given additionalProperties is true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool purchases a shipping service and returns purchase-related details and documents, so the core verb and resource are identifiable. However, it does not distinguish itself from Shipping_directPurchaseShipment, Shipping_oneClickShipment, or ShippingLegacy_purchaseShipment, and the opening 'Catalog entry.' adds noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus the many purchase/shipment siblings. 'Runs in your Kuundo deployment, not here' is environment context, not usage guidance, and no prerequisites or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the operation is destructive ('replaces all ASINs'), conditional ('if available'), and runs in a different deployment ('not here'). However, it does not disclose authentication needs, reversibility, failure behavior, or rate limits, so the disclosure is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but the first sentence 'Catalog entry' is unhelpful filler and the key action is placed after the deployment caveat. The description would be better structured by leading with the replace behavior and then adding the execution-context note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and an empty/open input schema, so the description must do more to be safely usable. It states the central action and hints at remote execution, but omits the request contract, prerequisites, environment implications, and expected response, leaving the tool incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the description is the only real source of parameter meaning. It adds conceptual value by mentioning 'ASINs' and a 'specified A+ Content document', but it does not provide parameter names, formats, or required fields, which makes it hard to construct a correct request from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 replaces all ASINs related to a specified A+ Content document. This is more informative than a tautology, though it does not explicitly differentiate itself from sibling AplusContent operations such as listing or validating ASIN relations. The opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add confusion but do not fully obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool should be used when replacing all ASIN relations for an A+ Content document. It does not mention when not to use it, compare it to sibling tools, or state prerequisites such as an existing content document or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal an important trait: the tool runs in the Kuudo deployment, not in the current environment. It also implies a read-only retrieval operation, but it does not disclose output format, error behavior, authorization needs, or what exactly 'box labels' returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of unnecessary detail. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add caveat context, while the core retrieval purpose is clearly present. It could be slightly better front-loaded by leading with the action, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is not sufficient for an agent to confidently call this tool. It does not specify how to pass the shipment ID, what the label output looks like, or whether the tool is even invocable from the current environment given the 'not here' caveat. The empty schema and absent output schema make these gaps material.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties but allows additionalProperties, so the description is the only source of parameter intent. It identifies the key concept ('shipment ID that you specify') even though it fails to give the actual property name or format. With 0 declared parameters, the baseline is 4, and the description adds some semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Retrieves the box labels') and a specific resource ('for a shipment ID that you specify'). This is clear enough to distinguish from the sibling Awd_getInboundShipment, which suggests full shipment data rather than labels, though it never explicitly differentiates itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives like Awd_getInboundShipment or Shipping_getShipmentDocuments. The odd phrase 'Runs in your Kuudo deployment, not here' hints at an environment limitation but does not tell the agent when to use or avoid the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose effects and risks. It only states that the tool runs elsewhere and that it updates transport details; it does not say whether the update is idempotent, what permissions are needed, what gets modified, or what is returned. This leaves the mutation's behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At roughly fifteen words, the description is compact and communicates the update purpose efficiently. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' convey environment context, though they could be merged into one clearer sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should specify which shipment or transport details are required, any side effects, and the expected response. It gives none of those, and the empty schema with additionalProperties true leaves invocation an open question even if the environment caveat is set aside.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties, so there are no parameter semantics for the description to add; the empty schema already captures this. While additionalProperties:true permits arbitrary fields, the absence of defined properties means parameter documentation is not a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Updates transport details for an AWD shipment' names a specific action and resource, so an agent can see what the tool does. It does not explicitly differentiate from siblings like Awd_updateInbound or FulfillmentInbound_updateShipmentTrackingDetails, and the 'Catalog entry' phrasing adds ambiguity about whether the tool is actually executable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' is a clear environment caveat that tells an agent this tool is not available in the current context. However, it provides no 'when to use' conditions, prerequisites, or alternative tool names, so guidance for selection among siblings is largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal a notable trait: the tool 'Runs in your Kuudo deployment, not here,' suggesting it is not executed directly by this MCP server. However, it does not clarify authentication, side effects, or what 'invoice status' entails, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, using only three short clauses, and every part adds some information. The placement is not ideal because the actual purpose statement appears after the 'catalog entry' and 'runs in Kuudo' notes, but overall it is efficient and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no defined parameters, the description leaves critical gaps: it does not specify what identifiers to pass, how the Kuudo deployment context affects invocation, what the returned status looks like, or how this differs from many sibling invoice-related tools. An agent would struggle to confidently call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so there are no defined parameters to rely on. The description's phrase 'for the order or shipment you specify' is the only semantic hint that some identifier is required, which adds value beyond the schema. Given the 0-parameter baseline of 4, this is adequate, though it lacks parameter names or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core function: 'Returns the invoice status for the order or shipment you specify,' which is a specific verb and resource. However, the prefatory 'Catalog entry. Runs in your Kuudo deployment, not here' is ambiguous and the description does not differentiate it from similar sibling tools like ShipmentInvoicing_getInvoiceStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as DeliveryByAmazon_submitInvoice, ShipmentInvoicing_getInvoiceStatus, or Invoices_getGovernmentInvoiceStatus. The description does not mention any conditions, exclusions, or selection criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It indicates that the operation runs outside the current environment and implies a write action, but it does not explain side effects, prerequisites, authentication needs, or what happens after submission. The 'not here' note is a useful behavioral trait, but the operational behavior remains largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of filler, with each clause contributing either deployment context or the core operation. The three fragments feel slightly abrupt, but the content is efficient and front-loads the most important environmental caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no defined parameters, the description leaves significant gaps. It does not specify what inputs are required, what the response looks like, or how this relates to the sibling ShipmentInvoicing_submitInvoice. As a catalog entry, the 'not here' statement is helpful, but it is not enough for an agent to correctly invoke or reason about the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains zero defined parameters, so the baseline is 4. The description adds the only semantic clue: the invoice is tied to 'a given order or shipment,' implying an identifier or reference is needed. It does not name concrete parameters, but with no schema properties to document, the description provides reasonable minimal context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Submits a shipment invoice for a given order or shipment.' This goes beyond the tool name by specifying the invoice type and target. However, it does not differentiate from the very similar sibling ShipmentInvoicing_submitInvoice, and the 'Catalog entry' opener adds context rather than clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful environmental constraint: 'Runs in your Kuudo deployment, not here.' This tells the agent not to treat the tool as locally invocable. However, it gives no explicit guidance about when to use this tool versus related alternatives such as ShipmentInvoicing_submitInvoice or DeliveryByAmazon_getInvoiceStatus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It does disclose an important execution trait—'Runs in your Kuudo deployment, not here'—and 'Retrieve' implies a read-only operation. However, it omits pagination, response structure, authentication, rate limits, and possible scoping details, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The meaningful content is compact: one clause for environment and one for purpose. The leading 'Catalog entry.' is noise that does not help an agent select or invoke the tool, so the description is not perfectly economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description gives the essential action and deployment context. It is usable but thin: no output schema exists, yet the description does not describe response shape, ordering, or limits, and the 'Catalog entry.' label adds ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and the context reports 0 parameters with 100% schema coverage, so there are no parameter semantics to document. The baseline of 4 applies because no parameters can create ambiguity. The description adds nothing about the permissive additionalProperties:true field, but that field is not a documented parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Retrieve a list of return items' states a clear verb and resource. The list scope distinguishes it from the sibling ExternalFulfillmentReturns_getReturn, though the description does not explicitly name that alternative. The opening 'Catalog entry.' adds no semantic content and slightly muddies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over getReturn or any other returns/shipping tool. The only contextual note, 'Runs in your Kuudo deployment, not here,' is an environment constraint rather than usage direction. The agent is left to infer when a bulk list of return items is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior itself. It does indicate the operation is a read ('Returns...') and adds an unusual execution-location caveat ('Runs in your Kuudo deployment, not here'). But it doesn't explain what 'Kuudo deployment' means, whether results are current, or any prerequisites, leaving important behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the purpose in the final sentence, but the first two fragments—'Catalog entry.' and 'Runs in your Kuudo deployment, not here.'—are loosely structured and one is unclear. It could be tightened into a single coherent sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool, the description states what it returns and where it runs, which is close to sufficient. However, with no output schema, 'a list of inventory summaries' is vague about the response shape, and the unexplained 'Kuudo deployment' reference leaves the calling environment unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already complete (100% coverage). The description has nothing to add to parameter semantics, matching the baseline 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Returns a list of inventory summaries.' This is enough to identify it as a read/list operation among the FbaInventory siblings (createInventoryItem, addInventory, deleteInventoryItem). However, the opening 'Catalog entry' is ambiguous and the description doesn't explicitly contrast it with sibling tools, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives, such as FbaInventory_addInventory or FbaInventory_createInventoryItem. The note 'Runs in your Kuudo deployment, not here' provides deployment context but does not help an agent choose this tool for a task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does add context: it identifies the tool as a 'Catalog entry' that runs in the Kuudo deployment, which is a meaningful execution-scope disclosure. However, it does not disclose which filters are supported, pagination behavior, or return shape, which a filter-based list operation should surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the most operationally critical caveat ('Catalog entry. Runs in your Kuudo deployment, not here') front-loaded. The final sentence is mildly redundant ('feed details for the feeds') and could be tightened, but the overall size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a filtering list operation with an empty schema, additionalProperties allowed, and no output schema — yet the description gives no valid filter names, no pagination behavior, and no sense of what a 'feed detail' contains. An agent has no guardrails for constructing a correct invocation, so the definition is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes zero properties and only allows open-ended additionalProperties, so the description's phrase 'filters that you specify' provides real added meaning by telling the agent that arbitrary properties are interpreted as feed filters. It does not enumerate valid filter keys or value formats, so it stops short of full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource — 'Returns feed details for the feeds that match the filters' — and the plural framing signals a list operation rather than a single-feed fetch. It is clear enough to distinguish from Feeds_getFeed on plural-vs-singular grounds, but it never explicitly names that sibling or the split, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage-related context is the execution caveat 'Runs in your Kuudo deployment, not here,' which clarifies scope but gives no guidance on when to select this tool over Feeds_getFeed, Feeds_createFeed, or Feeds_cancelFeed. No exclusions, alternatives, or triggering conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It provides one non-obvious fact: the operation is a catalog entry that runs in the Kuudo deployment rather than in the current environment. However, it does not disclose side effects, reversibility, or prerequisites, which would be valuable for a confirmation-type mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, roughly 20 words, but the first two sentences ('Catalog entry. Runs in your Kuudo deployment, not here.') are vague and delay the core action to the final sentence. It is compact but not ideally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description supplies the minimum semantic content needed to understand what confirmPlacementOption does. It omits workflow context such as the need to first generate/list placement options, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters, so there is little for the description to add; the baseline for 0 parameters is 4. The description implies conceptual identifiers such as placement option and inbound plan, but no declared parameters need documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The final sentence clearly states the action ('Confirms') and the resource ('placement option for an inbound plan'), distinguishing it from siblings like listPlacementOptions, generatePlacementOptions, and confirmPackingOption. The opening 'Catalog entry' adds no purpose information but does not obscure the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. The description does not say to call this after generating or listing placement options, nor does it mention any alternative. 'Runs in your Kuudo deployment, not here' is a deployment note rather than a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does disclose an important execution trait: 'Runs in your Kuudo deployment, not here,' and 'Provides the full details' implies a read-only operation. But it omits side-effect guarantees, authentication requirements, error behavior, or what 'full details' includes, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly free of fluff, with the core purpose in one sentence. However, the purpose is not front-loaded—the first sentence 'Catalog entry' provides little value and delays the actual action, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no output schema and an empty schema that still allows additional properties, the description should compensate by specifying required identifiers (e.g., shipmentId, inboundPlanId) or the shape of returned details. It does neither, leaving an agent with insufficient information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description adds mild semantic context by indicating the shipment is tied to an inbound plan, suggesting that identifiers for both may be needed. It does not name parameters, but since the schema declares none, it is not penalized heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Provides the full details for a specific shipment within an inbound plan.' This clearly differentiates it from other shipment-related tools by scoping to inbound plan shipments. However, the opening 'Catalog entry' is meta-noise and it does not explicitly name sibling alternatives, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives like FulfillmentInbound_listShipmentItems, Awd_getInboundShipment, or ShippingLegacy_getShipment. The description only states what the tool does, not the conditions or context in which it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully notes the operation runs in the customer's Kuudo deployment rather than in the agent's environment, and 'page' implies paginated retrieval. However, it does not mention permissions, response format, or any operational side effects beyond reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of filler. It opens with the catalog/deployment context and ends with the functional statement. Each clause earns its place, though the purpose statement would be clearer if placed first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too incomplete for confident invocation: it refers to a 'given packing group' but does not say how to provide it, and the empty schema gives no parameter names. There is no output schema and no annotation coverage, so the agent lacks required input and return-value context. The deployment note is useful but does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is empty with additionalProperties true, so the description adds meaning by indicating that a packing group is the scope and that results are returned in pages. It does not name the exact parameter key or format for the packing group, but with no declared parameters the baseline is satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action, resource, and scope: 'Retrieves a page of boxes from a given packing group.' This distinguishes it from siblings like listPackingGroupItems, which retrieves items rather than boxes. The opening 'Catalog entry' phrase adds slight ambiguity, but the core purpose is identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus related tools such as listInboundPlanBoxes, listShipmentBoxes, or listPackingGroupItems. The deployment note 'Runs in your Kuudo deployment, not here' is context but does not help select among alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does provide some behavioral context: the operation is a paginated list and it runs in the user's Kuudo deployment rather than in this environment. However, it does not disclose pagination mechanics, output structure, permissions, rate limits, or confirm that the operation is read-only beyond the implication of 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly front-loaded, with the deployment context stated early and the core purpose in a single clear sentence. The fragment 'Catalog entry' is vague and adds little value, but overall there is no wasteful prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool an agent may need to invoke, the description is incomplete: it does not explain how to identify a shipment, how pagination inputs/outputs work, or what the response contains, and the input schema offers no parameters. The 'Runs in your Kuudo deployment, not here' note is useful but also makes the actual invocation path unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented parameters and zero required parameters, so there is no parameter semantics for the description to add. The schema's 'additionalProperties: true' is unhelpful, but the 0-parameter baseline applies and the description offers no misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Provides a paginated list of box packages in a shipment' clearly states the verb, resource, and scope. However, it does not explicitly differentiate this tool from sibling FulfillmentInbound list operations like listInboundPlanBoxes or listPackingGroupBoxes, and the opening 'Catalog entry' adds ambiguity rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as listShipmentItems, listShipmentPallets, or listInboundPlanBoxes. The deployment note ('Runs in your Kuudo deployment, not here') hints at where execution happens but does not explain the selection conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates that the operation is a rename and that it is not executable here, but it does not mention required permissions, side effects, idempotency, or what happens to the plan beyond the name change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not bloated, but it front-loads a vague 'Catalog entry' and a deployment note before the actual operation statement. The key action is left to the final sentence, so the structure is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the input schema is empty, so the description is the only source of operational context. It gives the operation and deployment constraint but omits request parameters and any behavioral details needed to actually call or exercise the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is empty with additionalProperties true, yet the operation logically requires at least an inbound plan identifier and a new name. The description does not name, format, or even hint at these parameters, so the agent cannot construct a valid request from the description or schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence, 'Updates the name of an existing inbound plan,' names a specific verb, resource, and object, and the tool name differentiates it from the sibling updateShipmentName. The opening 'Catalog entry' and 'Runs in your Kuundo deployment, not here' add ambiguity about whether this is a callable operation, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the tool runs in a Kuundo deployment, not in this environment, which is a useful when-not-to-invoke exclusion. It does not name alternatives or conditions for updating an inbound plan, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose two meaningful traits: the operation is asynchronous and it runs in the Kuudo deployment rather than locally. However, it omits what the submission response contains, whether the operation is idempotent, failure modes, or any side effects, leaving the agent without a full behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and avoids fluff, with the valuable qualifiers 'Runs in your Kuudo deployment' and 'asynchronous' present. The standalone 'Catalog entry' fragment is redundant and adds little meaning, and the main verb is placed last, slightly reducing front-loading, but overall the text is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a create/submit operation with no annotations, no output schema, and an open-ended input schema (additionalProperties: true). The description does not explain what payload is expected, how to confirm the async request was accepted, or how to retrieve the resulting government invoice (e.g., via a status sibling). The remote-deployment note is helpful but does not make the tool safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so the schema covers 100% of declared parameters and the description need not explain them. The baseline of 4 applies here. The description adds no parameter detail, but with no documented parameters that is acceptable, despite the additionalProperties: true flag leaving the request body unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submits') and resource ('government invoice creation request'), and adds the important qualifier 'asynchronous' so the agent understands the tool only triggers a request rather than returning a completed invoice. It does not explicitly contrast with sibling tools like Invoices_getGovernmentInvoiceStatus or Invoices_createInvoicesExport, but the name and wording make the core purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as Invoices_createInvoicesExport, DeliveryByAmazon_submitInvoice, or ShipmentInvoicing_submitInvoice. The phrase 'Runs in your Kuudo deployment, not here' gives execution-context information but does not explain selection criteria, prerequisites, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It communicates that the tool returns offer data and that it is not executable in the current deployment, which is useful. It does not mention auth requirements, rate limits, or edge cases, but for a simple query the core behavior is reasonably disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with the deployment constraint appearing early. However, the opening fragment 'Catalog entry.' is cryptic and does not earn its place, adding confusion rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide enough for an agent to call the tool safely and correctly. It fails to specify how to supply the required ASIN or any other runtime inputs, and it does not describe the return shape or the conditions under which the tool is relevant versus siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so there are no named parameters to rely on. The description adds the semantic that ASIN is the key input, but it does not specify the parameter name, required fields, formatting, or how to pass the ASIN. This leaves the invocation contract ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence clearly states the action and scope: 'Returns the lowest priced offers for a single item based on ASIN.' This identifies the resource and distinguishes the tool from batch-oriented siblings, though it does not explicitly contrast it with ProductPricing_getItemOffersBatch or getListingOffers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' gives an important environment-based exclusion, so the agent knows not to invoke it in the current context. However, the description provides no guidance on when to prefer this tool over alternatives such as getItemOffersBatch or getListingOffers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more responsibility for behavioral disclosure. It does add the useful remote-execution detail ('Runs in your Kuudo deployment, not here') and the verb 'Retrieve' implies a read operation, but it omits any details about permissions, response behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not verbose, but the structure is awkward: the ambiguous 'Catalog entry.' fragment comes first, and the actual purpose appears last. Reordering would make the meaning clearer without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is adequately minimal: it states what is retrieved and where it runs. However, it never explains how a specific product type definition is identified or what the returned definition contains, leaving an important gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds nothing about parameters, which is acceptable for a zero-parameter tool, though the schema's additionalProperties: true is never clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Retrieve an Amazon product type definition' uses a specific verb and resource, making the main action clear. However, the opening fragment 'Catalog entry' is ambiguous and does not clearly distinguish this from catalog-item retrieval siblings such as CatalogItems_getCatalogItem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives, and no sibling tools or conditions are mentioned. The note that it 'Runs in your Kuudo deployment, not here' describes execution context, not usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add some value by stating that the operation runs in the Kuudo deployment rather than locally and that it returns metrics. However, it omits auth requirements, output shape, and any side-effect or data-scope details, leaving significant behavioral information undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no redundant elaboration. It front-loads the deployment caveat and then states the return behavior. The phrase 'Catalog entry' is vague and adds little value, but overall the structure is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with zero parameters, the description is thin for a tool with no output schema and no annotations. 'Aggregated replenishment program metrics' does not specify what metrics are actually returned, and the terms 'Catalog entry' and 'Kuudo deployment' are left unexplained. An agent also cannot tell how this differs from the 20221107 sibling, so the definition is not fully complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so there are no parameter semantics for the description to supplement. The baseline of 4 applies because no parameters exist; the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb ('Returns') and resource ('aggregated replenishment program metrics for a selling partner'), so an agent can tell what the tool does at a high level. However, it does not distinguish this tool from the sibling Replenishment20221107_getSellingPartnerMetrics or from Replenishment_listOfferMetrics/listOffers, and 'Catalog entry' adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It does not mention that Replenishment20221107_getSellingPartnerMetrics is a versioned counterpart or that listOfferMetrics/listOffers cover different scopes. The only contextual statement, 'Runs in your Kuudo deployment, not here', is about deployment location, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state that execution happens in the Kuudo deployment, not locally, and that it creates a report schedule. However, it does not explain what creating a schedule entails, whether it is immediately active, what permissions are needed, whether the action is reversible, or what the response/outcome is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the remote-execution caveat before the action. The sentence 'Catalog entry' is somewhat redundant with 'Runs in your Kuudo deployment, not here,' so it is not perfectly economical, but overall it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is thin. It tells the agent the tool creates a report schedule in a remote deployment, but it does not clarify what a report schedule requires, whether the tool is actually callable, or what happens after creation. The remote-execution note is useful, but the overall context is insufficient for a creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties and zero required parameters, so there is little parameter semantics for the description to add. The baseline for zero formal parameters is 4; the description does not need to compensate. The schema's additionalProperties:true allows arbitrary properties, but the description is not obligated to document them given the reported parameter count is 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and object: 'Creates a report schedule.' This is enough to distinguish it from the sibling get/cancel report-schedule tools. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' muddies whether this tool is directly invocable or merely a metadata record, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' provides some usage context: the tool is meant for a remote environment rather than this one. But the description gives no explicit when-to-use guidance compared with Reports_getReportSchedules, Reports_getReportSchedule, or Reports_cancelReportSchedule, and it offers no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden; it does convey read-only intent via 'Returns' and adds a useful execution-environment caveat that it 'Runs in your Kuudo deployment, not here.' However, it omits authorization needs, pagination, whether filters are required, and what 'report schedule details' contain. It remains non-contradictory but thin on behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and wastes few words, front-loading the key return behavior after an unnecessary 'Catalog entry' fragment. The deployment note is a useful caveat and the filter statement is precise at a high level. It is concise without omitting the central idea.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, an agent still lacks enough to invoke correctly: no filter field names or types, no indication of whether the 0-parameter schema means no arguments are accepted, and no return structure. The description is adequate only as a high-level catalog entry, not as complete invocation guidance for a blank schema with additionalProperties. It also never references a sibling for comparison.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties (additionalProperties: true), so there are no formal parameter semantics to document; per the baseline this should not be penalized heavily. The description does mention 'filters that you specify,' which is accurate but vague—it gives no example filter keys or value formats. This is acceptable under the zero-parameter baseline, though not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Returns') and names the resource ('report schedule details') plus a selection mechanism ('filters'), so an agent can see it is a read/list operation over report schedules. It is distinct from siblings like Reports_getReportSchedule by pluralizing, though it never explicitly contrasts itself. The odd 'Catalog entry' and deployment note do not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence tells the agent when to choose this over sibling tools such as Reports_getReportSchedule or Reports_getReports, nor does it state any exclusions or prerequisites. The deployment note explains where it runs, not when to invoke it. An agent would have to infer from the name alone how to route between schedule-list vs schedule-get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does communicate that the tool is a read operation ('Returns information') and that execution happens externally in the Kuudo deployment. However, it does not mention authentication requirements, side-effect potential, rate limits, or the implications of 'not here' for the calling agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the key behavioral information is front-loaded in the second sentence. 'Catalog entry' is a somewhat vague prefix that does not earn its place, but overall the description is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the returned 'information about a seller account and its marketplaces' actually contains. The term 'information' is vague—an agent cannot predict the response shape, included fields, or how marketplaces are represented. The unexplained 'Kuudo deployment' reference also leaves a gap in understanding the invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero required parameters, so there are no parameter semantics to document. Schema description coverage is 100%, and the description correctly says nothing about parameters. With zero params, a high baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: 'Returns information about a seller account and its marketplaces.' This distinguishes it from Sellers_getMarketplaceParticipations, which focuses on marketplace participations only. The phrase 'Catalog entry' is confusing and adds noise, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over Sellers_getMarketplaceParticipations or SellerWallet_getAccount. The only context added is 'Runs in your Kuudo deployment, not here,' which describes the execution environment but does not help an agent decide when this tool is appropriate or when an alternative should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add a meaningful behavioral caveat ('Runs in your Kuudo deployment, not here') and the get semantics are clear from the action. However, it does not disclose output shape, error behavior, authentication requirements, or what 'Catalog entry' implies for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with each sentence serving a distinct purpose. The main action appears last after 'Catalog entry' and the environment caveat, which slightly delays the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description leaves critical invocation details unresolved: it references a serviceJobID that is not declared as a parameter and does not say how to provide it. An agent cannot reliably construct a correct call beyond knowing the high-level purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so the description is the only source of parameter meaning by naming 'serviceJobID'. It adds value beyond the schema, but it still leaves ambiguity about how the parameter should be supplied and whether it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Gets details of service job') and identifies the resource as the one indicated by the provided serviceJobID. It does not explicitly contrast with siblings like Services_getServiceJobs, but the singular-by-ID phrasing makes the basic purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, alternatives, or exclusions are provided. The only contextual hint, 'Runs in your Kuudo deployment, not here,' is about the execution environment, not about choosing between this tool and related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses that the tool runs in a Kuudo deployment rather than locally and that the entire shipment object is returned. However, it does not mention side effects, authentication requirements, error behavior, or rate limits, though 'Return' implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler. The key behavior is stated directly in the final sentence, and the deployment context, while oddly phrased, is relevant. It earns a solid score for brevity, though the fragmented style could be smoother.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, it conveys the return value and execution environment. But with no output schema and no parameter schema, the lack of detail on how to supply shipmentId and what happens when the shipment is not found leaves a meaningful gap for an agent trying to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and allows additionalProperties, so the only signal that a shipmentId is needed comes from the description. This adds semantic meaning beyond the empty schema, but it leaves the parameter's type, location, and required status undefined, and it conflicts with the formal parameter count of 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Return the entire shipment object for the shipmentId.' This makes the operation identifiable as a read-by-ID call. However, the 'Catalog entry' and 'Runs in your Kuudo deployment, not here' phrasing adds confusion, and it does not explicitly differentiate it from the many other getShipment siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as Shipping_getShipment, MerchantFulfillment_getShipment, or FulfillmentInbound_getShipment. The only contextual note is environmental ('Runs in your Kuudo deployment, not here'), which does not help an agent choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose an important runtime trait ('Runs in your Kuudo deployment, not here') and the read-style return of tracking information. However, it does not state whether this is read-only, what permissions are needed, or what the returned tracking information includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but three sentences are used for three pieces of information. 'Catalog entry.' is a low-value label and could be merged with the deployment sentence; the purpose sentence is clear and front-loaded enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no schema-defined parameters, the description conveys environment and purpose. It omits return structure, how the shipment is identified, and any relationship to the modern Shipping_getTracking sibling, leaving the agent to guess whether this catalog entry is callable or just a reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties and coverage is 100%, so there are no parameter semantics for the description to add. The baseline for 0 parameters is 4; 'of a shipment' weakly implies a shipment context but no parameter is named, and additionalProperties: true leaves possible arbitrary inputs undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Return the tracking information of a shipment', which gives a specific verb and resource. The 'Catalog entry' and deployment note add context but do not obscure the core function. It does not explicitly differentiate from Shipping_getTracking, though the Legacy prefix suggests a variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'Runs in your Kuudo deployment, not here', which implies the tool is not invocable in the current environment. There is no guidance on when to choose this tool over Shipping_getTracking or Shipping_getShipmentDocuments, and no conditions, exclusions, or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add useful context by stating that execution occurs 'in your Kuudo deployment, not here' and implies a read-only operation with 'Retrieve.' However, it does not disclose authentication needs, error behavior, or what 'catalog entry' means operationally, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and wastes few words. The environmental note and the retrieval purpose are both present. However, the opening 'Catalog entry.' is fragmented and jargon-like, reducing structural polish without adding much clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no annotations and no output schema. It explains where the tool runs but not how to identify which supply source to retrieve, what the response contains, or what prerequisites exist. Given the singular 'getSupplySource' name and empty schema, an agent would not know how to invoke it correctly in a non-trivial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties and additionalProperties is true, so there are no parameters for the description to document. Per the 0-parameter baseline, this is acceptable. The ambiguity of additionalProperties true is not clarified, but the description cannot add much parameter meaning when none are declared.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Retrieve a supply source.' This is clear enough to know the basic operation. However, 'Catalog entry' is vague and does not distinguish this from the sibling SupplySources_getSupplySources, so it misses explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The phrase 'Runs in your Kuudo deployment, not here' hints at environment context but does not explain when this should be selected over SupplySources_getSupplySources or other SupplySources tools. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by noting the operation runs in the Kuudo deployment rather than the current environment and by stating that it returns upload/access information. However, it does not disclose permissions, side effects, failure behavior, or what exactly is created.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and gets to the core action and return value quickly. The phrase 'Catalog entry' is somewhat cryptic, but overall the description is appropriately sized and front-loads the most important functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides too little detail: it does not explain how to specify the target resource, what inputs may accompany the call, or what shape the returned upload destination information takes. The empty schema with additionalProperties allowed makes this omission more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared parameters, so the baseline is 4. The description adds no parameter-level detail and leaves the additionalProperties: true allowance completely undocumented, but it also does not misrepresent the parameter situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear operation and deliverable: it creates an upload destination and returns the information needed to upload and programmatically access a file. It does not explicitly distinguish itself from similar-looking siblings such as Services_createServiceDocumentUploadDestination, but the verb, resource, and outcome are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The only contextual note, 'Runs in your Kuudo deployment, not here,' is an environment caveat and does not help an agent choose between this tool and other upload-destination or file-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does state the destructive action ('cancels') and expands scope to include 'its associated shipment,' which is useful. However, it does not mention irreversibility, prerequisites, failure conditions, or what happens to downstream processes after cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences and avoids unnecessary detail. However, the actual purpose is not front-loaded: 'Catalog entry' and the deployment-location statement come before the meaningful cancellation action, which slightly reduces scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter cancellation action, the core action and scope are stated, but the description lacks the usage context needed to choose this over sibling cancel tools and does not describe expected outcomes or limitations. With no annotations or output schema, the description could reasonably provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero formal parameters, so there is little for the description to add; the baseline for zero-parameter tools is 4. Still, the schema has additionalProperties: true while the description never explains how the inbound order is identified, which is a minor gap if callers need to supply some identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The sentence 'Cancels an AWD Inbound order and its associated shipment' clearly identifies the verb and resource, and distinguishes this from Awd_createInbound, Awd_confirmInbound, and shipping-related cancel tools. However, the opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add ambiguity about whether this is a directly invocable action and why the location matters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as Shipping_cancelShipment, FulfillmentInbound_cancelInboundPlan, or Awd_confirmInbound. 'Runs in your Kuudo deployment, not here' is a location caveat, not a usage condition or exclusion, so the agent is left to infer when cancellation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure; it states the return content and an important execution-environment caveat. However, 'Catalog entry' is ambiguous and it does not clarify whether the operation is actually invocable, what input is needed, or any read/side-effect guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and mostly no-filler, with each sentence adding some information. The main action is placed after the two caveat sentences rather than front-loaded, and 'Catalog entry' is somewhat opaque, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity retrieval tool with no output schema, the core result is described clearly. Yet the deployment caveat plus missing input semantics leaves an agent unsure whether and how to invoke it in the current environment, so completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared parameters, so there is little parameter semantics for the description to add; baseline 4 applies. The phrase 'a browse node's' implies an identifier is needed but never says how to provide it, which is a minor gap against the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear resource (browse node review topics) and exact output (ten most positive and ten most negative), so an agent can tell this is a review-topic retrieval operation. It does not explicitly contrast with sibling tools like getBrowseNodeReviewTrends or getItemReviewTopics, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this over CustomerFeedback_getItemReviewTopics or getBrowseNodeReviewTrends. The only context is deployment-related ('Runs in your Kuudo deployment, not here'), which is not a selection rule among the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the operation returns data and mentions a deployment caveat ('Runs in your Kuudo deployment, not here'), but it does not clarify side effects, required authentication, or the meaning of the 'Catalog entry' label. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The functional sentence is concise and informative, but the opening 'Catalog entry. Runs in your Kuudo deployment, not here' is cryptic and not clearly self-explanatory. A more front-loaded and explicit statement of the invocation context would improve the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description leaves several gaps: the exact invocation environment is unclear, no return structure is described, and the input specification is only high-level ('weight and dimensions'). The tool is low-complexity, but the cryptic 'not here' phrase makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero properties, yet the description indicates that package weight and dimensions influence the returned slots, which is the only parameter information available. This meaningfully compensates for an empty schema, though it stops short of specifying parameter names or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb and resource: 'Returns time slots available for Easy Ship orders'. It also names the selection criterion (package weight and dimensions), which distinguishes it from nearby sibling tools like EasyShip_createScheduledPackage. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' introduces ambiguity about whether the tool is directly invocable, which slightly detracts from clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving handover slots before scheduling an Easy Ship order, based on package dimensions. It does not, however, name any alternative tools or state when not to use it, so the usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose an important behavioral trait: 'Runs in your Kuudo deployment, not here,' which tells the agent this is not a locally invocable operation. However, it does not explicitly state read-only behavior, response characteristics, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences and is easy to parse. However, the 'Catalog entry' sentence adds limited value and the core purpose is placed last, after context. It is concise but not perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool, the description identifies what the tool does and where it executes. Still, with no output schema and no annotation coverage, it does not explain what the returned status data looks like or how the operation being checked is identified, leaving meaningful gaps for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared parameters and 100% schema coverage, so by the baseline rule a 4 is appropriate. The description adds no parameter-level detail, but with no declared parameters there is little to document. The empty schema and 'additionalProperties: true' are not clarified, but the description does not actively mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Gets the status of the processing of an asynchronous API call.' This distinguishes it from most sibling tools, which focus on creating, updating, or retrieving concrete fulfillment entities. The 'Catalog entry' phrase adds confusion but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies use for checking async operation status but does not mention any alternative tools, prerequisites, or exclusions. The deployment note is context, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the key behavioral trait that the tool runs externally, not in the current environment, and that it is a read-style operation returning a list. It does not disclose return shape, pagination, or required permissions, but for a simple list operation the main caveat is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the important deployment caveat before the function statement. The only weak element is the jargon phrase 'Catalog entry,' but there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description must supply the return shape, the criteria, and enough context to choose among many siblings. It provides neither the criteria names nor any output detail, so an agent cannot fully determine how to invoke or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared parameters, so the baseline is generous, but the text claims criteria can be specified without naming any of them. 'Criteria that you specify' adds the idea of filtering, yet the agent is left to guess which criteria are accepted, especially because additionalProperties is true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it 'Returns a list of inbound shipments based on criteria that you specify.' This is not a tautology, but it does not differentiate from closely related siblings such as FulfillmentInbound_getShipment or Awd_listInboundShipments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an important execution context ('Runs in your Kuudo deployment, not here') that tells the agent this tool is not for the current environment, and 'criteria that you specify' implies a filtering use case. However, it names no alternative tools and gives no concrete conditions for choosing this over the many shipment-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the operation returns a count, implying a read-only lookup, and adds the environment-specific behavior of running in the Kuudo deployment. However, it omits details such as how sellerSku and feature are supplied, whether the result is a raw number or wrapped in an object, and any error or authorization behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with no excessive wording. The fragmented 'Catalog entry.' opener adds little, but the core sentence is efficient and the deployment warning is relevant. It earns a strong score without being perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no parameter schema, the description should compensate by explaining invocation and results. It states the return value is a count and mentions the deployment context, but it does not specify the exact parameter keys, required format, or how the feature is identified. The core is adequate but leaves notable ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined properties and allows additionalProperties, so the description adds meaningful value by referencing 'sellerSku' and 'feature' as expected inputs. It does not provide exact parameter names, formats, or requirements, but for a schema with no parameters, this is useful semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a count of items for a given sellerSku and feature, which is a specific verb+resource combination. It distinguishes itself from siblings like getFeatures and getFeatureInventory by focusing on the sellerSku-specific item count, though it does not explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a deployment-level clue ('Runs in your Kuudo deployment, not here') but provides no guidance on when to choose this tool over related FulfillmentOutbound tools. There is no mention of alternatives, preconditions, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose a significant behavioral caveat: this is a catalog entry that runs in the user's Kuudo deployment, not in the current environment. It also implies a read-only list operation, but it omits details about authorization, side effects, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, non-redundant sentences. The execution-location caveat is front-loaded, and the functional sentence is clear. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an empty schema, no output schema, no annotations, and vague 'shipping criteria,' the description is not sufficient for an agent to invoke it correctly. The agent would not know which criteria are valid, how they should be structured, or what the response shape is. The deployment warning is useful but does not fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties but allows additionalProperties, so the description's mention of 'shipping criteria that you specify' is the only meaningful parameter guidance. The baseline for a zero-parameter schema is 4, and the description adds a useful hint even though it does not enumerate valid criteria.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: it returns a list of fulfillment order previews based on shipping criteria. This distinguishes it from order-mutation siblings like createFulfillmentOrder and cancelFulfillmentOrder, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus related shipping or fulfillment tools. The phrase 'based on shipping criteria that you specify' is only an implicit usage hint, with no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden; it does disclose that this is a read/list-like operation, the date-time filter, and nextToken pagination. It does not disclose output structure, ordering, which order statuses are included, or any auth/rate-limit implications, leaving behavioral detail incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and the core return behavior is front-loaded. The opening fragments 'Catalog entry. Runs in your Kuudo deployment, not here.' are slightly redundant and could be compressed, but there is no wasted explanatory filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the definition omits important details for reliable selection and invocation: exact parameter names, return value structure, and relationship to sibling tools. The 'runs in your Kuudo deployment' note provides some execution context, but the entry remains too thin for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero declared properties but allows additionalProperties, so the description is the only source of parameter meaning; it correctly identifies the date-time filter and nextToken. However, it never names the actual query parameter(s) or their formats, so an agent still cannot construct the invocation reliably.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns a list of fulfillment orders') and the resource, plus the key filtering semantics by date-time or nextToken. It is distinguishable from single-order tools like getFulfillmentOrder, though it does not explicitly name sibling alternatives and the 'Catalog entry' opener slightly muddies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context that the tool runs in the Kuudo deployment, not the current environment, and implies the main use case is listing orders fulfilled after a date-time. However, it does not explain when to choose this tool over related fulfillment-outbound operations or how pagination via nextToken should be handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full disclosure burden. It does reveal a notable behavioral trait—remote execution in the Kuudo deployment—and 'Returns' implies a read-only list operation. However, it does not mention authorization, error behavior, side effects, or output format. For a simple list/catalog lookup, this is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at roughly two short sentences and contains no filler. The remote-execution caveat and return scope are both included. The fragment 'Catalog entry' front-loads a somewhat vague label rather than the primary action, but the overall structure is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the core action and scoping. Gaps remain around how seller SKU and marketplace are determined, what the returned list entries look like, and whether the tool is actually invocable from the current environment. It is close to sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema parameters, the baseline is 4. The description adds domain scoping by stating the codes are 'for a seller SKU in a given marketplace,' which provides meaning beyond the empty schema. It does not fully clarify how those values are supplied since no parameters are declared, but it still gives useful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete operation: 'Returns a list of return reason codes for a seller SKU in a given marketplace.' The verb and result are clear and distinguish it from the sibling tools. The opening 'Catalog entry' and 'Runs in your Kuudo deployment, not here' add context but do not obscure the core purpose. It stops short of a 5 because it does not explicitly contrast with any alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The only usage-related signal is 'Runs in your Kuudo deployment, not here,' which hints at remote execution but does not explain prerequisites, exclusions, or preferred alternatives. The agent is left to infer usage context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more weight and does provide some behavioral context: it is a catalog entry, executes in a Kuudo deployment rather than here, and returns marketplace-dependent results. However, it is vague about what 'not here' means, does not address side effects or auth requirements, and gives no detail on how the schemas and values are delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no real verbosity. However, 'Catalog entry' and 'Kuudo deployment' are unexplained jargon that could confuse an agent instead of clarifying the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description gives a high-level idea of the return value but not the structure of the schemas or the meaning of the execution/environment caveat. An agent still cannot confidently determine whether this tool is callable from the current environment or how the response will be shaped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and zero required parameters, so there is little for the description to add. The 0-parameter baseline applies, and the description introduces no parameter confusion, although it also does not clarify the additionalProperties: true allowance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action: it returns marketplace-dependent schemas and their set of possible values, and the tool name ties this to invoice attributes. It does not explicitly say 'invoice attributes' or contrast itself with the other Invoices_* siblings, leaving some disambiguation to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives like Invoices_getInvoices or Invoices_getInvoicesDocument. The line about running in a Kuudo deployment hints at an environment restriction, but it does not explain whether the agent should invoke this tool, ignore it, or route the call elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does useful work by saying the call is a read-style 'Returns' operation and by adding the deployment boundary ('Runs in your Kuudo deployment, not here') and the conditional presence of exportDocumentId. It stops short of disclosing authentication, error behavior, or full response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the main action stated plainly and no repeated schema information. 'Catalog entry' is slightly opaque, but the description is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description needs to explain how to identify the export and what the response contains; it provides only one field and an empty parameter contract. The relationship to Invoices_createInvoicesExport and Invoices_getInvoicesExports is also absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero declared properties, so the baseline credit applies, and the description adds the concept of 'the export that you specify.' However, it never names the parameter or its format, which is especially confusing when the formal schema is empty and the tool claims a target must be specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Returns invoice export details') and the target ('the export that you specify'), and it calls out the key exportDocumentId field. It doesn't explicitly contrast with sibling tools like getInvoicesExports, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the export that you specify' implies a retrieval-after-selection workflow, and the deployment warning says it executes in Kuudo, not locally. It does not state when to prefer this over Invoices_getInvoicesExports or how to obtain the export identifier, so guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden. It does disclose the key side effect (sends a critical, customer-facing message) and adds the deployment context that the operation runs in the Kuudo deployment, not here. However, it does not address reversibility, prerequisites, failure behavior, or permission requirements, and the ambiguous 'Catalog entry' phrasing clouds whether the tool is actually executable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences totaling roughly 30 words with no filler. The deployment caveat and catalog-entry status are front-loaded before the purpose statement. The two cryptic fragments ('Catalog entry.' and 'Runs in your Kuudo deployment, not here.') could be merged or expanded, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter, no-output-schema tool: the description covers what the tool does and where it executes. But the 'Catalog entry' phrasing is ambiguous, there is no guidance on what context is needed to invoke it (which buyer/order), and no mention of what happens on success or failure. It is minimally viable with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, so per baseline the description need not explain parameter semantics. Schema coverage is trivially 100%. The one gap is that additionalProperties is true with no guidance about what unstructured inputs (e.g., order identifier, message content) the operation may expect, but this does not lower the score below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Sends a critical message to a buyer that an unexpected problem was encountered affecting the completion of the order.' The trigger scenario ('unexpected problem...affecting completion') distinguishes it from sibling messaging tools like Messaging_createConfirmOrderDetails or Messaging_CreateAmazonMotors. It does not name a sibling it is not, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied through the scenario ('unexpected problem was encountered affecting the completion of the order'); there is no explicit when-to-use guidance, no when-not-to-use conditions, and no alternative tools named. The 'Runs in your Kuudo deployment, not here' caveat addresses environment rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It characterizes the operation as returning information, implying a read-only getter, and adds a notable environmental constraint: 'Runs in your Kuudo deployment, not here.' It does not disclose side effects, auth requirements, or error behavior, but for a simple getter the read-only implication is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first fragment, 'Catalog entry,' is confusing and adds little value. The key information about the subscription lookup is in the final sentence, but the runtime caveat interrupts the message and could mislead an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is thin. It identifies the conceptual selection criteria but not the exact property names to use, and it does not describe the returned subscription data or how this call relates to getSubscriptionById. An agent would likely need additional knowledge to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema and additionalProperties set to true, the description provides the only parameter guidance by naming 'specified notification type and payload version.' This goes beyond the empty schema, though it still does not give exact parameter names or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Returns information about subscription'. It also differentiates from the sibling Notifications_getSubscriptionById by naming 'notification type and payload version' as the selection criteria, rather than an ID. However, the opening 'Catalog entry' and the runtime caveat add ambiguity about what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a subscription is identified by notification type and payload version, which distinguishes it from getSubscriptionById. It does not explicitly state when to use this tool versus the alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the tool executes in a Kuudo deployment rather than the current environment and indicates a read-style behavior ('Returns...'). However, it does not clarify permissions, whether the operation is fully read-only, what happens when called, or what the returned metrics actually contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly front-loaded, with no filler. The phrase 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are slightly redundant as deployment-oriented caveats, but overall the description remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool, the description is nearly adequate, but it leaves ambiguity about whether the tool is actually callable from this environment. Since there is no output schema, the vague phrase 'aggregated replenishment program metrics' provides limited detail about what values the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter usage. The baseline for zero-parameter tools is strong, and the description adds no misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as returning 'aggregated replenishment program metrics for a selling partner,' giving a specific verb and resource. It also adds deployment context ('Runs in your Kuudo deployment, not here') that helps distinguish this from tools in other domains, though it does not explicitly compare it to similar metrics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The statement 'Runs in your Kuudo deployment, not here' is a deployment caveat, not a usage guideline, and no alternative tools are suggested. An agent is left to infer whether and how it should invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states that the tool runs in the Kuudo deployment rather than locally and implies a read-only retrieval. It does not disclose response format, error behavior, or authorization requirements, but for a simple read operation this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly to the point. 'Catalog entry' is slightly redundant with the next sentence, and the purpose statement could be front-loaded, but there is no real verbosity and each remaining sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not name the actual parameter, and there is no output schema to clarify return values. The strange 'Catalog entry' phrasing and the schema with zero properties make it unclear how an agent should actually invoke this tool aside from guessing under additionalProperties. This is a significant omission for a tool intended to be called.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and allows additionalProperties, so the description's mention of an 'Amazon account identifier' adds meaningful context. However, the exact parameter name is not provided, and the schema gives the agent no structured way to know which key to pass. This is a useful hint but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and identifies the resource ('a Seller Wallet bank account') plus the lookup key ('Amazon account identifier'). It clearly conveys a single-account read operation, and the name SellerWallet_getAccount distinguishes it from list-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by Amazon account identifier' implies this tool should be used when a specific account identifier is available and a single bank account record is needed. However, the description does not explicitly mention alternatives like SellerWallet_listAccounts or state when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the operation runs in the user's Kuudo deployment, not locally, and that it performs a purchase, implying a side effect. However, it does not detail financial implications, prerequisites, or what the returned documents contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads key context: catalog entry, execution location, then the action and return value. The 'Catalog entry' phrase is slightly ambiguous, but overall the description is economical with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter operation with no output schema, the description covers the essential action, execution context, and broad return type. It is incomplete in explaining what 'Catalog entry' means, whether prior rate selection is needed, and what specific purchase details or documents are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and with 0 parameters the baseline is 4. The description does not add parameter-level detail, but none is required here. The schema's additionalProperties: true is not addressed, but it is not a practical concern given no documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('purchases') and a specific resource ('shipping service identifier'), and states that it returns purchase-related details and documents. This is clear, but it does not explicitly distinguish this from sibling tools like Shipping_purchaseShipment or Shipping_directPurchaseShipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling shipping tools. It mentions that it runs in the Kuudo deployment rather than here, but this is environmental context rather than usage direction. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the operation returns a list and that it executes in a 'Kuudo deployment, not here.' It does not mention whether the operation is read-only, whether it requires authentication, or what happens when no solicitation types are available, but the described behavior is simple enough that 'returns' is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easy to scan, but 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are somewhat redundant and cryptic, and the main functional detail is placed after them. It is concise but not optimally structured for an agent trying to understand the tool quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete for an agent that needs to invoke the tool. It does not explain how to specify the order, what solicitation types are returned, what the response looks like, or how this differs from related tools like Messaging_getMessagingActionsForOrder. The deployment caveat is noted but not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero documented parameters, and the baseline for 0 parameters is 4. The description adds meaningful guidance by saying an order must be specified, which implies an order identifier is needed. It does not name the parameter or provide a format, but this is still useful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns a list of solicitation types that are available for an order that you specify.' This clearly identifies the operation's function. It does not explicitly differentiate from sibling tools like Messaging_getMessagingActionsForOrder, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to retrieve solicitation types for a specified order. It also adds an environment constraint ('Runs in your Kuudo deployment, not here'), which gives some context. However, it does not state when to prefer this tool over alternatives or when it should not be used beyond the vague 'not here'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It does add useful behavioral context: the operation runs in a separate Kuudo deployment and returns paginated data. It does not disclose auth requirements, rate limits, or a clear read-only statement, but 'retrieve' and pagination imply a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the key facts: catalog entry, execution location, and paginated retrieval. 'Catalog entry' adds limited value, but there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read/list tool, the core is present, but the lack of an output schema or annotations leaves return format and authorization expectations implicit. The 'Catalog entry' phrase also introduces ambiguity about whether this is directly invocable, which is not resolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters with 100% coverage, so the baseline is 4. The description's pagination mention is the only parameter-related hint and confirms the list nature, but there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('retrieve') on a specific resource ('supply sources') and indicates pagination, which distinguishes it from the singular getSupplySource and the create/update/archive siblings. However, the opening 'Catalog entry' is ambiguous and no sibling is named, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over SupplySources_getSupplySource (single vs. paginated list) or the write operations. The only contextual statement, 'Runs in your Kuudo deployment, not here,' addresses runtime location, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses remote execution and the draft-status precondition, but does not state what fields are updated, side effects, permissions, or response behavior. 'Catalog entry' is also unexplained and adds ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the core update statement is prominent. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here.' is cryptic and could be clarified while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating update operation with no annotations and no output schema, the description is incomplete: it lacks required identifiers or payload, effect details, and return shape. The status constraint is helpful but not sufficient for an agent to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares no properties yet allows additionalProperties, so an agent cannot learn what identifies the inbound order or what update payload to send. The description adds no parameter meaning beyond the resource name, failing to compensate for the permissive empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Updates an AWD inbound order,' with clear preconditions 'DRAFT status and not yet confirmed.' This distinguishes it from sibling tools like Awd_confirmInbound, Awd_cancelInbound, and Awd_createInbound without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear applicability context: only for inbound orders in DRAFT and not yet confirmed, and notes that it runs in the Kuudo deployment rather than locally. It does not explicitly name alternatives, but the status condition acts as an implicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two behavioral traits: this is a catalog entry and it runs in the user's Kuudo deployment rather than in the current environment. 'Get' also implies a read-only operation. However, it does not describe response format, pagination, errors, authentication, or side effects, so the disclosure is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the most important caveat: this runs in Kuudo, not here. The purpose statement is compact and without fluff. The phrases 'Catalog entry' and 'Kuudo deployment' are slightly jargon-heavy, but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description has to provide the full invocation contract. It explains what the tool does and where it runs, but it leaves critical invocation details unspecified: how the package or shipment is identified, how marketplace and channel are passed, and what the returned list contains. An agent could select the tool but not confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the schema provides no parameter information. The description adds the only meaningful input signal: shipping options are selected based on the shipment's marketplace and channel. It does not specify parameter names or formats, but with zero schema properties this is still a valuable contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Get' and resource: 'a list of shipping options for a package in a shipment', and names the key input context: marketplace and channel. It is clear about what the tool does, though it does not explicitly differentiate it from sibling tools like Shipping_getRates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The described use case is implied clearly: call this when you need shipping options for a package in a shipment. The line 'Runs in your Kuudo deployment, not here' gives an important context cue that this tool executes remotely, but no alternatives are named and no explicit when-to-use versus when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that this is a 'Catalog entry' and that execution happens in the Kuudo deployment, not in the current environment. However, it does not disclose side effects, permissions, reversibility, or response behavior for a mutation-like update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and front-loads the important 'not here' deployment constraint before the action statement. Minor redundancy exists between 'Catalog entry' and 'Runs in your Kuudo deployment, not here,' but the overall size is appropriate and free of significant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an empty input schema, the description provides enough context to recognize its purpose and non-local execution. It is not complete enough to actually invoke correctly, since there is no information about required identifiers or expected payload structure, but the 'not here' statement may intentionally signal that invocation is not the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented properties and allows additionalProperties: true, so the description needs to compensate. It adds that the update concerns packages for a 'specified shipment,' but it does not explain what identifiers or fields should be supplied. With zero schema parameters the baseline is 4, but the open additionalProperties and implied shipment/package identifiers reduce the value of that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Updates') and a clear resource ('details about the packages that will be used to fulfill the specified shipment'). This is distinguishable from sibling ExternalFulfillmentShipments_updatePackageStatus, which focuses on status rather than package details, though the description does not name 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear contextual constraint: it 'Runs in your Kuudo deployment, not here,' which tells the agent this is not an Amazon-side invocation. However, it does not explicitly explain when to choose this over related siblings like createPackages or updatePackageStatus, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does mention pagination and a deployment caveat, which is useful. However, 'Catalog entry' is cryptic and unexplained, and there is no mention of return format, errors, permissions, or side effects beyond the implied read-only nature of a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 20 words, so it is concise, but the first two sentence fragments ('Catalog entry.' and 'Runs in your Kuudo deployment, not here.') are cryptic and appear before the actual purpose. A cleaner structure would state the function first and then add deployment caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with zero documented parameters, the description leaves important gaps: it does not explain how to identify the inbound plan, what fields a pallet package contains, or how pagination parameters should be supplied. The ambiguous 'Catalog entry' remark could confuse an agent about whether the tool is callable at all. No output schema exists to compensate for these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero parameters and has 100% schema description coverage, so the baseline is 4. The description does not add parameter-level meaning, but no parameters are documented to require explanation. The 'paginated' hint implies pagination-related inputs, yet these are not formalized in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Provides a paginated list of pallet packages in an inbound plan,' using a specific verb and resource. This distinguishes it from sibling tools like listInboundPlanBoxes, listInboundPlanItems, and listShipmentPallets by scoping to pallets within an inbound plan rather than boxes, items, or shipments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as listInboundPlanBoxes or listShipmentPallets. There are no prerequisites, exclusions, or contextual selection rules. The note that it 'runs in your Kuudo deployment, not here' is an environment constraint, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the operation updates a shipment name but does not mention side effects, permissions, reversibility, failure modes, or whether the tool is actually invocable in this environment. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' hint at behavior but do not meaningfully disclose operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easy to read, but it is not well front-loaded: the core action appears only in the final sentence. 'Catalog entry' adds little value and reads as filler, while 'Runs in your Kuudo deployment, not here' is context that could have been placed after the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an empty input schema, the description is too sparse to support reliable invocation. It does not state required identifiers, new name input, return behavior, or prerequisites. The description may help an agent select the tool, but not confidently invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds minimal parameter meaning by mentioning the updated field ('name') and target ('existing shipment'), but it does not specify how to identify the shipment or what input is expected. Since the schema itself provides no parameter information, the description could have done more, but the zero-parameter baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Updates the name of an existing shipment.' This distinguishes it from sibling update tools such as FulfillmentInbound_updateShipmentSourceAddress and FulfillmentInbound_updateShipmentTrackingDetails. The extra context about being a catalog entry and running in Kuudo does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action: use this when an existing shipment's name needs to be changed. However, no alternatives are named and there is no explicit when-not-to-use guidance. The 'Runs in your Kuudo deployment, not here' note provides some environmental context but not a clear routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses that this is only a catalog entry, executes in a Kuudo deployment rather than here, and targets the sandbox, so an agent understands it is not a normal callable API operation. It does not disclose side effects, authorization needs, errors, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences with no verbosity; each sentence contributes environment, deployment context, or functional purpose. 'Catalog entry' is slightly cryptic but not padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an empty input schema, the description leaves too much unstated: what input should accompany the local call, what the response or error behavior is, and how this relates to other fulfillment and shipping status tools. The deployment/sandbox disclosure is useful but does not make the entry actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and additionalProperties is true, so there are no parameter names or descriptions for the description to supplement. With 0 declared parameters, the baseline of 4 applies, and the description is not obligated to document missing fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation—'Requests that Amazon update the status of an order'—and scopes it to the sandbox testing environment, which goes beyond the tool name. However, it does not explicitly say 'fulfillment order' or differentiate this from sibling status-update tools like FulfillmentOutbound_updateFulfillmentOrder or Orders_updateShipmentStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a meaningful when-not ('Runs in your Kuudo deployment, not here') and a context cue (sandbox testing environment). But it never explicitly states when to choose this over alternative status-update tools, so the usage guidance is implied rather than clearly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a 'catalog entry' that 'runs in your Kuudo deployment, not here,' which is meaningful behavioral context beyond the absent annotations. However, it does not discuss permissions, side effects beyond the message send, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is compact: two sentences that front-load the purpose and then add essential runtime context. Every clause earns its place without filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action and the notable runtime characteristic are covered, making the tool minimally usable. Still, without annotations or an output schema, the description leaves unclear what inputs are required and what a successful invocation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero parameters, so the baseline is 4. The description does not elaborate on how the buyer, order, or digital access key are identified, but with no schema-declared parameters this is not a significant deduction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: sends a buyer a message to share a digital access key for digital content in their order. The verb 'sends' and the specific resource 'digital access key' set it apart from generic Messaging_* siblings, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus other Messaging_* options. The use case is implied by 'Sends a buyer a message...', but there are no conditions, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does disclose the execution environment and the read-style behavior of returning filtered orders, but it omits details like output shape, pagination, or any authorization expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the behavioral caveat about running in the Kuudo deployment. 'Catalog entry' is somewhat vague but does not add meaningful bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions a time period, but the input schema has no parameters to express it, leaving an agent without a clear way to specify the filter. With no output schema and no parameter details, the description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no declared parameters, so the baseline is 4. The description adds the concept of a specified time period even though the input schema exposes no properties, which is useful context even without parameter names or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action and resource ('Returns orders') and narrows the scope to orders created or updated within a time period, which helps distinguish it from single-order operations like Orders_getOrder. The phrase 'Catalog entry' is ambiguous, but the core purpose is still identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys an important context: the tool runs in the customer's Kuudo deployment rather than in this environment. However, it does not explicitly state when to prefer this tool over Orders_getOrder, Ordersv2_searchOrders, or other order-listing siblings, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It usefully reveals that the tool is a catalog entry that executes remotely ('Runs in your Kuudo deployment, not here'), which is significant. However, it does not mention read-only status explicitly, error behavior, authentication needs, or whether the call has side effects, though 'Retrieve' weakly implies a read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and wastes few words. The first sentence 'Catalog entry' is terse but adds context, and the second sentence gives the purpose. A small amount of clarity is lost because 'Catalog entry' and 'not here' overlap, and 'given account' introduces ambiguity without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and no output schema, the description is relatively lean. It conveys the tool's purpose and remote execution context, but it does not describe the return format or how the 'given' account is selected, which could prevent an agent from using it correctly even in the Kuudo deployment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and an empty schema, the baseline is 4, but the description's phrase 'in a given Seller Wallet bank account' implies an input for specifying the account without any schema support or explanation. The schema has additionalProperties true, yet no parameter name or format is provided, leaving the agent to guess how to identify the account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Retrieve the balance in a given Seller Wallet bank account.' It distinguishes from nearby siblings by specifying 'balance' rather than account details or transactions, though it does not explicitly name any alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' gives an important environmental exclusion that tells the agent this tool is not callable in the current context. However, it does not explain when to prefer this tool over related tools like SellerWallet_getAccount or SellerWallet_listAccountTransactions, leaving selection logic mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context about deployment location and notes that the list can be filtered by method type, and 'Returns' implies a read operation. However, it does not disclose potential side effects, pagination, output shape, or what 'Catalog entry' really means, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and generally efficient, with the core purpose stated in the final sentence. The phrase 'Catalog entry' is somewhat vague and the deployment note is placed before the main purpose, but overall there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description provides the essential deployment caveat and states what is returned. But with no output schema and no exact filter syntax, the description leaves an agent without enough detail to know the response structure or how to pass the optional method-type filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so the description's mention of filtering by method type adds some value beyond the schema. Nevertheless, the description does not specify the exact parameter name, format, or accepted method type values, leaving an agent to guess how to apply the filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: it 'Returns the list of payment methods for the seller.' The added filter-by-method-type detail further clarifies scope. However, the opening 'Catalog entry. Runs in your Kuudo deployment, not here' introduces ambiguity about whether this tool is directly callable, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a seller's payment methods are needed, and it provides a deployment caveat: it runs in the Kuudo deployment, not the current environment. It does not name alternative tools or provide explicit when-not-to-use guidance, so it relies on inference rather than direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds useful non-obvious context by stating the operation runs in the user's Kuudo deployment, not locally. However, it does not disclose whether the deletion is permanent/irreversible, whether all notifications or a subset are removed, or what permissions are required, which is a notable gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and the remote-execution caveat is useful, but the opening fragment 'Catalog entry.' is unexplained and adds noise rather than clarity. The remaining sentences are efficient but the structure could be improved by stating the action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter destructive tool with no annotations and no output schema, the definition is minimally adequate but leaves open important details: whether all notifications are removed or only selected ones, what happens after invocation, and whether the action can be undone. 'Catalog entry' also raises ambiguity about whether this is an invocable operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and the description's phrase 'your application's notifications' implies the target scope is derived from the deployment/app context rather than explicit arguments. No parameter documentation is needed here, though the open additionalProperties field is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Remove'), a clear resource ('your application's notifications'), and the target surface ('Appstore notifications dashboard'). It is also distinct from the sibling AppIntegrations_createNotification, which is the add counterpart, so an agent can tell this is the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus any alternative. It does not mention createNotification or recordActionFeedback, nor does it state prerequisites, exclusions, or conditions under which deletion should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the transparency burden. It does indicate this is an informational call that returns metadata rather than contents and notes that it runs in a Kuudo deployment. However, it does not disclose response shape, authentication needs, rate limits, or what exact 'information required' is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and communicates its core purpose directly. The 'Catalog entry' phrase adds little value, but the overall structure is compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only metadata lookup, the description is close to adequate. However, with no output schema, it leaves the returned 'information required' vague and does not explain what an agent should do with it, such as fetching from a URL or applying a decryption key.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden for the description. The input schema already reflects the parameter count completely, and the additionalProperties setting is the only nuance but does not require description-level explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it 'returns the information required for retrieving a feed document's contents,' which identifies a clear resource and behavior. It distinguishes this from actually retrieving the contents or managing feed submissions, though it does not explicitly differentiate from sibling Feeds tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when an agent needs the retrieval metadata for a feed document, but it gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as Feeds_getFeed or Feeds_createFeedDocument, leaving selection partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'Fetches' implies a read-only operation, and 'Runs in your Kuudo deployment, not here' adds execution-environment context. However, it does not describe return shape, side effects, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the most important execution-context note. It is concise without being vague, though the fragment 'Catalog entry' adds limited independent value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter getter, the description gives a workable purpose, but it lacks detail about what 'top level information' includes and what the response will look like. The execution-context warning is helpful, yet the tool remains minimally documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema is fully sufficient. The description adds no parameter details, but none are needed in this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('fetches') and resource ('inbound plan'), with 'top level information' adding scope. It is distinguishable from sibling list/detail tools, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when top-level plan information is needed, but it does not state when to prefer this over related tools like listInboundPlans or listInboundPlanItems. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does reveal that execution happens in the Kuudo deployment rather than locally and that the operation returns labels, implying read-only behavior. But it does not state side effects, required permissions, output format, or error behavior, leaving important behavioral gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the deployment context is front-loaded before the functional summary. It is slightly disjointed—'Catalog entry.' is a fragment and 'not here' is ambiguous—but it wastes little space and remains quickly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description gives the essential output ('package/pallet labels') and the execution environment. It is incomplete about what the output looks like, whether the tool is callable from the current server at all, and what prerequisites apply; no output schema or annotations exist to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with no required parameters, so there are no parameter semantics to explain. The description adds no parameter detail, but the zero-parameter baseline is 4, and nothing here violates that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific result—package/pallet labels for Amazon fulfillment center processing—so an agent can identify the tool's primary function. It does not explicitly distinguish this from sibling label/document tools (e.g., FulfillmentInboundV0_getBillOfLading, Awd_getInboundShipmentLabels), so it misses the top score. The 'Catalog entry... not here' phrasing adds deployment context but slightly muddles whether this tool actually returns labels in the current environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for faster and more accurate shipment processing at the Amazon fulfillment center' provides a use context, and 'Runs in your Kuudo deployment, not here' states an exclusion. However, it never tells the agent when to prefer this over the many sibling label/shipping tools, nor what to use instead, so the guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses the execution environment and the return shape (feature list plus enrollment status), but it says nothing about side effects, authentication needs, errors, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded. 'Catalog entry' is slightly redundant with the following sentence about running in the Kuudo deployment, but the overall structure is efficient and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and environment, but with no output schema or annotations it leaves gaps: how the marketplace is specified, what a 'feature' means in this context, and how this tool differs from sibling feature tools are not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, giving a baseline of 4. The description adds conceptual meaning by saying results are scoped to a specified marketplace and the seller making the call, though the mechanism for specifying the marketplace is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it returns a list of Multi-Channel Fulfillment features and whether the calling seller is enrolled for each. This distinguishes it from sibling feature-related tools like getFeatureInventory and getFeatureSKU, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful scope context: MCF orders, a specified marketplace, and the seller on the call. It also notes that execution happens in the Kuudo deployment, but it does not state when to prefer this tool over related FulfillmentOutbound feature tools or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds a meaningful runtime caveat ('Runs in your Kuudo deployment, not here') and 'Returns' implies a non-mutating lookup. However, it does not clarify what 'Catalog entry' means for execution, whether auth or rate limits apply, or how results are presented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded, with the execution caveat placed early. The opening fragment 'Catalog entry.' is somewhat vague and could be considered noise, so it is not perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and the critical environment caveat, but with no output schema and no filter details, an agent does not learn the response structure or how to form filters. The sibling ambiguity also remains unresolved, leaving the description minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters and baseline for no params is 4. The description adds the concept of 'filters that you specify', which is useful given additionalProperties is true, letting the agent know arbitrary filter properties may be accepted. It still does not enumerate valid filter names or value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read operation: it 'returns invoice exports details' for matching filters, naming the resource and action. However, it does not differentiate this from sibling tools like Invoices_getInvoicesExport or Invoices_getInvoices, so it falls short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for exports that match the filters that you specify' implies use when a filtered list of invoice exports is needed, and 'Runs in your Kuudo deployment, not here' gives an environment constraint. It does not explicitly state when to prefer this tool over its siblings or list exclusions, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a buyer-facing side effect (sends a message) and the unusual routing context ('Runs in your Kuudo deployment, not here'). It does not mention permissions, response behavior, or idempotency, but the core side effect is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler. The functional sentence is clear, though leading with 'Catalog entry' and 'Runs in your Kuudo deployment, not here' puts routing metadata before the core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter catalog entry the description conveys the operation and runtime location. It still lacks any indication of the response/return value, and the 'not here' deployment note is ambiguous about whether this tool can actually be invoked from the current environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters and has 100% coverage, so the description does not need to add parameter-level detail. The additionalProperties:true caveat is not explained, but with no declared inputs this is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: sends a message asking a buyer to provide or verify customization details, with concrete examples (name spelling, images, initials). This clearly differentiates it from sibling messaging tools like confirm delivery, order, or service details, although it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use is implied from the action: an agent should select this tool when a buyer needs to provide or verify customization details. However, it gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as the createConfirm* messaging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal that this is a catalog entry, that it runs elsewhere and not here, and that it sends a message to the buyer. It does not disclose side effects beyond sending, required authorization, or message content specifics, which a fully transparent description would cover for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the critical 'Catalog entry' and 'not here' caveat before the purpose statement. The phrasing is slightly cryptic ('your Kuudo deployment, not here') but the overall size is appropriate and every sentence contributes relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema catalog entry, the description gives enough to recognize the tool's purpose and to know that it should not be invoked in the current environment. It is incomplete for actually invoking it elsewhere—there is no guidance on the message content, required order context, or response behavior—but the 'not here' warning substantially reduces the risk of misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and schema description coverage is 100%, so there are essentially no parameters to explain. The zero-parameter baseline is 4, and the description does not need to add parameter-level meaning. The extra 'additionalProperties: true' is not clarified, but no required parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Sends a message to ask a buyer an order-related question prior to shipping their order.' This makes the tool's general purpose clear and distinguishes it from the sibling delivery and service confirmation tools, though 'order-related question' remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual timing ('prior to shipping their order') and explicitly warns that it 'Runs in your Kuudo deployment, not here,' which is a useful negative usage signal. However, it does not name alternatives or explain when this tool should be preferred over the other Messaging_* confirmation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of describing behavior. It does disclose that the tool sends a message, which is a side-effecting action, and that execution happens in the Kuudo deployment, not the current environment. However, it leaves 'Catalog entry' unexplained and gives no information about prerequisites, authorization, or how the order/buyer is identified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at three short sentences and avoids redundant wording. It could be slightly better ordered by putting the core purpose before the catalog/deployment note, but it remains scannable and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description conveys the core purpose and deployment location, which is much of what an agent needs. It is incomplete on usage boundaries and does not clarify whether the agent can invoke this tool directly or should treat it only as a catalog/reference entry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared parameters and zero required parameters, so the 0-param baseline of 4 applies. The description does not need to explain parameter meanings, although the permissive 'additionalProperties: true' leaves a minor gap about whether hidden free-form fields are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and object: it sends a message to a buyer about warranty information for a purchase in their order. The warranty focus distinguishes it from sibling Messaging_* tools, though the opening 'Catalog entry' phrase adds ambiguity about whether this is a directly executable tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use it when needing to send warranty details to a buyer for an order. It also provides a deployment constraint by saying it runs in the Kuudo deployment rather than here, but it does not explicitly contrast it with alternative messaging tools such as Messaging_sendInvoice or Messaging_createLegalDisclosure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the transparency burden. It does disclose an execution trait ('Runs in your Kuudo deployment, not here') and says the tool 'returns' data, implying read-only behavior, but it does not mention side effects, auth requirements, rate limits, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences with little waste. However, the most action-relevant purpose is placed after the 'Catalog entry' and environment warnings, so it is not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-schema read tool, it provides the core purpose and an important environment caveat. It is incomplete around return format, error/pagination behavior, and what 'not here' means operationally, and there is no output schema or annotation to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero declared properties, so the 0-parameter baseline is 4; the description nevertheless adds meaning by specifying the scope is a single SKU listing. It still does not name a concrete parameter key, but that is an acceptable gap given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Returns the lowest priced offers') on a specific resource ('a single SKU listing'), so an agent can recognize the core purpose. It does not explicitly contrast with sibling tools like getItemOffers or getListingOffersBatch, and the 'Catalog entry... not here' preamble adds slight ambiguity, which keeps it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need lowest-priced offer data for one SKU listing. The line 'Runs in your Kuudo deployment, not here' gives an environment constraint, but no sibling alternatives or when-not-to-use conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose an important trait: this is a catalog entry that runs in another deployment, not here. Still, it omits side effects, prerequisites, or what happens after purchase, which is significant for a purchasing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loads the most unusual and decision-relevant information: this is a catalog entry running elsewhere. It has minimal fluff, though 'Catalog entry' could be clearer without more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is fairly lean but still leaves gaps. The catalog-entry nature and remote execution context are useful, but the relationship to Shipping_purchaseShipment and the expected invocation context in Kuudo are not clarified enough for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, and the baseline for a 0-parameter tool is 4. The description mentions using a shipment and the best fit service offering but does not need to detail parameter syntax since there are no formal parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it purchases a shipping service for a shipment, specifically using the best fit service offering. However, it does not differentiate this from the very similar sibling Shipping_purchaseShipment, so the 'direct' aspect remains unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' provides clear contextual guidance that this tool is not directly invocable in the current environment. It does not explicitly name alternatives or state when to choose this over Shipping_purchaseShipment or Shipping_oneClickShipment, leaving that selection opaque.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden, and it does add useful context by stating it 'Runs in your Kuudo deployment, not here' and returns a JSON schema. However, it does not disclose side effects, auth requirements, or failure behavior, and 'Catalog entry' adds ambiguity about whether this is an invocable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose sentence is compact, but the description front-loads the vague fragment 'Catalog entry.' and places the execution-location caveat before the main function. It is not overly long, but the ordering and opaque opener prevent a cleaner structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential facts: what it returns, why, and where it runs. The exact workflow trigger and how the returned schema should be consumed are left implicit, but this is relatively complete for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the 0-parameter baseline of 4 applies. The description does not need to explain parameters, and it appropriately focuses on the returned schema rather than input handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a JSON schema for providing additional inputs when purchasing a shipping offering, giving a specific verb and resource. It does not explicitly distinguish itself from similar siblings like Shipping_getCarrierAccountFormInputs, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when needed to purchase a shipping offering' implies the intended usage context, but it is not an explicit directive about when to call this tool. No alternatives or exclusions are mentioned, so the guidance remains implied rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior. It does indicate that this is a return-style, non-mutating operation and adds an execution-environment caveat ('Runs in your Kuudo deployment, not here'), but it does not mention permissions, failure modes, or whether the returned data varies by carrier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is concise and front-loaded with the key behavior. However, 'Catalog entry.' is vague filler, and 'Runs in your Kuudo deployment, not here' is unclear without further explanation, so not every sentence fully earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter catalog endpoint, the description gives the essential purpose but omits useful context such as whether the returned input schema is carrier-specific, how the form inputs should be used afterward, or any response structure. The absent output schema increases the need for a bit more return-value detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so no parameter documentation is needed. The baseline of 4 applies because description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return') and resource ('a list of input schema required to register a shipper account with the carrier'). This clearly differentiates it from sibling tools such as getCarrierAccounts and linkCarrierAccount, which address different parts of the carrier-account workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like Shipping_getCarrierAccounts or Shipping_linkCarrierAccount. The note about running in the user's Kuudo deployment is context, but it does not explain the calling workflow or when this endpoint should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the important contextual behavior that the call runs in the caller's Kuudo deployment rather than the current environment, and 'get' implies a read-only retrieval. It does not, however, describe possible side effects, response shape, pagination, or any required permissions, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded with the environment constraint before the core purpose. The opening 'Catalog entry.' is vague filler that does not earn its place, slightly reducing the score, but the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description provides the essential resource and environment context. It is missing details about what the returned history contains, whether the call is safe/read-only, and any prerequisites, which leaves an agent to infer those aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so the baseline is 4. The description adds no parameter details because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation clearly: 'to get the history of the previously generated collection forms', identifying both the verb and resource. It does not explicitly differentiate from sibling Shipping_getCollectionForm or Shipping_generateCollectionForm, but the 'previously generated' qualifier carries that distinction. The leading 'Catalog entry' phrase adds noise and is not a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers implied usage context: the tool is for retrieving history of forms that were already generated, which implies it is not for generating or fetching a single current form. It also contains an environment note, 'Runs in your Kuudo deployment, not here', which is a usage-relevant constraint. However, no explicit alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral disclosure burden. It does reveal that this is a catalog entry running in the Kuudo deployment rather than the current environment, which is useful. It does not mention authentication, side effects, or output shape, but 'Returns' implies a read-style operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 22 words. It front-loads the key facts, though 'Catalog entry' and 'Runs in your Kuudo deployment, not here' are somewhat redundant, which keeps it from being perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is mostly adequate: it explains where the tool runs and what it returns. It leaves some gaps, such as what an offering includes, whether arbitrary additional inputs are expected despite the empty schema, and what to do when not in the Kuudo deployment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined parameters, so there is no parameter documentation burden. The description does not add parameter-level detail, but with an empty schema this is not a meaningful gap; the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool 'Returns the available shipping service offerings,' which clearly names the verb and resource. The 'Catalog entry' phrase and deployment note add context without fully hiding the core purpose, but it does not explicitly differentiate from ShippingLegacy_getRates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a meaningful context signal by stating that the tool 'Runs in your Kuudo deployment, not here,' which tells the agent where invocation is valid. However, it does not explicitly state when to use this tool over its siblings or give a direct when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds important context by disclosing that the tool is a 'Catalog entry' that runs in a Kuudo deployment 'not here', implying limited or no local executability. However, it does not specify what 'valid' means, whether any response is returned, or whether there are side effects, leaving behavioral expectations incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly front-loaded with the most important constraint ('Catalog entry', 'Runs in your Kuudo deployment, not here'). The first phrase is somewhat redundant with the deployment note, but the overall length is appropriate and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is minimally adequate, but it lacks details about return values, what constitutes a valid or invalid account, and what an agent should do after invoking it. The 'Catalog entry' phrasing also leaves uncertainty about whether the tool is callable at all in the current environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero declared parameters, so the input schema already fully covers the parameter surface; the description does not need to add parameter detail. The baseline of 4 applies, and the additionalProperties:true quirk is not significant for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Verify if the current account is valid') with a specific resource ('current account'). However, the opening phrase 'Catalog entry' and the deployment note 'Runs in your Kuudo deployment, not here' muddle whether this is a real invocable tool or a placeholder, and it does not differentiate itself from sibling tools like Sellers_getAccount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit deployment exclusion ('not here') that tells an agent not to invoke it in the current environment, but it provides no positive guidance on when to use this tool or which sibling alternative to prefer. The context is helpful but leaves tool selection largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It reveals that the action is a rotation and runs remotely, but it does not explain side effects such as invalidation of the previous secret, required permissions, reversibility, or whether output is returned. For a sensitive mutation operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the opening 'Catalog entry' is filler that does not help an agent select or invoke the tool. The remaining two clauses are useful, and the description is not bloated, but it is not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is underspecified: it does not identify which developer application is affected, what inputs are expected, what the result looks like, or what authorization is required. The remote-execution note is helpful but does not make the description complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined parameters, so there is little parameter detail for the description to add. The description does not explain how the target developer application is identified, but the zero-parameter baseline of 4 applies because the schema does not require any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Rotates application client secrets for a developer application.' The 'Runs in your Kuudo deployment, not here' clause adds execution-context clarity, and the operation is distinct enough from the unrelated sibling tools without needing further differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating that execution happens in the user's Kuudo deployment rather than locally. It does not mention exclusions or alternatives, but no closely related alternatives appear in the sibling list, so this is a reasonable level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add meaningful context by noting this is a catalog entry that runs in the Kuudo deployment, not in the current environment, and 'Retrieve' implies a read-only operation. However, it does not describe output format, pagination, time range, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no filler, using two sentences to convey purpose and deployment context. The fragment 'Catalog entry.' and the placement of the environment note before the actual purpose are slightly awkward, but the text remains compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-style tool, the description conveys the core result: trends of return-related topics for a browse node. Yet it lacks detail about return value structure, how the browse node is identified, and how this tool relates to closely named siblings, leaving the agent with only a minimal catalog-style understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero schema-defined parameters and schema description coverage is effectively 100%, so there is little for the description to add. The mention of 'browse node' gives conceptual context about the data scope, though it does not introduce a named parameter, which aligns with the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Retrieve', and a specific object: 'trends of topics that customers mention when they return items in a browse node.' This clearly distinguishes the tool from sibling tools focused on review topics, review trends, or item-level data, even without naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over closely related siblings such as CustomerFeedback_getBrowseNodeReturnTopics, getBrowseNodeReviewTrends, or getItemReviewTrends. The only operational note, 'Runs in your Kuudo deployment, not here,' addresses environment rather than alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does add context about remote execution ('Runs in your Kuudo deployment, not here') and the read-only nature of returning estimates. However, it does not clarify side effects, authorization needs, or the meaning of 'Catalog entry,' leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but it front-loads the vague 'Catalog entry' and the ambiguous 'not here' before the functional sentence. The most important information—what the tool returns—appears last. It is concise but not optimally structured for an agent quickly scanning for the callable behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and an effectively empty input schema, so the description must supply enough context for both selection and invocation. It names the SKU and marketplace but does not specify required request body fields, the exact way to indicate the SKU, or the shape of the returned fee estimate. An agent could identify the right tool but would likely struggle to construct a valid call without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and additionalProperties true, so the description is the only source of parameter meaning. It names the two key conceptual inputs: the seller SKU and the marketplace in the request body. It does not provide exact field names or types, but for a zero-parameter schema this is a reasonable baseline-plus contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Returns the estimated fees for the item indicated by the specified seller SKU in the marketplace specified in the request body.' It distinguishes this from the sibling Fees_getMyFeesEstimateForASIN by centering on seller SKU. Despite the odd 'Catalog entry' prefix, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is appropriate when the caller has a seller SKU and knows the marketplace, but it never explicitly states when to use this tool versus the ASIN-based variant or the batch Fees_getMyFeesEstimates. The deployment note 'Runs in your Kuudo deployment, not here' gives context but not clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It warns that the tool 'runs in your Kuudo deployment, not here' and calls the operation a 'preview,' implying it is not the final confirmation, but it does not disclose side effects, persistence, required authorization, return contents, or how the preview is later confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and mostly relevant, but the core action is buried after two introductory fragments, and 'Catalog entry.' adds little value. It would be stronger if the 'Generate...' sentence came first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an empty input schema, the description must provide enough operational context on its own. It does not explain what the preview contains, how to identify the shipment, what inputs are required beyond vague 'boxes and/or items,' or how this fits with list/get/confirm preview operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with no declared parameters, so the description's mention of 'intended boxes and/or items' and 'a shipment with a confirmed carrier' is the only semantic guidance. This is adequate for a zero-parameter schema, though it still lacks concrete encoding details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'Generate a shipment content update preview' — and scopes it with 'a set of intended boxes and/or items for a shipment with a confirmed carrier.' This clearly differentiates it from sibling list/get/confirm preview operations and from packing-option generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear precondition for use: the shipment must have a 'confirmed carrier' and the request concerns 'intended boxes and/or items.' It does not explicitly name list/get/confirm preview tools as alternatives, but the context is clear enough for an agent to know when this operation is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden; it does add useful behavioral context by stating this is a catalog entry, runs externally in Kuudo, and returns a bill of lading. However, 'catalog entry' is ambiguous and unexplained, and there is no mention of output format, authentication needs, or operational limitations beyond the deployment note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly economical, but the opening fragment 'Catalog entry.' is vague and partly redundant with the following sentence about running in Kuudo. Reordering to lead with the return behavior would make the structure clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool the description covers the essential facts: what it returns, for which shipment type, and where it runs. It remains incomplete about what 'catalog entry' means operationally and what the agent should do with the returned document, especially since no output schema is present to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema description coverage is 100%, so the description does not need to document inputs; the no-parameter baseline is 4. The description adds nothing about how a specific shipment is identified, but that is not a significant gap given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and a specific resource ('bill of lading') scoped to LTL/FTL shipments, which makes the core purpose clear. It does not explicitly contrast with sibling document-returning tools such as FulfillmentInboundV0_getLabels or Shipping_getShipmentDocuments, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it applies to LTL/FTL shipments and, importantly, notes it runs in the user's Kuudo deployment rather than in the current environment. It does not name alternatives or give explicit when-not-to-use guidance, so it lacks the full exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does reveal the core side effect ('sends a message') and adds a useful execution-context trait ('runs in your Kuudo deployment, not here'). However, it does not mention permissions, reversibility, rate limits, or downstream consequences, which would make the behavioral picture richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the actual purpose is delayed until the third sentence. 'Catalog entry' is vague filler, and the deployment note comes before the main action. Front-loading the core behavior would make it more useful and less cluttered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description conveys the core operation and the execution environment. Still, it omits any expected input context, permission requirements, or result/acknowledgment information, leaving some uncertainty for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and the context signals confirm 0 parameters, so the baseline is 4. The description adds no parameter-level detail, which is acceptable at this baseline; the only complication is additionalProperties: true, which is not addressed but does not lower the score given the zero-parameter expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('sends a message to a buyer') and names the two related goals: arranging a delivery and confirming contact information for a delivery. This is clear enough to distinguish it from sibling Messaging_* tools focused on order details, service details, invoices, or warranties, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use condition: when the agent needs to arrange a delivery or confirm delivery-related contact information. It does not provide exclusions or point to a specific alternative tool, but the intended context is much clearer than a generic mutation description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does convey read-only behavior via 'Returns' and adds an execution-environment note ('Runs in your Kuudo deployment, not here'), but it does not disclose failure modes, pagination, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core return-purpose sentence is efficient, but 'Catalog entry.' adds little value and the environment note is awkwardly placed before the main statement. The description is short but could be restructured to lead with the return purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description covers purpose, identifier basis, and an environment caveat. It is incomplete because the empty input schema leaves uncertainty about how to pass the ASIN or SellerSKU, and no output shape or error behavior is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties, so the description's mention of 'ASIN or SellerSKU' is the only signal of what the call accepts. This adds meaningful meaning beyond the schema, though it stops short of giving exact parameter keys or requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Returns the parent categories to which an item belongs,' and identifies the input basis as ASIN or SellerSKU. This distinguishes it from sibling catalog tools that retrieve or search catalog items rather than parent categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving parent categories when an ASIN or SellerSKU is known, but it never names alternatives or states when not to use it. The usage context is inferable, but explicit routing guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the operation is a retrieval ('Retrieve'), the time window ('past six months'), the polarity split ('positive and negative'), and a notable execution constraint ('Runs in your Kuudo deployment, not here'). This goes well beyond a minimal definition, though it does not describe output format or invocation mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but not every sentence earns its place. 'Catalog entry.' is a redundant label that adds no value. 'Runs in your Kuudo deployment, not here' is useful context, and the retrieval sentence is clear. The main verb is not front-loaded, and the cryptic deployment phrase could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and an empty input schema, the description gives the core purpose and time range but leaves ambiguities: how the item is identified, what the trend data actually looks like, and what 'runs in Kuudo, not here' means for a caller. It is minimally viable for a zero-parameter tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero defined parameters, so the baseline is 4. The description does not need to explain individual parameters, and the schema's 100% coverage is trivial. However, it does not clarify whether the item is identified via context, hidden properties, or no input at all, which is a minor gap given additionalProperties is true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and names the exact resource: an item's positive and negative review trends for the past six months. It distinguishes itself from sibling tools like getBrowseNodeReviewTrends by explicitly saying 'item' rather than 'browse node', and from getItemReviewTopics by focusing on 'trends' rather than 'topics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention when to choose this over related tools, nor does it state any exclusions or prerequisites. The deployment note is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the tool is a catalog entry, that it runs in Kuudo rather than here, and that results are paginated. Still, it does not mention response shape, authentication, rate limits, or side effects; the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler. The main functional statement is clear and easy to parse. The placement of 'Catalog entry' and 'Runs in your Kuudo deployment, not here' before the purpose is slightly inefficient, but the overall structure remains concise and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should provide enough context for correct invocation. It identifies the output as a paginated list of pallet packages but does not explain how the shipment is identified, how pagination works, what the response looks like, or how the Kuudo deployment requirement affects invocation. The description is incomplete as an operational guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so there are no parameter names or types the description must explain. The mention of 'in a shipment' implies some shipment context, but since the schema defines no parameters, the description is not obligated to clarify parameter syntax or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it provides a paginated list of pallet packages in a shipment. The verb is specific ('Provides'), the resource is clear ('pallet packages in a shipment'), and it naturally distinguishes from sibling tools like FulfillmentInbound_listShipmentBoxes or FulfillmentInbound_listInboundPlanPallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' gives an explicit environment restriction and warns the agent that the tool may not be usable in the current context. However, it does not explicitly compare this tool to its siblings or state when to prefer it over similar tools such as listShipmentBoxes or listInboundPlanPallets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. The "Catalog entry" and "not here" statements usefully disclose that this is not an executable local operation, and "Updates" signals mutation. It does not mention prerequisites, reversibility, or side effects of updating tracking details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The environmental warning is front-loaded and the action verb is stated clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an empty input schema, the description should provide enough context to invoke it correctly. It only names the action and the remote deployment; an agent cannot know which shipment identifier, tracking fields, or expected response are involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented properties, so there are no parameter semantics to add; per the 0-param baseline, this is adequate. The description mentions "tracking details" but arbitrary additional properties are allowed, so an agent still gets minimal field-level help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Updates a shipment's tracking details" states a clear verb and resource, so the agent understands the core action. However, it does not differentiate from sibling update tools such as FulfillmentInbound_updateShipmentName or explain what "tracking details" specifically covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Runs in your Kuudo deployment, not here" is an explicit environmental exclusion, telling the agent this tool should not be invoked in the current context. It does not name alternatives or specify when to choose this over other shipment-update tools, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the operation is a mutation, may both update and request shipment, and runs in the Kuudo deployment rather than locally. However, it does not mention permissions, side effects, reversibility, or what 'requests shipment' concretely triggers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core operation while adding a useful deployment caveat. 'Catalog entry' and 'Runs in your Kuudo deployment, not here' overlap slightly, so it is concise but not maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no annotations and no output schema, and this is a mutating operation. The description explains what the tool is for but not how the agent should invoke it, what payload fields are expected despite the empty schema, how the update/request-shipment choice is made, or what response/side effects to anticipate. It supports selection but not confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the 0-param baseline applies; no parameter documentation is strictly needed. The description adds no parameter detail, but there are no declared parameters for it to explain. The additionalProperties:true allowance could be flagged, but it does not reduce the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Updates and/or requests shipment') and names the exact resource ('fulfillment order') with a distinguishing condition ('with an order hold on it'). This clearly separates it from the many FulfillmentOutbound sibling tools like create, cancel, or get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: for a fulfillment order with an order hold. However, it does not explicitly state alternatives or when not to use it, such as using createFulfillmentOrder for non-held orders or cancelFulfillmentOrder to void. The usage context is present but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the operation 'Creates a subscription' and that it runs remotely in the Kuudo deployment, which is a useful behavioral trait. However, it does not mention prerequisites such as the destination already existing, whether duplicates are allowed, authentication needs, or what the response contains, leaving notable gaps for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly information-dense, front-loading the execution location and then stating the purpose. The phrase 'Catalog entry' is filler and does not help an agent select or invoke the tool, which prevents a perfect score. Otherwise, the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple concept, the tool lacks an output schema, annotations, and defined parameters, so the description must carry the full invocation burden. It names conceptual inputs but does not provide enough detail for an agent to construct a valid call, such as parameter names, destination formats, or notification type values. The note about running in the Kuudo deployment is interesting but does not make the tool actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined properties, but the description adds meaning by naming the two conceptual inputs: 'specified notification type' and 'specified destination.' This is valuable given the empty schema, though it does not specify allowed formats, enums, or parameter names, so it stops short of a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates a subscription for the specified notification type to be delivered to the specified destination.' This clearly separates it from sibling tools like createDestination and getSubscription. The 'Catalog entry' prefix is vague, but the core sentence is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a subscription needs to be created for a notification type and destination, and it adds the context that it runs in the Kuudo deployment. However, it does not explicitly mention when not to use it or point to sibling alternatives such as Notifications_createDestination. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals an important operational trait (runs in the Kuudo deployment, not the current environment) and implies a read-only retrieval action, but it does not mention authentication needs, rate limits, or output behavior beyond retrieving topics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. The environment caveat is useful, though leading with 'Catalog entry' adds little semantic value and the actual retrieval statement appears last; still, the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool this is mostly usable, but without an output schema or an explicit parameter note, the return shape and the browse-node binding are left to inference. It also does not address routing among the many similar CustomerFeedback sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero documented parameters and 100% schema description coverage, so the baseline is 4. The description adds semantic meaning around 'browse node' and 'return items,' though it does not clarify how the browse node is supplied given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence 'Retrieve the topics that customers mention when they return items in a browse node' gives a specific verb, resource, and scope. The phrasing 'return items' clearly differentiates it from sibling review-topic/trend tools like CustomerFeedback_getBrowseNodeReviewTopics and CustomerFeedback_getBrowseNodeReturnTrends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need return topics for a browse node. It also provides an environment note, 'Runs in your Kuudo deployment, not here,' but it does not explicitly contrast this tool with similar CustomerFeedback siblings or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose an important runtime trait, 'Runs in your Kuudo deployment, not here', and implies a read-only retrieval, but it omits permission requirements, output shape, and limitations around the six-month window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the environment caveat before the action. 'Catalog entry' is slightly cryptic and adds little, but the overall structure is efficient and free of redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description covers the main operation and time scope. However, it does not describe the output format or explain how the browse node is identified, and the environment caveat is left ambiguous; with no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema has no gaps at 100% description coverage. The description appropriately avoids inventing parameter details, though it implies a browse-node scope that is not expressible in the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, Retrieve, and names the exact resource: positive and negative review trends of items in a browse node for the past six months. This narrow scope distinguishes it from sibling tools like getBrowseNodeReturnTrends and getBrowseNodeReviewTopics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no sibling tool is named as an alternative. The intended use is implied by the operation description, and the environment caveat adds context but does not help choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds meaningful behavioral context beyond the basics: the 'Runs in your Kuudo deployment, not here' deployment caveat and the precise 10+10 count of returned topics. However, it does not disclose whether review-topic data is restricted/protected, any authentication requirements, rate limits, or failure behavior, which is a notable gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler; the core retrieval statement is clear and the deployment caveat is paired with the catalog-entry label efficiently. The only slight weakness is the cryptic two-word fragment 'Catalog entry,' which adds limited value and feels like leftover labeling rather than useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero declared parameters and no output schema, the description covers the value returned (ten positive and ten negative topics) and the runtime context, which is most of what an agent needs. But it leaves open how the item is identified despite additionalProperties: true, and says nothing about prerequisites, restricted-data handling, or error cases — gaps that matter more because there are no annotations or output schema to fill them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties but allows additionalProperties, so the only semantic guidance available is the description's reference to 'an item's,' which correctly signals the subject of the query. Per the baseline rule for zero-parameter tools, the description need not enumerate parameters, and it does add meaning beyond the empty schema by tying the operation to an item context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Retrieve an item's ten most positive and ten most negative review topics.' It clearly states the output shape (ten positive, ten negative) and unambiguously distinguishes this tool from sibling CustomerFeedback tools like getBrowseNodeReviewTopics (browse-node scoped) and getItemReviewTrends (trends rather than topics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope word 'item' implies when to use this tool — for item-level review topics rather than browse-node-level ones — and the 'Runs in your Kuudo deployment, not here' note gives a mild environmental caveat. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative, leaving the agent to infer the routing from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals a significant execution-environment trait—running in the user's Kuudo deployment, not the current environment—and frames the operation as read-only by returning estimates. It does not cover authentication, rate limits, error cases, or response format, but the key deployment warning is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main functional sentence is tight and front-loaded. However, the opening 'Catalog entry.' is a wasted phrase that adds no usable information; removing it would make the description fully economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity fee-estimate lookup, the description names the core inputs and the execution environment. Yet with no output schema and an empty input schema, it leaves the request body structure, response format, and the practical implications of 'not here' unexplained, so an agent still lacks complete invocation detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters and schema coverage is 100%, so the baseline is 4. The description adds meaningful semantics by identifying the two central inputs: the ASIN and the marketplace in the request body. It stops short of specifying exact field names or formats, but it compensates for the empty schema adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action—returning estimated fees—for a specific resource identified by ASIN, with marketplace scope. It differentiates itself from the sibling Fees_getMyFeesEstimateForSKU by naming ASIN rather than SKU. The opening 'Catalog entry.' is unhelpful, but the functional sentence is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a fee estimate for a single ASIN is needed and notes it executes in the Kuudo deployment, not locally. However, it does not explicitly name alternatives such as Fees_getMyFeesEstimateForSKU or Fees_getMyFeesEstimates, nor does it state conditions for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait: the tool runs in a Kuudo deployment, not here, which prevents an agent from attempting invocation in the current environment. However, it omits details like return format, authentication requirements, or what 'catalog entry' means for execution, leaving the actual behavior under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each contributing distinct information: catalog-entry status, deployment environment, and the document's purpose. There is no redundancy or padding, and the most important constraint ('not here') is front-loaded before the functional statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential purpose and deployment limitation, but leaves gaps: it does not describe what the returned document looks like (binary, URL, base64), and it relies on unexplained jargon like 'Kuudo' and 'PCP' that could confuse an agent unfamiliar with the domain. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the description has no need to explain parameters. With 0 params, baseline is 4, and the description does not detract from that by adding misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Provide delivery challan document') and scopes it to 'PCP transportation in IN marketplace,' so it is not a tautology and is clearly distinguishable from sibling tools by domain. However, 'Catalog entry' introduces some ambiguity about whether this is a callable operation, and it does not explicitly differentiate from related FulfillmentInbound tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical context: it is for PCP transportation in the IN marketplace, and it explicitly says 'Runs in your Kuudo deployment, not here,' which tells the agent this tool is not callable in the current environment. It does not name alternatives or provide an explicit 'use when' statement, but the context and exclusion are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does disclose that this is a catalog entry, that it runs in the user's Kuudo deployment rather than 'here', and that the result is paginated. However, it omits authentication requirements, side effects, and what the 'Kuudo deployment' note actually means for invocation, leaving transparency partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no verbose elaboration. However, the main action is placed after the deployment note instead of being front-loaded, and the initial 'Catalog entry' fragment is cryptic. Still, the description is brief and the key operational sentence is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations, no output schema, and an empty parameter schema, the description should explain how to identify the shipment, how pagination works, and what the response contains. It only gestures at these points with 'for a given shipment' and 'paginated list'. The 'Kuudo deployment' note raises more questions than it answers, so the description is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true and no parameter descriptions, so the description is the only source of parameter meaning. It signals that a shipment must be specified ('for a given shipment') and that the response is paginated, implying pagination parameters. It does not name the parameter or format, but it adds meaningful semantics beyond the empty schema. With zero documented parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb ('Retrieve') and a specific resource ('shipment content update previews') with the scope 'for a given shipment' and a 'paginated list'. This distinguishes it from siblings like getShipmentContentUpdatePreview (single item) and generateShipmentContentUpdatePreviews (creation). The cryptic 'Catalog entry' phrase does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a paginated list of shipment content update previews for a shipment), but it does not explicitly name alternatives or provide when-not-to-use guidance. The 'Runs in your Kuudo deployment, not here' note gives environmental context but no routing to sibling tools such as getShipmentContentUpdatePreview or confirmShipmentContentUpdatePreview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose that this is a catalog entry running in the user's Kuudo deployment and that it performs a deletion. However, it does not disclose irreversibility, permission requirements, or downstream effects beyond the deletion itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and free of fluff. The execution-context note and the action statement each add necessary information without redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description lacks the target-identification mechanism and any indication of return behavior or failure effects. The schema and output-schema are empty, so the description needed to compensate more than it does; an agent could not confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and allows additional properties, so there is nominally nothing to document. However, a delete operation logically needs some way to identify which scheduled transaction to delete, and the description provides no guidance on any identifier or argument. This ambiguity makes the otherwise high schema coverage insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') and a specific resource ('a transaction request that is scheduled from Amazon Seller Wallet account to another customer-provided account'). This is clearly distinct from the other SellerWallet sibling tools, none of which delete scheduled transaction requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: it is used to delete a scheduled Seller Wallet transaction request, and it notes that the operation runs in the Kuudo deployment rather than in the current environment. It does not explicitly compare against alternatives, but the delete action is unique among the SellerWallet siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose an important environment trait—that the tool runs in Kuudo rather than here—and implies a write action via 'submits.' However, it omits side effects, eligibility criteria, authorization needs, and response behavior, which leaves meaningful unknowns for a mutation-like API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three short sentences and contains little filler. The purpose is not front-loaded because 'Catalog entry' comes first, but the overall size is appropriate and the environment caveat is useful enough to justify its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description gives only the basic purpose and runtime environment. It lacks details about required request body, shipment eligibility, expected response, or failure behavior, so an agent could select it confidently but cannot invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with additionalProperties true, so there are no formal parameter names to document. However, the description does not clarify how to specify the eligible shipment or the NDR feedback payload, making invocation ambiguous despite the schema's permissive additionalProperties flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—submitting NDR Feedback for an eligible shipment—with a clear verb and resource. No sibling tool exists for NDR feedback, so it is easy to distinguish among the large Shipping_ family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by noting the API 'Runs in your Kuudo deployment, not here,' and limits the action to 'any eligible shipment.' It doesn't list explicit alternates or exclusions, but no sibling tool covers NDR feedback, so the selection guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only, list-returning operation and notes the deployment quirk, but it does not mention authentication, rate limits, pagination, or any side effects. This is adequate for a simple zero-parameter read but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the key return semantics appear in the second sentence. The opening fragment 'Catalog entry' is vaguely redundant and 'Runs in your Kuudo deployment, not here' is awkwardly phrased, but there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation without an output schema, the description gives enough high-level return information to invoke correctly: a list of marketplaces and participation details. It omits response structure details, but the simplicity of the tool makes the definition sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema is empty and fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 a list of marketplaces where the seller can list items and information about the seller's participation. This clearly identifies the tool's purpose and distinguishes it from account-level Sellers tools like Sellers_getAccount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or alternative guidance, but the sentence 'Runs in your Kuudo deployment, not here' provides a useful deployment constraint. The unique purpose among siblings makes the usage context reasonably implied, though the description does not state exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable behavioral context: it is a 'Catalog entry,' runs in a separate Kuudo deployment, and returns a list. This makes the deployment boundary explicit. It does not disclose input format or return structure, but the operation is a simple read/list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences convey the catalog nature, deployment context, and primary behavior with no filler. The most important environmental constraint is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool the description is close to sufficient, but the postal-code input mismatch is a material gap: an agent cannot reliably invoke it without knowing how to pass the postal code. It also does not explain what 'access points' are or the shape of the returned list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties, yet the description mentions 'input postal code,' adding a semantic input the schema does not define. This is useful but incomplete because it does not specify a parameter name, type, or format, leaving the agent to guess how to supply the postal code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns a list of access points in proximity of input postal code.' This clearly identifies the tool's purpose. It does not explicitly contrast with sibling tools, but 'access points' is distinct among the Shipping sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Runs in your Kuudo deployment, not here' gives clear environmental context and explicitly excludes the current runtime. However, it does not mention when to choose this over an alternative or name a sibling fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool is a catalog entry, runs elsewhere, and returns instructions rather than mutating state. It does not mention permissions, rate limits, or required inputs, but for a non-runnable catalog entry this is a reasonable minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the most important routing information ('Catalog entry... not here') front-loaded. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero declared parameters and no output schema, the description tells an agent what the operation returns and that it is not available in this environment. It lacks detail on the shape of the returned instructions, but for a catalog-entry stub this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero properties and 100% coverage, so there are no parameter details for the description to add. The description offers no parameter-level detail, but none is required in this schema; the additionalProperties:true caveat is not addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear retrieval verb ('Returns') and a specific resource ('labeling requirements and item preparation instructions'), which distinguishes it from the many other FulfillmentInbound commands in the sibling list. The odd 'Catalog entry' phrasing is immediately clarified by the rest of the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit execution-context constraint: the tool runs in the user's Kuudo deployment, not here, so an agent knows not to invoke it in the current environment. However, it gives no guidance on when to choose this over related prep-related siblings such as listPrepDetails or setPrepDetails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavior burden; it does disclose that this sends a critical message remotely from the Kuudo deployment. However, it omits side effects, permissions, reversibility, and response behavior, which matters for a send/mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short and behavior is stated up front, but the opening 'Catalog entry.' adds little and the deployment note is slightly cryptic. Overall it is efficient with only minor filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no params and no output schema, the description is adequate for selection. But it never explains what additional properties are accepted (schema allows arbitrary ones) or what identifiers/context are needed, so invocation guidance is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties and 100% coverage, so there are no parameters for the description to clarify. AdditionalProperties is true, which creates slight ambiguity, but the zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sends') and defines the resource as a critical message containing legally required disclosure documents for a seller-buyer transaction. This clearly differentiates it from sibling Messaging tools like sendInvoice or CreateWarranty by its legal-document purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the deployment context ('Runs in your Kuudo deployment, not here') and the triggering condition (seller legally obligated to provide documents to buyer). It does not explicitly name alternatives or provide when-not-to-use guidance, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It transparently states that the operation runs in the Kuudo deployment, not the current environment, moves money to a Seller Central deposit method, and only applies if eligible. It omits irreversibility and idempotency details, but the core financial and deployment behavior is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable, with three sentences and no wordy filler. The opening 'Catalog entry' adds only marginal value since the next sentence already states it runs in the Kuudo deployment, but overall the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial, side-effecting tool with no annotations and no output schema, the description leaves gaps around expected response or status, eligibility rules, synchronous/asynchronous behavior, and failure modes. It covers the core action and deployment context but not enough for fully confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero properties and allows additionalProperties, so the description is the only source indicating that marketplaceId and accountType are meaningful identifiers for this operation. It names both parameters but does not specify their types, formats, or whether they are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Initiates') and identifies the exact resource: an on-demand payout to the seller's default deposit method in Seller Central, scoped by marketplaceId and accountType, with an eligibility qualifier. This clearly distinguishes it from read-oriented siblings like Transfers_getPaymentMethods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when an on-demand payout to a seller's default deposit method is needed and the seller is eligible. However, it does not explicitly state when not to use it, does not name alternatives, and does not explain how to determine eligibility before invoking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amazon-selling-partner-mcp MCP server](https://glama.ai/mcp/servers/KuudoAI/amazon-selling-partner-mcp/badges/card.svg)](https://glama.ai/mcp/servers/KuudoAI/amazon-selling-partner-mcp)

Score Badge

Copy to your README.md:

[![amazon-selling-partner-mcp MCP server](https://glama.ai/mcp/servers/KuudoAI/amazon-selling-partner-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KuudoAI/amazon-selling-partner-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KuudoAI/amazon-selling-partner-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server