fxapi Exchange Rates MCP Server

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

With no annotations, the description carries the full behavioral burden. It discloses the averaging methodology, base-currency conversion order, the 1830-day maximum date span, and that the first and last periods are cut to the requested range. It does not cover authentication, rate limits, or error behavior, but for a read-only data endpoint it is quite transparent.

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?

The description is appropriately sized and front-loads the core averaging behavior before adding constraints. Every sentence adds useful information, though the second paragraph could be slightly tighter.

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 7-parameter tool with no output schema, the description explains the returned concept (period averages with low and high), the grouping period, base-currency semantics, and date-range limits. It does not fully enumerate the response shape, but it provides enough 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 coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by explaining that daily rates are first expressed against base_currency and then averaged, and by adding the maximum 1830-day span between date_from and date_to.

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 states a specific verb and resource: it averages daily rates per calendar period and reports each period's low and high. This is clearly distinct from sibling tools such as getConvert, getFluctuation, and getHistorical.

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?

The description gives a meaningful use case by noting that average rates are what IFRS and US GAAP allow for translating income and expenses. However, it does not explicitly say when to choose this tool over alternatives like getFluctuation or getHistorical, nor does it list exclusions.

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

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

With no annotations, the description carries the full burden. It usefully discloses the plan/auth requirement ('Requires a plan that includes the convert endpoint') and the default of returning all currencies unless filtered. It does not mention rate limits, pagination, or the nature of the returned payload, leaving meaningful behavioral gaps.

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 tight sentences with zero filler, front-loading what the tool does before the plan prerequisite. Every clause earns its place.

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 5-parameter tool with no annotations and no output schema, the description covers purpose and licensing but omits the return shape (e.g., a map of currency→converted value), which is not documented elsewhere. Adequate but with a clear gap given the absent output schema.

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 coverage is 100%, so the schema fully documents date, type, value, currencies, and base_currency. The description reinforces the base-currency default and the all-vs-filtered behavior but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

States a concrete verb and resource: 'Converts a value from the base currency into all (or a filtered set of) currencies.' The scope (today or historical date, filtered currencies) is specific and unambiguous. However, it never names or contrasts with its obvious siblings getHistorical and getLatest, leaving sibling differentiation to inference.

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?

Usage is only implied by 'for today or for a given historical date' and the plan prerequisite. There is no explicit guidance on when to pick getConvert over getLatest/getHistorical, nor exclusions. An agent can infer the conversion purpose but gets no routing help.

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

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

With no annotations, the description carries the full burden, and it discloses the optional filtering and that it returns metadata. However, it says nothing about auth requirements, rate limits, or pagination, and the HTML-vs-JSON behavior is left to the schema rather than the description.

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?

One tightly written sentence that front-loads the resource (all supported currencies) before the optional filter clause. No filler or redundancy.

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 simple read-only listing tool with fully documented parameters and no output schema, the description is nearly sufficient. It could note return shape (JSON list vs HTML table) more explicitly, but nothing critical for calling it correctly is missing.

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 all three parameters (type, as_html, currencies) are already well documented in the schema, establishing a baseline of 3. The description restates the code/type filtering but adds no syntax or format detail beyond the schema.

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?

States a specific verb (returns) and resource (metadata for all supported currencies) with scope (all, optionally filtered). It is clearly a currency-listing tool distinct from conversion/historical siblings, though it never names a sibling to sharpen the boundary.

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?

Usage is implied: use this to enumerate supported currencies, optionally narrowed by code or type. There is no explicit when-to-use vs an alternative, no prerequisites, and no statement of when not to use it.

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

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

With no annotations the description carries the full behavioral burden. It usefully discloses the permissible date window, UTC day semantics, and the exact shape of what comes back (endpoint rates plus absolute and percent change), but it omits failure behavior (e.g. reversed dates), how non-trading days are resolved, and any auth or rate-limit context.

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?

A single tight sentence: the output content leads, followed by the validity window. No filler, no restatement of the name or title.

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 six-parameter read with no output schema, the description compensates by describing the returned fields and their meaning, and by stating the valid date range. It stops short of explaining how base_currency transforms the returned values or what happens on invalid or non-trading dates.

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 coverage is 100% and each of the six parameters is documented inline, so the baseline is 3. The description adds real meaning beyond that by clarifying that date_from/date_to are inclusive endpoint days whose end-of-day rate is used, which the terse schema entries do not convey.

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 gives a specific verb and resource ('returns ... its rate at the end of date_from and of date_to and how much it changed') and even specifies the two output measures, absolute and percent. It implicitly separates itself from getRange/getHistorical by returning only the two endpoint rates plus a delta, but it never names a sibling, so the differentiation is inferred rather than stated.

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?

