Skip to main content
Glama
psonhoang

schwab-mcp

by psonhoang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

place_order

Preview orders in a Schwab account to validate pricing, then place the live order only after explicit user confirmation.

Instructions

Preview or place a live order in one Schwab account.

SAFETY CRITICAL / two-step confirmation flow. This tool NEVER submits a live order on the first call:

  • With confirm=False (the default, and how this must always be called the first time for any new order), the order is only sent to Schwab's preview/dry-run endpoint, which validates and prices it WITHOUT submitting it to the market. The response contains the proposed order and Schwab's preview details. You MUST show these details to the user in full and obtain their explicit confirmation before calling this tool again.

  • Only after the user has explicitly confirmed should this tool be called again with the exact same order and confirm=True. Only then is the live order actually submitted to Schwab.

Args: account_number: The plain Schwab account number as shown to the user (not the internal account hash). order: The order object per Schwab's order schema (orderType, session, duration, orderStrategyType, price, orderLegCollection with instruction/quantity/instrument, etc.). confirm: Must be False (default) for the initial preview call, and True only on a follow-up call after the user has explicitly confirmed. Never default this to True.

Returns: If confirm is False: preview details and no order placed. If confirm is True: the submitted order's id and status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orderYes
confirmNo
account_numberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explicitly states that the tool NEVER submits a live order on the first call, explains the dry-run endpoint behavior, and describes the different return outcomes for confirm=False versus confirm=True.

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

Conciseness5/5

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

The description is lengthy but every sentence serves a safety-critical purpose. The key warning and two-step flow are front-loaded before parameter details, and the structure makes the conditional behavior easy to follow.

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?

Given the tool's complexity, the lack of an output schema, and the absence of annotations, the description provides a complete picture: what happens on preview, what happens on confirmation, return values, and required user confirmation. Nothing essential to calling the tool correctly is missing.

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%, but the description compensates fully. It clarifies that account_number is the plain Schwab account number rather than the internal hash, explains the order object's key fields, and defines the confirm parameter's meaning, default, and safety implications.

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 description opens with a precise verb and resource: 'Preview or place a live order in one Schwab account.' It clearly differentiates the tool from sibling order-management tools like list_orders and cancel_order by focusing on order submission rather than retrieval or cancellation.

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?

The description explicitly defines the two-step confirmation flow: call with confirm=False first to preview, show the user the details, and only call with confirm=True after explicit user confirmation. This is a clear, unambiguous usage protocol that leaves no room for misinvocation.

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