Skip to main content
Glama
nziacbdc

movmint-fx-mcp

by nziacbdc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

movmint-fx-mcp

MCP server for the Movmint FX quoting and capture service. Exposes two tools (get_fx_quote, capture_fx_quote) that LLM clients can call to get live FX rates and execute trades.

Architecture

How it fits together

┌─────────────────────────────────────────────────────────────────┐
│  LLM Client (Claude Desktop / Open WebUI + Ollama)              │
└───────────────────────┬─────────────────────────────────────────┘
                        │
          ┌─────────────▼──────────────┐
          │  Transport layer           │
          │                            │
          │  Option A: stdio           │  ← Claude Desktop spawns
          │    (no port, no proxy)     │    the process directly
          │                            │
          │  Option B: HTTP via mcpo   │  ← Open WebUI / Ollama
          │    localhost:8008          │    connects as tool server
          └─────────────┬──────────────┘
                        │
          ┌─────────────▼──────────────┐
          │  MCP Server (Node.js)      │
          │  src/index.ts              │
          │                            │
          │  Tools:                    │
          │  • get_fx_quote            │
          │  • capture_fx_quote        │
          └─────────────┬──────────────┘
                        │  OAuth2 client_credentials
                        │  Bearer token (cached, auto-refreshed)
          ┌─────────────▼──────────────┐
          │  Movmint API               │
          │  api.nextgen.digitalfiat.app│
          │                            │
          │  POST /fx/quote            │
          │  POST /fx/quote/capture/:id│
          └────────────────────────────┘

MCP Server (src/index.ts)

Written in TypeScript using the @modelcontextprotocol/sdk. Key behaviours:

  • Transport: StdioServerTransport — communicates over stdin/stdout. Does not bind to a network port by itself.

  • Auth: OAuth2 client_credentials flow. Tokens are cached in memory and refreshed 30 seconds before expiry.

  • Validation: Tool inputs are validated with zod schemas before the API is called.

Tool: get_fx_quote

Calls POST /fx/quote on the Movmint API.

Parameter

Type

Required

Description

from_currency

string

Yes

Source currency code (e.g. BSD, USD)

to_currency

string

Yes

Target currency code (e.g. USDC, EUR)

amount

number

Yes

Amount in from_currency

funding_method

IMMEDIATE | DEFERRED

No

Defaults to IMMEDIATE

tx_configuration

object

Yes

Client reference ID + source/target payment config

participants

array

No

KYC participants (ULTIMATE_ORIGINATOR, ULTIMATE_BENEFICIARY, etc.)

Returns a quote_id valid for approximately 30 seconds.

Tool: capture_fx_quote

Calls POST /fx/quote/capture/{quote_id} on the Movmint API.

Parameter

Type

Required

Description

quote_id

string

Yes

The quote_id returned from get_fx_quote

Returns transaction details including the deposit address for funding.

Payment configuration schemas

tx_configuration accepts source_configuration and target_configuration, each with a source_type and an account_configuration that is one of:

Type

Fields

BANK_ACCOUNT

account_number, routing_number, account_type (CHECKING/SAVINGS)

DLT_WALLET

wallet_address, network (ethereum/solana/base/sanddollar)

CARD

card_number, expiry_date, cvv, cardholder_name, card_type (CreditCard/DebitCard)

Related MCP server: Realtime Exchange Rate MCP Server

Environment variables

Variable

Default

Required

CLIENT_ID

—

Yes

CLIENT_SECRET

—

Yes

MOVMINT_BASE_URL

https://api.nextgen.digitalfiat.app

No

MOVMINT_TOKEN_URL

https://api.nextgen.digitalfiat.app/oauth2/token

No

MOVMINT_TOKEN_AUDIENCE

fx-service

No

Store these in a .env file at the project root (never commit it — it is gitignored).

CLIENT_ID=your-client-id
CLIENT_SECRET=your-client-secret
MOVMINT_BASE_URL=https://api.nextgen.digitalfiat.app
MOVMINT_TOKEN_URL=https://api.nextgen.digitalfiat.app/oauth2/token
MOVMINT_TOKEN_AUDIENCE=fx-service

Bootstrap: running locally

Prerequisites

  • Node.js 20+

  • uvx (ships with uv) — for running mcpo without a permanent install

1. Install dependencies and build

cd /path/to/movmint-fx-mcp
npm install
npm run build        # compiles src/ → dist/

