Related Servers

Each verify_* tool targets a distinct verification source (URL, sandbox command, GitHub, npm, git diff, signed receipt), and the audit lifecycle tools (start / record_claim / record_behavior / record_review / finish) have clear distinct roles that the descriptions explicitly contrast. The only real confusion risks are elliot_record_claim vs elliot_record_behavior (both record evidence into an audit) and elliot_report vs elliot_audit_finish (both emit results), and the descriptions do enough to separate them. The auditor-vs-reviewer split adds cognitive load but is spelled out.

There are two clearly separate naming families (verify_<target> and the elliot_ namespace), and the elliot_ family mixes structures: elliot_audit_start / elliot_record_claim (noun_verb) alongside elliot_snapshot and elliot_review_packet (no clear verb). Each family is internally readable, but the merged set does not follow a single predictable pattern, so an agent cannot infer a call from a name alone.

14 tools is comfortably within a healthy range for a server that bundles two related capabilities (receipt-backed verification and a docs-vs-code audit protocol). Each tool maps to a real step in one of those workflows, with no obviously redundant tool, though elliot_report and elliot_audit_finish sit close enough that the count could be trimmed by one.

The surface covers the full verification lifecycle (snapshot → verify → attest → report) and the full audit lifecycle (start → record claims/behaviors → review → finish), which is strong end-to-end coverage. Gaps are modest: verification targets only cover npm and GitHub (no PyPI/Docker/registry equivalents, forcing agents into verify_outcome), and there is no tool to retrieve individual receipt contents, only an aggregate summary.