Pacs008 MCP vs Mcptoon — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Pacs008 MCP vs Mcptoon
In-depth architectural comparison of the Pacs008 MCP and Mcptoon MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Pacs008 MCP
Finance & Fintech · Local stdio
Quality: 59/100 (Good) | Auth: No auth required
Mcptoon
Finance & Fintech · Local stdio
Quality: 71/100 (Great) | Auth: No auth required
Verdict Summary: Choose Pacs008 MCP if you need specialized Finance & Fintech tools running via a local process. Choose Mcptoon if your workspace requires Finance & Fintech integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Pacs008 MCP when:
You need dedicated capabilities in the Finance & Fintech domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
ISO 20022 FI-to-FI credit-transfer generation + validation (pacs.008 FI-to-FI Customer Credit Transfer, pacs.004 Payment Return, pacs.002 Status Report). 15 tools across message-type + scheme discovery, JSON Schema + rail-usage validation, validated XML generation, XSD validation, inbound parsing, the November 2026 structured-address cliff toolkit (classify/validate/repair/batch), and legacy SWIFT MT103 → pacs.008 conversion. Built on the pacs008 library (100% branch coverage, Apache-2.0). Install pip install pacs008-mcp, run pacs008-mcp.
Tools & Capabilities Breakdown
Pacs008 MCP Tools (16)
list_message_types
List every supported ISO 20022 pacs message type and its human name.
Use this first, before any generation or validation call, to discover the
exact ``message_type`` strings this server accepts (e.g.
``pacs.008.001.08`` FI-to-FI Customer Credit Transfer). To learn a type's
required fields or full schema, call ``get_required_fields`` or
``get_input_schema`` instead.
Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one
per supported message type.
list_schemes
List every registered scheme / usage-guideline profile.
Scheme profiles (CBPR+, HVPS+, Fedwire, CHAPS, T2 RTGS, SCT Inst, generic)
layer rail-specific rules on top of base ISO 20022. Use this to discover
the ``scheme`` names accepted by ``get_scheme`` and ``validate_scheme``.
Registry aliases (e.g. ``cbpr+``, ``cbprplus``) collapse to their canonical
profile, so each profile appears exactly once. Returns a list of
``{"scheme": ..., "name": ...}`` dictionaries.
get_scheme
Return the rule attributes of a scheme / usage-guideline profile.
Use this to inspect a rail's constraints -- whether the UETR is mandatory,
the permitted charge bearers, remittance-info length cap, per-message
transaction cardinality, pinned message versions, and which parties must
carry an LEI -- before assembling or validating a batch.
Args:
scheme: A registered scheme profile name (see ``list_schemes``).
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Pacs008 MCP is categorized under Finance & Fintech and uses a local stdio subprocess. In contrast, Mcptoon belongs to Finance & Fintech using local stdio subprocess. Select Pacs008 MCP when you need capabilities focused on finance & fintech and Mcptoon when you require tools for finance & fintech.
List only the required input field names for a pacs message type.
Use this for a quick checklist of the mandatory columns before building
payment records. For full type/format constraints (not just which fields
are required), call ``get_input_schema`` instead.
Args:
message_type: A supported ISO 20022 pacs message type.
get_input_schema
Return 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 check records against this schema use
``validate_records``.
Args:
message_type: A supported ISO 20022 pacs message type.
validate_records
Validate flat payment records against a message type's JSON Schema.
Use this before ``generate_message`` to catch structural/type errors per
record and get a row-by-row error report. This checks JSON-Schema shape
only; to check a batch against a rail's usage guidelines use
``validate_scheme``.
Returns a report ``{"is_valid": bool, "total": int, "valid": int,
"errors": [...]}``.
Args:
message_type: A supported ISO 20022 pacs message type.
records: One or more flat payment records to validate.
validate_scheme
Validate payment records against a scheme's usage-guideline rules.
Use this to check a batch against a rail's rulebook (CBPR+, HVPS+,
Fedwire, CHAPS, T2 RTGS, SCT Inst) -- charge-bearer restrictions, UETR
presence, remittance-info length, and per-message transaction cardinality.
This is complementary to ``validate_records`` (JSON-Schema shape).
Returns ``{"scheme": str, "is_valid": bool, "total": int,
"violations": [...]}``.
Args:
scheme: A registered scheme profile name (see ``list_schemes``).
records: One or more flat payment records to check.
generate_message
Generate a validated ISO 20022 pacs XML message from in-memory records.
This is the primary generation tool: pass payment records you already hold
in memory and receive an XSD-validated XML document; no file is written.
Run ``validate_records`` first to surface record-level errors, and
``list_message_types`` to confirm the ``message_type`` string.
Returns the validated XML document as a string, or an ``{"error": ...}``
payload (serialized) if generation fails.
Args:
message_type: A supported ISO 20022 pacs message type.
records: One or more flat payment records.
validate_xml
Validate a raw XML string against a message type's bundled XSD.
Use this to check an externally produced XML document against the official
ISO 20022 schema. To generate a document that is already XSD-validated,
use ``generate_message`` instead.
Returns ``{"message_type": str, "is_valid": bool}``.
Args:
message_type: A supported ISO 20022 pacs message type.
xml: The raw XML document to validate.
parse_message
Parse and classify an inbound ISO 20022 XML message.
Use this on the receiving side to identify what a message is -- its
``msg_def_idr`` (e.g. ``pacs.002.001.10``), family, version, and any
Business Application Header -- before processing it. Handles both bare
``Document`` messages and BAH-wrapped envelopes.
Returns a dict with ``msg_def_idr``, ``msg_family``, ``version``,
``root_local_name``, ``namespace_uri``, ``envelope_wrapped`` and ``bah``.
Args:
xml: The raw inbound XML message.
convert_mt103
Convert a legacy SWIFT MT103 into pacs.008-ready flat records.
This is the SWIFT MT-to-MX migration path (correspondent-banking MT103
coexistence with ISO 20022 ends November 2025): parse an MT103 text
payload and get back the flat pacs.008 record(s) that can be fed straight
into ``validate_records`` / ``generate_message``. An MT103 carries exactly
one transfer, so the ``records`` list always holds a single record. No
file is read or written.
Returns ``{"message_type": "pacs.008.001.08", "records": [{...}]}`` with
the parsed flat record, or an ``{"error": ...}`` payload if the MT103 is
missing a mandatory field (``:20:``, ``:32A:``, beneficiary) or malformed.
Args:
mt103_text: The MT103 payload as a string.
classify_address
Classify a postal address as structured, hybrid, or unstructured.
Use this to see where an address stands against the SWIFT structured-address
rule: ``structured`` (town + country + structured detail, no free-form
lines), ``hybrid`` (town + country + 1-2 free-form ``adr_line`` lines, the
minimum CBPR+ UG2026 bar), or ``unstructured`` (free-form only — rejected
from the cliff date). To check acceptability under a policy use
``validate_address``; to upgrade legacy lines use ``repair_address``.
Returns ``{"classification": str, "is_structured": bool, "is_hybrid":
bool, "is_unstructured": bool, "has_structured_fields": bool}`` or an
``{"error": ...}`` payload.
Args:
address: The postal address as a dict of snake_case fields.