2. Option A — Claude Desktop (stdio, no proxy needed)

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "movmint-fx": {
      "command": "node",
      "args": ["/absolute/path/to/movmint-fx-mcp/dist/index.js"],
      "env": {
        "CLIENT_ID": "your-client-id",
        "CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Restart Claude Desktop. The tools appear automatically in the tool picker.

2. Option B — Open WebUI + Ollama (HTTP via mcpo)

mcpo is a proxy that wraps any stdio MCP server and exposes it as an OpenAI-compatible HTTP tool server. Open WebUI can then connect to it as a tool source for any hosted model including Ollama models.

Port map (confirmed on this machine)

Service

Port

Ollama

11434

Open WebUI

8080

mcpo (this server)

8008

Step 1 — Create mcpo-config.json

Create mcpo-config.json at the project root (it is gitignored):

{
  "mcpServers": {
    "movmint-fx": {
      "command": "node",
      "args": ["/absolute/path/to/movmint-fx-mcp/dist/index.js"],
      "env": {
        "CLIENT_ID": "your-client-id",
        "CLIENT_SECRET": "your-client-secret",
        "MOVMINT_BASE_URL": "https://api.nextgen.digitalfiat.app",
        "MOVMINT_TOKEN_URL": "https://api.nextgen.digitalfiat.app/oauth2/token",
        "MOVMINT_TOKEN_AUDIENCE": "fx-service"
      }
    }
  }
}

Step 2 — Start mcpo

uvx mcpo --port 8008 --config /absolute/path/to/movmint-fx-mcp/mcpo-config.json

Verify it is running:

curl http://localhost:8008/docs        # OpenAPI/Swagger UI
curl http://localhost:8008/openapi.json

Step 3 — Connect Open WebUI

  1. Open WebUI → Admin Panel → Settings → Tools

  2. Add tool server URL: http://localhost:8008

  3. Open WebUI discovers get_fx_quote and capture_fx_quote automatically via the OpenAPI spec

  4. Enable the tools when starting a chat with any Ollama model

3. Development mode (watch + rebuild)

npm run dev      # tsc --watch, rebuilds dist/ on every save

Run mcpo in a separate terminal; it will pick up the rebuilt dist/index.js on the next tool invocation (the Node process is spawned fresh per mcpo request).

Project structure

movmint-fx-mcp/
├── src/
│   └── index.ts          # MCP server — tools, auth, API client
├── dist/                 # Compiled output (gitignored)
├── interactions/
│   └── SD-CAD_SD-USD Collection.postman_collection.json
├── mcpo-config.json      # mcpo proxy config with credentials (gitignored)
├── package.json
├── tsconfig.json
├── .env                  # Local credentials (gitignored)
└── .gitignore

Security notes

  • mcpo-config.json and .env both contain credentials and are gitignored. Do not commit either file.

  • The MCP server logs the token request URL and body to stderr for debugging. Avoid piping stderr to shared log aggregators in production.

  • The quote_id returned by get_fx_quote expires in ~30 seconds. Do not store or reuse stale quote IDs.

Available Tools

2 tools
capture_fx_quoteA

Capture (execute) a previously generated FX quote using its quote_id. The quote must not have expired (valid for ~30 seconds after generation). Returns transaction details including the deposit address for funding.

ParametersJSON Schema
NameRequiredDescriptionDefault
quote_idYesThe quote_id returned from get_fx_quote

TDQS

A4.3/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It discloses the critical expiration constraint and the return of transaction details including deposit address. It could mention the irreversible nature of execution, but the key traits are well-covered.

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, both front-loaded with essential information: action, condition, and return value. No superfluous words.

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?

For a simple tool with one parameter and no output schema, the description covers purpose, prerequisite, constraint, and return value. It is 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 coverage is 100%, so baseline is 3. The description repeats the source of quote_id (get_fx_quote) already in the schema description, adding no new parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description clearly states the action 'Capture (execute)' and the resource 'previously generated FX quote using its quote_id', effectively differentiating from sibling get_fx_quote.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description explicitly notes the expiration condition (~30 seconds) and the required prior step (generating a quote), providing clear context. It does not explicitly list when not to use, but the sibling relationship provides alternatives.

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

get_fx_quoteA

Generate an FX quote for a currency pair and amount. Returns a quote_id valid for ~30 seconds that can be captured to execute the trade.

ParametersJSON Schema
NameRequiredDescriptionDefault
from_currencyYesSource currency code, e.g. "BSD" or "USD"
to_currencyYesTarget currency code, e.g. "USDC" or "EUR"
amountYesAmount to convert in from_currency
funding_methodNoFunding method — defaults to IMMEDIATEIMMEDIATE
tx_configurationYesSource/target payment configuration and reference ID. Required by the API.
participantsNoKYC participants. Must include at least one ULTIMATE_ORIGINATOR and one ULTIMATE_BENEFICIARY for compliance.

TDQS

A3.9/5.0
Behavior3/5

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

Without annotations, the description carries full burden. It discloses the 30-second validity period, but omits other behavioral traits such as side effects, required permissions, rate limits, or what happens if the quote expires.

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 containing essential information without redundancy. Key details are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, nested objects, no output schema), the description is too brief. It does not explain the return structure beyond a quote_id, nor does it guide on using tx_configuration or participants fields.

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?

The input schema has 100% description coverage, so the tool description adds no additional meaning 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.

Purpose5/5

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

Description clearly states verb 'Generate', resource 'FX quote', and scope 'currency pair and amount'. It also mentions the returned quote_id with a 30-second validity and its use in execution, effectively distinguishing from the sibling tool 'capture_fx_quote'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description implies a sequential workflow (get quote then capture) via the phrase 'can be captured to execute the trade', but does not explicitly state when to use this tool versus alternatives or provide preconditions or exclusions.

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.

  1. 2 tool updatesv1.0.0
    • First observedcapture_fx_quote
    • First observedget_fx_quote
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one generates a quote, the other executes it. No overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case: get_fx_quote and capture_fx_quote.

Tool Count4/5

With only 2 tools, the set is minimal but appropriate for a focused FX quote-capture workflow. Slightly thin but not unreasonable.

Completeness3/5

The core flow of getting and capturing a quote is covered, but missing operations like quote status, history, or cancellation create notable gaps.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Currency MCP Agent

    mariakasimceva0305-ux
    F
    license
    Not graded
    quality
    D
    maintenance
    Local service for currency rates and conversion using MCP and agent layer. Accepts user requests, selects appropriate tool, and returns structured responses.
    1
    -

  • Realtime Exchange Rate MCP

    AllRates-Today
    A
    license
    A
    quality
    B
    maintenance
    Provides real-time foreign-exchange rates, historical data, and multi-currency lookups to MCP-compatible AI coding assistants like Claude Code and Cursor.
    4
    53 npm
    MIT