fidelity-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIDELITY_TIMEOUT | No | Default timeout in milliseconds | 30000 |
| FIDELITY_HEADLESS | No | Set to "false" to show the server's browser (default: headless) | true |
| FIDELITY_SESSION_DIR | No | Session directory | ~/.fidelity-mcp |
| FIDELITY_SESSION_TITLE | No | Session file suffix, for multiple logins |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fidelity_statusA | Report whether the browser is running, whether it is on a sign-in page, and when the session was last saved. Does not navigate. |
| fidelity_loginA | Open a visible browser window on Fidelity's sign-in page so the USER can log in and complete 2FA themselves. Waits up to 10 minutes, then saves the session. Never asks for or types credentials. Call once when a tool reports the session expired; don't retry in a loop. |
| fidelity_logoutB | Close the browser. The saved session stays on disk for the next tool call. |
| fidelity_get_accountsA | List Fidelity accounts (number and nickname). For balances use fidelity_get_positions. |
| fidelity_get_positionsA | Get holdings for every account from Fidelity's positions CSV: ticker, quantity, price, value, and cash balance ( |
| fidelity_get_quoteB | Get the last price (and extended-hours price when available) for a stock/ETF from the trade ticket. |
| fidelity_place_orderA | Buy or sell a stock/ETF. Dry run by default (preview only). Penny stocks (< $1) and extended hours always use limit orders; without limit_price the limit is one tick past the last price. The result shows the exact order (including limit price) for the user to confirm. |
| fidelity_stage_orderA | Set up a buy/sell for the USER to place: opens a visible Fidelity window, fills the trade ticket, clicks Preview, verifies it, and leaves it on the preview screen. The user clicks Place order (or Cancel) there; this tool never places. Stocks/ETFs take |
| fidelity_batch_ordersB | Run several market/auto-limit orders one after another in one account. Dry run by default. |
| fidelity_transferA | Move cash between two of the user's Fidelity accounts. Has no dry run: it submits immediately, so only call after the user confirmed from, to and amount. |
| fidelity_screenshotA | Screenshot the browser page, optionally after opening a Fidelity URL. For debugging selectors. |
| fidelity_page_contentA | List the page's buttons, links, form fields and tables (id, aria-label, text), optionally after opening a Fidelity URL. For fixing selectors. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools target distinct actions: status/login/logout cover auth, get_accounts vs get_positions vs get_quote cover data, and screenshot vs page_content are split for debugging. The order trio (place_order dry-run, stage_order user-confirmed, batch_orders multi-order) is the main risk; descriptions clarify the boundaries but an agent could still hesitate between place_order and batch_orders for a single account.
All tools use a consistent fidelity_ prefix and snake_case, with verb_noun patterns like get_positions, place_order, stage_order, batch_orders. The one deviation is fidelity_status, a bare noun rather than a verb phrase, but it stays readable and predictable.
Twelve tools is well-scoped for a brokerage automation server, with each tool covering a distinct stage: auth, read, trade, transfer, and debugging. Nothing feels padded or missing at the count level.
The surface covers the full lifecycle: session status, login/logout, accounts, positions, quotes, order placement (dry-run, staged, batch), transfers, and selector debugging. Gaps are minor but real: no order status/cancel or order history, and no transaction history, which an agent may need after placing or staging an order.