This site runs an MCP server. Measured: it is smaller than the file it competes with

Since 2 August 2026 there is an endpoint at /mcp that hands the measurement datasets and the published methods to an AI client on request. Before recommending that anyone else build one, here is what it actually returns — and the number that decides whether it was worth it.

2 August 2026 · Protocol MCP 2025-06-18 · transport streamable HTTP · server card

What it can do

Three tools, no authentication, no state:

Tool	Input	Returns
list_measurements	none	every measurement with its dataset URL and the page documenting the method
get_measurement_data	dataset	one dataset as JSON — measured values, control run, conditions
get_method	name (optional)	a reproducible method, or the list of them

The number that matters

Everything the server can return, added together, is about 1,300 tokens. The llms.txt file on the same domain — a plain text summary any model can read in one request — is about 1,988 tokens.

So a model that simply reads one text file ends up with more context than one that calls all three tools. The protocol solves a size problem this site does not have. That is worth saying plainly, because the opposite is usually implied: an MCP server sounds like capability, and here it mostly is not.

Where it earns its place anyway

One thing it does that a text file cannot: it makes a number checkable at the moment of use. Asked how much text survives OCR on a screenshot, a model can either recall something approximate or call get_measurement_data and read 92.6 % out of the dataset, along with the control run that makes the figure meaningful. The second answer can be verified; the first cannot.

Two smaller advantages follow from the same property. The data is structured — JSON rather than prose, so it can go straight into a calculation. And it is current: llms.txt is maintained by hand and drifts, the endpoint reads the same files the site serves.

What it does not solve

• Reach. No one finds a site because it has an MCP endpoint. The server has served a few dozen calls, essentially all of them our own tests.
• Discovery. A client has to be told the address. The server card helps only clients that already look there.
• Anything at scale. Five datasets and three methods fit in any context window. At fifty the calculus reverses — that is when the endpoint starts to pay for itself.

How to connect it

The endpoint speaks JSON-RPC 2.0 over HTTP POST. Authentication is offered but not required; anonymous requests get identical answers.

curl -X POST https://provinglab.dev/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

In a client that supports remote MCP servers, add https://provinglab.dev/mcp as a streamable-HTTP connector. A GET on the endpoint answers 405: the server is stateless and opens no server-initiated stream, which the specification permits.

Questions

Why build it if the numbers say it barely helps?

Because the cost was one file and the failure mode is bounded: if the worker breaks, it falls back to serving the site unchanged. And because the claim "measurements you can verify" should survive contact with an agent that wants to verify them. What would not have been defensible is publishing the endpoint and implying it does more than it does.

Is anything protected behind it?

No. Every resource on this domain is public. An OAuth flow exists because some clients refuse to connect without one — it grants no access beyond anonymous, and auth.md says so in its first paragraph.