Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ELLIOT_DIRNoWhere receipts and audit state are stored. Defaults to `.elliot/` in the working directory..elliot/
ELLIOT_ROLENoSet 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_TOKENNoUsed 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_IDNoHuman-readable signer label included in signed receipts. Defaults to the public-key fingerprint. The label is not an identity proof by itself.
ELLIOT_GITHUB_APINoGitHub API base URL, for GitHub Enterprise or tests.https://api.github.com
ELLIOT_SIGNING_KEYNoPath to an Ed25519 PKCS#8 private key. When set, every saved receipt is signed. Keep it outside the repository.
ELLIOT_NPM_REGISTRYNoRegistry used by `verify_npm`.https://registry.npmjs.org
ELLIOT_REVIEW_TOKENNoEnables 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_URLSNoWhen 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 14 tools

Disambiguation4/5

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.

Naming Consistency4/5

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).

Tool Count4/5

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).

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive