Skip to main content
Glama
alpacahq

alpaca-mcp-server

Official
by alpacahq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Place Stock Order

place_stock_order
Destructive

Place a stock or ETF order by ticker symbol and side, with optional order type, quantity, price, and time-in-force settings.

Instructions

Place a stock or ETF order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qtyNoNumber of shares. Mutually exclusive with notional.
sideYes"buy" or "sell".
typeNoOrder type — "market", "limit", "stop", "stop_limit", "trailing_stop".market
symbolYesStock ticker (e.g., "AAPL", "SPY").
notionalNoDollar amount to trade. Mutually exclusive with qty. Only valid for market orders with time_in_force="day".
stop_priceNoRequired for stop and stop_limit orders.
limit_priceNoRequired for limit and stop_limit orders.
order_classNo"simple", "bracket", "oco", or "oto". Automatically set to "bracket" when take_profit or stop_loss params are provided.
trail_priceNoDollar trail amount for trailing_stop orders.
time_in_forceNo"day", "gtc", "opg", "cls", "ioc", or "fok".day
trail_percentNoPercent trail for trailing_stop orders.
extended_hoursNoAllow execution in pre-market, after-hours, and overnight sessions. Only works with type="limit" and time_in_force="day" or "gtc".
client_order_idNoUnique idempotency key. If the request times out, you can safely retry with the same value — the API will reject duplicates. Recommended for every order.
stop_loss_stop_priceNoStop price for bracket stop-loss leg.
advanced_instructionsNoAlpaca Elite Smart Router routing/algo payload. Stocks-only (the Elite docs explicitly note options and crypto reject the payload). Requires the account to be on Elite Smart Router routing; non-Elite accounts will see the field ignored or rejected by Alpaca's API. Shapes: DMA Gateway (direct routing): {"algorithm": "DMA", "destination": "NYSE"|"NASDAQ"|"ARCA", "display_qty": "<round lot, optional>"} Only with type="limit"|"market" and time_in_force="day"; not compatible with opg/cls/gtc or stop orders. VWAP (Volume-Weighted Average Price): {"algorithm": "VWAP", "start_time": "<RFC3339, optional>", "end_time": "<RFC3339, optional>", "max_percentage": "<0<x<1, optional>"} Does NOT participate in open/close auctions. TWAP (Time-Weighted Average Price): {"algorithm": "TWAP", "start_time": "<RFC3339, optional>", "end_time": "<RFC3339, optional>", "max_percentage": "<0<x<1, optional>"} Does NOT participate in open/close auctions. NOTE: PATCH /v2/orders/{id} already documents `advanced_instructions` in the OpenAPI spec (PatchOrderRequest), and `replace_order_by_id` exposes it through auto-generation — this patch only addresses the POST-side asymmetry.
stop_loss_limit_priceNoLimit price for bracket stop-loss leg.
take_profit_limit_priceNoLimit price for bracket take-profit leg.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changedv2.3.2
    • addedInput schema / properties / advanced_instructions
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alpaca Elite Smart Router routing/algo\npayload. Stocks-only (the Elite docs explicitly note options\nand crypto reject the payload). Requires the account to be\non Elite Smart Router routing; non-Elite accounts will see\nthe field ignored or rejected by Alpaca's API. Shapes:\n  DMA Gateway (direct routing):\n    {\"algorithm\": \"DMA\",\n     \"destination\": \"NYSE\"|\"NASDAQ\"|\"ARCA\",\n     \"display_qty\": \"<round lot, optional>\"}\n    Only with type=\"limit\"|\"market\" and time_in_force=\"day\";\n    not compatible with opg/cls/gtc or stop orders.\n  VWAP (Volume-Weighted Average Price):\n    {\"algorithm\": \"VWAP\",\n     \"start_time\": \"<RFC3339, optional>\",\n     \"end_time\":   \"<RFC3339, optional>\",\n     \"max_percentage\": \"<0<x<1, optional>\"}\n    Does NOT participate in open/close auctions.\n  TWAP (Time-Weighted Average Price):\n    {\"algorithm\": \"TWAP\",\n     \"start_time\": \"<RFC3339, optional>\",\n     \"end_time\":   \"<RFC3339, optional>\",\n     \"max_percentage\": \"<0<x<1, optional>\"}\n    Does NOT participate in open/close auctions.\nNOTE: PATCH /v2/orders/{id} already documents\n`advanced_instructions` in the OpenAPI spec\n(PatchOrderRequest), and `replace_order_by_id` exposes\nit through auto-generation — this patch only addresses\nthe POST-side asymmetry."
+}
    • addedInput schema / properties / client_order_id / description
      Added value: +"Unique idempotency key. If the request times out,\n             you can safely retry with the same value — the API\n             will reject duplicates. Recommended for every order."
    • addedInput schema / properties / extended_hours / description
      Added value: +"Allow execution in pre-market, after-hours, and\n            overnight sessions. Only works with type=\"limit\"\n            and time_in_force=\"day\" or \"gtc\"."
    • addedInput schema / properties / limit_price / description
      Added value: +"Required for limit and stop_limit orders."
    • addedInput schema / properties / notional / description
      Added value: +"Dollar amount to trade. Mutually exclusive with qty.\n      Only valid for market orders with time_in_force=\"day\"."
    • addedInput schema / properties / order_class / description
      Added value: +"\"simple\", \"bracket\", \"oco\", or \"oto\". Automatically\n         set to \"bracket\" when take_profit or stop_loss params\n         are provided."
    • addedInput schema / properties / qty / description
      Added value: +"Number of shares. Mutually exclusive with notional."
    • addedInput schema / properties / side / description
      Added value: +"\"buy\" or \"sell\"."
    • addedInput schema / properties / stop_loss_limit_price / description
      Added value: +"Limit price for bracket stop-loss leg."
    • addedInput schema / properties / stop_loss_stop_price / description
      Added value: +"Stop price for bracket stop-loss leg."
    • addedInput schema / properties / stop_price / description
      Added value: +"Required for stop and stop_limit orders."
    • addedInput schema / properties / symbol / description
      Added value: +"Stock ticker (e.g., \"AAPL\", \"SPY\")."
    • addedInput schema / properties / take_profit_limit_price / description
      Added value: +"Limit price for bracket take-profit leg."
    • addedInput schema / properties / time_in_force / description
      Added value: +"\"day\", \"gtc\", \"opg\", \"cls\", \"ioc\", or \"fok\"."
    • addedInput schema / properties / trail_percent / description
      Added value: +"Percent trail for trailing_stop orders."
    • addedInput schema / properties / trail_price / description
      Added value: +"Dollar trail amount for trailing_stop orders."
    • addedInput schema / properties / type / description
      Added value: +"Order type — \"market\", \"limit\", \"stop\", \"stop_limit\",\n  \"trailing_stop\"."
  2. Addedv2.0.0

