Market Intel MCP

Name: Market Intel MCP
Author: datakoot

Server Details

Live & historical FX rates and currency conversion for AI agents. No API keys.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 41 days
Last Tested: 2026-10-18 10:13
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: datakoot/market-intel-mcp
GitHub Stars: 0
Server Listing: Market Intel MCP

TDQS

A4/5.0

Scored 2026-10-15 06:35 across 5 tools

Disambiguation5/5

Each tool targets a distinct FX operation: listing currencies, latest rates, historical single-date rates, time-series rates, and amount conversion. While fx_rates, fx_historical, and fx_timeseries all return rates, their temporal scopes (latest, specific date, range) are clearly differentiated in descriptions, so an agent can easily select the right one.

Naming Consistency5/5

All tool names use a consistent fx_ prefix in snake_case, creating a predictable pattern. Although the suffix varies (verb, noun, adjective), the convention is uniform and readable, with no mixing of styles.

Tool Count5/5

Five tools is well-scoped for a focused FX reference-rate service, covering listing, latest, historical, time-series, and conversion without redundancy. Each tool earns its place.

Completeness4/5

The surface covers core FX workflows: list currencies, fetch current rates, fetch historical rates, fetch ranges, and convert amounts. A minor gap is the lack of historical conversion (fx_convert only uses latest rates), but agents can work around this by combining fx_historical with manual calculation.

Available Tools

5 tools

fx_convertFX ConvertA

Read-onlyIdempotent

Inspect

Convert an amount from one currency to another at the latest ECB reference rate. Returns the rate, the converted result, and the rate date.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Target 3-letter currency
`from`	Yes	Source 3-letter currency
`amount`	Yes	Amount in the 'from' currency to convert. Send it as a number, not a string.

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	No
`date`	No
`from`	No
`rate`	No
`amount`	No
`result`	No
`source`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds the ECB reference-rate source as the authoritative origin of the numbers, which is useful context, but says nothing about rate freshness, unsupported currencies, or error behavior.

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 tight sentences with the core action front-loaded and the return payload summarized afterward; no filler or repetition.

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?

An output schema exists, so return values need not be detailed, and the parameters are fully documented in the schema. The description is complete for a simple conversion call, though a note on currency coverage or rate staleness would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the schema even specifying the numeric-format constraint for amount, so the schema carries the parameter burden. The description adds no syntax or format detail beyond what the schema already provides, making the baseline 3 appropriate.

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?

States a specific verb (Convert) and resource (currency amounts) plus the data source and rate vintage ('latest ECB reference rate'). The word 'latest' implicitly separates it from fx_historical and fx_timeseries, though siblings are never named explicitly.

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?

Usage is only implied: an agent can infer this is for current conversion rather than time-series or rate lookup, but the description never states when to prefer it over fx_rates or fx_historical, nor any prerequisites such as supported currency coverage.

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

fx_currenciesFX CurrenciesA

Read-onlyIdempotent

Inspect

List the currencies supported for exchange-rate lookups, with their full names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of supported currencies
`source`	Yes
`currencies`	Yes	ISO 4217 codes mapped to currency names

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only that full names are included in the result, a modest return-content hint; with an output schema present, little more behavioral disclosure is warranted.

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?

A single front-loaded sentence with no filler; the verb and resource lead, and the result detail trails. Nothing is wasted.

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?

For a zero-parameter enumeration tool with full annotation coverage and an output schema, the description is essentially sufficient. Return format is delegated to the output schema, which is the correct division of labor, though a note on how these currency codes feed into the sibling tools would have closed the loop.

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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The schema cannot add meaning here, and the description correctly does not invent any.

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?

States a specific verb ('List') and resource ('currencies supported for exchange-rate lookups'), which an agent can distinguish from the rate/conversion siblings fx_convert, fx_rates, fx_historical, and fx_timeseries. It stops short of explicitly naming those siblings as alternatives, but the resource 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.

Usage Guidelines3/5

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

The phrase 'supported for exchange-rate lookups' implies this is a discovery/enumeration step before calling the rate tools, but the description never states when to use it versus the siblings or any prerequisites. Usage is inferable rather than stated.

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

fx_historicalFX HistoricalA

Read-onlyIdempotent

Inspect

Get foreign-exchange rates for a base currency on a specific past date (YYYY-MM-DD). ECB publishes rates on business days; a weekend/holiday date returns the most recent prior business day.

ParametersJSON Schema

Name	Required	Description
`base`	No	3-letter base (default USD)
`date`	Yes	The date to look up, YYYY-MM-DD (MM/DD/YYYY is also accepted). Weekends and holidays return the previous business day's ECB rates.
`symbols`	No	Optional comma-separated targets

Output Schema

ParametersJSON Schema

