elliot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ELLIOT_DIR | No | Where receipts and audit state are stored. Defaults to `.elliot/` in the working directory. | .elliot/ |
| ELLIOT_ROLE | No | Set to `reviewer` for a separate reviewer-only MCP server process (the auditor process uses `auditor`). The auditor server omits `elliot_record_review`; the reviewer server exposes only that tool. | |
| GITHUB_TOKEN | No | Used by `verify_github` for private repos and higher rate limits. Sent only to the GitHub API (api.github.com or ELLIOT_GITHUB_API). | |
| ELLIOT_SIGNER_ID | No | Human-readable signer label included in signed receipts. Defaults to the public-key fingerprint. The label is not an identity proof by itself. | |
| ELLIOT_GITHUB_API | No | GitHub API base URL, for GitHub Enterprise or tests. | https://api.github.com |
| ELLIOT_SIGNING_KEY | No | Path to an Ed25519 PKCS#8 private key. When set, every saved receipt is signed. Keep it outside the repository. | |
| ELLIOT_NPM_REGISTRY | No | Registry used by `verify_npm`. | https://registry.npmjs.org |
| ELLIOT_REVIEW_TOKEN | No | Enables isolated review mode; configure the same non-empty secret on auditor and reviewer server processes (generate one with `openssl rand -hex 32`). | |
| ELLIOT_ALLOW_PRIVATE_URLS | No | When set to `1`, allows `verify_url` to reach loopback, private-network and link-local addresses (including cloud metadata), which are otherwise refused on every redirect hop. | 0 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_urlA | 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. |
| verify_outcomeA | 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 the last one. Put every file the check needs in the repository: files elsewhere (such as /tmp scripts) do not exist inside the sandbox. If the OS sandbox cannot start, returns INCONCLUSIVE without running the command. |
| verify_attestationA | 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. |
| verify_githubA | 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. |
| verify_npmA | Check the npm registry for a package and version. Use before claiming a package or release was published. |
| elliot_snapshotA | Fingerprint every tracked and untracked file in the git repository before starting a task, so verify_changes can later prove what really changed. |
| verify_changesA | 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. |
| elliot_reportA | 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. |
| elliot_audit_startA | 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. |
| elliot_record_claimA | 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 citation and submit again. |
| elliot_record_behaviorA | 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 attach this to an unrelated sentence. |
| elliot_review_packetA | 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. |
| elliot_record_reviewA | 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 checked against the files. |
| elliot_audit_finishA | Close the audit and write report.html, report.md and claims.json into elliot-report/-/ at the repository root. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools target clearly different resources: verify_changes (file diffs), verify_url (HTTP), verify_outcome (sandboxed command), verify_github, verify_npm, verify_attestation are unambiguous. Weaker spots are the report-family (elliot_report summarises receipts, elliot_review_packet packages findings, elliot_audit_finish writes report files) and elliot_record_claim vs elliot_record_behavior, which are distinguished only by careful reading of the descriptions.
There is a coherent, if dual, convention: elliot_* for audit-state tools and verify_* for external-evidence checks, each with readable verb/noun content. Minor deviations exist (elliot_audit_start / elliot_audit_finish use noun_verb ordering while elliot_record_claim, elliot_record_behavior, elliot_record_review use verb_noun).
14 tools sits comfortably in the reasonable band, and each verify_* variant covers a genuinely different evidence source rather than padding. The only mild bloat is the three report/output tools, though each serves a different consumer (user summary, reviewer process, on-disk artifacts).
The audit lifecycle is well covered end to end: snapshot, audit_start, claim/behavior recording, review_packet, record_review, audit_finish, report. Gaps are minor: no tool to list or inspect individual previously recorded claims/receipts, and no ability to retract an already-accepted claim, plus verification is limited to GitHub and npm among external registries.