get_open_ordersRetrieve all open orders for the authenticated user, with optional filtering by market slugs, to review pending trades and manage active positions.
Get all open orders for the authenticated user
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Query parameters and pagination; use the exact field names shown. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is fully covered. The description adds only that results are scoped to the authenticated user's open orders — no details on pagination, result volume, or what 'open' means (unfilled vs partially filled).
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?
One short, front-loaded sentence with no filler. It is concise to the point of being thin, but nothing is wasted or buried.
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?
There is no output schema, yet the description says nothing about the shape of returned orders or pagination behavior, despite the schema exposing a pagination-bearing query object. For a listing endpoint this leaves an agent guessing about result size and how to page.
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 description coverage is 100%, including the nested slugs filter, so the description need not repeat parameter syntax. It adds no parameter meaning, and notably never mentions that filtering by market slug is even possible, leaving an agent to discover it in the 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?
States a specific verb and resource (get open orders) plus scope (authenticated user). It does not distinguish itself from sibling get_order (single order lookup) or cancel_all_open_orders, so an agent must infer the difference from names alone.
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 on when to call this versus get_order for a specific order, or versus create_order/cancel_all_open_orders. The only implicit cue is 'authenticated user', which hints at an auth prerequisite but nothing else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.