The Case for Small Candidate Lists in MCP for Wikidata

A lot of tooling around entity resolution makes the same mistake: it assumes more results create more clarity. In practice, they often create the opposite. When a model, analyst, or developer asks for a match to a person, place, company, or work, a huge pile of near-misses does not improve judgment. It dilutes it.

That is why the design choice in the Wikidata + Google Knowledge Graph MCP to keep search bounded deserves serious attention. The project defaults to returning 3 candidates, with a ceiling of 5, instead of dumping a long result set into the client. On paper, that can look conservative. In day-to-day use, it is usually the right call.

This matters even more in the specific setting the project is built for. The server is meant to let agents search Wikidata, inspect selected facts, and link local records to Wikidata QIDs with visible evidence and explicit uncertainty when the evidence is not strong enough. That last part is the key. If the goal is not simply “find something close” but “support a defensible match or refuse one,” then candidate discipline is not a cosmetic feature. It is the center of the workflow.

Small lists force the right question

When teams first think about entity matching, they often frame the problem as retrieval. Can we find every plausible candidate? But once a system enters operational use, retrieval stops being the hard part. The real challenge is decision quality. Can the user, or the model acting on the user’s behalf, separate a genuine match from a plausible imposter?

A bounded list changes the shape of that decision. Instead of asking the model to rummage through ten, twenty, or fifty names and improvise a confidence story, the MCP server pushes it toward a narrower task: compare a small number of plausible entities, inspect the facts that matter, and either match or hold.

That restraint pairs naturally with the project’s documented outcomes: AUTO_MATCH, HOLD, AMBIGUOUS, and NO_CANDIDATE. Those states tell you something important about the philosophy behind the tool. It is not pretending search is certainty. It is exposing a controlled path from candidate retrieval to a clear resolution status.

In my experience, this is where many entity tools fall apart. They look impressive in demos because they return a lot. Then someone tries to use them for linking real records and discovers that abundance is not the same as evidence. A short list is a way of admitting that search is only useful when it leads to an inspectable choice.

The model context problem is real

MCP is not a traditional search UI. It sits in the path of language models and agentic tools. That changes the economics of result presentation.

A human staring at a web page can skim ten blue links and ignore the noise. A model does not “skim” in the same way. Every candidate consumes context, invites comparison, and increases the chance that weak signals get overinterpreted. If two entities share a label and one shares a partial description, the model may build a story around the wrong one simply because too much low-quality evidence was offered at once.

This is one of the strongest arguments for small candidate lists in MCP for Wikidata. The server is not trying to be an encyclopedia browser. It is trying to be a disciplined interface between a knowledge source and an agent that needs bounded, high-signal inputs.

The same logic extends to MCP for google knowledge graph and wikidata when both providers are used together. Cross-provider checks are helpful, but they can also multiply ambiguity if the client is handed too many candidate records from each side. A small, filtered set keeps the interaction legible. The model can examine exact identifiers, selected facts, and provider concordance without drowning in alternatives.

There is a practical token budget angle here too, though it is not only about cost. Short candidate lists preserve space for what actually matters next: the evidence. A useful match flow often needs labels, aliases, descriptions, selected statements, and sometimes ranks, qualifiers, or references. If the first step wastes context on a sprawling candidate set, the system has less room left for careful verification.

Search should narrow, not narrate

One understated strength of the project is that candidate retrieval is only one stage in a larger evidence process. The server documents tools for search, entity inspection, related items, resolution, and status. The CLI also supports batch work and evidence export. That tells me the project is built around a sober operational idea: search should narrow the field, then fact inspection should carry the burden of proof.

That is exactly where small candidate lists belong.

A broad result page invites storytelling. A bounded candidate set invites checking. Is the occupation right? Is the location right? Do the identifiers line up? Do the relevant statements have the expected rank or qualifiers? Are there references available when you request them? Those are the questions that produce reliable links.

Once you see entity resolution this way, the design starts to look less restrictive and more mature. A candidate list is not the product. It is an intermediate object. Its only job is to place the next fact-checking step within reach.

I have seen teams lose weeks because they confused those stages. They optimized retrieval metrics and celebrated that a true match appeared somewhere in the top twenty. Then they discovered the operator still had to sort through nineteen distractions, or the model kept latching onto a familiar but wrong entity. A top-twenty hit rate can look fine in a spreadsheet and still be miserable in actual use.