Name	Required	Description
`base`	Yes	ISO 4217 base currency actually used
`date`	Yes	ECB rate date actually used YYYY-MM-DD
`rates`	Yes	Quote currencies mapped to the ECB reference rate
`source`	Yes
`requested_date`	Yes	Caller-requested date YYYY-MM-DD

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld/destructive=false, so the safety profile is handled. The description adds genuinely non-obvious behavior: ECB publishes only on business days and weekend/holiday dates resolve to the most recent prior business day. Return format is not described, but an output schema exists.

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 sentences, zero filler, with the core purpose front-loaded and the ECB business-day caveat second. Every clause earns its place.

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?

A simple read-only lookup with a fully documented schema, rich annotations, and an output schema, so return values need no explanation. The one behavior an agent could get wrong — non-business-day dates — is explicitly addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (base, date, symbols) are already documented, including the default USD and accepted date formats. The description restates the date format and base-currency notion without adding syntax or constraints 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (get), resource (foreign-exchange rates), and scope (a specific past date) — clearly a point-in-time lookup. It implicitly separates itself from fx_rates (current) and fx_timeseries (range) via 'a specific past date', though it never names a sibling explicitly.

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 phrase 'on a specific past date' implies the usage context, and the weekend/holiday note hints at edge-case handling. But there is no explicit when-to-use vs when-not guidance and no named alternative among fx_convert, fx_currencies, fx_rates, or fx_timeseries.

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

fx_ratesFX RatesA

Read-onlyIdempotent

Inspect

Get the latest foreign-exchange rates for a base currency (default USD), optionally limited to specific target currencies. Source: European Central Bank reference rates.

ParametersJSON Schema

Name	Required	Description	Default
`base`	No	3-letter base currency, e.g. USD, EUR (default USD)
`symbols`	No	Optional comma-separated targets, e.g. EUR,GBP,JPY

Output Schema

ParametersJSON Schema

Name	Required	Description
`base`	Yes	ISO 4217 base currency actually used
`date`	Yes	ECB rate date YYYY-MM-DD
`rates`	Yes	Quote currencies mapped to the ECB reference rate
`source`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuine value beyond that by disclosing the data source (ECB reference rates), which tells the agent about provenance and update cadence. It stops short of stating freshness or rate limits.

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 tightly written sentences, front-loaded with the core action and following with the optional narrowing and data source. No filler or redundancy.

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?

For a simple zero-required-parameter read tool with a full schema and an output schema (so return values need not be explained), the description covers purpose, default, filter, and source adequately. Only the absence of routing guidance against the four siblings keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (base, symbols) are fully documented in the schema, including the USD default and comma-separated format. The description restates the same defaults and target-currency concept without adding syntax or constraints beyond the schema.

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?

States a specific verb and resource ('Get the latest foreign-exchange rates') plus scope (base currency, optional targets). 'Latest' implicitly distinguishes it from fx_historical/fx_timeseries, but no sibling is named explicitly, so 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.

Usage Guidelines3/5

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

Usage is implied by 'latest' spot rates and the optional target filter, which contrasts with time-series siblings, but the description never states when to choose this over fx_convert, fx_historical, or fx_timeseries. No explicit alternatives or exclusions are given.

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

fx_timeseriesFX TimeseriesA

Read-onlyIdempotent

Inspect

Get a time series of exchange rates for a base currency over a date range (max ~1 year), useful for trend analysis. Provide start and end as YYYY-MM-DD and one or more target currencies.

ParametersJSON Schema

Name	Required	Description
`end`	Yes	End date, YYYY-MM-DD (MM/DD/YYYY is also accepted).
`base`	No	3-letter base (default USD)
`start`	Yes	Start date, YYYY-MM-DD (MM/DD/YYYY is also accepted). Range up to about one year.
`symbols`	Yes	Comma-separated targets, e.g. EUR,GBP

Output Schema

ParametersJSON Schema

Name	Required	Description
`base`	No
`rates`	No
`source`	No
`end_date`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`start_date`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral fact is the ~1-year range ceiling, which is already repeated in the schema's 'start' description, so marginal new context; no rate limits, auth needs, or data-freshness caveats are disclosed.

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?

A single tight sentence with the core action and its scope front-loaded, followed by the input-format reminder. Nothing is wasted, though it is slightly dense and could split the format guidance.

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?

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers scope, date format, range limit, and multi-target input, leaving only the sibling-routing question unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. The description restates the YYYY-MM-DD format and that one or more target currencies are expected, but adds no syntax or constraint detail beyond what the schema already documents for start, end, base, and symbols.

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?

States a specific verb and resource ('Get a time series of exchange rates') plus scope (base currency, date range, max ~1 year) and a purpose hint (trend analysis). This is clear, but it never differentiates itself from near-siblings like fx_historical or fx_rates, which likely also return rate data over dates.

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?

'useful for trend analysis' implies the use case, but the description never says when to pick this over fx_historical, fx_rates, or fx_convert. Usage is inferable rather than stated, and no exclusions or prerequisites are given.

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.

2 tool updatesOct 8, 2026

Changedfx_convert1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedfx_timeseries1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

3 tool updatesOct 3, 2026

Changedfx_convert1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "amount": {},
+    "date": {},
+    "from": {},
+    "rate": {},
+    "result": {},
+    "source": {},
+    "to": {}
+  },
+  "type": "object"
+}

