Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Create a single-trade approval request

place_trade
Destructive

HIGH RISK: creates a BotSpot website approval request for a single trade that may place real-money orders after approval. Provide reason before approval: at least 200 characters explaining the decision, supporting evidence and material risks; prefer 600–2,500. Maximum 100,000 Unicode characters and 400 KiB UTF-8. Do not include hidden chain of thought or secrets. Call this only when the signed-in user explicitly asks to buy or sell a specific symbol. Supply the requested quantity, or convert an authorized approximate dollar amount using a current price and disclose the reference, fees and possible execution difference. When any order price comes from an analysis, first call inspect_analysis_artifact and resolve_analysis_reference, then pass only the returned resolutionId in analysisBindings for the corresponding trade field. Never copy a displayed chart value, model-written number, or sampled chart row into the trade payload. The server loads the immutable resolution and fills the price before it validates and stages the order. A future condition such as trading when two series cross is a conditional trade intent, not an immediate place_trade request. Do not turn a condition into a present order or infer a current price. Include brokerCredentialId only when the user named an exact saved connection or explicitly delegated connection choice. Otherwise omit it so the website approval card can require visible broker selection before approval. Broker access must come from a saved broker credential; do not pass raw broker credentials, API keys, raw runtime configuration, inline code, requirements text, CSV rows, JSON row dumps, or other runtime payloads. Do not call list_broker_credentials merely to fill brokerCredentialId for an otherwise complete order. Multi-leg option package orders and multi-leg bracket-shaped approval requests are accepted and sent through LumiBot; if a broker or LumiBot cannot place the exact order shape, BotSpot returns the sanitized broker/LumiBot error. For an entry-only option package use top-level trade.orderClass=multileg, trade.orderType=debit or credit, trade.limitPrice, trade.timeInForce and trade.legs. Put assetType/symbol/side/quantity/expiration/strike/right on each leg, not on the package. It needs no invented exits. A requested multileg_bracket uses entry legs plus takeProfit/stopLoss. Use trade.assetType=option, entry.legs, takeProfit.limitPrice and stopLoss.stopPrice, with top-level timeInForce; use entry.legs only with those user-supplied exits. Set approvalOnly=true when the user asks to stage for review without submitting, even if a trading window exists. The tool still prepares its normal approval and will not submit that order until approved. Without an active owner-approved trading window, the tool returns a short-lived website authorization URL for the signed-in user to approve or deny. On that page the owner may explicitly authorize further trades in the same broker account for a chosen duration. An active window executes only for its bound owner, app, environment and broker account; expiry or revocation requires new website approval. It does not execute from chat-only approval, and it never returns broker secrets. 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": {
      "reason": "<reason>",
      "trade": "<trade>"
    },
    "name": "place_trade"
  }
}

Input Schema

NameRequiredDescriptionDefault
tradeYes
reasonYesRequired 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.
approvalOnlyNoSet true when the owner requests review without submission. Always require approval for this order, even during an active trading window.
idempotencyKeyNo
brokerSelectionNoPreserve the user-requested provider and/or paper/live mode while leaving brokerCredentialId absent when no exact saved connection was selected. The user chooses a matching saved connection at approval.
analysisBindingsNo
brokerCredentialIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / approvalOnly
      Added value: +{
      +  "description": "Set true when the owner requests review without submission. Always require approval for this order, even during an active trading window.",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / trade / properties / symbol / maxLength
      Previous value: -64New value: +256
  3. Changed4 schema fields changed
    • changedInput schema / properties / trade / properties / assetType / enum
      Previous value: -[
      -  "stock",
      -  "option",
      -  "future",
      -  "crypto_future",
      -  "cont_future",
      -  "forex",
      -  "crypto",
      -  "index"
      -]New value: +[
      +  "stock",
      +  "option",
      +  "future",
      +  "crypto_future",
      +  "cont_future",
      +  "forex",
      +  "crypto",
      +  "index",
      +  "prediction_contract"
      +]
    • addedInput schema / properties / trade / properties / entry / properties / legs / items / properties / outcome
      Added value: +{
      +  "$ref": "#/properties/trade/properties/outcome"
      +}
    • addedInput schema / properties / trade / properties / legs / items / properties / outcome
      Added value: +{
      +  "$ref": "#/properties/trade/properties/outcome"
      +}
    • addedInput schema / properties / trade / properties / outcome
      Added value: +{
      +  "description": "Selected prediction contract outcome; Kalshi uses yes or no.",
      +  "maxLength": 64,
      +  "minLength": 1,
      +  "pattern": "^[^\\x00-\\x1F\\x7F]+$",
      +  "type": "string"
      +}
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description adds the entire approval lifecycle the agent cannot otherwise know — no active trading window yields a short-lived authorization URL, windows are bound to owner/app/environment/broker account, chat-only approval never executes, 'a pending request is not execution,' and broker secrets are never returned. It also discloses that the server reloads the immutable resolution and fills the price before validating and staging, which is a non-obvious internal behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The risk warning and the core call condition are correctly front-loaded, and nearly every sentence carries real policy. However it is a single unstructured wall of prose where distinct concerns — authorization flow, analysis binding, multileg shape, client rendering — run together, and some client-rendering guidance ('a button name alone is not an approval link') is repeated framing rather than new information.

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

Completeness5/5

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

For a destructive, deeply nested, multi-mode trading tool with no output schema, the description covers what an agent needs: when to call, when not to, how to source prices, the approval/URL return surface, and the follow-up (get_deployment_action_status). The remaining gaps are low-risk order-plumbing fields rather than anything that would cause a wrong call.

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?

With schema description coverage at 43% and a deeply nested trade object, the description compensates well for the highest-risk fields: reason length rules (≥200, prefer 600–2,500, 400 KiB cap, no hidden chain of thought), analysisBindings must carry only resolutionId, brokerCredentialId omission semantics so the approval card forces broker selection, and the exact shape for multileg (top-level orderClass/orderType/limitPrice/timeInForce with per-leg assetType/symbol/side/quantity/expiration/strike/right) versus multileg_bracket. It leaves lower-risk fields such as idempotencyKey, precision, multiplier, autoExpiry, quoteSymbol and the secondary* leg fields entirely unexplained.

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?

Opens with a specific verb, resource and risk level: 'HIGH RISK: creates a BotSpot website approval request for a single trade that may place real-money orders after approval.' That framing immediately distinguishes it from read-side siblings such as get_single_trade_status, broker_orders, or get_broker_positions, since it is clearly an approval-staging action rather than a query.

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 gates are given: 'Call this only when the signed-in user explicitly asks to buy or sell a specific symbol,' plus exclusions ('A future condition such as trading when two series cross is a conditional trade intent, not an immediate place_trade request') and a required prerequisite path (inspect_analysis_artifact then resolve_analysis_reference). It also names a specific anti-pattern with the alternative implied: 'Do not call list_broker_credentials merely to fill brokerCredentialId for an otherwise complete order.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.