Building an MCP server for fraud investigation: why we expose evidence instead of risk scores

Most fraud APIs give AI agents a risk score. We built one that gives them evidence.

Instead of telling an assistant that a signup scored 82, our MCP server lets it dig through the same material a human analyst would: devices, IP addresses, inboxes, past events, the review queue, and how all of those connect.

What comes out of that is not a better chatbot. It is an assistant that can run the checks analysts run every day, in seconds rather than minutes.

The experience is the same in Claude, Cursor, VS Code, or any other MCP client. You ask in plain English and get an answer with the evidence attached.

What an MCP server actually is#

The Model Context Protocol is an open standard for connecting AI assistants to outside tools and APIs. Instead of relying on what the model already knows, an MCP server lets it fetch live data, take actions where allowed, and fold several API calls into one plain-English answer.

For fraud work, that is the difference between an assistant that repeats a score and one that investigates.

The problem with a single number#

Nearly every fraud platform gives you one value:

Risk Score: 82

That works well enough in a dashboard, where a human supplies the context. It works badly for an AI, which has nothing to think about beyond the number itself.

The assistant can tell you the account looks high risk, and it will say so confidently. It cannot tell you why, which checks fired, which device drove the score, whether that device has been seen before, or whether this is one account or the visible corner of a ring.

A score is a summary of evidence. It is not the evidence.

What we expose instead#

Our MCP server exposes the investigation rather than its conclusion.

For any event, the assistant can reach the checks that fired and what each one counted for, the device fingerprint, the IP, the inbox, every earlier event touching those same things, your thresholds, and the review queue ordered by risk.

That last one matters more than it sounds. "What is sitting in review, worst first?" is a question every operator asks each morning, and no scoring endpoint can answer it on its own.

The shift is from asking what the fraud score is to asking why an account is suspicious. Those are different questions. The first needs a number. The second needs evidence.

Fraud is a network, not a list#

Every event ties several things together, and the interesting information lives in how they connect.

Analysts walk those connections by hand. An agent walks them in one pass.

The six-click investigation#

A suspicious signup normally costs an analyst something like this:

Every step is another search, another page, another context switch. The agent runs that whole sequence before it answers, so you ask the question you actually have rather than the six that lead up to it.

"Are these two accounts the same person?"#

The assistant reduces both addresses to their real mailbox, compares device fingerprints, looks for shared IPs, and pulls the history on whatever it finds. Then it answers with the reasoning visible:

Yes. Both addresses reduce to the same inbox. They share a device fingerprint seen across six previous events, two of which were confirmed fraud. Nothing contradicts it.

Not just the conclusion, but what the conclusion rests on.

"Show me everything that touched this device."#

This is the query that finds rings. One fingerprint, every account that has carried it, every signup, login and review, in order.

Rings are obvious as a group and nearly invisible when you review the members one at a time.

Traditional APIs versus MCP#

The difference is not the intelligence. It is the access to context.

Read-only by default#

Giving an agent direct access to fraud infrastructure sounds risky, and it is. Agents retry, misread instructions, and occasionally loop. So the server is built to fail safe.

Ten of the twelve tools only read. The two that change anything, add_to_list and label_outcome, are not even registered unless you start the server with an explicit flag:

--allow-writes

Forget the flag and nothing breaks. The agent can still investigate everything. It just cannot change anything.

There is also a ceiling of 100 calls per process by default. An agent stuck in a retry loop hits that instead of your card, which turns a bug into an interrupted investigation rather than a surprise invoice.

How it fits together#

The model never invents the investigation. It asks the server, the server returns evidence, and the assistant explains what came back.

Installation#

claude mcp add kaidn \
  --env KAIDN_API_KEY=your_key \
  -- npx -y @kaidn/mcp

That is the whole setup. It takes an API key, and the free tier is enough to work through a real queue.

Why plain English is the right interface#

Analysts already think in questions, not queries.

Nobody works through a problem by composing a JOIN devices ON .... They think "who else used this device?" Nobody thinks "normalise the email aliases". They think "are these actually the same inbox?"

MCP is what turns the second phrasing into the dozen API calls the first one would have needed. That translation is why it feels different from clicking through a dashboard.

Not behind a sales call#

Plenty of vendors advertise MCP support now. Most of it sits behind an enterprise contract, a demo call, or a custom onboarding process, which means you cannot find out whether it is useful until you have already committed to it.

We did not think experimenting should require procurement. If you have an API key, you can start asking questions today. The package is @kaidn/mcp on npm and it is listed in the official MCP registry.

What this is actually for#

This is not AI replacing fraud analysts. It is AI removing the repetitive part of the job: the six dashboards and the manual hopping between devices, inboxes, IPs and history, so the analyst spends their attention on the decision instead of the fetching.

That is the part worth having. Not better summaries. Better investigations.

If you try it and hit a question the server cannot answer, we would genuinely like to know. Those are usually the fastest route to improving it, because they come from real queues rather than a demo.