MCP Conduct Register

Part of Awesome HORIZON SHIELD — the checkable index of every dataset, MCP server and ledger we run.

MCP Conduct Register is a machine generated public record of how Model Context Protocol servers behaved when they were measured. It is not a curated list of good servers. Nobody selects the rows, placement cannot be bought, and records that embarrass the operator are retained because the code contains no route for removing them.

This is not a curated list of good servers. It is a record of what was measured.

Nobody chose these rows. They are generated from a public API once a day by a script in this repository, and the script has no opinion. A row appears because an endpoint is on the measurement schedule, not because anyone liked it. A green row means the conditions that were measured passed on that date. It does not mean the numbers a server returns are correct, or that the business behind it is any good.

Absence is not a negative verdict. An endpoint that is not here has simply never been measured here.

Why this exists

An agent choosing between tens of thousands of MCP servers can only read what each vendor wrote about itself. This register adds the missing layer: records of conduct that the vendor did not author and cannot delete.

Every verdict carries a record_sha256 that anyone can recompute from the published bytes. The measurement code, the gate that runs it, and this generator are all public.

Generated from https://gate.horizonshield.dev/register at 2026-09-07 21:44 UTC.

9 rows. Nobody chose them. This table is written by a script, not a person.

Server	Endpoint	Latest verdict	Measured	Public measurements	record_sha256	History
KIRA fair price audit (the flagship MCP server) KIRA適正診断	https://mcp.horizonshield.dev/mcp	verified	2026-09-07	33	4cb43c135355	history
YAKUMO verified contractor directory YAKUMO加盟店ディレクトリ	https://hearing.horizonshield.dev/mcp	verified	2026-09-07	33	3c3b2503bcca	history
KIRA intake desk for renovation questions KIRA相談窓口	https://web.horizonshield.dev/mcp	verified	2026-09-07	33	49a468235d1a	history
JIDEC, the Bitcoin anchored public ledger JIDEC 公開検証台帳	https://jidec.horizonshield.dev/mcp	verified	2026-09-07	31	513597b0eb4f	history
Reform Shokunin Co., Ltd. (member No.001, Aichi) リフォーム職人株式会社（加盟No.001）	https://p001.horizonshield.dev/mcp	pending	2026-09-07	33	f33728d48ed2	history
Mineo Toyo Juki Co., Ltd. (member No.002) ミネオトーヨー住器株式会社（加盟No.002）	https://p002.horizonshield.dev/mcp	verified	2026-09-07	33	b5c826dc697b	history
The verification gate, measuring itself 検証ゲート（この検査機自身）	https://gate.horizonshield.dev/mcp	verified	2026-09-07	33	521281818759	history
Femtech source registry (verify sources, never diagnose) フェム情報源レジストリ	https://femtech.horizonshield.dev/mcp	verified	2026-09-07	11	94a6b6d2a871	history
https://intel.twzrd.xyz/mcp	https://intel.twzrd.xyz/mcp	not measured yet		0		history

Measured by gate commit 63010ebf09ae. The commit that produced each verdict is inside the hashed record.

The public register. Rows are scheduled measurements, not endorsements. An endpoint that is absent has simply never been measured here; absence is NOT a negative verdict. Webhooks are never published. Every stored verdict carries a record_sha256 you can recompute yourself. The operator_label field is a display name assigned by the operator, not a measurement.

Verify any row yourself

curl -s "https://gate.horizonshield.dev/history?endpoint=<the endpoint>"

Recompute the hash of any record and compare it with the record_sha256 in the response. If they disagree, that disagreement is itself worth publishing, and the ledger below will accept it.

Get listed

Two ways, both free, neither changes the verdict.

One command:

curl -s -X POST https://gate.horizonshield.dev/watch \
  -H 'content-type: application/json' \
  -d '{"endpoint":"https://your-server/mcp"}'

