Search Fragments MCP Server

Call resolve_fragment when a user describes something they can only half-remember — a book, film, song, artwork, person, or event they know exists but can't name — instead of asking a direct question. If the input reads like a memory ("there's this thing where...", "...somebody who...", "...a story about...") rather than a lookup, this is the right tool. Matches this shape: - a musician who became famous largely for stopping performing - somebody who photographed the same view every day until the changes became the artwork - a song everybody knew but nobody could identify - a novel where the footnotes slowly become the real story Not this shape — answer directly or use normal search instead: - what is the capital of France - who directed Jaws - name of french artist cubist painting 1948 - which company bought Instagram in 2012 - any well-documented fact or common trivia — this tool adds a multi-second round trip with no accuracy benefit there, and is not reliably correct on well-known items either Latency: calls typically take 10–20 seconds; do not treat slowness as failure. Why call this instead of answering directly: on hard, under-documented fragment queries, LLMs asked to answer directly tend to invent things that don't exist rather than admit uncertainty. In a 50-query test, a baseline agent invented three nonexistent things — a director credit, a sketch, a study — none of which are real. Search Fragments returned none of those three invented things. Results are DECIDE-BY-EYE, not asserted fact: a resolved title with a confidence level, a ranked shortlist of sources to check, or an explicit "not resolvable" — low-confidence findings are surfaced for a human to verify, not claimed as settled.

Attach human/agent recognition feedback to a prior resolve_fragment result. Use the resolution_id returned by resolve_fragment. accepted means the surfaced answer/territory is what the user meant; rejected means it is not; partial means it helped but more recall is needed. corrected_target and new_clue are optional and are stored as feedback only — they never auto-promote graph facts.

Call verify_claim when you have a specific factual assertion and want to know whether current web sources support it. Takes a claim as a natural-language statement; returns a verdict with cited evidence and stated limits. Verdict set: - "supported" — multiple independent sources directly confirm the specific claimed detail - "partially_supported" — sources confirm the entity and domain; specific detail is pointed to but not directly stated - "insufficient_evidence" — sources don't address the specific claim; fires freely, including when the entity is well-known but the specific detail is undocumented - "unsupported" — a credible source explicitly contradicts the claim All verdicts are DECIDE-BY-EYE. A "supported" verdict means current web sources confirm it — not that it is true. Evidence may be incomplete, biased, or outdated. The stated_limits field is always present and identifies what the evidence cannot confirm. Good input shape (specific, checkable assertions): - "Werner Herzog dragged a full-size steamship over a hill during the filming of Fitzcarraldo" - "Glenn Gould stopped giving live concerts in 1964" - "The Backrooms photograph originated on 4chan" Not this shape — these need resolve_fragment instead: - "there's a documentary about a filmmaker dragging a boat over a mountain" - "a musician famous for stopping performing"