VeriLock MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERILOCK_TOKEN | No | API token for VeriLock. Required for stdio mode to access authenticated tools; not used in HTTP mode (which uses Authorization headers). If omitted, auth-required calls will fail. | |
| VERILOCK_HTTP_HOST | No | Host interface for the HTTP transport. Defaults to 127.0.0.1; the container sets 0.0.0.0. | |
| VERILOCK_API_BASE_URL | No | Base URL of the VeriLock API. Defaults to https://verilock.online |
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 |
|---|---|
| list_documentsA | List documents available to the authenticated account. |
| get_documentA | Get public metadata and signing information for a document. |
| verify_document_hashA | Find VeriLock records matching an exact SHA-256 digest. No document bytes are accepted. |
| get_audit_eventsB | Read the private, hash-only evidence event history for a document. |
| get_evidence_manifestB | Read the cryptographic evidence manifest for a document. |
| get_certificateA | Read the public human-readable evidence certificate for a document. |
| get_chain_attestationA | Read the on-chain attestation status for a transaction hash. |
| get_signing_statusA | Return a compact signing status summary derived only from the document response. |
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 8 tools
Most tools have clearly distinct purposes—list, get, verify, and the various evidence artifact retrievals are well separated. There is minor overlap between get_document's signing information and get_signing_status's signing summary, which could cause occasional misselection.
All tool names follow a consistent snake_case verb_noun pattern: list_documents, get_document, verify_document_hash, get_audit_events, and so on. The pattern is predictable and makes the group easy to navigate.
Eight tools is well within the ideal range for a document verification/evidence server. Each tool covers a distinct operation needed for verification workflows without being bloated or thin.
The server covers the core read-side workflow: listing, retrieving, hash verification, audit events, evidence manifests, certificates, chain attestation, and signing status. A minor gap is the absence of a direct signature or document-binary verification behavior, though the hash-only approach may be intentional.