Or open a pull request against requests/ in this repository with a file named after your server. See CONTRIBUTING.md. A maintainer adds the endpoint to the measurement schedule. Nothing else about the listing is negotiable, including the verdict.

Point your agent card at your row (A2A Conduct Extension v1)

An A2A agent can carry its own conduct pointers in its card, under capabilities.extensions[], with the URI https://gate.horizonshield.dev/ext/conduct/v1. The params state who pays the agent (the same compensation shape condition 3 has always read, now in the place A2A 1.0 reserves for extension data), which endpoint is measured, where its record on this register lives, and where a connecting client can file its own walk as a witness (POST https://ledger.horizonshield.dev/witness). The gate reads the declaration from either place from version 0.3.2; when a card carries both, they must agree.

Declaring the extension changes no verdict. It makes the row findable from the card, and it makes every client that reads the card a potential second witness in the endpoint's monthly ring. The specification is served at the URI; a reference walk client is workers/hs-ledger/nenrin/a2a-conduct-walk/a2a_conduct_walk.py in the horizon-shield repository.

The ledger behind this

Measurements accumulate into monthly rings anchored to Bitcoin through OpenTimestamps. Anyone can submit an observation of any endpoint as a witness, under their own name and vantage. The operator holds no veto in code.

• Witness intake, GET returns a self description: https://ledger.horizonshield.dev/witness
• The ledger: https://ledger.horizonshield.dev/ledger
• Specification, anchored at Bitcoin block 962507: NENRIN_SPEC_v1
• The founding discrepancy record, two witnesses disagreeing about the operator's own server, both correct, anchored at block 962511: NENRIN_DISCREPANCY_0001

What this register does not do

It does not rank. It does not score. It does not accept payment for placement, and there is no placement to buy: the order of the table is the order the API returns. It will not remove an unflattering record, including about the operator's own servers. The operator is the first test subject under these rules and the failing records are still here.

How to cite this register

Archived on Zenodo with a permanent identifier, so a citation survives this repository moving or disappearing.

Oga, Toshikatsu (2026). MCP Conduct Register: a machine generated register of measured MCP server
conduct. Zenodo. https://doi.org/10.5281/zenodo.21970931

BibTeX and APA forms are generated by the "Cite this repository" button on GitHub, which reads CITATION.cff. The author is identified by ORCID 0009-0000-9180-903X, so this register sits in the same record as the open dataset and the preprints it was built from.

When citing a single row rather than the register, cite the endpoint's history URL and the record_sha256 of the verdict you are relying on. That pair is enough for a reader to recompute the record and confirm you quoted it correctly.

Questions people actually ask

How is this different from an awesome list? An awesome list is a human recommending things. This is a script reporting measurements. No human chose any row here, and the generator is in this repository so you can check that claim.

Can I pay to be listed, or to be listed higher? No, and there is nothing to buy. The order of the table is the order the API returns. There is no ranking and no score.

What does a green row prove? That the conditions which were measured passed on that date, from the vantage that measured them. It does not prove the numbers a server returns are correct, or that the business behind it is competent, or that it is safe to use.

What if your own server fails? It has, and the record is still published. The gate measures its own endpoint under the same rules. The founding record of the ledger behind this register is a disagreement between two witnesses about the operator's own server, in which both witnesses turned out to be correct.

Can I dispute a verdict? Yes, and that is the point. Measure the endpoint yourself and submit your observation to the public ledger under your own name and vantage. If your report conflicts with this register, the conflict becomes a permanent citable record. The operator has no veto in code.

Who runs this? Toshikatsu Oga, The HORIZONs Co., Ltd., Hiratsuka, Japan. A carpenter of thirty years. ORCID 0009-0000-9180-903X.

How do I cite this register? See CITATION.cff, or use the "Cite this repository" button on GitHub. A machine readable snapshot of the current table is published as register.json in this repository.

License

Code MIT. The measurement records are facts and are not claimed as property.

