An agent can connect on its own if it already holds LEMMAORACLE_TOKEN.Remote endpoint behind a static API key or header. The registry never sees the value; the agent fills the placeholder.
tools.schemasevery tool has an object input schema
pass
tools.annotations5 of 5 tools declare readOnlyHint or destructiveHint
pass
tools.directory_hintsevery tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
pass
tools.token_costabout 1,542 tokens to load every tool
pass
tools.api_dumptools are not a one-to-one API dump
stability100 · weight 15
pass
stability.changesno tool changes in 30 days
pass
stability.rug_pullno tool changed its meaning under the same name
dependencies33 · weight 15
fail
deps.known_vulns1 advisory to act on (malicious, or rated high or critical with a fix available): GHSA-qpx9-hpmf-5gmw in [email protected] (indirect, fixed in 1.13.8)
fail
deps.mcp_sdk_version@modelcontextprotocol/sdk 1.29.0 has 1 known advisory (GHSA-6qxp-vccf-f47h); update @modelcontextprotocol/sdk to 1.31.0 or later
Dependency graphs from deps.dev; advisories from OSV.dev, including the GitHub Advisory Database and the PyPI Advisory Database; all CC BY 4.0. The graph is what a clean install of this version resolves today; nothing was installed or run. How it is checked.
Endpoints
remote
auth
reachable
uptime 30d
p50
protocol
last ok
https://mcp.lemma.workers.dev/mcpstreamable-http
api_key ${LEMMAORACLE_TOKEN}
yes
93%
284 ms
2025-11-25
2026-10-19
package
registry
version
runtime
secrets
@lemmaoracle/mcp
npm
0.0.17
–
LEMMA_API_KEY
Tools (5)
lemma_get_circuitread-only
Retrieve a zero-knowledge proof circuit by its circuitId via GET /v1/circuits/{circuitId}. A circuit defines the constraints that proofs must satisfy and binds to a single schema. Returns CircuitMeta { circuitId, schema, description?, inputs?, verifier?: { type: 'onchain'|'offchain', address?, chainId? }, artifact?: { location: { type: 'ipfs'|'https', wasm, zkey } } }. Use this before lemma_submit_proof to confirm the circuit's schema, public inputs, and verifier configuration. Circuits are immutable; new variants get new circuitIds.
lemma_get_generatorread-only
Retrieve a Lemma document generator by generatorId via GET /v1/doc-generators/{generatorId}. A generator describes how a class of source documents is produced (e.g., what fields a 'KYC-v2' issuer must populate). Returns GeneratorMeta { generatorId, schema, description?, language?, source?: { type: 'url', uri }, inputsSpec?, outputsSpec? }. Each generator is bound to one schema. Use this when onboarding a new issuer or auditing how an existing schema is being populated.
lemma_get_proof_statusread-only
Get the verification status of a proof. NOTE: the v2 API does not yet expose a dedicated GET /v1/proofs/{id} endpoint, so this tool internally calls POST /v1/verified-attributes/query filtered by docHash (treating the verificationId returned from lemma_submit_proof as a docHash filter). Returns { status, circuitId, chainId, docHash } extracted from the matched item, or undefined if the verificationId is unknown. Status enum: received | verified | onchain-verified | rejected. Use the SDK's isVerified() helper (or check status === 'verified' || status === 'onchain-verified') to determine cryptographic validity.
lemma_get_schemaread-only
Retrieve a Lemma schema by its ID via GET /v1/schemas/{id}. A schema declares how documents of a given type are interpreted and normalized. Returns SchemaMeta { id, description? } with additionalProperties open — implementations commonly include a `normalize` artifact (WASM that maps raw documents to canonical form) and its content hash. Use this when you need to interpret attribute keys returned by lemma_query_verified_attributes.
lemma_query_verified_attributesread-only
Query cryptographically verified attributes from Lemma. Use this as the primary tool for finding documents whose attributes match given conditions (e.g., "subject's birthYear lt 2008"). Returns { results: Array<{ docHash, schema, issuerId, subjectId, attributes, isVerified, proof?: { status, circuitId, chainId }, disclosure? }>, hasMore }. The MCP layer enriches each item with an `isVerified` flag derived from `proof.status` (true when status is 'verified' or 'onchain-verified'). Use lemma_get_proof_status to monitor a specific proof; use lemma_get_schema to interpret the keys returned in `attributes`.