Skip to main content
Glama
Public.com MCP Server

Public.com MCP Server

Official
by PublicDotCom

place_order

Places single-leg or bracket buy/sell orders for stocks, crypto, and options, including market, limit, stop, and take-profit/stop-loss exit legs; executes real trades.

Instructions

Place a single-leg order (buy/sell stocks, crypto, or options).

⚠️ This executes a real trade. Consider running preflight_order first.

Args: symbol: Ticker symbol (e.g. "AAPL"). instrument_type: EQUITY, OPTION, or CRYPTO. order_side: BUY or SELL. order_type: MARKET, LIMIT, STOP, STOP_LIMIT, MARKET_ON_CLOSE or LIMIT_ON_CLOSE. The on-close types execute at the closing auction. time_in_force: DAY or GTD. Default is DAY. quantity: Number of shares/contracts (mutually exclusive with amount). amount: Dollar amount (mutually exclusive with quantity). limit_price: Required for LIMIT, STOP_LIMIT and LIMIT_ON_CLOSE orders. stop_price: Required for STOP and STOP_LIMIT orders. open_close_indicator: For options only — OPEN or CLOSE. expiration_time: Required when time_in_force is GTD. ISO 8601 format. equity_market_session: CORE or EXTENDED. For equity orders only. Not the REGULAR / REST_OF_DAY / TWENTY_FOUR_HOURS values that get_order and search_orders report in equityMarketSession; never feed those back here. tax_lot_matching_instructions: Optional list of specific tax lots to sell, each a dict {"tax_lot_id": str, "quantity": str}. Constraints enforced by the API: at most 8 per request; only for a SELL equity order with open_close_indicator=CLOSE; every lot must be the same symbol as the order; only MARKET or good-for-day LIMIT orders; the quantities must sum to the order quantity; and the account's tax-lot information must have been updated today. Omit to let the broker apply its default lot-matching. order_class: SIMPLE (default) places a standalone order. BRACKET, OCO or OTO place a bracket order, where the exit legs below are submitted automatically once this entry order fills. Bracket orders are for EQUITY and OPTION only, need a whole-share quantity (not amount), must use the CORE market session, and the entry order_type must be LIMIT or MARKET — LIMIT only for OCO. Every leg of the bracket, entry included, reports the entry's order ID as its bracketId. preflight_order cannot check the exit legs — it validates the entry order only. take_profit_limit_price: Limit price of the take-profit exit leg, placed on the opposite side of the entry. Requires a bracket order_class. stop_loss_stop_price: Stop price of the stop-loss exit leg, placed on the opposite side of the entry. Requires a bracket order_class. Placed as a STOP order unless stop_loss_limit_price is given too. stop_loss_limit_price: Limit price that makes the stop-loss leg a STOP_LIMIT order instead of a STOP order. Requires stop_loss_stop_price. account_id: Account ID. Optional if PUBLIC_COM_ACCOUNT_ID is set.

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": {
      "symbol": "<symbol>",
      "instrument_type": "<instrument_type>",
      "order_side": "<order_side>",
      "order_type": "<order_type>"
    },
    "name": "place_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountNo
symbolYes
quantityNo
account_idNo
order_sideYes
order_typeYes
stop_priceNo
limit_priceNo
order_classNo
time_in_forceNoDAY
expiration_timeNo
instrument_typeYes
open_close_indicatorNo
stop_loss_stop_priceNo
equity_market_sessionNo
stop_loss_limit_priceNo
take_profit_limit_priceNo
tax_lot_matching_instructionsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.7.0
    • addedInput schema / properties / order_class
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Order Class"
      +}
    • addedInput schema / properties / stop_loss_limit_price
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Stop Loss Limit Price"
      +}
    • addedInput schema / properties / stop_loss_stop_price
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Stop Loss Stop Price"
      +}
    • addedInput schema / properties / take_profit_limit_price
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Take Profit Limit Price"
      +}
  2. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / tax_lot_matching_instructions
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Tax Lot Matching Instructions"
      +}
  3. First observedv0.3.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), the description adds the critical warning that this executes a real trade and lays out API-enforced constraints (max 8 tax lots, same symbol, quantities must sum, tax-lot data freshness, bracket-order restrictions). This is exactly the behavior an agent cannot infer from structured fields.

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 with the one-line purpose and the real-trade warning, then an Args list where every entry carries substantive information. The example values and some parenthetical detail add length, but nothing is truly redundant for an 18-parameter tool.

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?

With an output schema present, return values need no explanation, and the description covers all 18 parameters, their conditional dependencies, and the bracket/tax-lot edge cases. An agent has everything needed to construct a valid call.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden — and it does: every parameter gets meaning plus conditional requirements (limit_price required for LIMIT/STOP_LIMIT/LIMIT_ON_CLOSE, expiration_time for GTD, open_close_indicator for options), mutual exclusions (quantity vs amount), and even a warning about the equity_market_session enum mismatch with other tools.

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?

States a specific verb (place) and resource (single-leg order) with the instrument scope (stocks, crypto, options), which cleanly separates it from siblings like place_multileg_order and place_short_order without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends running preflight_order first for validation, and repeatedly notes what preflight_order cannot cover (exit legs), which is clear usage context. It never spells out when to prefer a sibling such as place_multileg_order, so it stops short of the 5 tier.

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