get_fx_ratesFX exchange rates for 30+ currencies (ECB reference rates via Frankfurter, updated each business day). Optional base currency (default USD) and comma-separated symbols (e.g. 'EUR,GBP,JPY'). Free public data.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency, default USD | |
| symbols | No | Optional comma-separated quote currencies |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the data source, update frequency, and free access, which sets expectations about data freshness and API limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, information-dense sentences front-load the core purpose and then cover parameters and data source. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with zero required parameters, a 100% documented schema, and no output schema, the description provides all essential context: data source, update schedule, defaults, and parameter format. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description repeats the base default and adds an example for symbols, but does not materially extend the schema's meaning. It adds marginal clarity but no substantive new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (FX exchange rates for 30+ currencies) and its scope, distinguishing it from siblings like get_price or get_perp_prices by naming the currency domain. Although it lacks an explicit verb, the tool name and title supply 'Get', and the meaning is completely unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context—ECB reference rates via Frankurter, updated each business day, free data—which implicitly signals when to use it, but it does not name any alternatives or state when-not-to-use conditions. An agent must infer that other pricing tools cover different asset classes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a distinct data domain: FX rates, perpetual futures, portfolio summary, open positions, prediction markets, and general prices. There is minor potential overlap between get_price and get_perp_prices for crypto assets, but the distinction between spot/current price and perpetual futures is clear enough.
All tool names follow a consistent get_<resource> pattern in snake_case. Some resources are plural and some singular, but that is natural given the noun being fetched, so the naming is predictable and uniform.
Six tools is a well-scoped set for a market data and portfolio monitoring server. Each tool provides a distinct, useful capability without unnecessary bloat or an overly thin surface.
The server exposes only getter operations: no order placement, cancellation, position closing, or historical account activity. Given the broker/paper trading context implied by the server name and portfolio tools, the lack of any trading lifecycle actions is a significant gap.