angelone-mcp

An MCP (Model Context Protocol) server that wraps Angel One's SmartAPI — trading, portfolio, market data, GTT rules, and margin/brokerage — so any MCP client (Claude, Claude Code, etc.) can query your account and place orders through natural conversation.

⚠️ This places real orders on a real trading account. Test with small quantities first, and keep in mind Angel One (like most brokers) does not let you "undo" a filled order.

What's included

• angelone_mcp/client.py – REST client for every documented SmartAPI route: auth, orders, positions/holdings, GTT rules, historical candles/OI, quotes, option greeks, gainers/losers, margin calculator, brokerage estimator. Handles TOTP login, auto re-login on token expiry, and paces itself against SmartAPI's documented rate limits (see "Rate limiting" below).

• angelone_mcp/server.py – MCP server exposing 32 tools built on top of the client (see full list below).

Related MCP server: Zerodha MCP Server

1. Prerequisites

• Python 3.10+

• An Angel One trading account with SmartAPI access

• A SmartAPI app created at https://smartapi.angelone.in/ (gives you an API key)

• TOTP set up on your Angel One account, and the base32 secret used to set up that authenticator (not the 6-digit code — the secret behind it). You get this once, when you first scan the QR code to enable TOTP; if you don't have it saved, you'll need to reset/reconfigure TOTP on your account to get a fresh secret.

2. Install

cd angelone-mcp
python3 -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -r requirements.txt

3. Configure credentials

Set these environment variables (e.g. in a .env file you source, or directly in your MCP client config):

Never commit these to source control. Treat ANGELONE_TOTP_SECRET and ANGELONE_PIN like passwords — anyone with them plus your API key can trade on your account.

Optional: running behind an HTTP proxy

If your machine/network requires an outbound HTTP proxy to reach the internet, set:

These are only needed if the standard HTTP_PROXY / HTTPS_PROXY environment variables aren't already visible to the server process. That's commonly the case for MCP servers, since MCP clients usually launch the server with an explicit env block (like the JSON below) instead of inheriting your shell's environment — so a proxy configured in your shell won't reach the server unless you either add it to that env block yourself under HTTPS_PROXY, or use the ANGELONE_* variables above. If neither ANGELONE_HTTP_PROXY nor ANGELONE_HTTPS_PROXY is set, the server falls back to the standard HTTP_PROXY/HTTPS_PROXY/NO_PROXY variables automatically.

4. Run it

Standalone (for testing):

python -m angelone_mcp.server

It speaks MCP over stdio, so it's meant to be launched by an MCP client, not run interactively.

Claude Desktop / Claude Code config

Add to your MCP client's config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "angelone": {
      "command": "/absolute/path/to/angelone-mcp/.venv/bin/python",
      "args": ["-m", "angelone_mcp.server"],
      "cwd": "/absolute/path/to/angelone-mcp",
      "env": {
        "ANGELONE_API_KEY": "your_api_key",
        "ANGELONE_CLIENT_CODE": "your_client_code",
        "ANGELONE_PIN": "your_pin",
        "ANGELONE_TOTP_SECRET": "your_base32_totp_secret",
        "ANGELONE_HTTPS_PROXY": "http://user:pass@proxyhost:8080"
      }
    }
  }
}

Tools exposed

Session login, logout, get_profile

Orders place_order, modify_order, cancel_order, get_order_book, get_trade_book, get_individual_order_details

Portfolio / funds get_positions, get_holdings, get_all_holdings, get_rms_limit, convert_position

GTT (Good Till Triggered) rules gtt_create_rule, gtt_modify_rule, gtt_cancel_rule, gtt_details, gtt_list

Market data get_ltp, get_market_quote, search_scrip, get_candle_data, get_oi_data, get_option_greeks, get_gainers_losers, get_put_call_ratio, get_oi_buildup, get_nse_intraday_data, get_bse_intraday_data

Margin & brokerage get_margin, estimate_charges

How auth works

AngelOneClient logs in lazily on the first tool call using clientcode + pin + a TOTP generated on the fly from ANGELONE_TOTP_SECRET (via pyotp). It caches the resulting jwtToken, refreshToken, and feedToken in memory for the life of the process. If any call comes back with a 401/403 or a TokenException, it transparently re-logs-in once and retries — you don't need to call login yourself unless you want to force a fresh session.

Sessions issued by SmartAPI are valid until midnight IST regardless of activity, so a long-running server may still need a fresh login the next day — the auto-retry logic handles that automatically on the next call.

Session persistence across restarts

A successful login is also cached to a file on disk, so a fresh server process doesn't need a fresh TOTP-based login every time it starts (handy since TOTP requires the code to be freshly generated — restarting the server several times in a row otherwise means several real logins in a row).

On startup, before serving any tool calls, the server calls AngelOneClient.restore_session(), which:

1. Looks for a previously saved session file. If there isn't one, it does nothing further — the client stays in its normal lazy mode and logs in on the first tool call, same as before this feature existed.

