Why 'Just Use an LLM with MCP Tools' Doesn't Solve Citation Hallucination

The pitch, and why it sounds right

MCP standardizes how an LLM calls external tools. Wire up an MCP server for Crossref or OpenAlex, and in principle Claude or GPT can look up a citation the moment it's about to write one, instead of generating it from pattern-matched memory. That's a real capability, and it's a genuine improvement over an LLM citing purely from training-data recall with zero grounding.

But "the model can check" and "the model reliably does check, and correctly interprets what it gets back" are different claims. The gap between them is exactly where citation hallucination survives.

What actually happens with a single tool call

Walk through the same case from our previous post: a citation to "Attention Is All You Need" (Vaswani et al., 2017). Somewhere in the wild, a paper-mill operation registered a duplicate DOI under the identical title and author list, dated 2025, through a publisher called "Shenzhen Medical Academy of Research and Translation." We verified this is real and still checkable — see our previous post for the exact curl command against Crossref's API.

Now suppose an LLM with MCP tool access is asked to cite this paper, and it does the responsible thing: calls a Crossref search tool to check itself. We ran the same plain-text query ourselves against Crossref's live API to see exactly what that tool call would get back — and it's worse than a single fake result mixed in with real ones. The fake publisher doesn't have one duplicate entry in the results; it has seven, occupying positions 1 through 7 of the search results entirely, each with a different DOI and the same 2025 date. The real 2017 paper doesn't appear anywhere in the next twenty-three results we checked. An LLM calling this tool and taking the top hit — or the second, or the seventh — gets back a real-looking DOI, a plausible-looking publisher, and a title that matches exactly, every time. Nothing about any of those seven API responses screams "fake." They all look like a hit, because on the surface, they all pass the same check the real paper would.

This is the crux: a single tool call doesn't have a mechanism for detecting that it's wrong. It either finds something or it doesn't. It has no way to know that the thing it found is itself a fabrication, because from the API's perspective, the fabrication is indistinguishable from a real, registered, publicly indexed work.

Three specific ways it fails

1. The model may not call the tool at all for citations it's "confident" about. Hallucinated citations don't feel uncertain from the inside — that's what makes them hallucinations rather than admitted guesses. The citations most worth checking are exactly the ones an LLM is least likely to flag for checking.

2. Tool output gets filtered through the model's own summarization. Even when the model does call a tool and gets back an ambiguous or conflicting result, there's no guarantee that ambiguity survives into the final answer instead of being smoothed into a confident-sounding sentence. A hard status label (verified / mismatch / hallucinated) forces a decision; a paragraph of prose doesn't have to.

3. One source is not enough, and MCP doesn't change that. Our own tool made this exact mistake before we fixed it: querying only one provider (or querying several but trusting the first plausible-looking result) is precisely how a duplicate-DOI paper mill gets past you. It took querying seven independent sources and requiring corroboration — a consensus vote, not a single lookup — to reliably catch it. An LLM calling one MCP tool once is architecturally the single-source case.

What it would actually take to fix

You can make LLM-directed verification reliable — but the fix is not "add MCP," it's the same engineering as any citation-verification pipeline:

• Query multiple independent sources for every citation, not just one, and not only when the model decides to bother.
• Retry with a cleaner, more targeted query when the best match looks weak — not just when a search returns literally nothing.
• Require agreement across sources before accepting a match, so a single poisoned or noisy source can't unilaterally decide the outcome.
• Return a structured, unambiguous status instead of leaving the model to narrate its own confidence.

Build all of that, and you've built a verification engine that happens to be callable by an LLM — which is a fine architecture. But at that point the MCP layer is a distribution mechanism, not the solution. The solution is the consensus logic underneath it, which is the part that's actually hard and the part "just add MCP tools" skips. It's also, not coincidentally, what AccuraCite's own verification pipeline does — query independent sources concurrently, retry on a weak match instead of just a missing one, and require corroboration before returning a status.

Where LLM + MCP tool-calling genuinely helps

This isn't an argument against MCP. A verification engine exposed as an MCP tool is a legitimate way to bring real-time fact-checking into a chat or editor workflow — flagging a citation the moment someone drafts it, inline, without switching tools. That's a good distribution channel for exactly the kind of consensus-based checking described above. The mistake is treating tool access itself as the fix, when it's the transport layer for a fix that still has to be built.

FAQ

Doesn't giving an LLM real-time search access at least reduce hallucination compared to no tool access at all? Yes — grounding a model in live search results is strictly better than pure recall from training data. The claim here isn't that MCP tool access is worthless, it's that a single ungoverned tool call isn't sufficient to catch a sophisticated fake, like a duplicate DOI built to pass exactly this kind of surface-level check.

Could you build a consensus-checking MCP server that does what AccuraCite does? Yes, and that's exactly the "what it would actually take" section above — the consensus logic is the product, not the protocol it's exposed through. You can try that consensus logic directly on the AI citation checker without building anything.

Is this specific to citations, or does it apply to LLM tool use generally? The pattern generalizes: any time a single tool call's output is treated as ground truth without cross-checking, you've reintroduced the same blind trust that caused the original problem you were trying to solve.