The 3-to-5 candidate frame is a direct answer to that problem.

Why 3 is often better than 10

There is no universal perfect number, but there is a recognizable threshold where usefulness starts to decay. Once a candidate list grows beyond a handful of entries, most of the additional items stop being realistic alternatives and start being cognitive debris.

Three works well because it creates a meaningful comparison set without pretending every remotely similar entity deserves equal attention. If there is a clean best match, the rest of the pipeline can inspect it quickly. If there are two or three serious contenders, the ambiguity is honest and manageable. If there are no good contenders, the system should say so.

Five as a maximum is a reasonable escape hatch. Names collide. Organizations rename. Works get transliterated. There are edge cases where extra room helps. But making the default 3 and the cap 5 sends the right operational signal. More candidates are an exception, not the norm.

That matters for MCP for wikidata because Wikidata itself is broad, multilingual, and full of legitimate complexity. An unrestricted search can always produce more. The challenge is not whether more exists. The challenge is whether more helps.

Most of the time, it does not.

The discipline of saying “hold”

A system that always tries to resolve is dangerous. One of the healthiest details in the project is its explicit uncertainty model. HOLD, AMBIGUOUS, and NO_CANDIDATE are not failure states in the pejorative sense. They are evidence that the tool respects the boundary between plausible and proven.

Small candidate lists reinforce that discipline. They make it easier to stop when the available matches are weak. When a system returns thirty options, there is social pressure, and sometimes model pressure, to pick one. A short list paired with explicit outcomes gives the client permission to refuse.

That is not academic. In record linkage, a https://toolhub.wikimedia.org/tools/wikidata-google-knowledge-mcp false positive usually costs more than a deferred decision. A bad link contaminates downstream data, creates misleading joins, and is hard to unwind later. A held record can be revisited. A wrong QID can spread through a pipeline.

This is one reason I like the fact that the project frames Google and Wikidata agreement as provider concordance rather than proof of identity. That is exactly the right level of caution. If an exact /m/ join aligns with Wikidata property P646, or a /g/ join aligns with P2671, that is useful corroboration. It is not a license to stop thinking. Small candidate lists make that kind of corroboration easier to evaluate in context instead of using it as a blunt shortcut.

Bounded search improves inspectability

Inspectability is one of those words that can sound abstract until you have to explain a decision to someone else. Then it becomes painfully concrete.

Why did the system choose this QID? Which candidates were considered? What facts distinguished the winner from the runner-up? Was the decision based on label similarity, identifier agreement, statement context, or a mix? If there was not enough evidence, where exactly did the uncertainty remain?

A compact candidate set makes those answers easier to preserve and review. It also fits the project’s stated emphasis on inspectable evidence. Search can stay readable. Resolution outcomes can stay explicit. Evidence exports can stay focused on actual contenders rather than an unruly tail of long-shot matches.

That is especially valuable in batch workflows. The CLI supports batch operations and evidence export, which means users are not only resolving one record at a time in an interactive session. They may be reviewing many decisions after the fact. In that setting, brevity is not a luxury. It is what keeps audits possible.

I have worked on data review queues where each item came with a bloated result set and a wall of low-value text. After the first dozen records, reviewers stopped trusting the package and began using outside shortcuts. That is what happens when a system does not respect attention as a scarce resource. Bounded candidates are one of the simplest ways to avoid that trap.

The Google cross-check is useful precisely because it is bounded

The optional Google Knowledge Graph Search API support is easy to misunderstand. This project is not an export of Google Knowledge Graph, and it is not official software from Wikimedia or Google. It is a read-only tool that can optionally use Google as a cross-check in a resolution flow.

That cross-check becomes more valuable when the candidate set is small. If you already have a handful of plausible Wikidata entities, exact identifier joins using /m/ to P646 or /g/ to P2671 can confirm that multiple providers point to the same concept space. But if you start with a flood of candidates, the same cross-check can become noisy and overcomplicated.

There is a broader design lesson here for MCP for google knowledge graph. External provider agreement works best as a targeted validation step, not as an excuse to widen retrieval. Small lists preserve that ordering. Search narrows first, provider concordance checks second, final resolution last.

That sequencing is subtle, but it is the difference between a controlled pipeline and a messy search mashup.

