What can you do with this server?

This is a read-only MCP server for the OANDA v20 REST API, allowing you to retrieve forex market data and account information without placing or managing trades. * Get current prices (get_price): Fetch real-time bid/ask rates for one or more currency pairs (e.g., USD_JPY, EUR_USD, GBP_JPY) * Get candlestick/OHLC data (get_candles): Retrieve historical candlestick data with customizable granularity (5-second to monthly), up to 5,000 candles, with optional time range filtering and mid/bid/ask price selection * Get account summary (get_account_summary): View account balance, unrealized P&L, margin usage, open trade/position counts, currency, and net asset value (NAV) * Get open positions (get_open_positions): List all currently held positions with units, average entry price, and unrealized P&L per instrument * Get pending orders (get_pending_orders): View all unfilled/pending orders on the account * Get open trades (get_open_trades): List all open trades with entry price, position size, and unrealized P&L * Get recent transactions (get_recent_transactions): Retrieve recent account transaction history (fills, orders, funding, etc.) with optional type filtering (e.g., ORDER_FILL, MARKET_ORDER) * List tradeable instruments (list_instruments): Browse all instruments available to your account, with optional filtering by specific symbols

How do I use oanda-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@oanda-mcp what is the current price of USD_JPY?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

oanda-mcp

by aobathree

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

oanda-mcp

OANDA v20 REST API の 参照系(read-only) 機能を Claude から使えるようにする MCP サーバーです。発注・決済などの取引系ツールは含まれていません(安全のため、まず参照系のみ)。

提供ツール

ツール	内容
`get_price`	現在のBid/Askレート取得(複数通貨ペア可)
`get_candles`	ローソク足(履歴)取得。S5〜月足、最大5000本
`get_account_summary`	口座サマリー(残高・評価損益・証拠金など)
`get_open_positions`	保有ポジション一覧
`get_pending_orders`	未約定注文一覧
`get_open_trades`	オープントレード一覧
`get_recent_transactions`	直近の取引履歴(トランザクション)
`list_instruments`	取引可能な銘柄一覧

通貨ペアは OANDA 形式(USD_JPY, EUR_USD など)で指定します。

Related MCP server: bitvavo-mcp

1. OANDA側の準備(デモ口座)

OANDA fxTrade Practice(デモ口座) を開設
ログイン後、Manage API Access(My Account → Manage API Access)でパーソナルアクセストークンを生成
アカウントID(101-001-1234567-001 のような形式)を控える

2. インストール

Python 3.10 以上が必要です。

Windows

cd D:\oanda-mcp
pip install -e .

macOS

macOS標準の python3 は 3.9 のことがあり(その場合インストールが requires a different Python エラーで失敗します)、システムへの直接インストールも制限されているため、Homebrewで新しいPythonを入れて venv(仮想環境)を使います:

brew install python
cd ~/oanda-mcp
python3.13 -m venv .venv        # brewで入ったバージョンに合わせる(python3.12等)
source .venv/bin/activate
pip install -e .

補足: venvのpipが古いと pyproject.toml のみのプロジェクトを editableインストールできません(PEP 660はpip 21.3以降)。その場合は pip install -U pip してから再実行してください。新しいPythonで venvを作っていれば通常は問題になりません。

3. 認証情報の設定(.env)

.env ファイルはプロジェクトの外、ホームディレクトリ配下 (Windows: %USERPROFILE%\.oanda\.env、macOS/Linux: ~/.oanda/.env)に置きます(サーバー起動時に自動で読み込まれます。環境変数の設定は不要です):

Windows:

New-Item -ItemType Directory -Force $env:USERPROFILE\.oanda | Out-Null
copy .env.example $env:USERPROFILE\.oanda\.env
notepad $env:USERPROFILE\.oanda\.env

macOS/Linux:

mkdir -p ~/.oanda
cp .env.example ~/.oanda/.env
open -e ~/.oanda/.env   # または任意のエディタで開く

エディタが開いたら自分の値に書き換えます:

OANDA_API_TOKEN=あなたのトークン
OANDA_ACCOUNT_ID=101-001-1234567-001
OANDA_ENV=practice

プロジェクト直下に .env を置かない理由: このフォルダーで Claude Code などのコーディングエージェントを使うと、ワークスペース内のファイルとして認証情報が読める状態になるためです(Webull 公式 MCP サーバーのセキュリティ指針に倣った配置です)。.gitignore では引き続き .env を除外していますが、これは誤ってプロジェクト内に置いてしまった場合の保険です。

