finpay-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | debug | info | warn | error | info |
| DOCU_RAG_URL | No | Base URL of the docu-rag API. Enables search_docs tool. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_transactionA | Look up a single FinPay transaction by its ID. Returns the full transaction object including status, amount, currencies, exchange rate, sender/recipient names, and hub assignment. Returns a NOT_FOUND error if the ID does not exist. |
| list_transactionsA | List recent FinPay transactions with optional filters. Returns up to 50 transactions ordered by createdAt descending. Supports filtering by status and/or hubId. Returns an empty array if no transactions match the filters. |
| get_payment_hubA | Get a payment hub's current details and health metrics. Returns hub status, supported currencies, supported countries, transfer amount limits, average latency, and 24h success rate. Returns a NOT_FOUND error if the hub ID does not exist. |
| list_payment_hubsA | List all payment hubs in the FinPay platform with their current status and health metrics. Returns all 4 hubs: GlobalPay (global), SwiftRoute (SWIFT high-value), MobileFirst (mobile money), and RegionalX (Southeast Asia). |
| explain_serviceA | Get a detailed explanation of a FinPay microservice: its purpose, owning team, implementation language, upstream dependencies, downstream dependents, current health status, and port. Also returns a human-readable dependency graph description. Returns a NOT_FOUND error if the service name does not exist. |
| list_servicesA | List all 7 microservices in the FinPay platform with their metadata and current health status. Services include: api-gateway, transaction-service, hub-adapter-service, compliance-service, fx-service, notification-service, and audit-service. |
| get_system_healthA | Get a unified health snapshot of the entire FinPay platform. Returns overall system status (HEALTHY, DEGRADED, or DOWN), per-service health, per-hub health with success rates, and any active alerts. Use this tool first when triaging incidents. |
| search_docsA | Full-text search over FinPay architecture documentation via the docu-rag API. Returns a synthesised answer plus the top matching document chunks. Requires the DOCU_RAG_URL environment variable to be set; returns a disabled error if it is not configured. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| architecture-review | Load full FinPay system context (all services, all hubs, dependency graph) and conduct a structured architecture review. Optionally focus on a specific quality attribute such as resilience, scalability, or security. |
| incident-triage | Load current system health, recent failed or degraded transactions, and hub health metrics. Guides a structured incident triage. Optionally focus on a specific transaction ID. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| services-catalog | Full JSON catalog of all 7 FinPay microservices. Each entry includes the service name, description, owning team, implementation language, upstream dependencies, downstream dependents, current health status, port, and repository. Read this resource first to understand the platform before asking tool questions. |
| architecture-overview | Markdown document describing the FinPay system architecture: components, transaction lifecycle, dependency graph, payment hubs, key design decisions, and known trade-offs. Read this resource to get a complete system picture before conducting an architecture review or incident triage. |
TDQS
Scored across 8 tools
Each tool has a clear, distinct purpose: list_* returns collections, get_* returns individual entities by ID, explain_service provides detailed service metadata, and search_docs handles documentation queries. No two tools overlap in function or target resource.
All tool names follow a consistent verb_noun pattern in snake_case. List tools use 'list_', retrieval tools use 'get_', plus 'explain_' and 'search_' which are also descriptive verbs. Naming is uniform and predictable.
Eight tools is well within the ideal range for a payment platform query/monitoring server. Each tool covers a needed operation without redundancy or bloat.
The server provides complete read-only coverage for its domain: listing and getting hubs, services, and transactions, plus overall system health and documentation search. No obvious gaps for the intended use case; write operations are likely out of scope.