t212-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.6/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![t212-mcp MCP server](https://glama.ai/mcp/servers/guilyx/t212-mcp/badges/card.svg)](https://glama.ai/mcp/servers/guilyx/t212-mcp)

Score Badge

Copy to your README.md:

[![t212-mcp MCP server](https://glama.ai/mcp/servers/guilyx/t212-mcp/badges/score.svg)](https://glama.ai/mcp/servers/guilyx/t212-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guilyx/t212-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server