Alpaca MCP Server
Supports configuration through environment variables loaded from a .env file, including API endpoints and authentication keys.
Supports source code management and local development workflow through git clone operations.
Enables installation, development, and publishing of the package through npm registry.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Alpaca MCP Serverget stock bars for AAPL from last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Alpaca MCP Server
Expose Alpaca Market Data & Broker API as MCP tools.
Installation
Installing via Smithery
To install Alpaca Market Data Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @cesarvarela/alpaca-mcp --client claudeManual Installation
npm install alpaca-mcpRelated MCP server: alpaca-mcp-server
Local Development
git clone <repo-url>
cd alpaca-mcp
npm installEnvironment Variables
Create a .env at project root with:
ALPACA_ENDPOINT=https://data.alpaca.markets
ALPACA_BROKER_ENDPOINT=https://broker-api.alpaca.markets
ALPACA_API_KEY=YOUR_ALPACA_API_KEY
ALPACA_SECRET_KEY=YOUR_ALPACA_SECRET_KEYCommands
start (dev):
npm start(runsnpx tsx index.ts)build:
npm run build(compiles todist/)run compiled:
node dist/index.js
Usage
Once running, the MCP server listens on stdin/stdout. Use any MCP client or the CLI:
npm link # optional
alpaca-mcp # starts server globallyAvailable Tools
get-assets
{ assetClass?: "us_equity" | "crypto" }get-stock-bars
{ symbols: string[]; start: string; end: string; timeframe: string }get-market-days
{ start: string; end: string }get-news
{ start: string; end: string; symbols: string[] }
Each returns JSON in content[0].text or an error.
MCP Client Configuration
To integrate via mcp.config.json, add the following under the mcpServers key:
{
"mcpServers": {
"alpaca-mcp": {
"command": "npx",
"args": [
"-y",
"alpaca-mcp"
],
"env": {
"ALPACA_ENDPOINT": "https://data.alpaca.markets",
"ALPACA_BROKER_ENDPOINT": "https://broker-api.alpaca.markets",
"ALPACA_API_KEY": "<YOUR_API_KEY>",
"ALPACA_SECRET_KEY": "<YOUR_SECRET_KEY>"
}
}
}
}
## Publishing
```bash
npm publishLicense
ISC
Available Tools
4 toolsget-assetsD
| Name | Required | Description | Default |
|---|---|---|---|
| assetClass | No | us_equity |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-market-daysD
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-newsD
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| symbols | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-stock-barsD
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| symbols | Yes | ||
| timeframe | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: get-assets retrieves assets, get-market-days provides market schedule information, get-news fetches news data, and get-stock-bars obtains stock price bars. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern with hyphens (get-assets, get-market-days, get-news, get-stock-bars). This uniformity makes the tool set predictable and easy to understand.
With only 4 tools, the set feels thin for a financial data server, potentially lacking operations like trading, account management, or more granular data queries. However, it covers basic data retrieval functions adequately.
The tool surface is severely incomplete for a financial domain, offering only read operations (get-*) with no create, update, delete, or trading capabilities. This limits agents to passive data access without supporting full investment workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Alpaca MCP — real-time US stock market data via the Alpaca Market Data API
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server that interfaces with Alpaca trading API, allowing users to manage portfolios, place trades, and access market data through natural language interactions.836MIT

alpaca-mcp-serverofficial
AlicenseAqualityBmaintenanceAlpaca’s official MCP Server lets you trade stocks, ETFs, crypto, and options, run data analysis, and build strategies in plain English directly from your favorite LLM tools and IDEs61928MIT- FlicenseNot gradedqualityDmaintenanceA comprehensive MCP server for professional trading operations with Alpaca, providing 31 tools for account management, market data, order execution, custom strategy execution, and advanced portfolio analytics with intelligent position classification.2
- AlicenseNot gradedqualityDmaintenanceMCP server that provides AI agents with financial tools including real-time quotes, backtesting, technical analysis, and multi-exchange data via a simple CLI interface.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cesarvarela/alpaca-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server