.env の検索順は「OANDA_DOTENV で明示指定したパス → ホームの .oanda/.env → カレントディレクトリとその親 → プロジェクトルート」です。読み込まれるのは OANDA_ で始まるキーだけで(HTTPS_PROXY などの通信系キーは無視されます)、 OANDA_ キーを1つも含まないファイルはスキップして次の候補へ進みます。同名の環境変数が既に設定されている場合はそちらが優先されます。

4. 動作確認(MCP Inspector)

# Windows
npx @modelcontextprotocol/inspector oanda-mcp

# macOS(venvの実行ファイルを指定)
cd ~/oanda-mcp
npx @modelcontextprotocol/inspector .venv/bin/oanda-mcp

(.env はホームの .oanda/.env から自動で読み込まれるため、どのディレクトリから起動しても構いません)

ブラウザで Inspector が開いたら:

Arguments欄は空のまま、Connect をクリック(左下が緑の「Connected」になる)
上部の Tools タブ → List Tools で8ツールが表示される
get_price を選び、instruments に USD_JPY を入力して Run Tool
現在のbid/askがJSONで返れば成功

5. Claude Desktop への登録

設定ファイルの場所:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

command には oanda-mcp 実行ファイルのフルパスを指定してください。 Claude Desktop はターミナルと同じ PATH を引き継がないため、コマンド名だけでは起動に失敗することがあります。フルパスは Windows なら PowerShell で確認できます:

(Get-Command oanda-mcp).Source
# 例: C:\Users\<ユーザー名>\AppData\Local\Programs\Python\Python311\Scripts\oanda-mcp.exe

Windows(JSON内の \ は \\ にエスケープ):

{
  "mcpServers": {
    "oanda": {
      "command": "C:\\Users\\<ユーザー名>\\AppData\\Local\\Programs\\Python\\Python311\\Scripts\\oanda-mcp.exe"
    }
  }
}

macOS(venv内の実行ファイルをフルパスで指定。activateは使えないためフルパス指定が必須です):

{
  "mcpServers": {
    "oanda": {
      "command": "/Users/<ユーザー名>/oanda-mcp/.venv/bin/oanda-mcp"
    }
  }
}

.env はホームの .oanda/.env から自動で読み込まれるため、env ブロックは不要です。別の場所に置いた場合のみ、env ブロックで OANDA_DOTENV にそのパスを指定してください。

既に他の設定(preferences など)があるファイルの場合、mcpServers は最上位(一番外側の {} の直下)に、既存ブロックとカンマで区切って追加します。保存前に python3 -m json.tool <設定ファイル> で構文チェックすると安全です。

保存後、Claude Desktop を完全に再起動(タスクトレイのアイコンからも終了)すると「oanda」サーバーが認識されます。「ドル円の今のレートは?」のように話しかければツールが呼ばれます。

6. Claude Code への登録(任意)

claude mcp add oanda -- oanda-mcp

Claude Code はターミナルから起動するため、こちらはコマンド名のままで動きます (動かない場合はフルパスを指定してください)。

どのプロジェクトからでも使う(user スコープ + フルパス)

上のコマンドはデフォルトの local スコープ(実行したプロジェクト限定)で登録されます。どのプロジェクトからでも使いたい場合は --scope user を付けます。また、デスクトップアプリ版など PATH を引き継がない環境でも確実に起動するよう、command には実行ファイルのフルパスを指定するのが安全です:

# フルパスを確認
(Get-Command oanda-mcp).Source
# 例: C:\Users\<ユーザー名>\...\Python313\Scripts\oanda-mcp.exe

# user スコープでフルパス登録
claude mcp add --scope user oanda -- "<上で確認したフルパス>"

登録後は接続状態を確認できます:

claude mcp list
# oanda: ...\oanda-mcp.exe - √ Connected と表示されれば成功

設定は %USERPROFILE%\.claude.json に保存されます。なお、Microsoft Store 版 Python を使っている場合、Python のバージョンアップで Scripts フォルダーのパスが変わるため、その際は claude mcp add を再実行してください。起動中の Claude Code セッションには途中から追加したサーバーは反映されません。新しいセッションを開くとツールが使えるようになります。

7. 環境変数リファレンス

通常はホームの .oanda/.env に書くだけで足ります。

