CCXT vs Camt053 MCP
A side-by-side look at the CCXT and Camt053 MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose CCXT for finance & fintech work; choose Camt053 MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose CCXT when
- You need dedicated capabilities in the Finance & Fintech domain.
- You want tools like
list_exchanges, describe_exchange, describe_method.
Choose Camt053 MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
list_message_types, list_return_reasons, get_required_fields.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 64/100 · Good | 61/100 · Good |
| Install command | Not confirmed yet | Confirmed |
| Transport | — | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 44,480 | 2 |
| Directory activity | 2 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 32 | 24 |
| Full listing | View CCXT | View Camt053 MCP |
Tools & capabilities
CCXT tools 32
list_exchangesList every exchange this server supports (built from ccxt.exchanges at runtime), with name, websocket and prediction-market availability. Filter by a name query or by support for a unified method.describe_exchangeOne exchange's supported unified methods, market types, timeframes, required credential fields, sandbox availability and documentation URLs. Per-method detail lives in describe_method.describe_methodSearch unified method names by keyword, or get one method's signature and parameter documentation. With "exchange" it adds that exchange's own docs (including supported params.* keys and links to the exchange API reference), per-market-type feature support, and searches its implicit (exchange-specific) endpoints too. Full ccxt manual: https://docs.ccxt.com/search_marketsSearch and filter the markets of one exchange (by text, base, quote, settle currency, market type), paginated. Use this to resolve unified symbols — there is deliberately no list-all-markets tool. On prediction exchanges use search_events instead.get_tickers24h price tickers for one or more unified symbols on an exchange (outcome handles on prediction exchanges).get_orderbookCurrent order book (bids and asks) for one unified symbol.get_ohlcvHistorical OHLCV candlestick data for a symbol and timeframe. Rows are [timestampMs, open, high, low, close, volume]. Page back with "since"; "params.until" bounds the end.get_tradesRecent public trades for one unified symbol.search_eventsSearch events on a prediction-market exchange (polymarket, kalshi, limitless, myriad, hyperliquid with prediction=true). A scoping filter is required: query, tags, or params.eventId/params.slug. Returns events with their markets and outcome handles — outcome handles are what you pass as the symbol to get_tickers/get_orderbook/create_order on prediction exchanges.call_read_methodEscape hatch covering every unified read method not served by a dedicated tool (fetchFundingRate, fetchLedger, fetchOpenInterest, fetchLiquidations, fetchEvent, fetchSettlements, …). Only fetch*/load* methods are accepted — writes are structurally rejected. Get the signature first with describe_method. Docs: https://docs.ccxt.com/call_implicit_getCall an exchange-specific implicit REST endpoint over HTTP GET, for data the unified API does not cover. Pass the implicit method name in the "method" argument (e.g. "publicGetTickerPrice"); these are exchange-specific — find them with describe_method {"query": ..., "exchange": ...} (its results list the name to pass here). The response is the raw exchange payload. Consult the exchange API reference (describe_exchange .urls.doc) and the ccxt manual: https://docs.ccxt.com/get_safety_statusWhat this server is currently allowed to do: configured accounts (names only — never credentials), enabled capability tiers, caps, sandbox/live environments, journal location, unresolved order intents, and any configuration problems.- +20 more on the listing page
Camt053 MCP tools 24
list_message_typesList every supported ISO 20022 camt.05x message type and its name. Use this first, before any validation or generation call, to discover the exact ``message_type`` strings this server accepts. For the return-reason codes rather than message types, call ``list_return_reasons`` instead. Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one per supported message type (e.g. ``camt.053.001.14``).list_return_reasonsList every known ISO external return reason code with its name. Use this to discover the ``reason_code`` values that ``filter_entries`` and ``generate_reversal`` accept (e.g. ``AC04`` Closed Account). For the supported message types rather than reason codes, use ``list_message_types``. Returns a list of ``{"code": ..., "name": ...}`` dictionaries (e.g. ``{"code": "AC04", "name": "Closed Account Number"}``).get_required_fieldsList only the required input field names for a camt message type. Use this for a quick checklist of the mandatory columns before building reversing-entry records. When you need full type/format constraints (not just which fields are required), call ``get_input_schema`` instead. Args: message_type: A supported ISO 20022 camt.05x message type.get_input_schemaReturn the full JSON Schema for a message type's flat input record. Use this to learn every field, its type, and its constraints before assembling records, or to drive a form/UI. For just the required-field names use ``get_required_fields``; to actually check records against this schema use ``validate_records``. Args: message_type: A supported ISO 20022 camt.05x message type.validate_recordsValidate flat records against a message type's input JSON Schema. Use this on in-memory reversing-entry records to catch structural/type errors per row before generation. To validate a whole camt.05x *document* (XML) against its XSD instead, use ``validate_statement``. Returns a report ``{"valid": bool, "total": int, "valid_count": int, "errors": [...]}``. Args: message_type: A supported ISO 20022 camt.05x message type. records: One or more flat reversing-entry records to validate.validate_identifierValidate a single financial identifier (IBAN, BIC, or LEI). Use this for a one-off identifier check with a clear pass/fail. To validate identifiers embedded across a whole batch of records, prefer ``validate_records`` rather than calling this per field. Returns ``{"kind": str, "value": str, "valid": bool}``. Args: kind: One of ``"iban"``, ``"bic"``, or ``"lei"`` (case-insensitive). value: The identifier value to check.parse_statementParse an incoming camt.05x statement XML string into structured data. Use this to turn a raw statement into a navigable dict (header, statements, accounts, balances, entries). To pull just the flat entry list use ``list_entries``; to only check the document is schema-valid use ``validate_statement``. Returns the parsed document as a JSON-serialisable dict (group header plus statements, each with its account, balances, and entries), or an ``{"error": ...}`` payload if the XML cannot be parsed. Args: xml: The raw statement XML as a string.convert_mt940_to_camt053Convert a legacy SWIFT MT940 statement into a camt.053 structure. Use this as the Phase-1 migration wedge: SWIFT MT940 customer statements retire in **November 2028**, so this tool bridges the gap by turning raw MT940 text into the same JSON-serialisable camt.053 document shape that ``parse_statement`` returns (group header plus statements, each with its account, balances, and entries). Downstream tools (``list_entries``, ``filter_entries``, ``classify_entry``, ``export_journal``) then work on the result unchanged. Wraps the ``camt053-loader-mt940`` library's ``parse_mt940``; the MT parsing itself is delegated (no MT grammar is reimplemented here). The resulting ``ParsedDocument`` is serialised with the same ``to_dict()`` the server's other parse tools use, so agents get a consistent structure. Nothing is read from or written to disk. Returns the converted document as a JSON-serialisable dict, or an ``{"error": ...}`` payload if the MT940 text cannot be parsed (e.g. a missing ``:20:`` reference or a malformed balance / statement line). Args: mt940_text: The raw MT940 statement text as a string.convert_mt942Convert a legacy SWIFT MT942 interim report into a camt.052 structure. Use this as the Phase-1 migration wedge for intraday reporting: SWIFT MT94x messages retire in **November 2028**, so this tool bridges the gap by turning raw MT942 *Interim Transaction Report* text into the same JSON-serialisable camt.052 (Bank-to-Customer Account **Report**) document shape the server's parse tools return (group header plus statements, each with its account, balances, and entries). MT942 is the intraday sibling of MT940: where MT940 maps to camt.053 (end-of-day statement), MT942 maps to camt.052, so the resulting ``message_type`` is ``camt.052.001.08``. Downstream tools (``list_entries``, ``filter_entries``, ``classify_entry``, ``export_journal``) then work on the result unchanged. Wraps the ``camt053-loader-mt942`` library's ``parse_mt942``; the MT parsing itself is delegated (no MT grammar is reimplemented here). The resulting ``ParsedDocument`` is serialised with the same ``to_dict()`` the server's other parse tools use, so agents get a consistent structure. Nothing is read from or written to disk. **Documented model limitation.** The ``camt053`` typed model is camt.053-statement-oriented: it has no dedicated field for camt.052's floor-limit (``<Lmt>``) or transaction-summary (``<TxsSummry>``) blocks. Rather than drop that data, the loader surfaces it on the balance list using clearly proprietary ``type_code`` values so consumers can recognise and filter them: ``:34F:`` floor limits become ``FLIMD`` / ``FLIMC`` balances, and ``:90D:`` / ``:90C:`` entry-count summaries become ``SUMD:<count>`` / ``SUMC:<count>`` balances (the ISO ``NbOfNtries`` count is encoded after the colon; the sum is the balance ``amount``). See the loader's README. Returns the converted document as a JSON-serialisable dict, or an ``{"error": ...}`` payload if the MT942 text cannot be parsed (e.g. a missing ``:20:`` reference or a malformed floor-limit / summary / statement line). Args: mt942_text: The raw MT942 interim transaction report text as a string.validate_statementValidate an incoming camt.05x statement XML against its XSD schema. Use this to confirm a document is well-formed and schema-valid before processing it. This checks XSD conformance only; for the Nov 2026 CBPR+ business rules use ``check_cbpr_readiness``, and to extract the data use ``parse_statement``. Detects the document's message type, validates it against the matching ISO 20022 schema, and returns a report ``{"valid": bool, "message_type": str, "errors": [...]}``. A well-formed but schema-invalid document yields ``valid=False`` with a populated ``errors`` list (and the detected ``message_type``); a valid one yields ``valid=True`` with no errors. Returns an ``{"error": ...}`` payload instead if the XML cannot be parsed (e.g. it is malformed or is not a camt ``Document``). Args: xml: The raw statement XML as a string.check_cbpr_readinessCheck a camt.053 statement against the CBPR+ Nov 2026 acceptance rules. Use this to audit a statement for the business-rule changes (schema version, structured postal addresses) enforced from the Nov 2026 cutover. For plain XSD schema validity use ``validate_statement`` instead; for just the cutover date use ``get_cbpr_cutover_date``. A coordinated CBPR+ / Fedwire / CHAPS / T2 cutover lands on **14-16 November 2026**: unstructured-only postal addresses get rejected, ``camt.110/111`` exceptions and investigations become mandatory, and T2S R2026.NOV upgrades camt.053 / 054 to schema revision MR2026. This tool walks the supplied payload and reports every issue that will fail the Nov 2026 acceptance rules: * **Schema version** vs the CBPR+ current set (``camt.053.001.08`` / ``camt.053.001.13``); ``.02``-``.07`` are flagged as deprecated warnings; unknown / non-camt.053 namespaces as errors. * **Postal addresses**: every ``<PstlAdr>`` is classified as fully structured, hybrid, or **unstructured-only** (``<AdrLine>`` without ``<TwnNm>`` + ``<Ctry>`` siblings, the Nov 2026 reject case). Returns a dictionary ``{"cbpr_ready": bool, "schema_version": str | None, "checked_at": ISO-8601 UTC, "cutover_date": "2026-11-16", "issues": [...], "summary": {...}}``. ``cbpr_ready`` is ``True`` iff no ``severity="error"`` issue was raised. An ``{"error": ...}`` envelope is returned instead if the XML is malformed or refused by the hardened pre-flight (DOCTYPE / ENTITY / oversized payload). Args: xml: The raw camt.05x statement XML as a string.get_cbpr_cutover_dateReturn the official CBPR+ / Nov 2026 cutover date as ISO 8601. Use this to quote the enforcement date directly, without parsing a document. To actually audit a statement against the rules that take effect on that date, call ``check_cbpr_readiness`` instead. The cutover (``2026-11-16``) is the date after which the rules checked by ``check_cbpr_readiness`` are enforced by the major clearing systems; payments that fail will be rejected at receive-time. Surfaced as a discrete tool so agents can quote it directly without having to call a readiness check first.- +12 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
CCXT
No confirmed install command for CCXT yet — follow the setup steps linked from its listing page rather than a guessed package name.
Camt053 MCP
{
"mcpServers": {
"sebastienrousseau-camt053-mcp": {
"command": "uvx",
"args": [
"camt053-mcp"
]
}
}
}
Frequently asked questions
CCXT is categorized under Finance & Fintech and uses an install path we have not confirmed yet. Camt053 MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick CCXT for finance & fintech work and Camt053 MCP for finance & fintech.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client. CCXT has no confirmed install command yet — follow its own setup instructions.
CCXT has no declared pricing — check the project's own site. Camt053 MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add ccxt and sebastienrousseau-camt053-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, CCXT has a quality signal of 64/100 (Good) with 2 views, 0 installs and 44,480 GitHub stars. Camt053 MCP has 61/100 (Good) with 5 views, 0 installs and 2 GitHub stars.