Retrieve recent tracked orders from your store by specifying the number to fetch.
Get the latest tracked orders
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "GetStoreTrackedOrders"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The amount of orders to retrieve |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only operation but fails to disclose behavioral traits such as sorting, pagination, authentication requirements, or what constitutes 'tracked'. Without annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but may sacrifice necessary details. Front-loading is not an issue; however, the tool could benefit from a slightly expanded description without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter, the description is incomplete. It doesn't explain what tracked orders are, how they relate to store context, or what the output looks like, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents the 'count' parameter with a description. The tool description adds no extra meaning, e.g., default value, limits, or behavior when omitted. Schema coverage is 100%, but description offers no augmentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the latest tracked orders', matching the tool name. However, it doesn't specify what 'tracked orders' means or how they differ from other order retrieval tools like GetOrderListFull, which diminishes distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool over alternatives. With many sibling tools for order retrieval, an explicit statement of context or exclusions is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.