Name: Elliot
Author: EmanueleCell4

Elliot MCP

Independent verifier for AI agents: checks agent claims and doc promises against the code.

Grade B Local · stdio No auth needed 14 tools v0.6.0 MIT

No reviews yet by EmanueleCell4GitHub 41 Runs on your machine, nothing hosted

87/100

trust score

tools declared

local

runs on your machine

downloads

What it does

Independent verifier for AI agents: checks agent claims and doc promises against the code.

Quickstart

Install it the way its author documents:

1. Download elliot-mcp-0.6.0.mcpb and open it in Claude Desktop or another client that installs MCP bundles (.mcpb) 2. Its sha256 is a56fcfb4947b80854173b4df3bdcaaf7cbcc6d049917615c73783c39ce7be2eb

The full guide: https://github.com/EmanueleCell4/elliot-mcp/releases/download/v0.6.0/elliot-mcp-0.6.0.mcpb

Publishernot claimed

EmanueleCell41 server

1 category

All 1 server

Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.

Tool surface

What the model actually sees. Descriptions are diffed on every release — see version history.

Only tools that write or reach the network

Read from its source code. A server that builds its tool list when it starts can list more tools than this.

Check that a URL (a deploy, a preview, a page) actually responds with the expected status and, optionally, contains expected text. Use before claiming something is deployed or live.

Parameter	Type	Required	Notes
url	string	yes	The URL that should be live.
expect_status	integer	no	Expected HTTP status (default 200).
expect_text	string	no	Text that must appear in the response body, e.g. a headline you just shipped.
claim	string	no	The claim being checked, in the agent's own words, e.g. 'Deployed the landing page'.

Run a command and arguments in a disposable repository copy under the host OS sandbox. Writes stay in the copy, network is blocked, and VERIFIED requires exit code zero. For a shell pipeline use command bash with args ["-c", "..."]; Elliot adds set -o pipefail so a failing step is not hidden by…

Parameter	Type	Required	Notes
path	string	no	Repository path (default: server working directory).
command	string	yes	Executable, for example npm, node or pytest. No shell is used.
args	array	no	Executable arguments, e.g. ["test"] for npm test.
timeout_ms	integer	no	Timeout, default 120000ms.
claim	string	no	The claim being checked, in the agent's own words, e.g. 'Deployed the landing page'.

Verify an Ed25519-signed Elliot receipt and its digest. Returns valid=true only when the signature passes and an explicitly supplied public key matches; without one it reports cryptographic validity but marks signer identity untrusted.

Parameter	Type	Required	Notes
receipt	object	yes	—
public_key	string	no	Public key independently trusted by the verifier. Omit to check only mathematical signature validity; valid remains false.

Check what GitHub actually says: whether a PR is merged, whether CI checks passed on a PR or commit, or whether a commit/branch was really pushed. Set GITHUB_TOKEN for private repos.

Parameter	Type	Required	Notes
repo	string	yes	owner/name
check	string	yes	—
pr	integer	no	Pull request number.
ref	string	no	Commit sha or branch name.
claim	string	no	The claim being checked, in the agent's own words, e.g. 'Deployed the landing page'.

Check the npm registry for a package and version. Use before claiming a package or release was published.

Parameter	Type	Required	Notes
name	string	yes	Package name, e.g. 'zod' or '@scope/pkg'.
version	string	no	Exact version; defaults to the latest dist-tag.
published_after	string	no	ISO time the version must have been published after (proves it is a new publish).
claim	string	no	The claim being checked, in the agent's own words, e.g. 'Deployed the landing page'.

Fingerprint every tracked and untracked file in the git repository before starting a task, so verify_changes can later prove what really changed.

