Football Atlas MCP server

Answer a question from the corpus, or refuse. Returns only the claims that bear on the question, each with the sources it cites and its editorial confidence. When the corpus cannot answer, answered is false and abstention_reason plus missing_topics say what was not covered — a refusal is a real result here, not an error. Use this when the user asked a question in words; use search when you want to see the candidates yourself.

Two to six knowledge objects side by side: their cards, every indexed attribute as a matrix (the same fields api/index.json publishes, null where an object does not say), the tags they share, the relations that run between them, the neighbours they have in common, and each one's claims with sources and confidence. Use this when the question is 'X vs Y', 'is X the same as Y' or 'how does X differ from Y' — search or get_topic first if you only have names, then pass the ids. An unknown id lands in `missing` with a near-miss suggestion and the rest are still compared.

Fetch one knowledge object by id, with its claims and the sources each claim cites. Use this once search, answer or get_topic has given you an id. An unknown id is not a dead end: the answer names near-miss ids you can retry with.

Most recently verified knowledge objects (freshness signal). Use this to judge how current the corpus is, or to see what changed since you last read it. It ranks by verification date and ignores your topic entirely — use search or get_topic when you want objects that are relevant rather than recent.

Corpus overview: what this instance knows, counts by type, published tags, freshness. Use this first when you land here and do not yet know whether this corpus can answer your question.

Graph neighbours of an object: outgoing and incoming relations, each with its relation type. PAGED: 25 relations by default, 200 at most, and a response budget of about 64 KB per call — a page over budget comes back shorter WITH a next_cursor, never truncated. One cursor walks both directions, outgoing first; its absence means you have the last page. Use this after get_entity to widen an answer with adjacent objects. It walks one hop from an id you already have — use search when you have a question and no starting object.

The instance's source registry — each entry with its evidence tier, reliability and access date. PAGED: 25 entries by default, 200 at most, and a response budget of about 64 KB per call — a page over budget comes back shorter WITH a next_cursor, never truncated. Read next_cursor and call again to continue; its absence means you have the last page. Filter by object_id, tier, host or accessed_since to avoid paging through a registry you do not need. Use this when you need the registry entry behind a citation, or a sample of the whole registry to judge the corpus before trusting it; get_entity already tells you which sources a claim cites.

List the knowledge objects carrying a tag (topics are content-backed tags). PAGED: 25 objects by default, 200 at most, and a response budget of about 64 KB per call — a page over budget comes back shorter WITH a next_cursor, never truncated. Read next_cursor and call again to continue, and its absence means you have the last page. Use this to browse a known topic; use search when you have a question rather than a tag, and get_overview to see which tags exist. An unknown tag comes back with the topics that do exist, so a miss still moves you forward.

Full-text search over the knowledge graph. Matching ignores accents and apostrophes, so query in the user's own words; every hit carries the fields it matched and a score. BM25 relevance: each query term is weighted by how RARE it is in this corpus and by where it hits (name 3, tags 2, questions 2, body 1). A hit must also cover a minimum share of the question's information, measured in the same rarity weights — matching only common words does not qualify. Centrality (how many objects point at this one) breaks TIES ONLY and is never part of the score, so it cannot make an irrelevant object rank. Two hits with the same matched_fields can still differ: the score is rarity-weighted, so matching a rare term is worth more than matching a common one. Use this whenever you have a question rather than an id, then follow up with get_entity.