Live fiat currency spot rate and inverse rate for any ISO currency pair (e.g. USD to EUR, USD to GBP). [PAID: $0.015 USDC per call via x402]
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 3-letter ISO target currency (default EUR) | |
| from | No | 3-letter ISO source currency (default USD) |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesPrevious value: -trueNew value: +falseInput schema / properties / fromAdded value: +{
+ "description": "3-letter ISO source currency (default USD)",
+ "type": "string"
+}Input schema / properties / promptRemoved value: -{
- "description": "Input prompt for this service.",
- "type": "string"
-}Input schema / properties / toAdded value: +{
+ "description": "3-letter ISO target currency (default EUR)",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "prompt"
-]New value: +[]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does add real behavioral context by disclosing the paid-call cost and mechanism ($0.015 USDC per call via x402) and stating that both spot and inverse rates are returned. However it omits rate limits, error behavior for invalid currency codes, and rate freshness semantics beyond the word 'live'.
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 tightly written sentence carries the purpose, scope, and an example, with the payment cost appended in a clearly marked bracket. Front-loaded with zero filler; nothing needs trimming.
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 two-optional-parameter tool with no output schema and no annotations, the description covers what it returns (spot and inverse rate) and the non-obvious payment requirement. It is nearly complete, with only edge-case/error behavior left unstated.
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% and both params document their 3-letter ISO format and defaults, so the schema already does the heavy lifting. The description's examples (USD to EUR) illustrate usage but add no format or constraint detail beyond the schema, so the 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+resource: live fiat spot rate and inverse rate for any ISO currency pair, with concrete examples (USD to EUR, USD to GBP). It is clear what it does, but it gives no differentiation from siblings such as liminal-spot-prices, so the agent cannot tell them apart from the description 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?
Usage is only implied by the purpose statement – an agent infers 'call this to get an FX rate' but there is no explicit when-to-use, when-not, or named alternative among the sibling tools. The 'any ISO currency pair' phrasing is the only scoping hint.
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.