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., "@t212-mcp How is my portfolio doing, and which holding is furthest from its pie target?"
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.
A Model Context Protocol server that gives an AI assistant read-only access to a Trading 212 investing account: balances, positions, order and dividend history, pies, and the instrument catalogue.
It cannot trade. No tool places, amends or cancels an order, or changes a pie. The HTTP client has no code path that issues anything but a
GET. See Security.
You: How is my portfolio doing, and which holding is furthest from its pie target?
→ t212_get_account_info reporting currency
→ t212_get_account_cash balance and unrealised P/L
→ t212_list_positions holdings, ranked by value
→ t212_list_pies pie valuations
→ t212_get_pie allocation driftNode.js 20.11 or newer
A Trading 212 API key — in the app: Settings → API
Trading 212 issues separate credentials for practice and real-money accounts, and a key from one is rejected by the other. Start with the practice account.
Related MCP server: Trading 212 MCP Server
npx t212-mcpIt speaks MCP over stdio, so run it from a client rather than directly.
claude_desktop_config.json:
{
"mcpServers": {
"trading212": {
"command": "npx",
"args": ["-y", "t212-mcp"],
"env": {
"T212_API_KEY": "your-key",
"T212_ENVIRONMENT": "demo"
}
}
}
}claude mcp add trading212 \
--env T212_API_KEY=your-key \
--env T212_ENVIRONMENT=demo \
-- npx -y t212-mcpRun npx -y t212-mcp with the environment below and connect over stdio.
Variable | Default | Description |
| — | Required. API key from the Trading 212 app. |
| — | Secret, if your key was issued as a key/secret pair. Selects HTTP Basic auth. |
|
|
|
|
|
|
|
| Per-request timeout. |
|
| Retries rate limits, network faults and 5xx. Never 4xx or a schema mismatch. |
|
| Base cache lifetime, scaled per endpoint — see caching. |
|
| Exposes the CSV export tools. See Security. |
| — | Overrides the API host. For testing against a stub. |
The environment defaults to demo deliberately: the failure mode of that
default is reading play money by accident, which is the only acceptable
direction for the mistake to go.
See .env.example.
Tool | Returns |
| Free cash, total value, invested amount, unrealised P/L, blocked cash |
| Account id, reporting currency, which environment is connected |
| All open positions with market value; sort by value, profit or ticker |
| One position by exact ticker |
| Ranked instrument search by name, symbol or ISIN → exact tickers |
| Exchanges and, on request, their trading schedules |
| Orders placed but not yet executed |
| Executed orders, paginated, filterable by ticker |
| Dividends received, paginated |
| Deposits, withdrawals, fees and interest, paginated |
| Pies with invested value, current value and result |
| One pie's holdings, ranked by drift from target allocation |
| CSV export jobs and links — only if |
Also exposed: a t212://connection resource describing the connection (no
credentials, no network call), and a portfolio_review prompt.
Every tool is annotated readOnlyHint: true and destructiveHint: false.
Trading 212 tickers carry a market suffix: AAPL_US_EQ, not AAPL. Ask the
assistant for a company by name — t212_search_instruments resolves it.
Trading 212's limits are strict and per-endpoint; the instrument catalogue allows roughly one call per minute. The server shapes requests with a token bucket per endpoint group and waits for budget rather than being rejected and retrying blind.
Cache lifetimes are assigned by what the data is, not uniformly:
Data | Lifetime |
Instruments, exchanges | 12× base TTL |
History, dividends | 1× base TTL |
Pies | 0.2× base TTL |
Cash, positions | 0.1× base TTL |
Pending orders, exports | Never cached |
Stale reference data is cosmetic; a stale balance quoted as current is a wrong answer. Concurrent identical requests share one call.
Read SECURITY.md for the full threat model. In short:
Read-only by construction. The HTTP client exposes only get and has no
path that can issue another method. Order placement, cancellation and pie
mutation exist in the Trading 212 API and are deliberately absent here, so a
prompt injection reaching a tool call cannot move money.
Credentials stay in the process. Read from the environment, sent only to the configured Trading 212 host over TLS, never written to disk, never in a tool result, and scrubbed from logs and error messages by key name and by literal value.
Your data goes to your model provider. Anything a tool returns — balances, positions, transaction history — is sent to whichever model your client talks to. That is how MCP works, but decide knowingly before pointing this at a live account.
CSV exports are opt-in. Export download links grant access to a full
account statement without further authentication, so the tools are hidden
entirely unless T212_ALLOW_EXPORTS is set.
Create your API key with the narrowest scopes you need. This server never uses order-placement scopes.
npm ci
npm run check # format, lint, typecheck, test — what CI runs
npm run dev # run from source with reloadSee CONTRIBUTING.md.
docker build -t t212-mcp .
docker run --rm -i -e T212_API_KEY=your-key t212-mcp-i is required: the server talks over stdin and stdout.
Not affiliated with or endorsed by Trading 212. The Trading 212 API is in beta and may change. This software is provided as-is under the MIT licence; nothing it returns is financial advice, and you are responsible for verifying any figure before acting on it.
Returns the account's cash breakdown: free cash available to invest, total account value, amount currently invested, unrealised profit or loss, cash held inside pies, and cash blocked by pending orders. Use this for any question about how much money is in the account or how it is performing overall. Figures are in the account's own currency — call t212_get_account_info if you need to know which currency that is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe read-only nature is known. The description adds value by listing exactly which cash breakdown items are returned and noting the currency caveat, though it doesn't describe the return format (no output schema exists).
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?
Three sentences, each with a distinct purpose: the first lists contents, the second gives usage guidance, and the third adds a currency caveat and cross-reference. It is front-loaded with the main verb and contains zero fluff.
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 zero-parameter, read-only tool with no output schema, the description provides complete context: what the tool does, what data it returns, when to use it, and a critical caveat about currency. No essential information is missing.
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?
There are zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameters and doesn't attempt to; it appropriately focuses on output and usage.
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 the account's cash breakdown and enumerates specific components (free cash, total value, invested amount, etc.). It also distinguishes itself from siblings by mentioning t212_get_account_info for currency and by framing its use case directly.
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?
Explicit usage guidance is provided: 'Use this for any question about how much money is in the account or how it is performing overall.' It also points to an alternative tool for currency, giving clear when-to-use versus when-to-use-another-tool direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the account identifier and the currency every monetary figure from this server is reported in. Call this once when you need to label amounts correctly; the other tools return bare numbers in this currency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context by instructing to 'call this once' and explaining that other tools return bare numbers in this currency, which helps the agent understand the tool's role in labeling amounts correctly without needing to repeat calls.
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 exactly two sentences: the first states the core function, the second gives usage guidance. Every word earns its place, with no redundant or filler content.
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 no-parameter tool, the description adequately covers what is returned (account identifier and currency) and why it matters (for labeling amounts). Annotations cover safety, and the absence of an output schema is acceptable because the description states the return values in plain terms. No further details are needed for an agent to select and invoke this tool correctly.
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 schema is trivially fully covered. With no parameters, there is nothing to explain, and the baseline score of 4 applies as no additional parameter documentation is needed.
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 the account identifier and currency for all monetary figures, using a specific verb ('Returns') and resource. It explicitly distinguishes itself from sibling tools by explaining that other tools return bare numbers in this currency.
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 provides clear context on when to call this tool ('Call this once when you need to label amounts correctly') and explains the relationship with other tools. However, it does not explicitly name alternatives or state when not to use it, though the guidance implies it is only needed for labeling amounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one pie's contents: every instrument in it with its current share of the pie, its target share, the quantity owned, and its result. Use this to explain how a pie is allocated or which of its holdings are drifting from target. Get the pie's id from t212_list_pies first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Pie identifier, as returned by t212_list_pies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds behavioral detail about the return contents (current share, target share, quantity, result), which is especially valuable given no output schema.
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?
Three sentences, each serving a distinct purpose: return contents, usage context, prerequisite. No redundant or verbose language.
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 single-parameter read-only lookup with no output schema, the description sufficiently explains inputs, output fields, and use cases. It is complete for the tool's simplicity.
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 input schema fully describes the id parameter as returned by t212_list_pies, and the description repeats this guidance without adding new syntax or format details. Given 100% schema coverage, the description adds minimal semantic value beyond the schema.
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 one pie's contents with specific fields (current share, target share, quantity, result), distinguishing it from t212_list_pies which lists all pies. The verb 'Returns' and resource 'one pie's contents' make the purpose unambiguous.
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 instructs to use this tool to explain pie allocation or detect holdings drifting from target. It also directs the user to get the pie id from t212_list_pies first, providing a clear prerequisite and implying the alternative for listing pies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one open position by its exact Trading 212 ticker (for example AAPL_US_EQ, not AAPL). Only use this when you already know the exact ticker — otherwise call t212_list_positions, which returns everything in a single request, or t212_search_instruments to resolve a name to a ticker. Fails if the account holds no such position.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Exact Trading 212 ticker, e.g. AAPL_US_EQ. Case-sensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: it fails if no position exists, clarifies that the ticker must be exact (including suffix), and implies the scope is open positions only. This enriches the agent's understanding.
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 three short sentences: the first states the action, the second provides usage guidance with alternatives, and the third notes the failure condition. Every sentence earns its place with no wasted 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?
Despite having no output schema, the tool is simple and the description covers its core purpose, when to use it, and edge-case behavior. Annotations handle safety aspects, so the description is complete for effective selection and invocation.
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 input schema fully describes the ticker parameter (100% coverage), so the baseline is 3. The description goes beyond the schema by giving a concrete example and explicitly contrasting it with the plain ticker form, adding semantic clarity that helps the agent avoid common mistakes.
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 it returns one open position by exact Trading 212 ticker, and distinguishes itself from sibling tools by explicitly naming the alternatives and providing a concrete ticker example (AAPL_US_EQ, not AAPL). This is a specific verb+resource with strong sibling differentiation.
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 explicitly states when to use this tool ('Only use this when you already know the exact ticker') and provides clear alternatives ('otherwise call t212_list_positions... or t212_search_instruments'). This is a textbook example of usage guidance with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns dividends paid into the account, newest first, with the instrument, amount, and amount per share. Use this for dividend income questions. Results are paginated — pass the returned nextCursor to continue. Note this reports what was actually paid, not forecast yield.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return in this page. | |
| cursor | No | Opaque cursor from a previous call's nextCursor. Omit for the first page. | |
| ticker | No | Exact Trading 212 ticker to filter by. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds key behavioral details: newest-first ordering, pagination via nextCursor, and the important caveat that it reports actual paid amounts, not forecast yield.
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?
Three sentences, no fluff. The main purpose leads, followed by usage guidance, pagination note, and a clarifying caveat. 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?
For a simple read-only list endpoint with optional parameters and no output schema, the description fully covers what to expect: returned fields, ordering, pagination, and a semantic disambiguation. No significant gaps remain.
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 input schema covers all three parameters with clear descriptions (100% coverage). The description adds no new parameter-level semantics; it only mentions passing nextCursor, which the schema already explains. Baseline of 3 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?
The description immediately states the tool returns dividends paid into the account, listing specific fields (instrument, amount, amount per share) and ordering (newest first). This clearly distinguishes it from siblings like t212_list_transactions or t212_get_account_cash.
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 phrase 'Use this for dividend income questions' gives explicit context for when to choose this tool. It doesn't enumerate alternatives or exclusions, but the sibling list makes the boundaries clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the exchanges Trading 212 supports and their working schedules, including the time events that mark when each session opens and closes. Use this to answer whether a market is open, or to explain why an instrument cannot be traded right now. Schedules are verbose, so they are omitted unless explicitly requested.
| Name | Required | Description | Default |
|---|---|---|---|
| includeSchedules | No | Include full working schedules. These are long; leave false unless you need specific session times. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's job is to add context beyond safety. It does this by disclosing that schedules are verbose and omitted by default, requiring an explicit opt-in via includeSchedules. This transparency about default output behavior is valuable and goes beyond the structured 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 three sentences long, with the first sentence stating purpose, the second giving usage guidance, and the third providing a crucial caveat about verbosity. Every sentence earns its place, and the structure is front-loaded with the most important information. There is no wasted text.
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 list tool with one optional boolean parameter and no output schema, the description is complete. It explains what data is returned, when to use it, and how to control the verbosity of the response. It gives the agent all necessary information to correctly select and invoke this 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?
The schema fully documents the single boolean parameter with a description, so baseline is 3. The tool description adds meaningful context by explaining that schedules are verbose and omitted unless explicitly requested, directly clarifying the parameter's purpose and the default behavior. This enhances the schema description and helps the agent decide when to set it to true.
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 exchanges and their working schedules, with a specific verb ('Returns') and resource ('exchanges'). It also mentions the time events for session opens/closes, distinguishing it from sibling tools that focus on accounts, positions, or orders. This is a specific and accurate definition.
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 provides explicit when-to-use guidance: 'Use this to answer whether a market is open, or to explain why an instrument cannot be traded right now.' It does not explicitly mention when not to use it or name alternative tools, but given the sibling tools are unrelated, the usage context is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns past, already-executed orders newest first: what was bought or sold, at what price, and any taxes charged. Use this for questions about trading activity or realised results. Results are paginated — pass the returned nextCursor to continue. Optionally filter to a single ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return in this page. | |
| cursor | No | Opaque cursor from a previous call's nextCursor. Omit for the first page. | |
| ticker | No | Exact Trading 212 ticker to filter by, e.g. AAPL_US_EQ. Omit for all instruments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral details: ordering (newest first), pagination via cursor, and optional ticker filter. It doesn't mention edge cases like empty results, but this is not critical given the annotation coverage.
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 two sentences, front-loaded with the core purpose, followed by usage and pagination notes. Every sentence earns its place with no filler or redundancy. It is concise yet informative.
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 list tool with 3 optional parameters and no output schema, the description covers return contents, ordering, pagination, and filtering. Annotations provide safety context, and the description fills in the behavioral gaps. It is complete for an agent to select and invoke correctly.
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 description coverage is 100%, so the baseline is 3. The description adds meaning by linking cursor to pagination ('pass the returned nextCursor') and ticker to filtering, which goes beyond the schema's field descriptions. It also clarifies the return content, indirectly explaining limit's purpose.
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 past, already-executed orders with specifics like what was bought/sold, price, and taxes. The phrase 'already-executed' distinguishes it from pending order tools, and 'realised results' differentiates it from transaction history. This is a specific verb+resource description with clear scope.
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?
It explicitly says 'Use this for questions about trading activity or realised results', providing clear context. Pagination instructions ('pass the returned nextCursor to continue') offer practical usage guidance. However, it does not name alternatives or explicitly state when not to use this tool, leaving some ambiguity versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns orders that are placed but not yet executed, with their type, limit or stop price, and how much has filled so far. Use this for 'what orders do I have open'. This server is read-only: it can show pending orders but cannot place, amend or cancel them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces this by stating the server is read-only but adds little beyond what annotations already provide. It does clarify the scope of 'pending orders' versus executed ones, but this is largely a purpose clarification rather than new behavioral disclosure.
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 two sentences, front-loaded with the main verb and resource. The first sentence describes what the tool does, and the second adds usage context and limitations. Every word is purposeful with no 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?
For a zero-parameter, read-only tool with comprehensive annotations, the description covers what it returns, when to use it, and a key limitation. It gives a clear sense of the output fields without an output schema, making it complete for practical use.
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, and the schema reflects this with 100% coverage. The description doesn't need to explain parameters, and the baseline score of 4 is appropriate since there is nothing to add.
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 that the tool returns pending, unexecuted orders and specifies the key fields (type, limit/stop price, filled amount). It distinguishes itself from sibling tools by emphasizing 'not yet executed', differentiating from order history and 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 explicitly says 'Use this for what orders do I have open', providing a clear use case. It also notes what the tool cannot do (place, amend, cancel orders), offering a when-not-to-use boundary, though it doesn't name alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the account's pies — Trading 212's named baskets of instruments with target allocations — including each pie's invested value, current value, result, and progress towards its goal. Use t212_get_pie for the instruments inside a specific pie. This server is read-only and cannot create or change a pie.
| 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, and the description reinforces this by stating 'This server is read-only and cannot create or change a pie.' It also explains the return content (invested value, current value, result, progress), which is useful given no output schema. However, it doesn't mention limits like pagination or error conditions, though these are not critical for a simple listing.
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 two sentences and every word adds value: it explains the resource, the returned data, the sibling tool for details, and the read-only nature. It is front-loaded with the core purpose and has no filler or repetition.
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 (no parameters, no output schema, clear read-only behavior supported by annotations), the description provides complete context: what it returns, how it relates to the sibling tool, and that it cannot modify anything. There are no significant gaps.
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 schema trivially covers 100% and there is nothing for the description to compensate. The baseline for zero parameters is 4, and the description appropriately focuses on what is returned rather than parameter syntax.
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 states a specific verb ('Returns') and a clear resource ('the account's pies'), and defines what pies are (named baskets of instruments with target allocations). It also distinguishes itself from the sibling tool t212_get_pie by noting that the sibling provides the instruments inside a specific pie.
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 explicitly says 'Use t212_get_pie for the instruments inside a specific pie', providing an alternative and when to use it. It also implies when to use this tool (when you need an overview of pies), making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every open position in the account: ticker, quantity, average buy price, current price, and unrealised profit or loss (including the portion caused by currency movement). This is the tool for 'what do I hold', 'how is my portfolio doing', or any question about a specific holding when you do not already know its exact Trading 212 ticker. Returns the whole portfolio in one call, so prefer it over repeated single-position lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum positions to return. The total count is always reported. | |
| sortBy | No | Order of the returned positions. 'value' is market value, 'profit' is unrealised profit or loss, both descending. | value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it returns the entire portfolio in one call and includes profit/loss impact from currency movement, which helps the agent understand scope and output semantics.
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 three sentences, front-loaded with the core result and fields, then use cases, then a comparative note. Every sentence earns its place: return contents, when to use, and preference over alternatives. No filler or 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?
Despite no output schema, the description enumerates the returned fields, making the output shape clear. It also provides usage context, distinguishes from siblings, and notes the single-call portfolio behavior. This is complete for a list tool with two well-defined optional parameters.
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 description coverage is 100% for both parameters (limit and sortBy), with clear descriptions and defaults. The description does not add new parameter-level meaning but reinforces the 'whole portfolio' nature that relates to the limit parameter. Baseline 3 is appropriate because structured fields carry the semantic weight.
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 uses a specific verb ('Returns') and resource ('every open position in the account'), listing the exact fields returned (ticker, quantity, average buy price, current price, unrealised profit/loss). It clearly distinguishes from siblings by stating it returns the whole portfolio in one call, unlike single-position lookups.
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?
It explicitly states when to use the tool: for 'what do I hold', 'how is my portfolio doing', or any question about a specific holding when you do not already know the exact Trading 212 ticker. It also gives an exclusion by recommending it over repeated single-position lookups, which implicitly names the alternative behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns cash movements — deposits, withdrawals, fees and interest — newest first. Use this for 'how much have I deposited' or to explain a change in cash that positions do not account for. Results are paginated; pass the returned nextCursor to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return in this page. | |
| cursor | No | Opaque cursor from a previous call's nextCursor. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds valuable behavioral context about ordering ('newest first') and pagination ('pass the returned nextCursor to continue'). It also clarifies the types of transactions included. This goes beyond what annotations provide and does not contradict them.
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, compact and front-loaded with the core purpose, followed by use cases and pagination details. Every sentence adds useful information with 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?
With only two parameters and no output schema, the description covers all essential aspects: what it returns, why to use it, ordering, and pagination. The annotations supply safety context, making this complete for an agent to select and invoke the 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?
Schema coverage is 100%, so parameters are already described. The description adds meaning by explaining how to use the cursor ('pass the returned nextCursor to continue') and that results are paginated, which links limit and cursor. This enhances the schema descriptions rather than merely repeating them.
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 uses a specific verb ('Returns') and identifies the resource ('cash movements') with a clear scope ('deposits, withdrawals, fees and interest') and ordering ('newest first'). It clearly distinguishes from siblings like list_positions and list_dividends by focusing on cash movements that positions do not account for.
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?
It provides explicit use cases ('how much have I deposited' and 'explain a change in cash that positions do not account for'). While it doesn't name alternative tools, the use-case framing naturally steers away from positions and dividends. Could be improved by explicitly stating when not to use it, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds instruments in the Trading 212 catalogue by company name, symbol or ISIN, returning the exact tickers other tools need (for example AAPL_US_EQ). Use this first whenever you have a company name but not a ticker. Results are ranked, with exact symbol and ISIN matches first. Note this searches everything Trading 212 offers, not the account's holdings — use t212_list_positions for what is actually owned.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional instrument type filter, e.g. STOCK or ETF. Omit to search every type. | |
| limit | No | Maximum matches to return, best first. | |
| query | Yes | Company name, symbol or ISIN. Matching is case-insensitive and partial, e.g. 'apple', 'AAPL' or 'US0378331005'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating read-only, idempotent, and open-world behavior, the description adds valuable context beyond those flags: results are ranked with exact symbol/ISIN matches first, and it searches the entire Trading 212 catalogue rather than account holdings. This clarifies expected behavior and prevents misuse without contradicting the 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 three sentences long, front-loaded with the main action, followed by usage guidance and a clarifying scope note. Every sentence earns its place—no fluff, no repetition of schema details, and the alternative tool is mentioned naturally within the scope distinction.
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?
Despite having no output schema, the description explains the key output concept (exact tickers like AAPL_US_EQ), the ranking behavior, and the critical scope distinction from holdings. Combined with rich annotations (readOnly, idempotent, openWorld) and full parameter documentation, the agent has everything it needs to invoke the tool correctly without missing context.
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 schema covers 100% of parameters with detailed descriptions (e.g., query supports company name, symbol, or ISIN with case-insensitive partial matching). The description adds no new parameter-level semantics beyond the schema, so a baseline score of 3 is appropriate given the thorough 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 'Finds instruments in the Trading 212 catalogue by company name, symbol or ISIN', giving a specific verb, resource, and search criteria. It also distinguishes itself from t212_list_positions by explicitly saying it searches the catalogue, not account holdings, which sets it apart from siblings.
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?
Provides explicit when-to-use guidance: 'Use this first whenever you have a company name but not a ticker.' It also names a direct alternative for account holdings: 'use t212_list_positions for what is actually owned.' This is clear and actionable, leaving no ambiguity about when to choose this tool.
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.0t212_get_account_casht212_get_account_infot212_get_piet212_get_positiont212_list_dividendst212_list_exchangest212_list_order_historyt212_list_pending_orderst212_list_piest212_list_positionst212_list_transactionst212_search_instrumentsScored across 12 tools
Each tool targets a distinct resource and action: cash, account info, positions (all vs single), instrument search, exchanges, pending orders, order history, dividends, transactions, pies (list vs get). The only similar pair (list_positions vs get_position) is clearly differentiated by scope and purpose.
All tools follow the t212_<verb>_<resource> pattern, with 'list' for collections, 'get' for single resources, and 'search' for the catalog. This is perfectly consistent and predictable.
12 tools is well-scoped for a read-only brokerage account server. Each tool covers a distinct aspect of account data (cash, positions, orders, history, dividends, transactions, pies, exchanges, instruments) without redundancy or bloat.
For its stated purpose (read-only access to account and market data), the tool set is comprehensive. It covers all major read operations: account identification, cash, positions, pending and historical orders, dividends, transactions, pies with detail, exchange schedules, and instrument search. The read-only restriction is consistent with no create/update/delete tools, and there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server exposing a user ORANO library to their own AI agent.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
MCP server exposing the Backtest360 engine API as tools for AI agents.
