klarna-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for the stateless streamable-HTTP entrypoint (dist/http.js). It listens on this port with a /healthz endpoint and has no auth of its own. | 8080 |
| KLARNA_ENV | No | Klarna environment: `playground` or `production`. Point it at `production` only after you have watched the tools behave on test orders. | playground |
| KLARNA_REGION | No | Klarna region: `eu`, `na` or `oc`. | eu |
| KLARNA_API_KEY | No | Alternative to KLARNA_USERNAME and KLARNA_PASSWORD: a `klarna_<live|test>_api_...` key, sent as `Authorization: Basic <API key>` as Klarna documents it. | |
| KLARNA_PASSWORD | No | API credential password (the API key or shared secret). Used together with KLARNA_USERNAME. | |
| KLARNA_USERNAME | No | API credential username (a UUID shown next to the API key when you create the credential in the Klarna Merchant Portal). Used together with KLARNA_PASSWORD. | |
| KLARNA_ENABLE_WRITES | No | Set to `true` (exactly `true`) to register the write tools (capture, refund, extend authorization, cancel, release remaining authorization). The server is read-only by default and the write tools do not exist unless this is set. | false |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_orderA | Get a Klarna order: status (AUTHORIZED, PART_CAPTURED, CAPTURED, CANCELLED, EXPIRED, CLOSED), order_amount, captured_amount, refunded_amount, remaining_authorized_amount, expires_at, order lines, captures, refunds, merchant references and addresses. Amounts in minor units. This is also where refunds for an order are listed (Klarna has no separate list-refunds endpoint). |
| list_capturesB | List all captures on a Klarna order, with captured_amount and refunded_amount (minor units), capture time, references and shipping info. |
| get_captureB | Get one capture on a Klarna order by capture_id (amounts in minor units). |
| get_refundA | Get one refund on a Klarna order by refund_id: refunded_amount (minor units), time, description, reference and order lines. To list all refunds, use get_order. |
| list_payoutsA | List Klarna payouts (settlements to your bank account) with totals per payout: sale, fee, return, holdback, reversal, tax and settlement amounts, all in minor units. Filter by payout date range and currency. Paginated with size/offset; the response has a pagination object with total. |
| get_payoutA | Get one Klarna payout by its payment_reference (the reference on your bank statement), with all totals in minor units. |
| get_payout_summaryA | Summary of all payouts in a date range, one entry per currency: total sales, fees, returns, commissions, holdback, releases, reversals, tax and settlement amount (minor units). Good for monthly reconciliation. |
| list_transactionsA | List settlement transactions (SALE, RETURN, FEE, REVERSAL and so on) with amount in minor units, order id, capture/refund ids, merchant references and payout reference. Filter by payout (payment_reference) and/or Klarna order_id. Klarna's API has no date filter here: to get a period, find the payouts with list_payouts and pass each payment_reference. Paginated with size/offset. |
| get_payout_report_csvA | Download the settlement report for one payout, with all its transactions, as CSV text (Klarna's documented settlement report format). Use for reconciliation in a spreadsheet. |
| get_payouts_summary_report_csvA | Download a CSV report of all payouts and their transactions between two dates. Can be large: keep the range short (a month or less). |
| list_disputesA | List customer disputes (Klarna Disputes API v4) filtered by order, state, reason, purchase reference and date ranges. States: INITIATED, REPRESENTMENT, PRE_ARBITRATION, ARBITRATION, CLOSED. Cursor pagination: pass pagination.last_item from the previous page as starting_after. Your merchant account must be enrolled for the Disputes API; an empty list can also mean it is not. |
| get_disputeA | Get one dispute in its current state, including its requests, deadlines and evidence history (Klarna Disputes API v4). |
| get_payment_sessionA | Read a Klarna Payments session by session_id: status, order amount and lines (minor units), purchase country/currency, payment method categories and expiry. Useful when debugging a checkout that never became an order. This server never creates or updates sessions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target distinct resources (disputes, sessions, orders, captures, refunds, payouts, transactions). The main ambiguity is the payout cluster: get_payout_report_csv (one payout) vs get_payouts_summary_report_csv (range report) and list_payouts vs get_payout_summary differ by subtle wording. Descriptions mostly disambiguate, but the CSV pair could be misselected at a glance.
Names follow a consistent get_/list_ verb_noun pattern across the set (list_disputes, get_dispute, get_order, list_captures, get_capture, get_refund, list_payouts, etc.). The only minor wrinkle is payout (singular) vs payouts (plural) in the summary/report names, but conventions remain predictable.
13 tools is well-scoped for a Klarna merchant domain spanning disputes, payments sessions, orders, captures, refunds, payouts and settlement reports. Each tool maps to a distinct operation and none feels redundant or filler.
Read coverage is broad, but the surface is entirely read-only: there are no order creation, capture, refund, cancel or release operations, and disputes expose no actions (submit evidence, represent, arbitrate). This leaves obvious lifecycle gaps for a merchant integration, though it may be intentional for reconciliation-focused use.