Unofficial MCP server for Monobank API — personal, acquiring, and corporate
This server has 45 tools with significant structural gaps. Most tools lack detailed parameter descriptions, many parameters are described only as 'object' with no field-level documentation. Tool descriptions are present but generic (avg ~60 chars, well below the 194-char baseline). No output schemas are documented. The generic 'call_api' tool (tool #45) is a red flag: it bypasses the entire tool abstraction layer and exposes raw API complexity to the LLM. Parameter validation is minimal; many tools accept opaque 'body' objects without schema constraints. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. Security: credentials are injected via environment variables (good), but no per-tool permission gates or audit logging visible. Composition is weak: tools like 'create_invoice', 'cancel_invoice', 'remove_invoice', 'finalize_invoice' are similar enough to cause LLM confusion. No pagination support visible despite financial data that could return large result sets.
Generic API call to any Monobank API endpoint
Cancel an existing invoice
Create a new invoice for acquiring (Plata by Mono)
Create a new salary contact
Create a new salary registry
Create a new subscription
Delete a salary contact
Delete a card from a wallet
Generic 'call_api' tool (tool #45) bypasses abstraction layer. Exposes raw HTTP method/path/body to LLM, forcing it to reason about API internals. Violates single-responsibility principle and tool composition patterns.
19 tools accept 'body' parameter typed as 'object' with description 'parameters' or similar. No field-level schema visible. LLM cannot validate required fields, types, or constraints before calling. Violates constrained-input pattern.
No output schemas documented for any tool. LLM cannot plan downstream calls or extract required fields (e.g., invoice_id after create_invoice). Violates response-shaper and tool-chain patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Edit an existing subscription
Finalize an invoice
Get personal client information
Get corporate account balances for a given time period
Get corporate account by IBAN
Get corporate accounts
Get corporate account statement for a given time period
Get corporate transaction by ID or external reference
Get current currency exchange rates from Monobank
Get fiscal checks for an invoice
Get receipt for an invoice
Get the status of an invoice
Get merchant account details
Get merchant public key
Get merchant statement for a given time period
Get the state of a payment by ID
Get the state of a payment by external reference
Get details of a specific QR code
Get list of QR codes
Get a specific salary contact by ID
Get the status of a salary registry
Get available salary registry types
Get personal account statement for a given time period
Get payments for a subscription
Get the status of a subscription
Get cards in a wallet
List all employees
List salary contacts with optional pagination
List all submerchants
List all subscriptions
Prepare a corporate payment
Remove an invoice
Remove a subscription
Reset the amount for a QR code
Search salary contacts by query string
Set webhook URL for personal account notifications
Process a payment from a wallet
No error handling guidance. Tools return raw API errors without recovery hints. LLM cannot distinguish retryable (rate limit) from fatal (invalid IBAN) errors. Violates recovery-guide pattern.
Similar tool names cause LLM confusion: create_invoice, cancel_invoice, remove_invoice, finalize_invoice all operate on invoices but lack clear semantic distinction. Descriptions do not explain when to use each.