BotSpot: AI Trading, Backtests and Bots

Read and manage broker orders

broker_orders

Destructive

Read current orders through a saved broker connection, or request cancellation/modification of one exact owned order. Management always requires a fresh website approval and never places a replacement trade. Read the returned broker state after execution; a pending cancellation is not a canceled order.

Set "action" to choose the operation. Only send the fields listed for that action.

action="list": Get broker orders

No other fields required. Read-only: fetches current or recent broker orders directly from a saved broker credential. Use symbol, statuses, startTimeIso, and endTimeIso to narrow. Never pass raw broker credentials.

action="manage": Cancel or modify an existing broker order

Required fields: brokerCredentialId, orderId, operation, reason. HIGH RISK: request website approval to cancel or modify one exact order on a saved broker connection. Read current broker orders first and copy the native orderId and selected brokerCredentialId. The server binds the returned contract and side. operation=cancel takes no changes. operation=modify takes changes.limitPrice, stopPrice and/or quantity; quantity means the new total including fills already received, when the broker supports it. Use only changes the user requested and provide a reason of at least 200 characters explaining the action, evidence and remaining risk. Reuse the same idempotencyKey for a retry of the same request. A pending approval or completed worker is not proof of cancellation or a fill. After approval check the action status and refresh broker orders; fills can win cancellation races. Never place a replacement trade to emulate modification. For Codex, Claude, Cursor, and other clients without BotSpot native confirmation cards, return the exact authorizationUrl as a clickable Markdown link in your reply. Do not say a card or button was created unless the client actually rendered it. BotSpot clients may render structuredContent as a native confirmation, but a button name alone is not an approval link. A pending request is not execution; only the signed-in user may approve on the website. Report expiry and check get_deployment_action_status after approval.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "broker_orders"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	Which operation to run: "list", "manage". See the tool description for each one.
`reason`	No	Required explicit trade explanation: at least 200 Unicode characters; prefer 600–2,500 covering intent, evidence and material risks. Maximum 100,000 characters and 400 KiB UTF-8. Do not include credentials or hidden chain of thought. Used with action="manage". Required for action="manage".
`symbol`	No	Used with action="list".
`changes`	No	Used with action="manage".
`orderId`	No	Used with action="manage". Required for action="manage".
`outcome`	No	Selected prediction contract outcome; Kalshi uses yes or no. Used with action="list".
`statuses`	No	Used with action="list".
`assetType`	No	Used with action="list".
`operation`	No	Used with action="manage". Required for action="manage".
`endTimeIso`	No	Used with action="list".
`startTimeIso`	No	Used with action="list".
`brokerProvider`	No	Used with action="list".
`idempotencyKey`	No	Used with action="manage".
`brokerCredentialId`	No	Used with action="list", action="manage". Required for action="manage".

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only say destructiveHint=true and readOnlyHint=false; the description adds the crucial context that management requires fresh website approval by the signed-in user, that a pending cancellation is not a canceled order, that fills can win cancellation races, and how to surface authorizationUrl for non-BotSpot clients. That is substantial value beyond annotations. It stops short of describing what the list response contains or rate/credential-failure behavior, so not a full 5.

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?

Front-loaded purpose statement followed by clearly headed per-action sections, which suits a 14-parameter dual-mode tool. It is dense but mostly earns its length; the client-rendering paragraph (Codex/Claude/Cursor, Markdown links, card/button caveats) is long and partially restates the 200-character reason rule already in the schema.

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

Completeness4/5

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

For a destructive, approval-gated tool with a nested changes object and no output schema, the description covers the approval flow, post-execution verification, idempotency-key reuse, and expiry reporting. The remaining gap is that it never sketches the shape of the returned broker state, which matters more given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying that quantity means the new total including fills already received, that operation=cancel takes no changes, and that only fields listed for the chosen action should be sent. Those are non-obvious semantics that the flat schema cannot express, though individual fields like statuses and assetType are left to the schema.

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?

The opening sentence names both operations with specific verbs and scope: read current orders through a saved broker connection, or request cancellation/modification of one exact owned order. The action-keyed sections ("action=list: Get broker orders", "action=manage: Cancel or modify an existing broker order") let an agent pick the right mode without opening the schema.

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?

Explicit sequencing guidance: read current orders first and copy the native orderId and brokerCredentialId, check get_deployment_action_status after approval, and refresh broker orders afterward. It also names the forbidden alternative — "Never place a replacement trade to emulate modification" — which steers the agent away from place_trade.

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

All BotSpot: AI Trading, Backtests and Bots tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.