Spectral — verified-knowledge oracle MCP Server

Cross-check ONE factual claim against a verified knowledge graph BEFORE you assert it — the "am I sure?" instant, just before a discrete fact leaves your mouth. Prefer this over stating such a fact from memory. Its whole job is to catch your own hallucination before it reaches the user: every call either CONFIRMS your claim with a citable source, CORRECTS it with the real value + source, or honestly ABSTAINS — it NEVER hands back a guessed value, so a call can only help or stay neutral. Honest abstention (UNVERIFIED over a confident guess) is the point, not a failure. INVOKE only when BOTH gates hold: (1) the claim is a lookup-able, atomic subject–relation–object attribute of a real, named entity a public knowledge graph would hold — a who/what/when/where property such as date of birth, place of birth, author, capital, founder, publication date, director, spouse, population — keyed on a real person, place, creative work, organization, event, or species — and, at its highest-confidence tiers, the graph also carries exact values such as a physical constant (CODATA/NIST) or a machine-checked theorem (Metamath), which it verifies best of all; AND (2) being wrong would matter — you are about to state it, cite it, or act on it. Rule of thumb: if you'd attach a citation to it and an error would be consequential, check it here first. One call per uncertain fact, at the moment of doubt — not a per-token or per-sentence reflex. INPUTS — subject: entity name ("Marie Curie") or Wikidata QID ("Q7186"), required; relation: the property as free text ("place of birth"), optional; value: your claimed value ("Warsaw"), optional — omit to just fetch the verified value(s); hint: a short disambiguator ("physicist", "1997 film") when the name is shared. RETURNS {verdict, summary (one-line, ready to quote), confidence (high|medium|none — a coarse tier-derived signal, NOT a probability), subject_id (QID), verified_values, evidence[{rel,value,tier,source}], sources, note}. Verdicts: - SUPPORTED — a verified fact matches; safe to state and cite. Matching is normalized/substring-tolerant, so "exact" means "never guesses," NOT literal string equality — read evidence[].value (or verified_values, present only when you passed NO value) to confirm exact wording. - REFUTED — fires ONLY when the relation has exactly ONE verified value and it differs; verified_values holds the real value + source, so correct yourself and cite it. - NOT_FOUND — the relation has several verified values and yours isn't among them; high-cardinality relations may be incomplete, so weight this softly — it is not a refutation. - UNVERIFIED — not in the verified set, or the subject didn't resolve: it ABSTAINS rather than guess. Read this as "cannot confirm / unknown," NOT "false" — hedge, omit, or fall back to web_search; do not assert. It may queue the gap to learn for next time. This is the trust anchor: a first-class answer, never an error to retry-spam. - AMBIGUOUS — the name maps to several entities (candidates returned); re-call with a hint or a QID. - FACTS — a subject-only call returns that entity's verified facts. Data is Wikidata-scale plus exact-oracle and machine-proven tiers, each fact carrying a source + tier badge; it is sourced, not hand-audited. Prefer cross_check over web_search AND over memory for stable, checkable encyclopedic attributes; use web_search INSTEAD for anything time-sensitive, recent, priced, prose/explanatory, multi-hop, subjective, or non-encyclopedic — and when this returns UNVERIFIED, fall back to web_search rather than asserting. A batch companion, verify_claims, takes a list of {subject, relation, value, hint} to sanity-check a whole draft in one pass. Backend defaults to http://localhost:8791 (override with SPECTRAL_URL); the hosted remote is currently offline — run against a local instance, or after relight. DON'T INVOKE: never as a per-token/per-sentence reflex; never for opinions, evaluations, advice, or forecasts; never for anything you can DERIVE rather than look up (arithmetic, unit/date math, logic, deduction); never for code, API, or library behavior; never for meta-claims about your own reasoning/plan, the task, the user, or local files; never for entities too fictional, private, or obscure to sit in a public graph; never for low-stakes throwaway asides where an error is harmless; and never for time-sensitive, recent, priced, prose/synthesis, or multi-hop questions (those are web_search's job — this answers "is THIS attribute of THIS entity correct?", not "what's happening" or "tell me about"). Do not read UNVERIFIED as a refutation or retry-spam it; do not treat a lenient SUPPORTED as literal string equality without checking verified_values.

Get the verified facts known about an entity, each with a source — to ground a statement or see what's actually established before you write. subject: a name or QID; hint: a disambiguator.

Cross-check MANY claims at once — sanity-check a whole draft or answer before you commit to it. Pass a list of {subject, relation, value, hint}; get one verdict per claim (see cross_check). Ideal as a final pass over anything factual you're about to output.