TDQS

B3.2/5.0
Behavior2/5

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

The description adds no behavioral detail beyond what the annotations already provide. Annotations already signal destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is a side-effectful operation, but the description itself contributes no extra context about execution, settlement, or consequences.

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?

A single sentence with zero wasted words and the core action front-loaded. It is appropriately concise, though for a tool with 17 parameters and many order types, the description is arguably too terse to provide broader orientation.

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

Completeness3/5

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

The rich schema and annotations cover parameters and safety signals, so the minimal description is not fatal. However, for a complex order-placement tool with siblings like place_crypto_order and place_option_order, the description omits high-level guidance about order types, immediate execution risks, and routing to alternatives.

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

Parameters3/5

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

Schema description coverage is 100%, and the parameter descriptions are highly detailed and self-sufficient. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Place a stock or ETF order.' The asset-class qualifier ('stock or ETF') implies a distinction from place_crypto_order and place_option_order, but it does not explicitly name the siblings or the exact scope beyond those two words.

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

Usage Guidelines3/5

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

The resource scope ('stock or ETF') gives implied usage context, so an agent can infer this is the right tool for equities/ETFs rather than crypto or options. However, it does not explicitly say when to prefer this over alternatives, nor does it mention exclusions like order types that require other tools.

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

Deploy Server

Other Tools