agentee-mcp

Check order status

get_order_status

Read-onlyIdempotent

Look up orders for the signed-in account to check status, total, and tracking URL. Use for 'where is my order' inquiries; read-only and cannot modify orders.

Instructions

Look up orders placed with the signed-in account's email — the latest ones, or one by its number — with status, total and a tracking page url. Use it for 'where is my order'; for an order not placed yet use get_order_preview. status is e.g. draft (unpaid, from prepare_order), pending_payment, paid, in_production, shipped, delivered or cancelled. number is the full order number such as AO-261023-1234; without it you get the newest orders first (limit default 5, max 20). Read-only: it can't cancel or change an order. An account with no email returns an empty list and a note.

Input Schema

Name	Required	Description	Default
`limit`	No	Max orders to return (default 5, max 20).
`number`	No	Exact order number to look up, e.g. AO-261023-1234; omit for the most recent orders.

Output Schema

Name	Required	Description	Default
`note`	No	Present when the account has no email on file.
`orders`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.0Oct 23, 2026

changedInput schema / properties / number / description

Previous value: -"Exact order number to look up; omit for the most recent orders."New value: +"Exact order number to look up, e.g. AO-261023-1234; omit for the most recent orders."

Addedv1.1.0Oct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses read-only intent in user terms ('can't cancel or change an order'), default ordering (newest first), the limit default of 5 and max of 20, the enumerated status lifecycle, and the edge case of an account with no email returning an empty list with a note. That is substantive behavior an agent can't derive from readOnlyHint/idempotentHint alone.

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 key routing information (what it does, the alternative, read-only) is front-loaded and every sentence carries content. The opening sentence is long and comma-heavy, costing some skimmability, but nothing is filler.

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

Completeness5/5

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

An output schema exists, so return values needn't be explained in depth, but the description still names the core fields and covers status lifecycle, empty-result behavior, and scoping to the signed-in account. Complete for a two-parameter read 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?

Schema coverage is 100%, so both parameters are already documented. The description restates the number format and limit default/max and adds that omitting number returns newest-first, which is already in the schema's own wording — marginal added value.

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 verb (look up) and resource (orders for the signed-in account), plus what it returns (status, total, tracking url). It explicitly contrasts with get_order_preview, so an agent can distinguish it from the nearest sibling without reading schemas.

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

Usage Guidelines5/5

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

Gives an explicit trigger phrase ('where is my order') and names the alternative (get_order_preview) with the condition that selects it ('for an order not placed yet'). Nothing is left to inference.

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