Rings

Monthly rings (nenrin-ring-v1) live in rings/, one file per endpoint per month, built from history/ by scripts/make_ring.py. A ring holds counts with denominators, never a rate, score or rank, and carries the sha256 of the previous ring's file. history/ is an append-only archive of every endpoint's /history export, taken daily by scripts/archive_history.py; the gate itself keeps a bounded number of records per endpoint, this directory keeps all of them.

Ring 001 covers 2026-08 for eight endpoints. Its sha256 list rings/2026-08.sha256 is JIDEC entry 32: https://ledger.horizonshield.dev/ledger/32.

Rebuild any ring from the same history and compare bytes:

python3 scripts/make_ring.py --verify rings/<slug>/2026-08.json --history history/<slug>.json

Each August ring also carries an in-toto Statement v1 in a DSSE envelope beside it (rings/<slug>/2026-08.intoto.dsse.json): subject = the ring file's sha256, predicateType = https://gate.horizonshield.dev/ext/conduct/v1, predicate = the ring's counts copied, never recomputed. Signed ES256 with the same key that signs the agent cards (kid hs-2026-09, public key in rings/jwks.json and at every worker's /.well-known/jwks.json). Verify without the private key: python3 ring_to_intoto.py --verify rings/<slug>/2026-08.intoto.dsse.json --jwk rings/jwks.json (the tool lives in horizon-shield, workers/hs-ledger/nenrin/ring-v1/). The envelope adds a second door into the same bytes; the ring file stays the unit of record.

Independent recompute (record)

• 2026-09-05: a second party (Federico Blanco Sánchez-Llanos) cloned this repository and ran scripts/make_ring.py --verify against all eight August rings using the committed history/ exports. Result: 8 of 8 match, including the gate's own ring. This tests that the repository is internally consistent and reproducible. A from-scratch reimplementation in another language producing the same bytes is a separate test and has not yet been done.
• 2026-09-05 (update): the same second party then did the harder test. From Layer 3 of NENRIN_SPEC_v1.md alone (whose sha256 9ccba2e3... he checked against what make_ring.py cites, before trusting it), and without ever seeing this repository's source, he wrote a from-scratch reimplementation in Node.js (github.com/babyblueviper1/invinoveritas, scripts/nenrin_ring_reimpl/make_ring.js). Run against all eight published August history exports, it reproduces all eight rings byte for byte (femtech 7a310f5d, gate e473f717, hearing ceb47d33, jidec 3a215b6c, mcp 9ca61125, p001 00155986, p002 1f8d4f45, web 06d1f77b). Two independent implementations, Python and Node, now produce identical bytes from the same history. The earlier sentence "a from-scratch reimplementation ... has not yet been done" is therefore superseded.
• 2026-09-06 (correction to the 2026-09-05 update above; that line stays as written): two phrases in it claim more than the record supports and are narrowed here, with the reimplementer's agreement. "From Layer 3 of NENRIN_SPEC_v1.md alone": the specification's Layer 3 sketch names 11 of a ring's 20 fields and does not state the canonical form at all; the remaining fields and the byte rules were taken from the published ring files in this repository, read before the reimplementation was written. "Without ever seeing this repository's source": in the recompute recorded two lines above, the reimplementer had cloned this repository, executed scripts/make_ring.py --verify as a black box, and read its docstring header for the specification hash it cites; the body of make_ring.py, the logic that turns history entries into ring fields, was not read before or during the reimplementation. What was blind was the byte comparison: the rebuilt bytes were not checked against the eight published rings until the verify run reported match or mismatch. The full account, written by the reimplementer, is Section 4.2 of papers/nenrin-reproducibility/manuscript_v0.1.md in github.com/ogasurfproject-jpg/horizon-shield. Ledger entry 34 stays as anchored, including its field implementation_2_source_seen; a correction record that cites it is appended to the same ledger.