Retrieve open orders from your Trade Republic account. Set include_terminated to true to fetch finished, cancelled, or expired orders instead.
Open orders. With include_terminated=true: finished, cancelled and expired orders instead.
| Name | Required | Description | Default |
|---|---|---|---|
| include_terminated | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and non-destructive, so the description only needs to add behavioral context. It adds the key behavior that include_terminated changes the returned set from open orders to finished/cancelled/expired orders; however, it does not mention ordering, pagination, or whether duplicate/replacement orders are consolidated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the primary behavior and then add the parameter nuance. There is no filler or repetition of schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list tool, the description gives the essential invocation semantics and result scope. It is slightly thin on output expectations and doesn't disambiguate from get_transactions, but that is a minor gap given the simple input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that include_terminated=true returns finished, cancelled and expired orders instead of open ones. It covers the only parameter sufficiently for a boolean, though it leaves 'open' statuses unenumerated.
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 identifies the resource as orders and the primary scope as open ones, with the include_terminated flag broadening scope to finished/cancelled/expired. It is distinguishable from siblings like place_order or cancel_order, though it uses a noun phrase rather than an explicit verb like 'list'.
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 implies that the default call returns open orders and setting include_terminated=true retrieves terminated statuses, which tells an agent how to switch modes. It does not explicitly state when to prefer get_orders over get_transactions or other order-related siblings, nor give exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.