Retrieve working, open, or closed orders from your connected broker to track order status and manage pending trades.
broker_truth / live ops — working/open/closed orders from a connected broker. Use for 'working orders', 'pending orders'. Do NOT use web search.
| Name | Required | Description | Default |
|---|---|---|---|
| broker | Yes | ||
| status | No | Filter: open, closed, all |
Changes observed during successful MCP inspections.
v22.7.3Output schema / (root)Previous value: -{
- "properties": {
- "count": {
- "type": "integer"
- },
- "orders": {
- "items": {
- "properties": {
- "filled_qty": {
- "type": "number"
- },
- "limit_price": {
- "type": "number"
- },
- "order_id": {
- "type": "string"
- },
- "order_type": {
- "type": "string"
- },
- "qty": {
- "type": "number"
- },
- "side": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "symbol": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
-}New value: +nullv22.7.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by disclosing that data comes from a live broker connection (prerequisite implied) and represents real operational truth rather than simulated data, which meaningfully informs agent expectations.
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-loaded, with the core purpose stated first and usage/exclusion guidance in short follow-ups. The 'broker_truth' label is cryptic jargon and the web-search exclusion is slightly odd, but every sentence earns its place and there is no fluff.
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 simple 2-parameter read-only tool with strong annotations and no output schema, the description covers the essential ground: what is returned, the data source, the prerequisite (connected broker), and typical use cases. Minor gaps remain around broker parameter semantics and return-format/error behavior when no broker is connected.
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 only 50%, and the description partially compensates: it reinforces the status param's meaning ('working/open/closed' mirrors the schema's 'open, closed, all' filter) and ties the broker param to a connected broker. However, the required broker param still lacks format/value semantics (e.g., is it an ID from get_connected_brokers?), and the description does not fully make up for the coverage gap.
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 (orders), the scope (working/open/closed), and the data source (a connected broker, 'broker_truth / live ops'). This differentiates it from sibling order-adjacent tools like get_positions, get_account, and backtest tools, though it relies on the telegraphic 'broker_truth' jargon rather than stating a full sentence with an explicit verb.
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 gives explicit when-to-use guidance ('Use for working orders, pending orders') and an explicit exclusion ('Do NOT use web search'). It does not name a specific alternative tool for other order-related queries (e.g., historical order data), so the routing guidance is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.