変数	必須	説明
`OANDA_API_TOKEN`	✔	パーソナルアクセストークン
`OANDA_ACCOUNT_ID`	✔	口座ID
`OANDA_ENV`	-	`practice`(デフォルト)/ `live`
`OANDA_DOTENV`	-	読み込む `.env` ファイルのパスを明示指定

テスト

2層構成です(公式 Alpaca MCP サーバーのテスト戦略に倣ったもの):

python tests\test_server.py        # ユニット: モックのみ、認証情報・ネットワーク不要
python tests\test_integration.py   # 統合: practice口座の実APIに read-only GET で接続

統合テストは .env に実際の認証情報がないとき、および OANDA_ENV=live のときは自動的にスキップされます(安全のため live 口座では実行されません)。

なお、API リクエストには User-Agent: oanda-mcp/<version> が付与されます。

注意事項

トークンは口座への広い権限を持ちます。.env はプロジェクトの外 (ホームの .oanda/.env)に置き、リポジトリにコミットしたりチャットに貼り付けたりしないでください。
OANDA_ENV=live にすると本番口座のデータを参照します(このサーバーは参照のみなので発注はできませんが、口座情報は実データになります)。
OANDA証券(日本)の口座でAPIを使う場合は、口座コースごとのAPI利用条件を事前に確認してください。

今後の拡張(取引系を足す場合)

client.py に POST/PUT 系メソッド(/orders, /trades/{id}/close など)を追加し、server.py にツールを足すだけで拡張できます。その際は最大ロット数の上限チェックや、OANDA_ENV=live 時は発注を拒否するガードを入れることを強く推奨します。

Available Tools

8 tools

get_account_summaryA

Get the account summary: balance, unrealized P/L, margin usage, open trade/position counts, currency, and NAV.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lists what data is returned but does not disclose behavioral traits like read-only nature, latency, or error conditions. Since no annotations are present, the description carries the burden but is sufficient for a simple read operation.

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 a single, well-structured sentence that front-loads the purpose and lists key fields. No extraneous information.

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 no parameters and an output schema, the description adequately covers the tool's purpose and output. It is complete for the agent to understand what it returns.

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 schema coverage is 100%. The description adds value by enumerating the returned fields, which is helpful beyond the schema's structure.

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 retrieves an account summary, listing specific fields like balance, unrealized P/L, margin usage, etc. This distinguishes it from sibling tools such as get_open_positions or get_candles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., get_open_positions for positions only). No context on prerequisites or scenarios is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_candlesA

Get historical candlestick data for an instrument.

Args: instrument: OANDA instrument name, e.g. "USD_JPY". granularity: Candle size: S5,S10,S15,S30,M1,M2,M4,M5,M10,M15,M30, H1,H2,H3,H4,H6,H8,H12,D,W,M. Default "H1". count: Number of candles (max 5000). Ignored when both from_time and to_time are given. Default 100. price: "M" (mid), "B" (bid), "A" (ask), or combinations like "MBA". from_time: RFC3339 start time, e.g. "2026-07-01T00:00:00Z" (optional). to_time: RFC3339 end time (optional).

ParametersJSON Schema

Name	Required	Default
`count`	No
`price`	No	M
`to_time`	No
`from_time`	No
`instrument`	Yes
`granularity`	No	H1

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains parameter behavior but does not disclose whether the tool is read-only, any authorization needs, rate limits, or side effects. The read-only nature is implied but not stated.

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 structured as a clear docstring with Args. It is appropriately detailed without extraneous information. Each sentence adds value, though the format is slightly 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?

Given 6 parameters and an existing output schema, the description covers all parameter semantics and behavior (e.g., count vs time interaction). It does not need to explain output due to schema. Missing behavioral details are scored elsewhere.

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?

Schema coverage is 0%, so the description adds all meaning. It provides clear explanations for all 6 parameters: instrument format, granularity options, count limit and interaction, price options, and RFC3339 time format. This significantly aids correct 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 'Get historical candlestick data for an instrument.' It uses a specific verb and resource, and the context of sibling tools (like get_price for current price, list_instruments for listing) distinguishes it effectively.

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 explains parameter defaults and behavior (e.g., count ignored when from/to given), but does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool name and sibling contexts, but no direct guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_open_positionsA

List all currently open positions with units, average price, and unrealized P/L per instrument.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description indicates a read operation but does not elaborate on rate limits, authentication requirements, or data freshness. Adequate but minimal for a no-annotation tool.

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?