Changedfx_historical1 field changed

changedInput schema / properties / date / description

Previous value: -"YYYY-MM-DD"New value: +"The date to look up, YYYY-MM-DD (MM/DD/YYYY is also accepted). Weekends and holidays return the previous business day's ECB rates."

Changedfx_timeseries3 fields changed

changedInput schema / properties / end / description

Previous value: -"YYYY-MM-DD"New value: +"End date, YYYY-MM-DD (MM/DD/YYYY is also accepted)."

changedInput schema / properties / start / description

Previous value: -"YYYY-MM-DD"New value: +"Start date, YYYY-MM-DD (MM/DD/YYYY is also accepted). Range up to about one year."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "base": {},
+    "end_date": {},
+    "rates": {},
+    "source": {},
+    "start_date": {}
+  },
+  "type": "object"
+}

3 tool updatesSep 7, 2026

Changedfx_currencies1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of supported currencies",
+      "type": "integer"
+    },
+    "currencies": {
+      "additionalProperties": {
+        "maxLength": 128,
+        "minLength": 1,
+        "type": "string"
+      },
+      "description": "ISO 4217 codes mapped to currency names",
+      "maxProperties": 256,
+      "minProperties": 1,
+      "propertyNames": {
+        "pattern": "^[A-Z]{3}$"
+      },
+      "type": "object"
+    },
+    "source": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "count",
+    "currencies",
+    "source"
+  ],
+  "type": "object"
+}

Changedfx_historical1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "base": {
+      "description": "ISO 4217 base currency actually used",
+      "pattern": "^[A-Z]{3}$",
+      "type": "string"
+    },
+    "date": {
+      "description": "ECB rate date actually used YYYY-MM-DD",
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    "rates": {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "description": "Quote currencies mapped to the ECB reference rate",
+      "maxProperties": 256,
+      "minProperties": 1,
+      "propertyNames": {
+        "pattern": "^[A-Z]{3}$"
+      },
+      "type": "object"
+    },
+    "requested_date": {
+      "description": "Caller-requested date YYYY-MM-DD",
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "base",
+    "date",
+    "requested_date",
+    "rates",
+    "source"
+  ],
+  "type": "object"
+}

Changedfx_rates1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "base": {
+      "description": "ISO 4217 base currency actually used",
+      "pattern": "^[A-Z]{3}$",
+      "type": "string"
+    },
+    "date": {
+      "description": "ECB rate date YYYY-MM-DD",
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    "rates": {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "description": "Quote currencies mapped to the ECB reference rate",
+      "maxProperties": 256,
+      "minProperties": 1,
+      "propertyNames": {
+        "pattern": "^[A-Z]{3}$"
+      },
+      "type": "object"
+    },
+    "source": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "base",
+    "date",
+    "rates",
+    "source"
+  ],
+  "type": "object"
+}

5 tool updatesSep 6, 2026
- First observedfx_convert
- First observedfx_currencies
- First observedfx_historical
- First observedfx_rates
- First observedfx_timeseries

Related MCP Connectors

Market Intel MCP A
io.github.selflabbs
Live & historical FX rates and currency conversion for AI agents. No API keys.
Finance Cryptocurrency
2
AllRatesToday exchange rates (hosted)A
com.allratestoday
Live FX + official central-bank rates, 110+ sources. Hosted, keyless, nothing to install.
Finance Open Data
1114
Frankfurter A
io.github.lineofflight
Convert currencies and fetch blended FX rates from 50+ institutional sources.
Finance Open Data
424
Unit & Currency Converter A
io.github.guptaprakhariitr
60+ units, live FX, timezones, and date arithmetic for AI agents.
Finance Location Services
621

Related MCP Servers

UniRate MCPofficial
Finance
UniRate-API
A
license
A
quality
C
maintenance
Currency conversion and exchange rates for AI assistants. 170+ currencies, historical data back to 1999.
Updated a month ago (2026-09-19 04:30 UTC)
4
36 npm
MIT
@exchangerateapi/mcp-serverofficial
Finance Open Data
Exchange-RateAPI
A
license
A
quality
B
maintenance
Enables AI coding tools to access real-time and historical currency exchange rates for 160+ currencies, sourced from Reuters/Refinitiv.
Updated 17 days ago (2026-10-01 15:39 UTC)
4
26 npm
MIT
Realtime Exchange Rate MCP
Finance
AllRates-Today
A
license
A
quality
A
maintenance
Provides real-time foreign-exchange rates, historical data, and multi-currency lookups to MCP-compatible AI coding assistants like Claude Code and Cursor.
Updated 2 days ago (2026-10-16 21:38 UTC)
4
515 npm
MIT
Ratevertofficial
Finance Cryptocurrency
ratevert
A
license
Not graded
quality
B
maintenance
Enables searching and converting currencies, stocks, crypto, ETFs, and funds with current rates and source freshness for AI agents.
Updated 11 days ago (2026-10-07 19:35 UTC)
3
MIT