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 investigate the same material a human analyst would: devices, IP addresses, inboxes, historical events, the review queue, and the relationships between all of them. What comes out of that isn't a better chatbot. It's an assistant that can run the pivots analysts perform every day, in seconds rather than minutes.

The experience is the same whether you're 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 external tools and APIs. Rather than relying on what the model already knows, an MCP server lets it fetch live data, take actions where permitted, and fold several API calls into one natural-language answer.

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

The problem with a single number#

Nearly every fraud platform exposes 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 reason about beyond the number itself. The assistant can tell you the account looks high risk, and it can say it confidently, but it can't 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 isn't the evidence.

What we expose instead#

The Kaidn MCP server exposes the investigation rather than its conclusion. For any event, the assistant can reach the checks that fired and their weights, the device fingerprint, the IP, the inbox, every prior event touching those same entities, the tenant's effective thresholds, and the review queue ordered by risk.

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

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 graph, not a list#

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

Analysts walk those edges by hand. An agent can walk 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 the same 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 normalizes both inboxes to their canonical form, compares device fingerprints, looks for shared IPs, and pulls the prior events on whatever it finds. Then it answers with the reasoning visible:

Yes. Both addresses normalize 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 and 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 isn't the intelligence. It's the access to context.

Read-only by default#

Handing 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 are read-only. The two that change anything, add_to_list and label_outcome, aren't 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 can't modify a thing.

There's also a per-process quota ceiling, 100 calls by default. An agent stuck in a retry loop hits that ceiling 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's 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 "normalize 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 gated 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 can't find out whether it's useful until you've already committed to it.

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

What this is actually for#

This isn't AI replacing fraud analysts. It's AI removing the repetitive part of the job, the six dashboards and the manual pivoting between devices, inboxes, IPs and history, so the analyst spends their attention on the decision instead of the retrieval.

That's the part worth having. Not better summaries. Better investigations.

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