
nomue Record Verifier
io.github.licklider-aiPublished by GitHub account licklider-aiv0.2.0-rc.1Updated Oct 27, 2026
Local verification of nomue Protocol Records; current release supports the Release 1 Welch bundle.
Overview
Local stdio MCP server that lets an assistant verify a complete nomue Protocol Record against the Release 1 Welch bundle, with no account or API key.
- What you can do
- Verify a nomue Record: run the single verify_nomue_record tool on complete Record JSON text, returning the pinned verifier's exact stdout plus structured content.
- Inspect scoped checks: read structural, digest, admissibility, computability and two-sided Welch recomputation outcomes, version and reason codes, and the guarantee boundary.
- Check replay evidence: get the verifier exit code, SHA-256 digests of the input text and output bytes, and the verifier package identity.
- Handle refusals: unsupported bundles and resource-limit or internal refusals come back as machine-readable artifacts rather than a verdict.
- When to use it
- Use it when you already hold a complete nomue Record declaring the exact public Release 1 Welch bundle and want scoped structural, digest and Welch recomputation checks run locally. It is not meant for raw samples needing a new Welch calculation, method selection, other statistical tests, or an overall scientific-validity judgment.
- Requirements
- Runs as a local stdio process launched via npx from the npm package, so Node.js 20 or 22 is needed on Linux, macOS or Windows. No environment variables, account, API key or authentication. The first npx launch may download dependencies; verification afterwards runs locally without network access.
Installation
In SourceWeft
- Open nomue Record Verifier in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
nomue Record Verifier
Local, issuer-independent verification of nomue Protocol Records for MCP clients.
Status
@licklider/nomue-verifier-mcp is an experimental release-candidate package for Phase 1 local
use. It supports stdio only. It does not expose an HTTP endpoint, require an account,
use an API key, or call a Licklider-hosted service.
The server is a thin adapter around the exact npm dependency:
It does not implement statistical or Protocol semantics independently.
The published CLI tarball includes npm-shrinkwrap.json in addition to exact direct
dependency pins, so npm versions that honor dependency-package shrinkwraps can install
the reviewed runtime tree.
Version 0.2.0-rc.1 updates the exact verifier dependency to carry the df=1 Student-t
center precision correction. It follows the first release candidate under the explicit
verifier-MCP package identity. The experimental @licklider/nomue-mcp package remains
historical and will not be repurposed as the future nomue product MCP. The
user-facing name remains nomue Record Verifier, the client configuration key remains
nomue-verify, and the sole tool remains verify_nomue_record. This identity migration
does not expand the scientific scope: the release still accepts only the exact Release 1
Welch bundle identified below.
Add it to an MCP client
Add this one-line entry inside the client's mcpServers object:
A complete configuration file is:
This is the standard shape for macOS, Linux, and MCP clients that resolve npx
directly. No environment variables are needed. The first npx launch may download npm
dependencies; after installation, verification itself runs locally and does not require
network access.
On Windows, a client that does not resolve npm command shims directly can use this equivalent entry:
The repository CI matrix verifies the installed npm command shim and exercises the installed package entry point on Windows, macOS, and Linux. A clean-profile launch in Claude Desktop, Cursor, and Cline remains a release gate after the repository and npm release candidate are public.
Add nomue Record Verifier to Cursor
Cursor Plugin wrapper
This repository also contains a Cursor Plugin manifest at
.cursor-plugin/plugin.json and its exact version-pinned mcp.json. The wrapper adds
no rules, prompts, credentials, environment variables, or remote services; it installs
the same local stdio server configuration shown above. The manifest identifies the
package as a release candidate rather than implying a stable release.
The checked-in configuration is:
The manifest makes the repository ready for a clean-profile Cursor Plugin test and Marketplace review. It is not evidence of a live Cursor Marketplace listing; record that separately only after Cursor accepts the submission.
Tool
verify_nomue_record
The tool name is method-neutral because bundle dispatch, rather than the MCP server or the caller, determines which registered verification semantics apply. The current release supports only the exact Welch bundle below. Unsupported bundles are refused without fallback or silent method switching.
Use when: you already have a complete nomue Record declaring the exact public
Release 1 bundle
urn:nomue:bundle:itgc-guarantee:0.2.1-draft.1 and need scoped structural, digest,
admissibility, computability, or two-sided Welch recomputation checks.
Do not use when: you have only raw samples and need a new Welch calculation; need method selection; need an overall scientific-validity or causal judgment; need paired-t, Wilcoxon, Mann-Whitney, or another method; or have an unsupported Protocol bundle.
Input:
record_json is JSON text, not a parsed object. Empty and malformed strings are
accepted by the adapter and passed to the verifier. Preserving the original text keeps
strict JSON parsing, duplicate-member rejection, digest verification, and resource-limit
behavior inside the verifier. An MCP string cannot represent a malformed UTF-8 byte
sequence; test that byte-level refusal directly with the npm verifier CLI.
Result contract
The first MCP text content block is the exact stdout emitted by the pinned verifier CLI
implementation, including its final newline. structuredContent contains the same
parsed verifier artifact without a new adapter verdict. MCP result metadata carries:
- the verifier exit code;
- a SHA-256 digest of the exact input JSON text encoded as UTF-8;
- a SHA-256 digest of the exact stdout bytes; and
- the exact verifier npm package identity; and
- the verifier-generated field (
generated_at) that changes on independent replay.
These metadata fields describe the invocation and replay evidence; they are not a new verdict or guarantee.
Verifier exit codes retain their existing meanings:
Codes 2 through 5 remain normal, machine-readable verifier artifacts. The MCP call
is marked as a tool error only when the adapter itself cannot produce a verifier report
or refusal.
There is no blanket VERIFIED field. Read each scoped check, its version and reason
codes, plus guarantee_boundary. A clean report does not establish scientific truth or
scientific validity.
Exactness and replay
The MCP response preserves the bytes from the same underlying verifier invocation;
the input and output SHA-256 metadata make that preservation testable. A separate replay
with @licklider/[email protected] reproduces the substantive artifact exactly, but
the verifier intentionally creates a fresh top-level generated_at timestamp on each
run. Therefore two separate invocations cannot honestly be described as byte-identical.
Tests require equality of every other field and byte-for-byte preservation within the
MCP invocation.
To replay independently, save the same record_json text and run:
Supported environment
The package declares node >=20; the release CI matrix is configured to exercise Node.js
20 and 22 on all three operating systems. Do not claim an operating-system/client pair
as release-tested until that public CI job and the corresponding clean-profile client
check have passed.
Registry metadata
server.json and the package mcpName are aligned for the official MCP Registry:
The registry artifact advertises only the npm package and stdio transport. Hosted HTTP,
SLA, authentication, logging, and rate limiting are intentionally outside Phase 1.
Prepared publication and directory-submission steps are in
registry/SUBMISSIONS.md.
Development
From this directory:
The package smoke test packs and installs the tarball at a path containing spaces, starts its generated npm executable shim, lists the tool, calls valid, mismatched, and empty Records, checks output preservation, and enforces the 10-second startup budget. That budget covers MCP process startup and tool discovery only. Each verifier call is a separate resource-bounded child process with a 60-second fail-closed ceiling so a cold Node.js/tsx launch on a supported host is not misclassified as an MCP startup failure.
Security, non-claims, and license
See SECURITY.md, NON-CLAIMS.md, and LICENSE.
Source: README.md at commit a179919
Tools
0Version history
2- v0.2.0-rc.1LatestSep 18, 2026
- v0.2.0-rc.0Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts