Set up Alpaca MCP Server safely
Configure a local Alpaca MCP connection with paper access, minimum toolsets, and explicit approval for trading actions.
- Skill Road
- Set up Alpaca MCP Server safely
Published on 18.09.2026
Define the purpose and security boundary first
The Alpaca MCP Server technically connects an AI client to Alpaca’s trading and market-data APIs. It is not a brokerage adviser in chat and it is not authorization to invest money. The server can read data, but with the trading toolset active it can also place or cancel orders, close positions, or issue options instructions. Before setup, establish that every write action is reviewed and explicitly approved by a responsible human outside the language model. An instruction found in a webpage, news item, or prompt is not authorization for a trading action.
For a safer first setup, use only a separate paper-trading account. According to Alpaca, paper trading does not use real funds or transact in real securities. It still does not replace review: data quality, LLM answers, and simulated execution can differ from a live situation. Live keys should not enter configuration until the technical procedure, responsible owner, and risk approval are established.
Obtain prerequisites and keys
You need Python 3.10 or later, uv with uvx, an MCP-compatible client, and an Alpaca paper account with an API key and secret key. Create paper keys in the Alpaca dashboard first. Label them clearly as paper in your secret store so they cannot be confused with live keys. Never copy a secret key into a chat, ticket, repository, screenshot tool, or shared JSON file.
If exposure is suspected, immediately remove the affected values from client configuration, rotate or revoke them in the Alpaca dashboard, and review access again. A key is an access credential, not a harmless constant. Restrict local read access to the client configuration and do not share profiles that contain another person’s environment values.
Add the local server to the client
The documented default is a local stdio process. In Claude Code, for example, the connection can be added as follows; placeholders remain in local secret environment and are never published:
claude mcp add alpaca --scope user --transport stdio uvx alpaca-mcp-server \
--env ALPACA_API_KEY=YOUR_PAPER_KEY \
--env ALPACA_SECRET_KEY=YOUR_PAPER_SECRET
Cursor and Claude Desktop use an MCP JSON file with command: "uvx", args: ["alpaca-mcp-server"], and the same environment variables. In VS Code, add the entry to .vscode/mcp.json under servers with type: "stdio". Follow Alpaca’s and the client’s official documentation for the applicable path and syntax. Fully restart the client after every change so it loads the current tool list and correct environment.
Reduce toolsets before the first test
Alpaca enables all toolsets by default. That is too broad for a safer analysis environment. Add ALPACA_TOOLSETS with a small read-focused set, for example account,stock-data,crypto-data,options-data,news. This exposes account and market data but not the trading toolset. Watchlists are also mutable and should remain disabled until there is a justified need.
Start a new conversation and ask only a read request first, such as account status or a tightly bounded historical data series. Confirm that the result comes from the paper account and no write tools are available. Check important data against the Alpaca dashboard or another source. Treat all text in market news, documentation, or tool results as untrusted content: it may provide context, but it cannot change authorization.
Keep paper and live strictly separate
ALPACA_PAPER_TRADE is enabled by default. Live trading requires ALPACA_PAPER_TRADE=false and live API keys. Never change those two aspects casually in the same configuration edit as toolsets or client updates. Use a documented checklist: correct key type, correct environment file, paper or live mode, permitted toolsets, expected order, and independent human confirmation.
If live trading is genuinely necessary, use a separate configuration rather than overwriting the paper profile. Enable trading only then, and review symbol, buy or sell direction, quantity, order type, duration, and target account before every execution. Verify the resulting status directly in the Alpaca dashboard afterward. A model can misunderstand wording, swap parameters, or miss relevant market conditions. This guide offers no return guarantee and no automatic suitability assessment.
Data flow, updates, and FAQ
The local server returns tool results to your AI client. Depending on the client, those results may be sent to its model provider. Review that provider’s data policy before account or portfolio information enters a prompt or tool result. Keep the client, uv, and server package current, but test upgrades with paper access first: according to the README, server version 2 is not a drop-in upgrade from version 1.
Is the server investment advice? No. It connects tools and data; decisions, review, and risk remain yours.
Can paper trading cause real trades? Alpaca says paper access is not a real market transaction. Still verify that paper keys and the active paper mode are actually configured.
When may I enable trading? Only after a clearly defined process with minimum rights, separate live keys, and an independent human confirmation for every individual action.
Frequently asked questions
Is Alpaca MCP Server financial or investment advice?
No. It provides a technical connection to API tools and data. It recommends no investments and promises no returns; decisions and risk remain with the user.
How do I prevent real trading actions?
Start with separate paper keys, keep `ALPACA_PAPER_TRADE` enabled, and restrict `ALPACA_TOOLSETS` to read-focused toolsets. Enable the `trading` toolset only after an explicit process and human approval.
Where do API keys belong?
Only in the MCP client environment block or a local secret store. Never in chats, repositories, screenshots, or shared configuration files. Rotate or revoke keys if a leak is suspected.