This server wraps the Alpaca trading API with an enforced daily USD spending limit, preventing AI agents from making trades that exceed a configured budget. It defaults to paper trading, with live trading requiring explicit opt-in.
Check setup status: View environment configuration, paper/live trading mode, current daily cap, and ledger file location.
Monitor daily spending: See today's limit, amount used, amount remaining, lifetime order count, and the last 10 orders.
Set the daily USD cap: Configure the maximum USD the agent can spend per day (default $10; set to 0 to disable trading). Resets at UTC midnight and cannot be silently overridden by the agent.
View account snapshot: Retrieve buying power, cash, equity, portfolio value, and PDT flag from your Alpaca account.
View open positions: List current open positions with symbol, quantity, average entry price, current price, and unrealized P&L.
Get live quotes: Fetch the latest bid/ask/mid quote for any ticker symbol.
Place guarded orders: Submit buy/sell orders (market or limit) pre-flighted against the daily cap — orders exceeding the remaining budget are refused with a BUDGET_EXCEEDED error and a human-readable hint.
Close guarded positions: Close full or partial positions, also pre-flighted against the daily cap to prevent budget overruns.
MCP server wrapping the Alpaca trading API with a hard daily USD cap guard. Enforced server-side — an over-eager AI agent literally cannot exceed it. Paper trading by default; live trading requires explicit opt-in.
💰 No monthly fee. Pay 3% only when your API earns. 3,000 calls free. MPP / Tempo interop. See pricing →
🍋 Part of the LemonCake suite. Japan FSA Q1–Q11 inquiry completed (2026-05); pure SDK / non-custodial distribution model confirmed registration-exempt. External security audit cleared. See LemonCake security posture.
npx -y alpaca-guard-mcpAlpaca's official MCP exposes the Alpaca trading API directly to LLMs. Powerful, but the single biggest objection from teams shipping agentic trading is:
"What if the AI rage-buys $50k of meme stocks at 3am because the prompt got injected?"
Alpaca's MCP doesn't ship agent-level spending controls (correctly so — that's not Alpaca's job). alpaca-guard-mcp does:
Preflight every order against a daily USD cap stored in ~/.alpaca-guard/cap.json.
Refuse the call (with a structured hint the LLM can read) if the trade would breach the cap.
Record the charge on success; the cap survives across MCP server restarts and rolls over at UTC midnight.
Paper trading is the default. Live trading is blocked unless the operator sets ALPACA_GUARD_ALLOW_LIVE=yes-i-understand.
There is no agent-side override. The cap is a circuit breaker, not a suggestion.
Related MCP server: ReadyTrader-Stocks
Add to your MCP client config (claude_desktop_config.json or equivalent):
{
"mcpServers": {
"alpaca-guard": {
"command": "npx",
"args": ["-y", "alpaca-guard-mcp"],
"env": {
"ALPACA_API_KEY": "PK...",
"ALPACA_SECRET_KEY": "...",
"ALPACA_PAPER_TRADE": "true"
}
}
}
}Restart your MCP client. The 🔨 tools icon should show alpaca-guard-mcp tools.
Free Alpaca paper-trading account: https://app.alpaca.markets/paper/dashboard/overview
In your MCP client, ask:
Set my alpaca-guard daily limit to $50.
The agent will call guard_set_limit({ dailyLimitUsd: 50 }). The first-ever default is $10 as a safety floor.
Buy 1000 NVDA at limit $900.
The agent will call guarded_place_order. The guard will preflight: notional = 1000 × $900 = $900,000, remaining = $50, refused with BUDGET_EXCEEDED.
The hint the agent sees back:
This order would cost ~$900000.00 but only $50.00 remains under today's
$50.00 cap. Either (a) wait until tomorrow (UTC), (b) call guard_set_limit
to raise the cap (you decide, not the agent), or (c) split the order into
smaller qty. The agent cannot override this from inside a tool call.Tool | Read-only? | Notes |
| ✅ | Env state, mode, current cap, ledger location |
| ✅ | Daily limit / used / remaining / recent 10 orders |
| ❌ | Set the daily USD cap. Idempotent. |
| ✅ | Alpaca account snapshot |
| ✅ | Current open positions |
| ✅ | Bid / ask / mid for a symbol |
| ❌ | Place an order; preflighted against the cap |
| ❌ | Close a position; preflighted on notional |
Env var | Required | Default | Notes |
| ✅ | — | From Alpaca dashboard |
| ✅ | — | From Alpaca dashboard |
| — |
| Set to |
| live only | — | Must literally be |
| — |
| Where |
| — | — | Currently unused (v0.1 local-ledger mode). Future: switch the guard to LemonCake's permit-based preflight when the upstream API ships it. See issue #4. |
Without any Alpaca credentials, the guard still works for the preflight stage. From the test in this repo:
$ ALPACA_GUARD_LEDGER_DIR=/tmp/alpaca-guard-test \
echo '{"jsonrpc":"2.0",...,"method":"tools/call","params":{"name":"guarded_place_order",
"arguments":{"symbol":"NVDA","qty":1000,"side":"buy","type":"limit","limitPrice":900}}}' \
| node dist/index.jsReturns:
{
"allowed": false,
"status": "BUDGET_EXCEEDED",
"tradeNotionalUsd": 900000,
"remainingUsd": 10,
"limitUsd": 10,
"hint": "This order would cost ~$900000.00 but only $10.00 remains ..."
}That preflight ran before any Alpaca call — and would refuse the order even on a paper account. With paper credentials added and a sensible cap, the same guarded_place_order against a 1-share order at $25 will succeed and record $25 against the daily ledger.
┌──────────────────────────────────┐
│ Agent (Claude / Cursor / Cline) │
└────────────┬─────────────────────┘
│ tool: guarded_place_order(symbol, qty, side, type, limitPrice?, tif?)
▼
┌────────────────────────────────────────────────────────────────────┐
│ alpaca-guard-mcp │
│ │
│ 1. Resolve effective price (limit_input OR get_latest_quote) │
│ 2. Preflight against ~/.alpaca-guard/cap.json │
│ 3. If !allowed → refuse with BUDGET_EXCEEDED (no Alpaca call) │
│ 4. If allowed → forward to Alpaca REST /v2/orders │
│ 5. On success → record charge in ledger (cap.json + history) │
│ 6. Return Alpaca order + x402-shaped receipt │
└──────────────────┬──────────────────┬──────────────────────────────┘
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────────┐
│ Alpaca REST │ │ ~/.alpaca-guard/cap.json │
│ (paper or live) │ │ { dailyLimitUsd, │
└──────────────────────┘ │ todayUsedUsd, │
│ history[] } │
└──────────────────────────┘Read-only tools (get_account, get_positions, get_latest_quote) bypass the guard — they don't spend.
alpaca-guard-mcp is built by the same team as agent-payment-mcp at lemoncake.xyz. The eventual goal is for the guard to live on LemonCake's permit preflight endpoint — same daily cap mechanic, but server-side and shared across MCP clients.
That endpoint doesn't exist yet (see issue #4). Until it does, the local ledger is the right shape: zero network dependency, survives restarts, simple to inspect.
When the LemonCake API ships, LEMON_CAKE_PAY_TOKEN will be honored: if set, the guard switches to remote preflight. The tool surface stays identical.
Phase | Status | Notes |
Phase A: local-ledger guard + paper trading | ✅ shipped v0.1.0 | This release |
Phase B: LemonCake permit integration | ⏳ gated | |
Phase C: KYA tier multi-cap (daily + weekly + per-symbol) | ⏳ | After Phase B |
Phase D: Listed on Anthropic Connectors Directory | ⏳ | Same submission flow as agent-payment-mcp |
MIT. Source at github.com/evidai/lemon-cake/tree/main/alpaca-guard-mcp.
Alpaca MCP server v2 — the upstream this guard wraps (logically; we talk directly to Alpaca REST so we don't depend on it at runtime)
agent-payment-mcp — sibling MCP from the same team, where the permit flow originates
LemonCake — interactive playground & docs
Alpaca account snapshot (buying power, cash, equity, portfolio value, PDT flag). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds 'Read-only' consistent with annotations, but does not reveal additional behavioral traits beyond what annotations already convey.
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?
The description is a single sentence that front-loads the purpose and lists key fields. No wasted words, concise and efficient.
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?
For a simple read-only tool with no parameters and no output schema, the description is fairly complete, listing the main fields. It lacks guidance on when to use versus siblings, but overall adequate.
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?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter details, and schema coverage is complete (100%).
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?
The description clearly states the tool returns an Alpaca account snapshot with specific fields (buying power, cash, equity, portfolio value, PDT flag) and identifies it as read-only. This distinguishes it from siblings like get_positions (positions list) and get_latest_quote (quote data).
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?
The description implies usage for overall account status but does not explicitly state when to use this tool versus alternatives like get_positions or guarded_place_order. No exclusion criteria or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest bid/ask/mid quote for a given symbol from Alpaca's market-data API. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. AAPL, TSLA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds 'Read-only', which is redundant, and mentions the data source. No additional behavioral traits (e.g., rate limits, data freshness) are disclosed beyond what annotations provide.
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?
Two concise, front-loaded sentences with no unnecessary words. Every sentence earns its place.
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?
Given the tool's simplicity (single parameter, no output schema, no nested objects) and the presence of annotations covering safety, the description is largely adequate. However, it could mention whether the quote is real-time or delayed to improve completeness.
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?
Schema coverage is 100% (only parameter 'symbol' with example values). The description adds no further parameter meaning beyond the schema. Baseline score of 3 is appropriate given high schema coverage.
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?
The description clearly states the tool retrieves the latest bid/ask/mid quote for a given symbol from Alpaca's market-data API. It is specific (verb+resource) and distinguishes from sibling tools that handle orders, positions, or accounts.
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?
No explicit guidance on when to use this tool versus alternatives. While it is implied for retrieving quotes, there is no mention of cases where other tools might be more appropriate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current open positions on Alpaca (symbol, qty, avg entry price, current price, unrealized P&L). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds specific fields beyond annotations (readOnlyHint, idempotentHint) and explicitly states 'Read-only', consistent with annotations. No contradictions. Lacks details on data freshness or error conditions, but adequate for simple read.
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?
Single sentence of 17 words, front-loaded with key purpose. No unnecessary words.
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?
Given no parameters and no output schema, description sufficiently covers what the tool returns. Annotations provide behavioral safety. No output schema needed.
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?
Input schema has no parameters, so schema coverage is 100%. Baseline is 3; description adds no parameter info, which is appropriate.
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?
Description explicitly states it returns current open positions with specific fields (symbol, qty, avg entry price, current price, unrealized P&L). Clearly distinguishes from siblings like get_account (account info) and guarded_close_position (closing positions).
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?
Description does not explicitly compare to alternatives, but the context of sibling tools makes usage clear: use this to retrieve positions. No explicit when-not or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a position on Alpaca. Pre-flighted against the daily cap: if closing requires re-opening exposure (short close → re-buy) that exceeds the cap, refuses.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker of the position to close | |
| qty | No | Optional — partial close. If omitted, closes the full position. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the guard mechanism and refusal condition, adding value beyond annotations (which show destructiveHint false, meaning not inherently destructive). No contradiction; it explains the conditional refusal behavior.
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?
Two sentences, direct and to the point. No extraneous words. Efficiently communicates purpose and key behavior.
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?
Given no output schema, the description covers the guard logic well. However, it lacks details on return values or failure modes beyond refusing. Still sufficient for a simple close operation with guard.
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?
Schema coverage is 100%, with both parameters described. The description does not add new meaning beyond the schema (e.g., qty is already labeled 'Optional — partial close'). No additional parameter nuances provided.
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?
The description clearly states the action (close a position), the resource (position on Alpaca), and adds the unique guard mechanism. It differentiates from siblings like guarded_place_order by focusing on closing, not opening.
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?
The description explains the guard behavior but does not explicitly state when to use this tool versus alternatives like a plain close (if it existed) or guarded_place_order. Implicit usage from context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order on Alpaca, but ONLY if the trade's notional USD value fits within today's remaining cap. Pre-flight is mandatory: agent cannot override. If notional > remaining, returns BUDGET_EXCEEDED with a structured hint. On success the charge is recorded to the local ledger so the cap survives MCP restarts.
Returns: { allowed, status, tradeNotionalUsd, remainingUsd, limitUsd, alpacaOrder?, x402Receipt? }
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker e.g. AAPL | |
| qty | Yes | Quantity in shares | |
| side | Yes | ||
| type | No | market | |
| limitPrice | No | Required if type=limit | |
| tif | No | day |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly and non-idempotent. Description adds key behaviors: mandatory pre-flight check, budget persistence via local ledger recording, and structured error response. No contradiction with annotations.
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?
The description is a single, well-structured paragraph with front-loaded purpose, followed by constraints, error behavior, persistence, and return format. Every sentence adds value without redundancy.
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?
Covers core behavior and return structure but lacks context about dependencies (e.g., need to set limit via guard_set_limit) and does not explain edge cases for parameters like limitPrice. Given no output schema, the return structure is described but informally.
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?
Schema has 50% parameter description coverage (3 of 6 parameters described). The tool description does not add any parameter-specific meaning or clarify missing descriptions, leaving ambiguity about side, type, and tif.
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?
The description clearly states the tool's action ('Place an order on Alpaca') with a specific condition regarding daily budget cap, distinguishing it from siblings like guarded_close_position. It uses specific verbs and resources.
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?
Explicitly states when to use ('Pre-flight is mandatory') and what happens if budget exceeded (BUDGET_EXCEEDED). Does not explicitly mention when not to use or alternative tools, but context from siblings implies it's the execution tool after setting a limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the daily USD cap. The agent cannot raise its own cap silently — calling this tool is logged in the ledger. Typical use: human operator runs this once to set the daily limit (default $10) before letting the agent loose.
| Name | Required | Description | Default |
|---|---|---|---|
| dailyLimitUsd | Yes | Non-negative USD value. Set 0 to disable trading entirely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds important behavioral context beyond annotations: calling is logged in the ledger and agent cannot raise its own cap silently. Annotations already provide idempotentHint=true.
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?
Two sentences, no wasted words, front-loaded with purpose.
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?
Single parameter, no output schema, but description and annotations together provide sufficient context for proper usage.
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?
Schema covers all parameter details (non-negative number, set 0 to disable). Description adds context about default value ($10) but does not repeat schema info.
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?
The description clearly states 'Set the daily USD cap' with a specific verb and resource, and distinguishes itself from siblings by noting it's a guard operation that logs the action.
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?
Description provides typical use case (human operator sets once before letting agent loose) and default value ($10), but does not explicitly exclude other uses or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's spend ledger: daily limit, used so far, remaining, lifetime order count, and recent 10 orders. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds value by listing exact fields returned and confirming read-only nature.
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?
Single sentence that front-loads the action and lists output fields, zero waste.
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?
Without output schema, description adequately lists all returned fields; could note data format but sufficient for a simple read-only tool.
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?
No parameters; baseline score of 4 applies as description needs no parameter info.
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?
Clearly states it returns today's spend ledger with specific fields, distinguishing it from sibling tools like get_account or get_positions.
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?
No explicit guidance on when to use vs alternatives, but the purpose is clear enough for an agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show alpaca-guard-mcp setup status: env vars, paper/live mode, current daily cap, and ledger file location. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by listing exactly what information is shown (env vars, mode, cap, ledger), which is beyond annotation data. No contradictions.
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?
Single-sentence description, front-loaded with action and subject, no superfluous words. Extremely concise.
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?
Given zero parameters and no output schema, the description adequately covers the tool's purpose and output content. It lists specific items returned, making it complete for a simple read-only status check.
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?
No parameters exist (schema coverage 100% trivially). The description does not need to add parameter information. Baseline score of 4 applies.
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?
The description clearly states the tool shows setup status with specific items: env vars, paper/live mode, daily cap, ledger location. It uses a specific verb ('Show') and resource ('alpaca-guard-mcp setup status'), and distinguishes from siblings that perform trading actions or get account/quote/positions.
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?
The description implies use for checking configuration but does not explicitly state when to use this tool versus alternatives like get_account or guard_status. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1get_accountget_latest_quoteget_positionsguard_set_limitguard_statusguarded_close_positionguarded_place_ordersetupScored across 8 tools
Each tool has a clearly distinct purpose: account info, market data, positions, order placement with guard, position closing with guard, cap management, status, and setup. No overlap in functionality.
Tools follow a fairly consistent pattern with 'get_' for read-only, 'guarded_' for guarded actions, and 'guard_' for guard management. However, 'setup' breaks the pattern and 'guard_set_limit' uses an underscore after 'guard', which is a minor inconsistency.
8 tools is well-scoped for a trading guard server. Each tool earns its place by covering essential operations: account, quotes, positions, order/close with safety, cap management, status, and setup.
The tool set covers core workflows: read account/positions/quotes, place/close orders with guard, manage cap, and view status. Missing features like order cancellation or detailed order history are minor gaps that agents can work around.
Automate trading on your own Alpaca account - build, backtest and run strategies via your AI.
Alpaca MCP — real-time US stock market data via the Alpaca Market Data API
No-KYC managed MCP for AI agents: sandboxed TypeScript trading SDK, isolated sub-accounts, futures.
Unified financial infrastructure connecting AI agents directly to trade live/demo brokerage accounts, Web3 non-custodial wallets, real-time market data across equities, ETFs, crypto, forex, options, DeFi swaps, and prediction markets, institutional research feeds, and algorithmic strategy backtesters.
