Skip to main content
Glama
florinel-chis

oanda-mcp

get_account

Read-only

Retrieve a summary of your trading account's full state, including balance, margin, and open trade counts, for a quick health check.

Instructions

Get the full state of the configured account, trimmed to summary level.

Returns {"account": {...}, "lastTransactionID": "..."}. The account object carries monetary fields as decimal strings in the account's home currency (balance, NAV, pl, unrealizedPL, marginUsed, marginAvailable, ...), the leverage setting marginRate (decimal string, e.g. "0.02" = 50:1), the open-item counts (openTradeCount, openPositionCount, pendingOrderCount), and createdTime as an RFC3339 timestamp. The per-order/trade/position detail lists the API embeds here are dropped; use the orders, trades, and positions tools for those. For a cheaper request that yields the same fields, prefer get_account_summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

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.

Install Server

Other Tools

Latest Blog Posts

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