What can you do with this server?

This server provides MCP tools to query a bitemporal knowledge graph of atomic claims. You can: * Answer natural-language questions using recall, which returns claims ranked by epistemic standing (similarity, provenance, currency, supersession). It supports point-in-time queries (as_of) and intent overrides (mechanism, current, historical, neutral). * Track belief changes over time with timeline, showing how claims about a subject evolved in assertion order, including supersession relationships. * Identify unresolved contradictions with conflicts, reporting open contradictions the compiler could not resolve. * Get corpus statistics with stats, breaking down claim counts by source, kind, and trust tier. These tools allow rich epistemic queries beyond simple keyword search.

How do I use claimbase?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claimbase is auto-promote still the promotion path?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

claimbase

by 4-R-C-4-N-4

Overview Schema Related Servers Score Discussions

Python

Local

claimbase

Notes are a build artifact, not a source of truth.

A compiled knowledge substrate. The source of truth is an append-only capture log; a background compiler extracts atomic claims, tracks supersession, and emits a bitemporal claim graph that agents query over MCP. Nobody gardens.

The design is in DESIGN.md. What follows is what is actually built, and what the measurements say — including where they say it does not work.

Status: Phase 0, and honest about it

Compiled over the guru, guru-web and rellm repos — 3,287 events, 11,667 claims, 14,360 edges, from six adapters.

Against two baselines on nine gold questions:

	ripgrep	chunk-RAG	claims
nDCG@10	0.229	0.500	0.679
mislead-rate	0.500	0.333	0.000

mislead-rate is the fraction of questions where a superseded record outranks every correct one. It is the number this project exists to move; nDCG mostly measures whether the thing was findable at all.

These rest on nine questions and ranking weights adjusted against them. That is fitting to noise as much as to signal. The two claims that survive scrutiny are categorical rather than marginal: the mislead-rate does not depend on weight magnitudes, and some answers are unreachable by search at any quality — see below.

An answer-level bench (same model, same turn budget, recall versus ripgrep + file reads, blind judging) ran three times: claimbase 3/4/3 correct, ripgrep 1/1/1. The gap is robust; differences between successive ranking versions are not measurable at that sample size, which is why tuning stopped.

Related MCP server: AutoWiki Agent

What it does that search cannot

Knows what stopped being true. A practice ends, eight documents go on describing it, and similarity gives the crowd the win. Ranking accounts for provenance, currency and whether a claim superseded others, so one correct claim can outrank eight stale ones — it wins with a lower cosine than the documents it beats.

Answers what was never written down. The sharpest failure in a real corpus is not contradiction, it is silence: a practice abandoned with no record of the abandonment. No compiler recovers that. assert captures it, and the answer becomes reachable — in testing, ripgrep replied "the evidence does not contain any information regarding..." to a question claimbase answered correctly.

Reads tables. A benchmark report is numbers, which carry almost no semantic signal; both baselines score 0.000 on metric questions. Compiled to claims, they become retrievable.

Design notes worth the detour

The adapter seam — six adapters were written and core/ was never touched. An abstraction with one implementation is not one.
Trust tiers — adapters declare who authored a claim; core enforces what that permits. Agent-written prose cannot become a fact. Claims that outrun their trust are demoted rather than dropped, keeping the evidence and withholding the authority.
capability vs practice — a tool that still works but is no longer used has not been falsified. Conflating the two cost the same test score three times through three different rules before the label at the source was found to be wrong.
findings.md — the running log, including every measurement that came out badly and several instruments that turned out to measure nothing.

Running it

docker compose up -d                              # postgres + pgvector on 5433
docker compose exec -T db psql -U claimbase -d claimbase -f /migrations/001_init.sql
python -m claimbase import                        # compile a corpus
python -m claimbase embed                         # vectors (needs ollama)
python -m claimbase supersede && python -m claimbase resolve
python -m claimbase recall "is auto-promote still the promotion path?"

Every command that can destroy work takes a verified snapshot first (scripts/backup_db.sh, ~/claimbase-backups/), and refuses to run if the snapshot fails. Extraction costs hours of GPU and was lost twice before that existed — once to an unscoped delete, once to a TRUNCATE CASCADE that reached claims through a foreign key. "Derived data is rebuildable" is not the same as "free to lose".

Extraction needs a local model server; everything else needs Postgres and Ollama. Corpora are declared in corpora/*.toml — named, and never derived from the working directory.

For agent access see MCP.md. Read-only by default; writes are opt-in, because a false claim written to the graph misleads every later session.

Licence

MIT

Available Tools

4 tools

conflictsB

Open contradictions the compiler could not settle. Empty is the normal state.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It conveys that the tool is read-only in nature ('Open' and 'Empty is the normal state') and manages expectations about empty results. However, it does not disclose any side effects, required permissions, response structure, or error conditions, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two short sentences that deliver core purpose and an important behavioral caveat ('Empty is the normal state'). Every word adds value, and the structure is front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and sparse annotations, so the description must explain return values and expected behavior. It only says 'Open contradictions' without specifying the structure of each conflict, how 'limit' affects output, or whether pagination exists. This leaves an agent under-informed for a tool with one parameter and no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The schema only provides a type and default, so the agent gets no meaningful semantics beyond the parameter name. Since the tool has one parameter, this is a notable omission, though 'limit' is somewhat self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Open contradictions the compiler could not settle.' This clearly distinguishes it from siblings like 'recall' or 'timeline' by focusing on compiler conflicts. However, 'open' is slightly ambiguous (display vs. fetch), so it doesn't quite reach a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives implied usage context by stating 'Empty is the normal state,' suggesting it is used for checking unresolved conflicts. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention any alternatives or sibling tools. Thus, it is clear but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recallA

Answer a question from the claim graph.

PASS THE QUESTION, NOT KEYWORDS. Phrasing carries meaning the ranking uses: "why is X still pending" is a question about mechanism and wants a durable explanation, while "is X still the current path" is about currency and wants the newest practice. Reduced to "X pending" both look identical and the wrong claims win. Full questions retrieve at least as well here — this is not a keyword index.

Returns claims ranked by epistemic standing — similarity, provenance, currency, and whether a claim superseded others — each with its source, kind, assertion date, and the intent the question was read as.

as_of: ISO date. Answers as the graph stood then ("what did I believe in June?"). intent: override if the reading looks wrong — mechanism | current | historical | neutral.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No
`as_of`	No
`query`	Yes
`intent`	No
`include_superseded`	No

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the transparency burden. It discloses how claims are ranked, what fields are returned, how as_of changes behavior, and how intent can override the default reading—offering a clear behavioral model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and tightly structured. The short opening sentence states purpose, the warning section earns its place by preventing a real misuse, and the parameter notes are compact and useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description covers purpose, query formulation, ranking behavior, return fields, and key parameters. It is nearly complete, but the lack of explanation for k and include_superseded, plus no detailed return format, prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensation is critical. It thoroughly explains query, as_of, and intent, adding meaning beyond the schema. However, k and include_superseded are left unexplained, a modest gap considering the useful context provided for the other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Answer a question from the claim graph.' It clearly differentiates recall from sibling tools by emphasizing ranked question answering over timeline, conflict, or stats navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage guidance with 'PASS THE QUESTION, NOT KEYWORDS,' concrete examples, and when to use as_of or intent. However, it does not explicitly mention sibling tools or state when not to use recall, so it misses explicit exclusion/alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statsB

What the corpus contains: counts by source, kind and trust.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It implies a read-only operation (returning counts) and is not misleading, but it does not explicitly state output format, access requirements, or limits. This is a moderate level of transparency for a simple stats tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that immediately conveys the core value. It is concise with no redundant information, earning a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a zero-parameter tool with no output schema, the description covers the general purpose but lacks explicit return structure and usage guidance. It is adequate for the simplicity but not fully comprehensive, leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the empty schema is complete and the baseline of 4 applies. The description adds useful context about the dimensions of the counts (source, kind, trust), which enriches understanding of the result.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool provides counts of the corpus by source, kind, and trust, giving a specific resource and scope. It distinguishes from siblings (recall, timeline, conflicts) by focusing on aggregate statistics, but lacks an explicit action verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus sibling tools, nor any mention of context, prerequisites, or exclusions. The description only states what it returns, leaving usage entirely implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

timelineA

How belief about a subject changed over time.

Matching claims in assertion order, showing which superseded which. Use when an answer may have changed rather than merely being unknown.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`subject`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals useful behavior: matching claims, assertion order, and showing which claims superseded others. However, it does not mention side-effect status, authentication requirements, or return format, so some behavioral ambiguity remains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two short sentences. It front-loads the core purpose, then adds behavior and usage guidance without filler or repetition. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter, read-style tool with no output schema, the description provides solid coverage: purpose, mechanism, and when-to-use. It lacks explicit return value details and limit behavior, but given the low complexity, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for parameter meaning. It conceptually references 'subject' but gives no format or expected values, and 'limit' is completely ignored. The description adds minimal value beyond the schema's bare parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: show how belief about a subject changed over time. It adds specificity with 'matching claims in assertion order, showing which superseded which,' which distinguishes it from sibling tools like 'conflicts' by focusing on temporal evolution. However, it lacks an explicit verb like 'returns' or 'lists' and does not directly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly gives usage context: 'Use when an answer may have changed rather than merely being unknown.' This tells the agent when the tool is appropriate. It does not mention exclusions or explicitly compare to sibling tools, but the guidance is clear enough for a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.0.0Aug 10, 2026
- First observedconflicts
- First observedrecall
- First observedstats
- First observedtimeline

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a clearly distinct concern: recall for answering questions, timeline for temporal evolution, conflicts for unresolved contradictions, and stats for corpus overview. There is negligible overlap because recall returns ranked claims, while timeline explains changes and conflicts lists unresolved issues.

Naming Consistency3/5

The names are short, lowercase, and readable, but there is no uniform convention: 'recall' is a verb, while 'timeline', 'conflicts', and 'stats' are nouns. This mixed style is still clear and memorable, so it is not chaotic, but it lacks the consistent verb-noun pattern seen in highly coherent tool sets.

Tool Count5/5

Four tools is an appropriate scale for a read-only claim graph query server. Each tool covers a distinct mode of interaction without redundancy, and the count is well within the ideal range for a focused server.

Completeness4/5

The core workflows are covered: querying (recall), temporal analysis (timeline), contradiction handling (conflicts), and statistics (stats). Minor gaps exist, such as no way to list all claims or fetch a claim by ID directly, but these are workarounds that do not severely hinder the intended use.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

brainatticOAuth
ai.brainattic
The knowledge base your AI reads and writes, under your rules — over MCP, EU-hosted.
Knowledge & Memory Search
2
ACEL Observatory A
za.co.pccswart.radar
Machine-readable entity discovery with provenance, trust and verified source evidence.
E-commerce & Retail Product Management
51
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
public-queryOAuth
com.amalgament
Agent-native MCP over US public + government records, entity- and parcel-keyed.
Government Data Open Data
1

Related MCP Servers

Cruxible Coreofficial
Autonomous Agents Developer Tools Knowledge & Memory
cruxible-ai
A
license
Not graded
quality
A
maintenance
Deterministic decision engine with DAG-based receipts. Build entity graphs, query with MCP, get auditable proof.
Updated 2 days ago (2026-09-04 15:01 UTC)
16
Apache 2.0
AutoWiki Agent
Knowledge & Memory File Systems
time-scout
A
license
Not graded
quality
C
maintenance
An MCP server that compiles any text into a verifiable, graph-based knowledge base using deterministic chunking and parallel extraction of epistemology primitives.
Updated 3 months ago (2026-06-18 06:21 UTC)
MIT
artagon-vault-mcp
artagon
F
license
Not graded
quality
C
maintenance
Read-only MCP server for querying an evidence-aware knowledge vault with temporal and provenance-aware data, supporting agent memory and semantic graph projections.
Updated 2 months ago (2026-07-20 21:32 UTC)
-
xrad
Knowledge & Memory Research & Data
narimannemo
A
license
Not graded
quality
A
maintenance
Provides an MCP server for storing and querying knowledge as verifiable claims, enforcing evidence-backed assertions with exact quotes and refusing paraphrases or unsupported relations.
Updated a month ago (2026-08-05 14:30 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/4-R-C-4-N-4/claimbase'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

claimbase

Status: Phase 0, and honest about it

What it does that search cannot

Design notes worth the detour

Running it

Licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Cruxible Coreofficial

Latest Blog Posts

MCP directory API