Skip to main content
Glama
clevertech-os

VeriLock MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VERILOCK_TOKENNoAPI 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_HOSTNoHost interface for the HTTP transport. Defaults to 127.0.0.1; the container sets 0.0.0.0.
VERILOCK_API_BASE_URLNoBase 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 8 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues