Model Context Protocol · Waitlist

Your verified claims, one MCP call away.

We are building an MCP server that lets an assistant query your claim register directly — so it answers from a dated, sourced fact instead of whatever your marketing page happened to say. It is not live yet. The waitlist gets the spec and the build dates first.

Two fields, no call. We reply with the draft tool spec and a plain list of what is built and what is not.

Claim-level answers

Provenance on every field

Dated and expiring

Tool call

Illustrative

search_knowledge

entity: acme.com · q: customer count

1 claim returned · verified 29 Aug 2026

8,000+ customers

source

acme.com/about

status

Fresh

expires

27 Nov 2026

While you read this

Your claims are already being read at machine speed.

Prompts sent to ChatGPT today

6,968,865

+28,935 every second

ChatGPT alone, at the last volume OpenAI disclosed

Pages read by AI answer engines today

8,362,638

+34,722 every second

Modeled from that prompt volume

Every one of those reads takes your page at face value. Not one of them can ask you what is still true.

Prompts sent to ChatGPT today

6,968,923

+28,935 every second

ChatGPT alone, at the last volume OpenAI disclosed

Pages read by AI answer engines today

8,362,708

+34,722 every second

Modeled from that prompt volume

Every one of those reads takes your page at face value. Not one of them can ask you what is still true.

Prompts sent to ChatGPT today

6,968,952

+28,935 every second

ChatGPT alone, at the last volume OpenAI disclosed

Pages read by AI answer engines today

8,362,743

+34,722 every second

Modeled from that prompt volume

Every one of those reads takes your page at face value. Not one of them can ask you what is still true.

Build status · 2 September 2026

What exists today, and what does not.

We publish a claim register and hold ourselves to it, so it would be a poor start to sell you a server that has not been built. Here is the honest split.

Live today

The public claim register at /claims

The dictionary, reviewed on a schedule

llms.txt and markdown mirrors of every page

In development

The MCP server and its three tools

Tenant scoping, so a key sees one register

Change events when a claim’s status flips

Not available

A public endpoint you can point a client at

Self-serve signup or API keys

Any uptime or latency commitment

Full tool surface unlocksQ4 2026
27days
23hrs
55min
59sec
Until then the surface stays hidden — no endpoint, no schema, no client config to copy. What is public today is this page and the register behind it.

Nothing on this page claims the server is running. When it ships it will be entered in the register at /claims with a date, like every other claim we make.

Why this exists

An assistant that reads your website inherits your website’s mistakes.

Assistants answer from whatever text they can retrieve. When a number from two years ago is still sitting on a page, that is the number they repeat — with no date on it, no source behind it, and no route for you to correct it. A register inverts the flow: the assistant asks, and gets back the claim you have actually verified, with the evidence still attached.

CLAIM EXAMPLE

Outdated

CURRENT CLAIM

Trusted by 4,000+ customers.

SOURCE OF TRUTH

Trusted by 8,000+ customers.

SUGGESTED UPDATE

Trusted by 8,000+ customers.

The surface

Three tools. Claim-level, not page-level.

The register already stores every claim as its own record — a statement, the source it came from, the date it was last checked, and the date it stops being trustworthy. These three calls are how an assistant reaches that record instead of scraping the page it happens to be rendered on.

search_knowledge

query · entity? → claim[]

Ask in words. Get back the claims that answer it — each carrying its source, the date it was last checked, and its current status.

get_claim

claim_id → claim

Pull one record whole: the statement, every source supporting it, each verification event against it, and the date it stops being trustworthy.

subscribe_to_changes

entity | topic → event[]

Be told when a claim’s status flips — verified, drifted, expired — instead of re-reading the whole register on a timer.

Specified, not shipped — the build status above says exactly what exists today.

How it fits

The register already exists. The server is the socket on the front of it.

1 — Register

Every claim is extracted, checked against its own source, dated, and given the day it stops being trustworthy. This part runs today.

2 — Server

That register is served over MCP: three read-only tools, scoped to your organisation, no write path into your content.

3 — Assistant

Claude, ChatGPT and your own agents call it while they answer, and cite the claim instead of guessing from a page.

Waitlist

Join the MCP waitlist.

Tell us where your knowledge lives. You get the tool spec as it firms up and a dated note when the server reaches private beta. That is the whole list.

Two fields. No newsletter, no drip sequence — we write when there is something dated to report.

Questions

Before you join the list.

What is MCP?

The Model Context Protocol is an open standard for connecting an assistant to an outside tool or data source. A client — Claude, an IDE, your own agent — connects to an MCP server and can then call the tools that server exposes while it is answering.

Can I use the server today?

No. There is no public endpoint and no signup beyond this list. The register that would sit behind it is live and public at /claims; the server in front of it is still being built.

Why not let assistants read the website?

They already do, and that is the problem. A page hands them prose with no verification date, no source, and no way to tell that a number expired last quarter. A claim record carries all three, so the assistant can answer and cite in one step.

What happens to what I submit?

Your site and email reach our own form inbox and are used to reply about the MCP beta. No newsletter list, no resale, no third-party tracker on this page.