Single sentence, front-loaded with the key verb and resource, no unnecessary words. Highly 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?

Given no parameters and presence of output schema, the description covers the tool's purpose but could mention scope (e.g., current account vs. all accounts). Minor gap.

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?

No parameters exist, so baseline is 4. The description does not need to add parameter info as schema coverage is 100% with zero parameters.

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 open positions with specific fields (units, average price, unrealized P/L), and it distinguishes from sibling tools like get_open_trades by focusing on positions rather than trades.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like get_open_trades or get_account_summary. Does not specify scope (e.g., all accounts or current account) or exclude scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_open_tradesA

List all open trades with entry price, units, and unrealized P/L.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully convey the tool's behavior. It correctly indicates a read-only list operation, but does not explicitly mention that it is non-destructive or what changes might occur. The description is adequate but not rich in behavioral detail.

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 a single, well-structured sentence that efficiently conveys the tool's purpose. No unnecessary words.

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?

Given the absence of parameters and the presence of an output schema, the description provides essential information about the return data. It is complete for the simplicity of the tool, though it could mention that no filtering is possible.

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?

With zero parameters, the schema fully covers all inputs. The description adds value by specifying the returned fields, but this is beyond parameter semantics. Baseline 4 applies.

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 the action (list) and the resource (open trades) along with specific data fields (entry price, units, unrealized P/L), making its purpose immediately understandable. However, it does not differentiate from the sibling tool get_open_positions, which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_open_positions or get_pending_orders. The description simply states what it does without context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pending_ordersA

List all pending (not yet filled) orders on the account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description is minimal and only states a read operation. It does not disclose any potential behavioral traits like rate limits or pagination, but the operation is straightforward.

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?

Single sentence front-loads the action and resource, with no wasted words. Perfectly concise.

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 zero parameters and the presence of an output schema, the description is complete. It explains the tool's purpose adequately.

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?

Zero parameters, so baseline score of 4 applies. The description correctly implies no inputs 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?

Description clearly states the verb 'list', the resource 'pending orders', and specifies 'not yet filled' and 'on the account', distinguishing it from siblings like get_open_positions or get_open_trades.

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?

No explicit guidance on when to use this tool vs alternatives such as get_open_positions or get_open_trades, though the name and description imply its specific use for unfilled orders.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_priceA

Get current bid/ask prices for one or more instruments.

Args: instruments: Comma-separated OANDA instrument names, e.g. "USD_JPY" or "USD_JPY,EUR_USD,GBP_JPY".

ParametersJSON Schema

Name	Required	Description	Default
`instruments`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden. It only states 'current bid/ask prices' but does not disclose traits like data freshness, authentication requirements, rate limits, or behavior when an instrument is invalid. This is minimal.

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 very short: a single line plus a concise docstring. Every sentence adds value, and the essential details are front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, output schema exists), the description covers purpose and parameter format. However, it lacks usage guidance and behavioral context, which are gaps for a minimal viable description.

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?

Although schema description coverage is 0%, the description includes a docstring explaining the parameter format: comma-separated OANDA instrument names with examples. This adds significant meaning beyond the schema's type and title.

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 explicitly states it retrieves current bid/ask prices for instruments. The verb 'Get' and resource 'bid/ask prices' are specific. It distinguishes from siblings like get_candles (historical OHLC) and list_instruments (available instruments).

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 when current prices are needed, but does not explicitly state when to use or not use this tool versus alternatives like get_candles for historical data. No exclusions or context are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_transactionsA

Get the most recent account transactions (fills, orders, funding...).

Args: count: How many recent transactions to return (default 50). type_filter: Optional comma-separated transaction type filter, e.g. "ORDER_FILL" or "MARKET_ORDER,ORDER_FILL".

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`type_filter`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description should disclose behavioral traits. It states 'Get' implying a read-only operation, but it does not explicitly confirm no side effects, nor does it mention authentication needs, rate limits, or the scope (e.g., current user's account). The parameter feedback is present but behavioral transparency beyond parameters is lacking.

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: one sentence for the purpose and two bullet-style parameter docs. It is front-loaded with the core action and has no unnecessary words. However, a more structured format (e.g., using headings) could improve scanability, but it is already efficient.

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?

Given the presence of an output schema (implied but not shown) and simple parameters (0 required, no nested objects), the description covers the essential aspects: what is returned (recent transactions) and how to filter. It does not specify the time window for 'recent' or any limits on count, but overall it is sufficient for a basic 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 description coverage is 0%, so the description bears the full burden. It explains count as 'how many recent transactions to return (default 50)' and type_filter as 'Optional comma-separated transaction type filter' with examples. This adds significant meaning beyond the schema, though it could be improved by listing valid transaction types or defining 'recent'.

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 most recent account transactions' and lists examples like 'fills, orders, funding...'. This is a specific verb+resource combination that distinguishes it from siblings such as get_account_summary, get_open_positions, and get_pending_orders, which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the alternatives. Sibling tools like get_open_trades or get_pending_orders have overlapping functionality, but no comparison or exclusions are mentioned. The context signals show many related tools, yet the description fails to clarify the use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_instrumentsA

List tradeable instruments available to the account.

Args: names: Optional comma-separated filter, e.g. "USD_JPY,EUR_USD". Omit to list everything.

ParametersJSON Schema

Name	Required	Description	Default
`names`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the tool lists instruments and the filter behavior but does not mention side effects, authentication, rate limits, or read-only nature. Basic transparency, 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?

Two concise sentences, front-loaded with the main purpose. No unnecessary words. Every sentence adds 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?

For a simple tool with one optional parameter and an existing output schema, the description is complete. It covers what the tool does and how to filter, leaving return format to the output schema.

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?

The schema has 0% description coverage, but the description fully explains the 'names' parameter: optional comma-separated filter with example and default behavior (omit to list everything). This adds significant meaning 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 lists tradeable instruments available to the account, with a specific verb and resource. It distinguishes from sibling tools like get_candles or get_price by focusing on the list of available instruments.

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 by stating the optional filter for comma-separated names and that omitting it lists everything. However, it does not explicitly guide when to use this tool versus alternatives or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jul 14, 2026
- First observedget_account_summary
- First observedget_candles
- First observedget_open_positions
- First observedget_open_trades
- First observedget_pending_orders
- First observedget_price
- First observedget_recent_transactions
- First observedlist_instruments

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct aspect of OANDA account data: account summary, historical candles, open positions, open trades, pending orders, current prices, recent transactions, and instrument list. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern with 'get_' or 'list_' as the verb. The naming is uniform and predictable, making it easy for agents to understand the action and resource.

Tool Count5/5

8 tools is an appropriate count for a trading data server. It covers the essential read operations without being overwhelming or too sparse.

Completeness2/5

The tool set is entirely read-only, missing all write operations such as creating orders, modifying orders, canceling orders, or closing trades. For a trading server, this is a significant gap that limits agent capabilities to data retrieval only.

Maintenance

ActivitySlowing

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

BankBridgeOAuth
money.bankbridge
Read-only bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Finance Databases
2
AttachéOAuth
studio.attache
GA4, Google Ads and Search Console in Claude. Read-only OAuth, multi-account for agencies.
1
Banco MCP A
io.github.douglac
Brazilian Open Finance MCP — 30+ banks (Itaú, Nubank, etc.) to Claude/Cursor. Read-only.
Finance Open Data
19220
Era ContextOAuth
app.era
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Finance Knowledge & Memory
1

Related MCP Servers

Market Pulse MCP
Cryptocurrency Finance
decksaga
A
license
A
quality
F
maintenance
Enables Claude to access real-time crypto prices, forex rates, and market sentiment data through free public APIs with no keys required.
Updated 4 months ago (2026-05-18 15:55 UTC)
5
3
MIT
bitvavo-mcp
Cryptocurrency Finance
aderik
A
license
A
quality
C
maintenance
Exposes a Bitvavo crypto exchange account as read-only tools for Claude, allowing portfolio queries, trade history, and market data without enabling trading.
Updated 4 months ago (2026-05-14 08:58 UTC)
2
14
17
MIT
HTS MetaTrader5 Trading MCP
Finance
Yumin-Kim
F
license
A
quality
D
maintenance
Enables Claude AI to perform forex trading operations and market data analysis through MetaTrader 5, including order placement, position management, and multi-timeframe candle data retrieval.
Updated 5 months ago (2026-04-03 06:15 UTC)
16
-
Binance MCP Server
Cryptocurrency Finance
Lubodi-Code
A
license
A
quality
C
maintenance
Enables Claude to query Binance Spot market data, account balances, and execute trades via natural language, with withdrawals disabled by default for security.
Updated 3 months ago (2026-06-22 06:01 UTC)
11
MIT

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/aobathree/oanda-mcp'

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