Fewer candidates make better use of selected facts

The project supports selected-fact retrieval, including ranks, qualifiers, and references on request. That is not a casual feature. Those details are often exactly what separate a lookalike from the real match.

Suppose two entities share a name. One has the right field of activity but the wrong time period. Another has the right geography but only a deprecated or lower-rank statement relevant to the claim you care about. These are the places where selected facts matter more than search ranking.

A short candidate list leaves space, both cognitively and within model context, to request that richer evidence. A long list crowds it out. If you have ever watched a model compare entity labels while ignoring the one qualifier that settles the issue, you know how expensive that trade-off can be.

When people ask why small lists are better, this is usually my answer: because they protect the next question. They leave room to inspect what matters.

Where the approach can feel limiting

No design choice is free. Small candidate lists do have trade-offs, and it is better to acknowledge them than pretend otherwise.

The obvious concern is recall. If the true match is obscure, badly labeled, or represented under a variant name, a strict candidate cap can hide it. That risk is real. Anyone dealing with messy local data should care about it.

The response is not to throw out bounded search. It is to use bounded search as part of an iterative process. Refine the query. Inspect related entities. Pull selected facts. Use the deterministic resolution logic to distinguish a confident match from a case that should remain open. In other words, do another deliberate pass instead of asking the first pass to solve every edge case by brute force.

A second limitation is user expectation. People are used to general-purpose search tools that reward broad exploration. They may initially see a 3-candidate response as too narrow. Usually that reaction fades once they notice how much faster it is to get to a defensible answer. But the expectation gap is real.

A third issue appears in highly ambiguous domains, where even five candidates may not capture every serious option. Here again, the right answer is not necessarily “return twenty.” It may be “return five, declare ambiguity, and ask for another discriminating signal.” That is less glamorous than giant search dumps, but operationally it is often superior.

When small candidate lists work best

There are certain conditions where this design shines. You have a local record with some identifying context, but not enough to trust a name-only search. You need a QID, not just a likely label. You care about showing evidence to a human or preserving it for audit. And you want the system to say “not enough” when the facts do not line up.

Under those conditions, a bounded MCP flow feels right.

The core benefits tend to show up in a tight pattern:

1. Search returns a few serious contenders.
2. Fact retrieval surfaces the distinguishing evidence.
3. Resolution logic states a clear outcome or declines to match.
4. Optional provider concordance adds reassurance without being treated as proof.
5. Batch and evidence export remain reviewable at scale.

That pattern is not flashy, but it is the kind of thing teams can actually trust.

Why this matters for the broader MCP ecosystem

Wikidata’s own MCP documentation frames the broader goal clearly: standardized tools that let language models explore and query Wikidata programmatically through the Wikidata API and Query Service. That is a useful foundation. But once these tools are embedded in coding agents, assistants, and data workflows, the question shifts from access to control.

Control is what small candidate lists provide.

They limit noise before it enters the model. They keep the system oriented toward evidence. They support deterministic outcomes instead of fuzzy prose. They Wikidata MCP reduce the chance that an agent mistakes provider agreement for identity proof. And they make the resulting decisions easier to inspect later.

These are not narrow implementation details. They are interface values. They shape how an agent behaves under uncertainty.

That is why the case for small candidate lists in MCP for Wikidata is stronger than it may first appear. It is not simply a matter of tidier output. It is a way of encoding judgment into the retrieval layer itself.

A better default for serious linking work

If a tool is meant for browsing, abundance can be pleasant. If a tool is meant for record linking, evidence review, and explicit uncertainty, abundance is often a liability.

The Wikidata + Google Knowledge Graph MCP takes a firmer line. It keeps search bounded, defaults to 3 candidates, allows up to 5, offers selected-fact inspection, supports deterministic resolution outcomes, and treats cross-provider agreement as supportive but not definitive. All of those choices cohere. They reflect a view that matching should be careful, inspectable, and willing to stop short of certainty.

That is the real argument for small candidate lists. They do not make the world simpler than it is. They make the decision process honest enough to handle the complexity without getting lost in it.

For teams working with MCP for google knowledge graph and wikidata, that is more than a usability preference. It is a practical safeguard. And for anyone building workflows around MCP for wikidata, it is a reminder that the most responsible search result is often not the longest one, but the shortest one that still preserves a real choice.