2. If a saved session is found, it loads the cached tokens and verifies them with a real getProfile call.

3. If that verification succeeds, the restored session is used as-is — no fresh login needed.

4. If it fails for any reason (expired token, revoked session, corrupt file, etc.), the cached tokens are discarded and a normal fresh login runs instead.

Every successful login (fresh or via the automatic 401/403 retry described above) re-saves the session file, so it stays current across the whole time the server runs, not just at startup. logout deletes the file.

The session file holds a live access token — not your PIN or TOTP secret, but enough to call the API as you until it expires. It's written with owner-only file permissions where the OS supports it; treat it as sensitive the same way you'd treat any cached login session.

Rate limiting

AngelOneClient paces every outgoing call against SmartAPI's documented per-endpoint rate limits — login and most portfolio reads at 1 request/sec, getProfile at 3/sec, quotes/GTT/order-detail lookups at 10/sec, order placement at 20/sec, and so on. Limits are per SmartAPI endpoint, not global, so calling different tools back-to-back is never slowed down by this — only a repeat call to the same endpoint made faster than SmartAPI's own limit allows gets held back, which you'd want anyway.

If SmartAPI reports its own limit was hit regardless (HTTP 403/429, "Access denied because of exceeding access rate"), the call backs off and retries a few times with increasing delay before giving up — and that response no longer gets misread as an expired session and doesn't trigger a spurious extra login the way it used to.

This applies to every tool automatically; there's nothing to configure to get it. To turn client-side pacing off entirely (SmartAPI still enforces its own limits server-side either way — this only controls whether the client tries to stay under them proactively):

Testing

pip install -e ".[test]"

# Offline: verifies the server registers the expected tools. No credentials
# or network access needed.
python -m pytest tests/test_tool_registration.py -v

# Offline: unit tests for session persistence (login state cached to disk,
# restored + verified via get_profile on restart, falls back to a fresh
# login when the cache is missing/invalid). Uses a fake HTTP layer - no
# credentials or network access needed.
python -m pytest tests/test_session_persistence.py -v

# Offline: unit tests for AngelOneClient's own rate limiting (pacing per
# ROUTE_MIN_INTERVAL, backoff/retry on a 403/429 rate-limit response, and
# that such a response is never misread as an expired session). Uses a fake
# HTTP layer - no credentials or network access needed.
python -m pytest tests/test_client_rate_limiting.py -v

# Live, read-only smoke test against your real account. Calls get_profile,
# get_order_book, get_holdings, search_scrip, get_ltp, etc. through the
# actual MCP server subprocess, plus a check that a session survives a
# restart of the server without calling the "login" tool again. Never calls
# place_order/modify_order/cancel_order/gtt_create_rule/gtt_modify_rule/
# gtt_cancel_rule/convert_position/logout - a SafeSession wrapper
# hard-asserts those are never invoked. On top of the server's own rate
# limiting (see "Rate limiting" above), the test itself also paces its tool
# calls and backs off/retries if the API reports one was hit anyway (see
# "Rate limiting in the live test" below) - belt and suspenders. Requires
# ANGELONE_API_KEY/ANGELONE_CLIENT_CODE/ANGELONE_PIN/ANGELONE_TOTP_SECRET
# to be set; skips automatically if they aren't.
python -m pytest tests/test_readonly_live.py -v -s
# or, for a plain-text report without pytest:
python tests/test_readonly_live.py

Rate limiting in the live test

The live test (tests/test_readonly_live.py) calls a real account against the real SmartAPI. The server it drives already paces itself (see "Rate limiting" above), but the test adds its own independent pacing on top - useful because it also exercises things the server-side limiter doesn't see by itself, like two separate server subprocesses (the session-persistence check) hitting the same account back to back:

• A RateLimiter tracks the last time each MCP tool was called and, before calling it again, waits out the rest of that endpoint's minimum interval (1/req-per-second-limit, plus a ~20% safety margin). Distinct tools hit distinct SmartAPI endpoints with independent limits, so this only ever delays a repeat call to the same tool (e.g. get_profile being called again by the second server spawn in the session-persistence check) - a normal single pass through the suite, where every tool is called once or twice, isn't slowed down by it in practice.

• If SmartAPI reports a rate limit was hit anyway (HTTP 403, "Access denied because of exceeding access rate"), the test backs off and retries a couple of times with increasing delay instead of failing outright.

• This governs the test suite's own request pace only - it has no effect on how the MCP server behaves for a real MCP client (Claude, etc.); SmartAPI still enforces its limits server-side either way.

Notes / limitations

• Order params (price, quantity, etc.) are passed as strings, matching what SmartAPI's placeOrder expects.

• get_margin and estimate_charges take a list of position/order dicts — see the SmartAPI docs for exact field names per instrument type (https://smartapi.angelone.in/docs/Margin, .../Brokerage).

• Rate limits are enforced by Angel One per endpoint; see https://smartapi.angelone.in/docs/RateLimit. This server does not do its own client-side rate limiting.

• Not affiliated with or endorsed by Angel One / Angel Broking.