MCP server
MythosData answers over the Model Context Protocol. Everything on this page is read from the running server and from the limits it enforces — nothing here is maintained by hand.
Connect a client
Streamable HTTP, stateless, at /mcp. Point a client at it:
{
"mcpServers": {
"mythosdata": {
"type": "http",
"url": "https://mythosdata.dev/mcp"
}
}
}The registry manifest is at /.well-known/mcp/server.json.
Transport and limits
- Protocol
- 2026-07-28
- Also served
- 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05, 2024-10-07
- Body cap
- 64 KiB
- Rate limit
- 120 / 60s
The limits are stated so they are a published rule rather than a surprise. A caller over the rate limit receives 429 with the standard headers saying when to retry; a body over the cap receives 413. Neither fails silently. Any method other than POST and OPTIONS receives 405 with Allow, and that refusal points back at this page.
Tools it serves
9 tools, listed as the server declares them. Every one returns typed structuredContent against a published outputSchema.
searchFull-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.
Arguments:
query,limit(optional)get_entityFetch 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.
Arguments:
idget_topicList 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.
Arguments:
tag,limit(optional),cursor(optional)answerAnswer 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.
Arguments:
questionget_sourcesThe 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.
Arguments:
object_id(optional),tier(optional),host(optional),accessed_since(optional),limit(optional),cursor(optional)get_relatedGraph neighbours of an object: outgoing and incoming relations, each with its relation type. 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.
Arguments:
idget_latestMost 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.
Arguments:
limit(optional)get_overviewCorpus 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.
Takes no arguments.
compareTwo 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.
Arguments:
ids
If you are not using MCP
The same corpus is served as plain files. The agent interface lists every machine surface this build emits.