trooth-mcp

The Trooth Network over the Model Context Protocol. Four read-only tools, public data, no key.

Trooth operates the Trooth Network: one public, signed, machine-readable record per company, carrying its identity, products and demos, commercial terms, domain and marketing links, people, documents, security and privacy posture, AI practices, procurement terms and relationships. It is Trooth's only product and it is free.

DNS says where a company is. A TLS certificate says the connection is authentic. The Trooth Network says who the company is and what it does with your data.

Trooth witnesses and dates facts. It does not grade, rate or rank anyone. No tool here returns a number that sums a company up, and no such number exists. An agent that wants one is being asked to invent it.

What is in this repository

A license, this README and server.json. There is no server code here, and there is nothing to install.

The server runs in the Worker behind api.trooth.co, which is a different repository. server.json is the manifest published to the official MCP Registry. What this repository is, therefore, is the registry record plus the description of a surface that lives somewhere else, and the honest thing to do is say which of the two any given fact came from.

Everything below was read from a committed file. The lines marked live were observed against the endpoint itself on 2026-09-24 by Trooth's verification script (scripts/verify-public-mcp.mjs in the site repository, not in this one), which writes its report to docs/rebuild-package/PUBLIC_MCP_VERIFICATION.md there. In that run nothing failed: the report lists 85 results that matched what was expected and 11 informational readings. That run is anonymous, from one network location, and says nothing about a later time.

The endpoint

2026-07-28 removed protocol-level sessions and the initialize handshake and added a required server/discover RPC. Which era a request belongs to is decided by the presence of the reserved _meta key, not by the version value, so an unknown future version is refused rather than quietly served as an old one. Live: a 2026-07-28 request that omits the MCP-Protocol-Version header is refused with -32020, and so is an Mcp-Method header that contradicts the body.

An older client is not stranded. Live: initialize asking for 2025-06-18 gets 2025-06-18 back, asking for 2024-11-05 gets 2024-11-05, and an unrecognized version falls back to 2025-06-18 rather than failing.

The four tools

Four, and there are no others. Live: tools/list returned exactly these names. Each takes one required string argument. Each answers with prose in content[0].text for a person and the same answer as a typed record in structuredContent for a machine, from a declared outputSchema. All four are annotated readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true.

trooth_public_trust_profile

Argument company: a domain or a Trooth slug.

Returns the company's published Trust Profile if it has one. A profile Trooth has witnessed comes back as witnessed_signed, with the date it was last witnessed where the record carries one; a published profile with nothing witnessed comes back as self_declared, the company's own words. A company listed in the public directory without a published profile comes back with its directory entry, labeled signed_scan (the API's name for that provenance). When Trooth holds nothing, the answer is an honest absence carrying provenance: "honest_absence" and a claim_url, which is not a guess and not a negative finding about the company.

It reads the same source as GET https://trooth.co/api/network/profile?q=, deliberately, so the machine answer and the human page are built from the same record. The Worker caches that read for up to 120 seconds, so a change can take that long to appear here.

trooth_outside_in_read

Argument domain.

A neutral read of that domain's public surface at the moment of the call: HTTPS and TLS reachability, the common security headers, security.txt. These are observations. They are not witnessed evidence, they are not a grade, and the response labels them that way. An outside-in read says what a stranger can see from the internet. It says nothing about what the company runs.

The input is hardened, and this is the one tool where that matters, because it is the only one that makes an outbound request on a caller's behalf. Live: an IPv4 literal, an IPv6 literal, localhost, the cloud metadata address 169.254.169.254, a hostname resolving into 10.0.0.0/8 and a hostname resolving to loopback are each refused as bad_input with the reason named. A URL is reduced to its host before anything is read.

trooth_verify

Argument token: a Trust Ledger Token in tlt2. or tlt. form, or its JTI.

Re-runs both signatures and answers valid, expired, revoked or invalid, the last when a signature does not match, which the answer tells you to treat as tampered. The limit travels in the answer: Trooth's signature covers the signing event and the payload at issuance, and never the truthfulness of the claims inside it. A caller that reads a valid token as proof that its claims are true has made the one mistake this product exists to prevent.

Live: an unknown token and outright garbage both come back as an honest absence. Neither is ever reported valid.

trooth_ask

Argument question.

Answers questions about Trooth itself: what the Network is, what one record carries, what it costs, how witnessing works. It is not a question-answering service about a company; a question about a company is answered by the three tools above, which cite what they read. Live: a question outside the curated corpus comes back out_of_scope rather than invented.

What comes back

structuredContent carries status, provenance, subject, summary and, where it applies, claim_url. Live: the status enum the server declares is exactly:

published  listed  unclaimed  private  observed  valid  invalid
expired  revoked  answered  out_of_scope  bad_input  unavailable

provenance is the label that keeps an observation from being read as a proof. The values the verification script holds the server to are witnessed_signed, signed_scan, live_observation, honest_absence, withheld_by_owner, knowledge_base, input_error, self_declared and read_failed. The live run exercised five of them: witnessed_signed, live_observation, honest_absence, knowledge_base and input_error, the last on every malformed argument.

Two states stay deliberately apart, and collapsing them would misrepresent a company:

• unclaimed with honest_absence means Trooth holds no record. That is an absence of evidence, not a finding.
• private with withheld_by_owner means a record exists and its owner chose not to publish it. That is a decision, not missing data.

Resources and prompts

Live: three of each.

Prompts: vendor_trust_check, verify_trust_token, before_you_trust.

Discovery

https://trooth.co/.well-known/mcp.json is Trooth's own descriptor, and that file says so in its own first line. MCP defines no .well-known path for advertising a server. The specification's answer to "what is this server" is the in-band server/discover RPC, which needs the URL you already have, and a Server Card document is an active working-group proposal (SEP-2127, Draft) whose experimental shape is GET <mcp-url>/server-card, not that path. The descriptor is published because a fixed address a person or an agent can guess is worth having, and it is named as Trooth's own so nobody cites it as a convention.

There is no OAuth metadata beside it, and that absence is written down rather than left to be discovered. The MCP specification makes an authorized HTTP server an OAuth 2.0 protected resource; none of that applies here, because this server takes no credential and the four tools read data already public to any browser. So there is no protected resource, no protected-resource metadata and no authorization server, and the descriptor's protectedResourceMetadata is null rather than a URL nobody serves.

The registry record