Trading 212 MCP Server

A Model Context Protocol server for the Trading 212 public API. It exposes account data, positions, orders, pies, instrument metadata, and account history. It also includes an account-currency-aware analysis prompt. It does not provide independent market feeds, investment recommendations, or real-time streaming.

Python 3.11–3.14 is supported. The current source package version is 0.2.0; see the changelog for upgrade details. The project uses the official MCP Python SDK 2.x.

Install and run

You can follow the setup below yourself or ask a coding agent such as Codex or Claude Code to do it. Paste this prompt into the agent's chat:

Read https://github.com/RohanAnandPandit/trading212-mcp-server/blob/main/README.md#setup
and follow the setup process.

Setup

1. Install prerequisites and dependencies. You need Git, uv, and Python 3.11–3.14. Choose a stable installation folder, then run:

   git clone https://github.com/RohanAnandPandit/trading212-mcp-server.git
   cd trading212-mcp-server
   uv sync --frozen
   

   If you already have a checkout, reuse it without overwriting local changes. Alternatively, install the package from the checkout using pip install ., then run trading212-mcp-server. For a locked pip installation, use pip install --require-hashes -r requirements.txt followed by pip install --no-deps ..

2. Configure credentials locally. Create an ignored .env file from .env.example if one does not already exist:

   cp .env.example .env
   

   Generate credentials in your Trading 212 account's API settings, granting only the permissions you need. Edit .env yourself to set TRADING212_API_KEY and, for Basic authentication, TRADING212_API_SECRET. API-key-only authentication remains available for existing integrations, where accepted by Trading 212; remove the example secret value if using it. Start with ENVIRONMENT=demo and TRANSPORT=stdio. Use the live environment only when you explicitly choose to enable operations on your real account.

   Keep credentials out of chat, commands, logs, and MCP client configuration. If an agent is helping, enter the values yourself; the agent must wait for you and must not read, display, log, or repeat them.

   The server reads .env in its working directory at startup. Existing process environment variables take precedence.

3. Connect your MCP client. Use your client's supported method to register a local stdio server named trading212. Choose whether the connection should be available only in this workspace or across your projects before saving it. Clients that accept mcpServers JSON can use:

   {
     "mcpServers": {
       "trading212": {
         "command": "uv",
         "args": ["run", "--frozen", "--directory", "/absolute/path/to/trading212-mcp-server", "trading212-mcp-server"],
         "env": {
           "ENVIRONMENT": "demo",
           "TRANSPORT": "stdio"
         }
       }
     }
   }
   

   Replace the example path with your checkout's absolute path. Credentials stay in the checkout's .env file. To launch the server directly from the checkout, run uv run --frozen trading212-mcp-server.

4. Verify the connection. Restart your MCP client if needed and check that it connects to the server and discovers its tools. Setup is complete only when discovery succeeds. Imports and tool discovery do not make Trading 212 requests, and no credentials are required merely to import the server. Do not call account or trading tools during setup. Record where the MCP configuration was saved and any steps that remain.

Existing configurations pointing to src/server.py continue to work after uv sync --frozen. The script also remains the Inspector entry point:

uv run --frozen mcp dev src/server.py

Inspector requires Node.js and npx. Tool calls in Inspector use the configured account, including mutations when you invoke those tools.

Docker

docker build -t trading212-mcp-server .
docker run --rm -i --env-file .env trading212-mcp-server

For a desktop client, pass both credential variables through Docker:

{
  "mcpServers": {
    "trading212": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "-e", "TRADING212_API_KEY", "-e", "TRADING212_API_SECRET", "-e", "ENVIRONMENT", "trading212-mcp-server"],
      "env": {
        "TRADING212_API_KEY": "YOUR_API_KEY",
        "TRADING212_API_SECRET": "YOUR_API_SECRET",
        "ENVIRONMENT": "demo"
      }
    }
  }
}

The image runs as UID/GID 10001. Credentials, local caches, and development files are excluded from the image. The default container cache is ephemeral; mount a private directory writable by UID 10001 at /home/app/.cache if you want persistence. Stdio does not require publishing a port.

Configuration

A TTL of zero disables caching for that category. Values must be finite and non-negative. HTTP transports bind only to 127.0.0.1:8000, with explicit Host/Origin restrictions. This is a local single-account server; hosted access, public HTTP binding, and multi-user authentication are not provided. Do not expose it through a public proxy or tunnel. Tool annotations describe effects; they do not implement permissions. Use API permissions and your MCP client's approval controls to govern account mutations.

Tools

All previous tool names are retained:

Positive order quantities buy; negative quantities sell. Zero/non-finite quantities, non-positive prices, and empty tickers are rejected. Pie updates may include any documented field independently; name is optional. Export dates must include a timezone and be ordered. Pies are deprecated upstream, but their tools are retained.

fetch_account_info aliases fetch_account_summary. The older position tools remain compatibility aliases. Historical tools return a single page with nextPagePath; pass its cursor and other query parameters to fetch the next page. Limits retain their existing clamp to 1–50. Requests do not automatically traverse all pages or follow export download links.

Resources and prompt

Resources retain their existing URIs:

• trading212://account/summary, trading212://account/cash
• trading212://positions, trading212://positions/{ticker}
• trading212://orders, trading212://orders/{order_id}
• trading212://pies, trading212://pies/{pie_id}
• trading212://instruments, trading212://exchanges
• trading212://history/exports

Compatibility URIs: trading212://account/info, trading212://account/portfolio, trading212://account/positions, trading212://account/portfolio/{ticker}, and trading212://account/positions/{ticker}.

The analyse_trading212_data prompt includes account currency when available and explains GBX/GBP units. If account retrieval fails, it still returns the base prompt and writes a generic diagnostic to stderr.

Cache and request guarantees

Private data remains cached. Credential/base-URL fingerprints isolate SQLite storage across accounts, secret rotations, environments, and API versions. Authorization and cookies never enter the cache layer. Cache responses contain financial data in plaintext; private filesystem permissions are not encryption. Use a private local disk, not a shared or network-mounted cache directory.

Only successful GETs are cached, and expired responses are never served. Mutations are never cached or automatically retried. After any attempted mutation, private-cache generations advance, including when the outcome is uncertain. A cross-process file lock covers reads, writes, body consumption, and invalidation, preventing older in-flight reads from repopulating the current generation. Different credential namespaces remain independent; external trades or writes using another API key may remain invisible until the TTL expires.

MCP tool results and resource contents carry freshness details under _meta["io.github.RohanAnandPandit.trading212/cache"]: an array of cacheHit, retrievedAt (UTC), and ttlSeconds records. Existing data fields remain intact.

Transient GET failures may be retried twice within a 30-second retry budget, respecting Retry-After and rate-reset headers. Individual HTTP operations have explicit timeouts. Waiting for another process's cache lock is bounded separately at 30 seconds. A failed mutation can have an unknown outcome: check the account before deciding whether to issue it again.

Upgrading from 0.1.x

Stop older server processes, update the checkout, and run uv sync --frozen. The new server never reads or migrates .cache/hishel or .cache/trading212-v2. Those directories may contain private responses and Authorization headers. After confirming the paths belong to this application, explicitly remove old cache directories yourself. The upgrade does not delete user data. Rebuild Docker images and replace any older images that may have included local files.

Development and security

See CONTRIBUTING.md for architecture and verification commands, SECURITY.md for private reporting, and the modernization validation report for checked behavior.

Keeping the Trading 212 schema in sync

Trading 212's live OpenAPI description is the authority. docs/api.json is the reviewable checked-in snapshot. Before making API-facing changes or preparing a release, check it without account credentials:

uv run --with PyYAML python .agents/skills/trading212-api-sync/scripts/sync_api_schema.py --check

If the command reports drift, refresh the snapshot:

uv run --with PyYAML python .agents/skills/trading212-api-sync/scripts/sync_api_schema.py --update

Review the resulting diff rather than treating regeneration as sufficient. Update endpoints, parameters, request and response models, enums, deprecations, tests, and documentation where relevant, then run the full verification suite. The repository-local trading212-api-sync agent skill contains the complete workflow. The schema check only downloads public documentation; it must never make authenticated account requests or trading mutations.

This project is independently maintained and is not affiliated with or endorsed by Trading 212. Consult the provider's current documentation and terms. Licensed under MIT.