What DOKU's MCP Server Is For, and What It Leaves Out

This is the second part of what I covered at Kelas Beta on 23 September. The first part was about AI helping to build a payment system, where the worst outcome is a bad document. This one is about AI operating a payment system, where the worst outcome is money moving when it shouldn’t.

It was the biggest block of the session, and the one the room cared about most, because it answers the question every backend engineer there had come in with: where, exactly, does an agent plug into a payment system I already run?

MCP for people who already know REST

Strip the hype off and the Model Context Protocol is a fairly modest idea. You already have payment APIs: create a checkout, create a virtual account, look up a transaction. MCP wraps those as a list of named tools that an agent can discover on its own, each with a description and an input schema, so the model can decide which one to call and with what arguments.

The transport isn’t the interesting part. What changes is that the tool list becomes a contract between your system and something that reads natural language. Whatever is on that list, a sufficiently persuaded agent can try to call. Whatever isn’t on it, no prompt can conjure.

That’s why I’d frame MCP as an integration decision rather than an AI decision. Your payment core is already in production, reconciled and audited, and you’re not going to rewrite it for an agent. What you decide is which surface you open.

What DOKU built it for

DOKU’s MCP server exposes the payment operations a merchant would use to accept money, packaged so they work from the tools people already build agents in: VS Code and Cursor, Claude Code, n8n, and LangChain in Python or JavaScript. The intended user is a merchant or developer building an agent of their own (a chat cashier, a support bot, an internal ops assistant) who wants it to create payments and check on them without hand-writing an integration for every channel.

When I asked the server for its tool list, it returned 35 tools. Grouped by what they do (the grouping is mine, the server returns a flat list):

That’s broad coverage on the accepting side. Almost every way a customer in Indonesia might pay you is there.

The column that’s empty

Look at the table again and try to find refunds. You won’t. None of the 35 tools can refund a paid transaction, void or cancel one, trigger settlement, disburse or pay out, or handle a dispute. The closest thing is deleting a virtual account that hasn’t been paid yet, which is cancelling a bill, not returning money.

And it isn’t because DOKU lacks those features. Refunds, order cancellation, settlement and payouts all exist as regular REST APIs in DOKU’s public developer documentation. They just aren’t exposed to agents.

So the way I read the inventory is: money in is exposed to agents, money out is not. I want to be careful here. That’s my reading of the tool list, not an official DOKU policy statement. But whether or not anyone wrote it down as a rule, it’s the right design, and it’s the one I’d recommend to anyone building their own MCP surface over a payment system.

The reasoning is about reversibility. If an agent wrongly creates a checkout, the worst case is an unpaid link that expires. If an agent wrongly issues a refund, the money has left, and getting it back is a manual process with a human on the phone. Those two mistakes aren’t in the same category, and the tool list is the cheapest place to encode the difference.

Read the list in both directions

Here’s the part I’d have been embarrassed to leave out, because a room full of people with laptops would have found it themselves in five minutes. If the tool list is the attack surface, it has to be read for what an agent can see, not only for what it can do.

The same 35 tools include get_all_customers, lookups by customer email and name, transaction history by customer name, and a list of stored card tokens. Money going out is closed; a merchant’s customer base is not, if you hand the agent those tools. Prompt injection doesn’t need a refund tool to do damage. A product name or a shipping address crafted to make the agent “look up” every customer is enough.

The fix is the same as for writes: least privilege, decided at configuration time. The demo agent I built for the session (more on it in part 3) is given exactly four of the 35:

get_merchant_payment_methods
get_transaction_by_invoice_number
get_transaction_by_date_range
create_doku_direct_checkout

Not because the other 31 are dangerous, but because a keripik shop’s cashier doesn’t need them. In n8n it’s one setting on the MCP client node. I think it’s the cheapest security decision available to anyone wiring an agent into payments, and I’d bet it’s also the one most often left at the default of “all tools”.

There’s a reasonable objection: restricting tools makes the agent less capable, and the next feature request will need a tool you didn’t include. True. You’ll add it then, deliberately, with a reason written next to it, which is a far better position than having every tool enabled from day one and discovering which ones mattered from an incident report.

The exercise I left the room with

At the end of the session I didn’t ask people to try the MCP server. I asked them to open a note on their phone and write two columns for the product they’re building right now: the tools an agent is allowed to call, and the ones it isn’t. I’m fairly sure the right-hand column is what determines the architecture, and it takes about five minutes to write a first version.

If you want to try it against something real, DOKU’s sandbox credentials are free to get. The next post walks through the agent the room could order snacks from that night, and where its guardrails ended up living.

Series from my Kelas Beta session, 23 September 2026: 1 · AI-assisted development · 2 · What DOKU’s MCP server is for · 3 · A chat cashier that can’t count money