Public.com MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

place_order

Submit a real buy or sell order for stocks, crypto, or options, including market, limit, stop, stop-limit, and bracket orders.

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, or STOP_LIMIT. 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 and STOP_LIMIT 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. 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.

Input Schema

TableJSON Schema

Name	Required	Default
`amount`	No
`symbol`	Yes
`quantity`	No
`account_id`	No
`order_side`	Yes
`order_type`	Yes
`stop_price`	No
`limit_price`	No
`order_class`	No
`time_in_force`	No	DAY
`expiration_time`	No
`instrument_type`	Yes
`open_close_indicator`	No
`stop_loss_stop_price`	No
`equity_market_session`	No
`stop_loss_limit_price`	No
`take_profit_limit_price`	No
`tax_lot_matching_instructions`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.7.0Sep 11, 2026

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"
+}

Changed1 schema field changedv0.5.0Jul 25, 2026

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"
+}

First observedv0.3.1Jun 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond annotations, which only state readOnly=false and idempotent=false. It discloses that bracket exit legs are submitted automatically once the entry fills, that every leg reports the entry's order ID as bracketId, and that preflight_order validates only the entry leg, plus the full constraint set for tax-lot matching. These are real behavioral traits an agent needs before calling.

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-loads the trade warning and the preflight recommendation before the Args block, which is the right priority. The Args block is long but every entry adds required meaning for a zero-coverage schema; density is justified by 18 parameters, though a few constraint sentences are terse enough to require re-reading.

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 an 18-parameter trade-placement tool with 0% schema coverage, the description covers every parameter, conditional dependency, and behavioral edge (bracket legs, tax lots). Since an output schema exists, the absence of return-value discussion is correct and not a gap.

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 does so thoroughly: it documents all 18 params, gives enum values (EQUITY/OPTION/CRYPTO, BUY/SELL, MARKET/LIMIT/STOP/STOP_LIMIT, DAY/GTD, SIMPLE/BRACKET/OCO/OTO), mutual exclusivity (quantity vs amount), conditional requirements (limit_price for LIMIT, expiration_time for GTD), and detailed tax-lot constraints.

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 (order) and immediately narrows scope with 'single-leg', which distinguishes it from place_multileg_order and the spread-placement siblings. The parenthetical (buy/sell stocks, crypto, or options) tells the agent the instrument coverage 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 Guidelines4/5

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

Explicitly warns 'This executes a real trade' and routes the agent to preflight_order first, naming a concrete alternative. It doesn't spell out when to prefer place_short_order or place_multileg_order, but 'single-leg' plus the preflight pointer give clear context.

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