oanda-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Each tool targets a distinct resource or filtered view, such as list_orders vs list_pending_orders and list_trades vs list_open_trades. The only overlapping pair is get_account/get_account_summary, but the descriptions explicitly clarify the cost tradeoff. Overall, purposes are clearly delineated.
Naming Consistency5/5
All tools follow a consistent list_X or get_X pattern with clear resource nouns (accounts, instruments, candles, orders, trades, positions, transactions). There are no mixed conventions or vague verbs.
Tool Count3/5
At 22 tools, the server is on the heavy side, with several near-duplicate filter tools (list_open_*, list_pending_orders) and convenience wrappers (get_latest_candles) that could be folded into the base tools. Still, each tool maps to a clear endpoint and the count is within reason for a comprehensive trading data API.
Completeness2/5
The read side is exhaustive: accounts, instruments, market data, orders, trades, positions, and transactions are all covered. However, there are zero write or mutation tools—no way to create, modify, or cancel orders, close trades, or change account settings. This is a critical gap for a trading server and will cause agent failures when action is required.
Average 4.4/5 across 22 of 22 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 17, 2026
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no mutation concerns. The description adds valuable context about the response shape, including decimal string fields and the meaning of negative units on the short side, going beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the first sentence is concise, the second sentence is a long enumeration of fields and types. Since an output schema exists, this detail is redundant and makes the description less crisp than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 tool with one optional parameter and an output schema, the description covers the core purpose and return semantics. It is more than adequate, though still somewhat verbose.
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 has 100% coverage for the single 'limit' parameter, so the schema fully documents it. The description adds no parameter-specific information, matching the baseline for high 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 verb 'List' and the resource 'open positions', defining them as 'instruments with at least one open trade'. This scope distinguishes it from siblings like list_positions and get_position, making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for open positions but provides no explicit when-to-use guidance or comparison with alternatives. It references list_positions only to describe the return shape, not to direct the user on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals that this is a safe read operation. The description adds the return payload structure, which is useful but not strictly behavioral beyond the annotation. It does not disclose error conditions or side effects, but for a simple get operation this is acceptable. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, then provides a structured example of the return object. The additional field listing is useful but slightly redundant given the output schema, yet it does not feel overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, high schema coverage, and an output schema. The description covers the return format and key fields, providing enough context for an agent to use it correctly. It could mention not-found behavior, but that is not essential given the schema and annotations.
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 coverage is 100%, and the schema already thoroughly explains the order_specifier parameter, including examples of Oanda-assigned IDs and client-assigned IDs with '@' prefix. The description repeats this information without adding substantial new parameter context, so baseline 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 starts with 'Get a single order by ID or client-assigned ID.' This uses a specific verb ('Get') and resource ('single order'), and clearly differentiates from sibling tools like list_orders by emphasizing the singular retrieval and supporting client-assigned IDs.
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 implies usage for retrieving one specific order, but does not explicitly mention alternatives or when not to use it. Context makes it clear that it is for single-order retrieval, which provides clear guidance without exclusions.
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?
Beyond the readOnlyHint annotation, the description discloses that snapshots are periodic rather than per-tick, and details the output structure including time, price, bucketWidth, and bucket percentages. This adds meaningful behavioral context without contradicting the annotation.
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 concise yet comprehensive, with a clear opening statement followed by structured details. Every sentence contributes useful information about behavior or output format, with no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, output format, and key behavioral nuances. While it doesn't address alternative tools or error scenarios, the presence of an output schema and read-only annotation reduces the burden, making it reasonably complete.
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 coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal new parameter insight—it mentions depth trimming and snapshot time but largely mirrors the schema's existing descriptions.
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 opens with 'Fetch the aggregate pending-order book for an instrument,' clearly identifying the verb, resource, and scope. It distinguishes itself from sibling tools like get_position_book by specifying 'pending-order book' and 'aggregate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives such as get_position_book or get_candles. It implies the use case via the title and first sentence but lacks direct comparison or exclusion statements, so it falls at the 'implied usage' level.
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 provide readOnlyHint=true, and the description adds meaningful behavior: ordering (most recent first), return structure (trades array, lastTransactionID), and field semantics (e.g., sign of units indicates direction). It does not contradict annotations and adds value beyond the safety flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then provides a detailed but organized return object breakdown. It is somewhat long but each sentence adds field-level detail, avoiding fluff. Slightly more verbose than necessary given an output schema exists, but remains well-structured.
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 rich schema and annotations, the description is comprehensive: it explains ordering, return shape, field meanings, and extras for closed trades. It covers all important behavioral aspects not already encoded in structured data, leaving little ambiguity.
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% with detailed explanations for all four parameters (limit, state, before_id, instrument). The description itself does not discuss parameters, so the schema carries the burden, matching the baseline of 3.
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 lists trades on the configured account, with a specific verb and resource. It also distinguishes from siblings like list_open_trades by implying a broader scope through the return details and field descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing trades generally but does not explicitly mention when to prefer this over siblings like list_open_trades or get_trade. There is no when-not-to-use guidance, though the schema filters (state, instrument) hint at usage scenarios.
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, and the description adds useful context: it explains the 'complete' field semantics (false = still forming), that prices are decimal strings, and the structure per requested price side. This goes beyond the schema and annotations, though it does not cover rate limits or other operational traits.
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 concise and front-loaded: a single, clear purpose sentence followed by an efficient return-format example. Every sentence adds value without 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?
Given the tool's moderate complexity, the description is complete. It details both the request shape (implicitly via schema) and response shape, including field semantics. The presence of an output schema reduces the need to explain return structure, and the description fills the remaining semantic gaps.
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 contains a detailed description of the candle_specifications parameter, including the exact format and allowed values, so schema coverage is 100%. The tool description does not add extra parameter semantics, so baseline 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 opens with 'Get the most recent candle for each requested instrument/granularity', which is a specific verb+resource+scope. It clearly distinguishes from siblings like get_candles by focusing on 'latest' and the per-specification response structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need the latest candle) but does not explicitly state when to use this tool versus alternatives like get_candles. No exclusions or comparisons are provided, so it stops at implied usage rather than clear guidance.
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, so the read-only nature is known. The description adds valuable behavioral context beyond annotations, such as the meaning of pipLocation, the requirement to use displayPrecision for order prices to avoid PRICE_PRECISION errors, and marginRate as leverage. This goes beyond simple return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and then provides a structured, detailed breakdown of the returned fields. Each statement earns its place, though it is longer than necessary for a simple list tool. It is not wasteful, but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not explain return values, but it does so thoroughly with field semantics and practical usage tips. Given the two optional parameters and readOnly annotation, the description is complete enough for an agent to invoke correctly, though it omits edge cases like pagination or error behavior.
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 'limit' and 'instruments'. The description does not add any additional parameter semantics beyond what the schema already provides, so the 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 clearly states 'List instruments tradeable on the configured account', using a specific verb and resource. It distinguishes from sibling tools by focusing on account instruments, not accounts, summaries, or trades.
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 for use: listing tradeable instruments for the configured account. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident given the tool name and sibling context, earning a 4 rather than a 5.
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 include readOnlyHint=true, and the description is consistent. It adds substantial behavioral detail beyond the annotation: exact return structure with lastTransactionID, field-level semantics (signed units, state enum, price as decimal string), and optional bookkeeping fields. This exceeds the minimal read-only disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, followed by a detailed but organized return structure. The field list is lengthy but informative, and each sentence conveys meaningful information without redundancy. It is longer than minimal but appropriately sized for a complex return type.
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 complexity (4 optional parameters, rich return schema, no required inputs), the description is highly complete. It covers the return format, field details, and data conventions (e.g., signed units). The presence of an output schema further reduces the need to explain return values, yet the description goes beyond that.
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?
All four parameters are fully described in the schema (coverage 100%), so the description does not need to add parameter-level details. The description does not specifically elaborate on limit, state, before_id, or instrument beyond what the schema already states, meriting the baseline score.
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 opens with a clear verb and resource: 'List orders on the configured account'. It conveys the scope (account-level) and ordering (most recent first). It also enumerates the order types returned, which distinguishes it from list-related siblings like get_order or list_pending_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to choose this tool versus list_pending_orders or other listing tools. However, by describing return fields that include all order states and a state filter, it implies comprehensive order listing. It stops short of naming alternatives or exclusions.
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?
The description provides extensive details about the return payload, including field semantics (e.g., decimal strings, positive/negative units), trade states, and closed-trade fields. It also notes the account context. This goes well beyond the readOnlyHint annotation, though it does not address error handling or rate limits.
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 moderately long but each sentence provides meaningful details about the output structure and field types. It is well-organized, with the main purpose front-loaded and subsequent information presented as a clear list.
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-trade retrieval tool with one parameter and an output schema, the description is highly complete. It covers the return format, key fields, state values, and special cases like closed trades, making it sufficient for an agent to understand the tool's behavior.
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 trade_specifier parameter with an example and format. The tool description does not add any additional parameter-level details, so it matches the baseline for high 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 retrieves a single trade's details, distinguishing it from list_trades/list_open_trades by explicitly specifying 'single trade'. The verb 'Get' and resource 'details of a single trade' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description focuses on the operation and return format rather than providing context on selecting it over list_trades or list_open_trades. Usage is only implied by the tool's name and the phrase 'single trade'.
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?
Even though the readOnlyHint annotation already signals a safe read operation, the description adds valuable behavioral details: the exact return structure (list of objects with 'id', 'tags', optional 'mt4AccountID') and the significance of the 'id' field. This goes beyond what annotations alone convey.
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 concise (about 4 sentences) and front-loaded with the main verb and resource. The additional details about the return format and ID usage are directly relevant and not redundant, making every sentence earn 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?
Given the tool's simplicity (one optional parameter, simple list return) and the presence of an output schema, the description is complete. It covers purpose, usage context, return format, and even a note about MT4 bridging, making it fully self-contained for an AI agent.
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 only parameter 'limit' is fully described in the input schema (maximum number of accounts, default 50, minimum 1). With 100% schema coverage, the description does not need to add much, and it doesn't—the mention of the output format is helpful but not directly about the parameter.
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 lists accounts authorized for the configured API token, using a specific verb ('List') and resource ('accounts'). It also distinguishes from sibling tools by emphasizing this is the entry point for account identifiers used by other tools, such as 'get_account' or 'list_account_instruments'.
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 implies usage as the first step for any account-related operation by noting the 'id' is the identifier every other tool operates on. It provides clear context but does not explicitly name alternative tools for different scenarios or state when not to use the 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?
Beyond the readOnlyHint annotation, the description defines what 'pending' means, details the exact return structure ({'orders': [...], 'lastTransactionID': '...'}), and lists per-order fields with types (signed decimal string, decimal string, RFC3339). It also mentions attached on-fill details, which is useful behavioral context. It does not contradict the annotation.
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 consists of two focused sentences. The first states the purpose and definition, and the second conveys the return format. Every sentence contributes value with no redundancy or 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?
Given the simple one-parameter interface and the presence of an output schema, the description fully covers what an agent needs to know: the purpose, the meaning of 'pending', and the return structure. It also leverages a sibling reference (list_orders) to avoid repeating field definitions.
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 only parameter (limit) is fully documented in the input schema with type, default, minimum, and description (100% coverage). The description adds no additional parameter semantics beyond the schema, so the 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 opens with a specific verb and resource: 'List every pending (not yet filled or cancelled) order on the account.' It clearly distinguishes from siblings like list_orders by focusing on pending only, and defines 'pending' explicitly (not yet filled or cancelled).
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 clearly implies the intended use case (viewing pending orders) and references list_orders for field structure, which helps an agent relate it to the broader tool. However, it does not explicitly state when to prefer this over list_orders or any exclusions, so it stops short of full explicit guidance.
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, so the description adds value by disclosing return structure details (decimal strings, marginRate format with example, RFC3339 timestamps) and the lightweight nature of the call. This goes beyond the annotation's safety signal without contradicting it.
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 that are front-loaded with the primary purpose and followed by a compact, informative return format explanation. Every sentence earns its place with no redundancy or filler.
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 no parameters, a read-only annotation, and an output schema available, the description is fully self-sufficient. It explains the key output nuance (marginRate as leverage) and the umbrella purpose, leaving no gaps for this simple read-only 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?
There are zero parameters and an empty schema, so the baseline is 4. The description adds no parameter-specific detail, but none is needed; the 'configured account' phrasing implies a single default account, which is a minor semantic addition.
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 a specific verb+resource: 'Get a summary of the configured account'. It distinguishes itself from siblings by explicitly excluding order/trade/position lists and referencing the same summary fields as get_account, making its scope unmistakable.
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 clear when-to-use context ('lightest way to check balance, NAV, and margin headroom') and a when-not-to-use signal ('no order/trade/position lists'). However, it does not explicitly name an alternative tool for those lists, so it falls short of the explicit-alternative standard.
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?
Beyond the readOnlyHint annotation, the description richly discloses behavioral traits such as 'tradeable false outside trading hours or when the market is halted,' null bid/ask when no liquidity, and null spread when either side is missing. It also specifies the time format (RFC3339) and decimal-string representation for prices, which is valuable operational context.
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 opens with a single concise purpose sentence, then a second sentence enumerates the return fields and edge cases. Every sentence earns its place, and the structure is efficient for the complexity of a multi-instrument quote response.
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?
The description completely specifies the output format, including field names, types, formats, and null behaviors. It also covers the tradeable flag logic, making it self-sufficient even without an explicit output schema shown. The single parameter is fully defined in the schema, so the overall context is complete.
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 already covers the parameter fully with a description including format examples ('EUR_USD', 'USD_JPY') and minItems. The tool description adds no new semantic detail beyond the schema, so the baseline score of 3 applies.
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 'Get the current price for one or more instruments,' using a specific verb and resource. It distinguishes itself from historical data tools like get_candles or get_latest_candles by emphasizing 'current price' and providing a detailed return structure unique to real-time quotes.
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 implies usage for retrieving current bid/ask/spread data, with explicit mention of market-hours and liquidity conditions. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.
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?
Beyond the readOnlyHint=true annotation, the description discloses the exact response structure, field types, type-dependent variation, decimal-string representation, signed units semantics, and dropped internal fields. This is substantial behavioral context that goes well beyond the annotation.
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: one summarizing purpose, one detailing response structure, one noting field conventions. Every sentence adds value and the main action is front-loaded.
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 single-parameter read tool, the description fully explains the response format, field behavior, and exclusions. The output schema exists, but the description goes beyond it with type semantics and dropped-field details.
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 already documents transaction_id with a description and 100% coverage. The description doesn't add parameter-specific details beyond what's in the schema, but the schema fully covers it, so baseline 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 opens with 'Get the details of a single transaction', which is a specific verb+resource+scope statement. It clearly distinguishes from siblings like list_transactions and get_transactions_range by emphasizing 'single transaction'.
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 'single transaction' clearly implies this tool is for retrieving one transaction by ID, in contrast to list_transactions or get_transactions_range. It doesn't explicitly name alternatives or exclusions, but the context is sufficiently 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?
Beyond the readOnlyHint annotation, the description provides rich behavioral detail: the exact response structure, field types, decimal string representations, sign conventions for currentUnits, and attached order fields. This goes well beyond what annotations alone convey.
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 compact yet information-dense. The first sentence states the core purpose, and the second sentence efficiently conveys the return shape and field semantics. Every word earns its place, with 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 (one optional parameter, no nested objects), the description fully covers what the tool does, what it returns, and the format of returned values. The presence of an output schema further reduces the need for return-value enumeration, making this description complete.
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 already fully documents the single parameter (limit) with a clear description ('Maximum number of trades to return.'). The tool description adds no additional meaning about the parameter, so the baseline score 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 starts with a specific verb ('List') and resource ('every open trade on the configured account'), clearly distinguishing it from sibling tools like list_trades or list_open_positions. The scope is unambiguous and immediately understandable.
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 tool's purpose is clear from the name and first sentence, implying use when open trades are needed. However, it does not explicitly contrast itself with alternatives like list_trades or mention when not to use it, so it lacks explicit exclusion guidance.
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, so the read-only nature is covered. The description adds valuable behavioral context beyond annotations: it explains that flat positions are retained for lifetime P/L, and details the exact shape of the response with field meanings (e.g., 'units' positive/negative). This exceeds baseline but stops short of disclosing pagination or other potential edge cases, so 4 is appropriate.
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 front-loaded with the core purpose, then the alternative, then a structured breakdown of the return format. Every sentence contributes unique information, and the use of code formatting for the response keys improves skimmability. No extraneous 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 list tool with a nested position structure, the description fully specifies return fields, side semantics, and decimal string conventions. Although an output schema exists, the description's elaboration on field meanings adds practical completeness that makes the tool immediately usable.
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 only parameter 'limit' is fully described in the schema (100% schema description coverage) with type, default, and minimum. The description does not add further parameter nuance, but since the schema covers it completely, the baseline of 3 applies.
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 ('List') and clearly identifies the resource ('every position the account has ever held, one per instrument'). It explicitly distinguishes itself from list_open_positions by stating it includes flat positions, which sets it apart from its sibling.
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 ('List every position... includes flat positions') and when to use an alternative ('use list_open_positions for current exposure only'). This gives direct guidance on tool selection.
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?
Beyond the readOnlyHint annotation, the description richly discloses behavior: maximum 5000 candles, pagination edge cases (setting from_time to exact last time to avoid silent skip, include_first semantics, the excluded candle counting against count), and candle attributes (volume as integer, complete flag semantics, price decimal strings with flattening/nesting). This is substantial value beyond 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 dense but every sentence earns its place. The structure is logical: first sentence states the core action, second paragraph handles parameter constraints and pagination, third covers response format. It is appropriately sized for an 8-parameter tool 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?
Given the tool's complexity, the schema coverage, and the output schema existence, the description is complete. It explains parameter interactions, return fields, and behavioral nuances like silent skips and incomplete candles. There are no critical gaps about how to use or interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage, the description adds significant meaning: the mutual exclusivity of count with both range bounds, the exact pagination behavior of include_first, the distinction between range and count, and the meaning of complete and price component flattening. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch OHLC candles for an instrument' with a specific verb and resource, and elaborates on count/range behavior. However, it does not explicitly distinguish this tool from the closely related sibling get_latest_candles, so it lacks overt 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 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 use count vs. from_time/to_time, including the constraint that count cannot combine with both bounds. It also details pagination strategy, but it does not explicitly mention when to use an alternative like get_latest_candles or list_pricing, so it falls short of full when/when-not guidance.
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?
Beyond the readOnlyHint annotation, the description thoroughly discloses the return structure (changes vs. state with specific fields), the meaning of lastTransactionID, and data formats (RFC3339 timestamps, decimal strings). It also implies potential large responses when omitting the parameter. This adds substantial value beyond the annotation.
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 appropriately sized and well-structured: it opens with the main purpose, then details the return object, explains the polling pattern, and closes with data format notes. Every sentence contributes useful information without 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?
Given the tool's complexity and the presence of an output schema, the description is complete: it specifies the output structure, the incremental polling workflow, and parameter behavior. It fully equips an agent to call the tool correctly without needing additional external context.
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% for the single parameter, and the schema description already explains the semantics. The description adds value by showing the exact usage pattern ('Feed the returned lastTransactionID back as since_transaction_id'), which reinforces the parameter's purpose 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's function: 'Poll the configured account for state changes since a transaction.' It uses a specific verb ('poll') and identifies the resource (account state changes) and the scope (since a transaction). This distinguishes it from siblings like get_account or get_transactions_range, which provide snapshots or transaction lists.
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 operational context: it explains incremental polling by feeding lastTransactionID back as since_transaction_id, and notes that omitting it returns changes since account creation. It does not explicitly state alternatives or when not to use it, but the usage pattern is well-defined relative to the sibling tools.
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?
The description provides rich behavioral details beyond the readOnlyHint annotation: it explains the return structure, decimal string formatting, flat representation, and the HTTP 404 error for untraded instruments. This gives the agent a clear understanding of edge cases and response 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 detailed but every sentence contributes essential information about what the tool returns, how the data is structured, and error behavior. It is well-organized and appropriately sized for the complexity.
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 an output schema present, the description still adds crucial context about data types (decimal strings), sign conventions, and failure modes. The tool is a read-only single-position lookup, and the description covers all necessary behavioral aspects completely.
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 already documents the instrument parameter with an example, and the description adds meaningful behavior: the parameter must refer to an instrument the account has traded, otherwise a 404 is returned. This adds value beyond the raw 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 precisely states 'Get the account's position for one instrument (open or flat)', which is a specific verb+resource+scope. It clearly distinguishes from sibling tools like list_positions by focusing on a single instrument.
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 clearly indicates the tool is for retrieving a single instrument's position and notes the 404 failure when the instrument has never been traded. However, it does not explicitly contrast with alternatives like list_positions or list_open_positions, though the 'one instrument' phrasing implies the distinction.
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?
The description explains key behaviors beyond the readOnlyHint annotation: the return shape (time, price, bucketWidth, buckets), the meaning of longCountPercent/shortCountPercent as decimal strings representing percentages, and the trimming of buckets to at most depth on each side of the current price. This gives the agent a clear understanding of what to expect without relying on the 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?
The description is compact and well-structured: an opening sentence stating the purpose, followed by a clarifying sentence about the relationship to the order book, and a detailed but concise enumeration of the return fields. Every sentence adds value and the content is front-loaded with the main action.
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 moderate complexity and the presence of a full input schema plus an output schema, the description provides all necessary context: the purpose, the distinction from order book, the field semantics, and the depth trimming behavior. It is complete enough for an agent to select and invoke the tool correctly without needing additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema already covers all three parameters with descriptions, the tool description adds semantic nuance: it explains that percent values are decimal strings (e.g., '"0.2543" means 0.2543%'), and that the buckets are trimmed to 'at most depth buckets on each side of the current price.' This enriches the schema's baseline and helps the agent interpret parameter behavior correctly.
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 opens with a specific verb and resource: 'Fetch the aggregate open-position book for an instrument.' It clearly distinguishes itself from the sibling get_order_book by explicitly noting that this is about open positions rather than pending orders, with the same shape but different semantics.
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 implies when to use this tool by contrasting it with the order book ('Same shape as the order book, but each bucket's longCountPercent/shortCountPercent describe open positions... rather than pending orders'). It does not explicitly name an alternative, but the context makes it clear that position data is the focus, differentiating it from order-related tools.
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?
Beyond the readOnlyHint annotation, the description discloses the API quirk that the endpoint returns page links instead of transactions, and details the exact response structure (from, to, pageSize, count, pages, lastTransactionID). It also notes RFC3339 timestamps. This is significant behavioral context that would otherwise be surprising.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph with code formatting, but every sentence carries necessary information about the pagination quirk and response format. It is not overly verbose for the complexity of the endpoint, though it could be slightly more succinct without losing value.
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?
Although an output schema exists, the description provides a thorough explanation of the non-obvious page-link behavior, the workflow for retrieving actual transactions, and timestamp formats. This makes the tool fully understandable and actionable even without inspecting the schema or output schema.
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% and each parameter is well-documented, but the description adds extra value by clarifying how page_size relates to the page URLs (at most page_size transactions per link). This goes slightly beyond the schema's 'Transactions per page link' description, earning a 4.
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 lists transaction pages for a time range, and explicitly distinguishes this endpoint from get_transactions_range by explaining that it returns page links, not the transactions themselves. This is a specific verb+resource with clear 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?
Provides explicit guidance to call get_transactions_range to fetch the actual transactions using the from/to IDs from page URLs. This names a concrete alternative and tells the agent when to use that sibling, which satisfies both when-to-use and next-step 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 provide readOnlyHint=true, and the description adds substantial context beyond that: the return structure, decimal string fields, dropped detail lists, and trimmed nature. It fully discloses what the tool does and does not return, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: the first sentence states the action, the second gives the exact return shape, the third explains field types, the fourth lists exclusions, and the fifth offers an alternative. It is front-loaded and efficiently structured.
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 output schema exists and the tool has no parameters, the description is exceptionally complete. It not only covers what the tool returns but also adds semantic details (decimal strings, home currency, dropped lists) that the schema alone wouldn't convey, leaving no gaps for correct invocation and interpretation.
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 coverage is 100% (vacuously). According to the rubric, 0 params merits a baseline of 4. The description goes beyond the schema by explaining the response semantics, but since there are no input parameters, there is nothing more 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 'Get the full state of the configured account, trimmed to summary level,' specifying the verb, resource, and scope. It distinguishes itself from siblings by explicitly contrasting with get_account_summary and noting that detail lists are dropped.
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 guidance is provided: 'For a cheaper request that yields the same fields, prefer get_account_summary' names the alternative, and 'use the orders, trades, and positions tools for those' tells the user when not to use this tool. This covers both when-to-use and when-not-to-use.
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?
Beyond readOnlyHint=true, the description discloses return shape (transactions array, lastTransactionID), field details (id, time RFC3339, type), decimal string representation for monetary values, signed units, and the 1000-transaction cap. This is rich behavioral context that annotations don't provide.
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 front-loaded with a one-sentence summary, then a focused paragraph that adds usage and return details without repetition. Every sentence earns its place; no 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 read-only tool with an output schema, the description covers usage context, return format, field semantics, limits, and cross-references to related tools. It is complete and self-sufficient for an agent to 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 coverage is 100% with descriptions for all parameters, so baseline is 3. The description adds value by clarifying the inclusive nature of the ID range, the purpose of limit, and the transaction_types filter examples, plus the practical warning about range size.
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 opens with 'Get the transactions in an inclusive ID range,' which is a specific verb+resource+scope. It also distinguishes from siblings by explicitly referencing list_transactions page links and get_transaction for type-specific fields.
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 states when to use: with ID ranges from list_transactions page links or directly when IDs are known. It also gives a practical constraint (keep ranges modest, max 1000 per request) and points to get_transaction for type-specific details.
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:

[![oanda-mcp MCP server](https://glama.ai/mcp/servers/florinel-chis/oanda-mcp/badges/card.svg)](https://glama.ai/mcp/servers/florinel-chis/oanda-mcp)

Score Badge

Copy to your README.md:

[![oanda-mcp MCP server](https://glama.ai/mcp/servers/florinel-chis/oanda-mcp/badges/score.svg)](https://glama.ai/mcp/servers/florinel-chis/oanda-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/florinel-chis/oanda-mcp'

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