Usage is only implied: an agent can infer this is the tool for 'how did X move between two dates'. There is no explicit when-to-use, when-not-to-use, or routing to getRange, getAverage, or getHistorical. The date-validity constraint (back to 1999-01-01, newest yesterday) is a boundary, not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two real constraints — data availability back to 1999 and that the date must be at least one day old — which are genuine behavioral traits. It says nothing about permissions, rate limits, or response shape, leaving the safety/operational profile incomplete.

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 short sentences with no filler, and the primary purpose is front-loaded before the constraints. Efficient, though the second sentence could be tightened slightly.

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 4-parameter read tool with fully documented schema and no output schema, the definition covers purpose, data horizon, and the key input validation rule. Reasonably complete; a brief note on the returned structure or default base would close the remaining gap.

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 coverage is 100%, so the schema already documents all four parameters, including formats, defaults, and enums. The description only adds a constraint on `date` (past-day requirement, 1999 floor) and does not touch `type`, `currencies`, or `base_currency`; baseline 3 is appropriate given the schema does the heavy lifting.

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?

States a specific verb and resource ("Returns the exchange rates") with a scoping qualifier ("for a specific date") that implicitly separates it from getLatest and getRange. It never names a sibling explicitly, so the agent must infer the boundary, but the purpose itself is 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?

Usage is only implied by the scope phrase "for a specific date" and the constraint that the date must be in the past. No alternative is named (e.g., use getRange for multi-day spans, getLatest for today), and no exclusions are stated, so the agent gets context but no routing guidance.

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

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

With no annotations provided, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: the data update interval varies by subscription plan (daily to minutely). That is real value, but it omits auth/rate-limit behavior and the shape of the returned payload.

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 sentences, front-loaded with the core purpose, with zero filler. Every clause carries information.

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?

Parameters are well covered by the schema, but with no output schema the description should ideally sketch the return structure (rate map, timestamp). The freshness note is helpful, yet the response format an agent will receive is left undefined.

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 the schema already documents base_currency, currencies, and type thoroughly. The description only restates the USD default for base_currency, adding no new semantic detail; baseline 3 applies.

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?

States a specific verb and resource ('Returns the latest exchange rates') and names the base currency with its default, so the operation is unmistakable. It does not, however, distinguish itself from siblings like getHistorical, getAverage, or getFluctuation, which an agent must infer from the name alone.

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?

There is no explicit when-to-use guidance and no mention of alternatives such as getHistorical or getRange. The subscription-plan note hints at freshness constraints but does not tell the agent when this tool is the right choice over its siblings.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses the required subscription tier, the maximum span and look-back per accuracy, and the CSV emission shape (one row per point and currency with header). It does not mention rate limits, error behavior, or what happens when the span limits are exceeded, which keeps it short of a 5.

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?

The purpose and plan requirement are front-loaded before the bulleted accuracy table, and the bullets are scannable rather than prose. It is somewhat long, but nearly every clause carries a hard constraint an agent needs to construct a valid call.

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 7-parameter, no-output-schema tool there is no schema to fall back on for return values, and the description covers the CSV case in detail while leaving the default JSON structure implicit. Combined with the plan and span constraints, an agent has enough to call correctly, though the JSON response shape is not spelled out.

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 the baseline is 3, and the description adds genuine meaning beyond it: the accuracy enum values are tied to concrete span/look-back constraints on datetime_start and datetime_end, and format=csv is explained in terms of row layout. Only the currencies/type/base_currency semantics remain purely schema-documented.

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 opening sentence gives a precise verb+resource+scope: returns exchange rates for every interval between datetime_start and datetime_end at a chosen accuracy. It is clearly a multi-point series tool, which implicitly separates it from a single-latest or single-conversion tool, but it never names or contrasts with siblings like getHistorical or getLatest, so an agent must infer the boundary.

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 states a real prerequisite ('Requires a plan that includes the range endpoint (medium and up)') and exhaustive per-accuracy span/look-back limits, which govern when a call will succeed. However, there is no guidance on when to choose getRange over getHistorical, getAverage, or getFluctuation — usage is implied by the name and parameter set rather than explained.

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

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

With no annotations provided, the description carries the burden and does disclose one genuinely useful behavioral trait: 'Requests to this endpoint do not count against your quota or rate limit.' That is non-obvious side-effect information an agent could not infer. It does not, however, state the response shape, read-only nature, or any auth requirements.

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 tight sentences with zero filler; the return content is front-loaded and the exemption caveat follows immediately. Every sentence earns its place.

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 zero-parameter, annotation-free tool with no output schema, the description tells the agent what it gets back (monthly and grace quota usage) and the rate-limit behavior. A brief note on the response fields or units would close the remaining gap.

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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly adds no spurious parameter discussion.

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?

States a specific verb ('Returns') and resource ('your current monthly and grace quota usage'), which is unambiguous and clearly distinct from the currency-rate siblings (getConvert, getLatest, getHistorical, etc.). An agent can tell instantly that this is an account-metadata call, not a market-data call.

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?

Usage is implied (check your quota consumption) and the note that the call is exempt from quota/rate limits supports frequent calling, but there is no explicit when-to-use or when-not-to-use guidance. Since the sibling tools serve an entirely different domain, there is no real alternative to route between, so the gap is modest.

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