Parameter	Type	Required	Notes
path	string	no	Any path inside the repository (default: the server's working directory).

Check whether files really changed, compared with a snapshot taken before the task (or with HEAD if no snapshot is given). Use before claiming code was fixed, cleaned, refactored or written.

Parameter	Type	Required	Notes
snapshot_id	string	no	Id returned by elliot_snapshot.
path	string	no	Any path inside the repository.
paths	array	no	Only count changes under these repo-relative paths.
claim	string	no	The claim being checked, in the agent's own words, e.g. 'Deployed the landing page'.

Summarise recent receipts: how many claims were checked and how many held up. Show this to the user when they ask what the agent really did.

Parameter	Type	Required	Notes
limit	integer	no	How many recent receipts (default 50).

Start auditing whether this repository does what its README, docs and security/pricing pages say. Pins the commit, lists the files that make claims, and returns the protocol to follow.

Parameter	Type	Required	Notes
path	string	no	Any path inside the repository (default: the server's working directory).
sources	array	no	Audit only the claims made in these repo-relative files, e.g. a pull request description saved as .elliot-pr/PR.md. Turns off the repo-wide risk sweep.

Submit one claim with its verdict and evidence. Elliot checks that the claim's source quote is really in the docs at those lines, that every evidence quote is really in the code at those lines, and runs every 'absent' search itself. If anything does not check out the claim is rejected: fix the…

Parameter	Type	Required	Notes
audit_id	string	yes	—
claim	string	yes	The claim, quoted or tightly paraphrased, as a user would read it.
source	object	yes	Where the project makes the claim.
verdict	string	yes	VERIFIED: the code implements it. PARTIAL: implemented with a material gap or narrower than claimed. FALSE: the code contradicts it or the feature does not exist. UNVERIFIABLE: depends on a deployment
severity	string	no	Required for PARTIAL and FALSE: how much a user relying on the claim is hurt.
evidence	array	yes	Code that implements or contradicts the claim. Use type 'absent' when the claimed thing does not exist in code.
explanation	string	yes	One or two plain sentences: what the code actually does.
user_impact	string	no	Required for PARTIAL and FALSE: what a user who relies on this sentence would get wrong, concretely. If there is no real consequence, use VERIFIED with a note.
note	string	no	For VERIFIED: a minor gap worth mentioning that misleads nobody.

Record something risky the code does that the docs never mention (for example, it sends usage events, stores a key in plain text, or skips permission prompts) and no doc sentence promises otherwise. If a doc sentence does promise otherwise, use elliot_record_claim on that sentence instead. Never…

Parameter	Type	Required	Notes
audit_id	string	yes	—
behavior	string	yes	What the code does, plainly, e.g. 'Sends the user email to PostHog on login'.
signal	string	no	The code signal id from the risk sweep that led here, if any.
severity	string	yes	—
user_impact	string	yes	Who is affected and how.
docs_searched	string	yes	Where you looked in the docs and found nothing about it.
evidence	array	yes	Code that does it.

Returns only findings and checked evidence for review. Give it to a fresh reviewer process. With ELLIOT_REVIEW_TOKEN configured, the auditor endpoint cannot record review decisions; connect the reviewer only to a separate ELLIOT_ROLE=reviewer server.

Parameter	Type	Required	Notes
audit_id	string	yes	—

For the reviewer process: confirm, downgrade or reject one finding. In isolated mode provide the audit-scoped reviewer_token from the evidence packet. Confirm needs evidence you checked yourself (a code quote or an absent search); reject needs a code quote showing the claim holds. All evidence is…

Parameter	Type	Required	Notes
audit_id	string	yes	—
reviewer_token	string	no	Per-audit capability included in the evidence packet when isolated review is enabled.
finding	string	yes	The finding id, e.g. 3 or b1.
outcome	string	yes	confirm: real and material (pass severity to change it, e.g. low). downgrade: the mismatch is real but immaterial and becomes a note; do not pass a severity. reject: the claim actually holds.
reason	string	yes	—
severity	string	no	Corrected severity, when the auditor's is wrong.
evidence	array	no	—

Close the audit and write report.html, report.md and claims.json into elliot-report/<date>-<commit>/ at the repository root.

Parameter	Type	Required	Notes
audit_id	string	yes	—
out_dir	string	no	Override the output folder (relative to the repository root).
skipped	array	no	Risk-sweep items you looked at and decided need no claim, each with a reason. They are listed in the report.

Free

$0 forever

Every tool, no call limit
No card, and mcprush charges nothing for it
Source published under MIT
Runs on your machine — nothing of it reaches our gateway
Nothing to cap, because mcprush bills nothing

Nothing here is billable: mcprush charges nothing to install Elliot or to call it, at any volume.

BTrust score 87 / 100

Release 0.6.0 · scanned 28 Oct 2026

Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.

Threat score94

Client score87

Findings11 threat · 5 capability

Capabilityhigh

Coveragesource

Verificationrepo

Surface digest9b6af436983831d8c9e59a567b6db54c01c1aecce3d5d1e5746478ea1cedaf85

Score vectorthreat 94 → client 87

Term	Level	What it prices	Points
capability-exposure	high	capability blast radius (high) — client exposure if the model is manipulated	−6
verification-discount	repo	publisher verification (public source) — no provenance, but the source is public and inspectable	−1
coverage-honesty	source	inspection depth (source) — how much of the target the scan could see	−0

score = clamp(round(threatScore − E_cap − E_ver − E_cov), 0, 100). No model, no opinion, no network call at scoring time: the same methodology version against the same bytes always produces this number, and every line above is a field of the report rather than a summary of it.

What the scan could actually read

A grade is only as meaningful as its coverage, so the scanner publishes its own depth before it publishes its result.

Tool surfaceread

Implementation sourceread

Package metadataread

Live transportnot available

Tools were statically extracted from the published source (14 recovered), not enumerated from a running server. Tool-poisoning, Unicode-smuggling, capability and toxic-flow analysis ran on this inferred surface, but a mis-parsed registration could be missed or mis-attributed, so tool-derived findings are capped below “confirmed”. To grade the real runtime surface, scan the running server: --command "npx -y <package>".

14 of the 14 recovered tools are registered only when process.argv[2] === "init" is false (src/index.js:17) — typically when a key or option is configured. They are part of the server's surface and were analysed; a server started without that configuration exposes none of the recovered tools.

Capability — what it could do if the model were manipulated

Tags derived from each tool’s schema and the implementation, not from what the tool calls itself. high is the level these add up to.

No tool is registered unconditionally · 14 only when process.argv[2] === "init" is false (src/index.js:17) — typically when a key or option is configured. All 14 are in the table below and were analysed; the conditional ones are marked.

Tool	Capability tags	Why the tag was assigned
verify_url conditional	untrusted-input	untrusted-input: declares openWorldHint: true (interacts with entities outside the server)
verify_outcome conditional	code-exec	code-exec: parameter "command"
verify_attestation conditional	untrusted-input	untrusted-input: declares openWorldHint: true (interacts with entities outside the server)
verify_github conditional	untrusted-input	untrusted-input: declares openWorldHint: true (interacts with entities outside the server)
verify_npm conditional	untrusted-input	untrusted-input: declares openWorldHint: true (interacts with entities outside the server)
elliot_snapshot conditional	state-write	state-write: declares readOnlyHint: false
verify_changes conditional	no tags
elliot_report conditional	no tags
elliot_audit_start conditional	state-write	state-write: declares readOnlyHint: false
elliot_record_claim conditional	state-write	state-write: declares readOnlyHint: false
elliot_record_behavior conditional	state-write	state-write: declares readOnlyHint: false
elliot_review_packet conditional	state-write	state-write: declares readOnlyHint: false
elliot_record_review conditional	state-write	state-write: declares readOnlyHint: false
elliot_audit_finish conditional	state-write	state-write: declares readOnlyHint: false

Toxic-flow graph

The lethal trifecta, checked as a graph rather than as a checklist: untrusted input, a sensitive source and an external sink have to meet before there is a path worth worrying about.

flow-1

Untrusted input can drive an external action even though no sensitive source is exposed.

Supply chain and provenance

Integrityfirst-seen

Surface digest9b6af436983831d8

Scanned2026-10-28

This is the first scan of this surface here, so there is nothing yet to compare it against.

Every result on this tab comes from one deterministic pass over the published package — offline, rule by rule, and auditable line by line above. Same methodology version, same bytes, same score.

Where are you running it?

Tool surface

Release history

Elliot MCP

What it does

Quickstart

Where are you running it?

Tool surface

What counts against your monthly calls

What the scan could actually read

Capability — what it could do if the model were manipulated

Toxic-flow graph

Supply chain and provenance

Release history

See also