Skip to main content
Glama
Sign In
Portfolio Analytics MCP

Portfolio Analytics MCP

by RugSec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_fx_rates

Read-only

Retrieve current foreign exchange rates for specified currencies in a chosen base currency, with an optional percentage change since a start date.

Instructions

Latest FX rates into a base currency (and the change since start_date).

Rate = units of base_currency per 1 unit of the currency, e.g. with base
EUR, USD -> 0.92 means 1 USD = 0.92 EUR. Minor units are accepted
("GBp" is converted as GBP / 100).

Args:
    currencies: ISO codes, e.g. ["USD", "GBP", "CHF"].
    base_currency: ISO code to express rates in. Default EUR.
    start_date: Optional YYYY-MM-DD to also return the % change since then.

Returns:
    `base_currency` and per currency `rate` and `date` (plus
    `start_rate` and `change_since_start_pct` with start_date).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "currencies": "<currencies>"
    },
    "name": "get_fx_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
currenciesYes
start_dateNo
base_currencyNoEUR

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description earns credit for adding substance beyond them: the rate direction convention (units of base per 1 unit of currency) with a worked example, minor-unit handling ('GBp' treated as GBP/100), and the exact return fields. It stops short of rate limits, caching, or error behavior, keeping it below 5.

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?

Purpose and the rate formula are front-loaded, followed by compact Args and Returns blocks; every line carries information an agent needs to call or interpret the tool. No filler or repeated text.

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

Completeness5/5

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

With no output schema, the description supplies the return shape (per-currency rate and date, plus start_rate and change_since_start_pct), which is exactly what an agent needs to interpret results. Combined with full parameter coverage, nothing material is missing for this three-parameter read 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?

Schema description coverage is 0%, so the description carries the full burden and does so: it gives ISO-code format and an example for currencies, the ISO-code plus default for base_currency, and the YYYY-MM-DD format plus conditional return impact for start_date. It also clarifies edge semantics like minor-unit conversion that the schema cannot express.

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?

States a specific verb and resource ('Latest FX rates into a base currency') plus the optional historical-delta scope. The FX domain is instantly distinguishable from the equity/ETF-focused sibling tools such as get_quote and get_price_history.

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 'Args' section makes clear that start_date is optional and only needed when a percentage change is wanted, and that base_currency controls the expression of rates. It gives clear usage context but never explicitly excludes cases or names an alternative tool to use instead.

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

Deploy Server

Other Tools