get_order_statusZeigt den aktuellen Stand einer Bestellung. In dieser Demo ist "reserviert" (on-hold) der Endzustand: der Betrag wird nie eingezogen und die Reservation faellt nach drei Tagen weg. Verlangt das Handle aus create_order.
| Name | Required | Description | Default |
|---|---|---|---|
| order_handle | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| total | No | ||
| status | Yes | ||
| created | No | ||
| is_paid | Yes | ||
| currency | No | ||
| order_handle | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explicitly discloses that the demo treats 'reserviert' (on-hold) as the final state, that the amount is never collected, and that the reservation expires after three days. This is important behavioral context that an agent could not infer from the schema and that materially affects how the result should be interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the main verb and resource, then adds only essential behavioral caveats. Every sentence adds value: status display, demo-specific terminal state, no-charge behavior, and prerequisite handle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-style tool, the description covers the main purpose, the key behavioral caveat, and the source of the input handle. It does not explain the exact return fields, but an output schema exists, so that is not a significant gap. It could mention that the status may be transitional in other environments, but the demo limitation is already explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only contains 'order_handle' with no description and 0% coverage, so the description must compensate. It explains what the parameter refers to (the handle produced by create_order), which gives the agent enough semantic grounding even though it does not specify the exact format. This is a meaningful addition beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Zeigt den aktuellen Stand einer Bestellung') and identifies the exact resource (Bestellung). It also immediately distinguishes this from siblings by specifying that it requires the handle from create_order, which makes it easy for an agent to see how it fits into the ordering workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the exact prerequisite context: it requires the handle from create_order. It does not explicitly name alternatives, but given the sibling list, it is clear that this is the order-status lookup and not payment-link or product retrieval. The privacy/demo behavior further clarifies when the tool reflects a final/terminal state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or stage: products are searched and read, orders are created and checked, payment links are created, and login has separate start and status tools. The two status tools are clearly separated by domain, so an agent is unlikely to confuse them.
All tools use a consistent snake_case verb_noun pattern such as create_order, get_order_status, search_products, and start_login. The action words are specific and the objects are clear, making the expected behavior predictable across the entire set.
Seven tools is well within the ideal range for a focused commerce demo. Each tool covers a necessary step in the demo workflow without redundant additions or unnecessary complexity.
The tool surface covers the full demo workflow: product discovery, order creation, payment-link generation, order status checks, and the external login flow. The demo's explicit constraints make the absence of admin operations such as update or delete acceptable, and there are no dead ends.