Skip to main content
Glama
tersignhq

tersign

Official
by tersignhq
OverviewSchemaSourceRelated ServersScoreDiscussions(2)Admin
TypeScript
Remote

Verify compliance record

verify_compliance_record

Check an action record's integrity offline: recompute its canonical digest, confirm the attestation matches, and recover the signer. Returns valid status, signer, and digest.

Instructions

Verify a Tersign action record against its attestation: recompute the record's canonical digest, confirm the attestation commits to that exact digest, and recover the signature. Fully OFFLINE — no network, no API key, no account. Use this for an action record (a disclosure or other non-payment agent action); use verify_receipt for a payment receipt. PASS proves integrity and internal consistency only. Authorship needs an out-of-band signer address: pass expectedSigner, or the identity is whatever the artifact claims about itself. Returns { valid, signer, digest }; on mismatch, valid:false plus the recovered signer and the recomputed digest.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recordYesthe action record object as issued (ComplianceRecordV1 shape). Pass the object, not a JSON string; any field edit changes the digest and fails verification — which is the point
attestationYesthe attestation that accompanies the record: the signature over the record digest, as returned alongside it at issuance
expectedSignerNo0x address the record MUST be signed by, obtained out-of-band (for the public ledger: https://tersign.ai/v1/ledger). Omit to recover the signer without enforcing it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.7
    • addedInput schema / properties / attestation / description
      Added value: +"the attestation that accompanies the record: the signature over the record digest, as returned alongside it at issuance"
    • addedInput schema / properties / expectedSigner / description
      Added value: +"0x address the record MUST be signed by, obtained out-of-band (for the public ledger: https://tersign.ai/v1/ledger). Omit to recover the signer without enforcing it"
    • addedInput schema / properties / record / description
      Added value: +"the action record object as issued (ComplianceRecordV1 shape). Pass the object, not a JSON string; any field edit changes the digest and fails verification — which is the point"
  2. First observedv0.2.0

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description carries the full burden and does so thoroughly. It discloses that the operation is fully offline with no network/API key/account, that PASS proves only integrity and internal consistency, and that authorship requires an out-of-band signer. It also specifies the return shape and mismatch behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place. The description front-loads the core purpose, then adds offline behavior, sibling routing, an important limitation, and the return format. It is dense but not bloated, with no redundant phrases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having nested object parameters, no output schema, and no annotations, the description fully equips an agent to call the tool correctly. It covers parameter handling, return values, failure behavior, offline constraints, and the distinction from the similarly named sibling tool verify_receipt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds meaningful parameter semantics: record must be passed as an object not a string, any field edit changes the digest, attestation is the signature returned at issuance, and expectedSigner is optional but enforces authorship. This goes well beyond the schema property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Verify a Tersign action record against its attestation', and details the mechanism (recompute canonical digest, confirm attestation commits, recover signature). It also distinguishes itself from verify_receipt, making its scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'Use this for an action record... use verify_receipt for a payment receipt.' It also tells the caller when to pass expectedSigner versus omit it, and warns that PASS only proves integrity, not authorship without an out-of-band signer address.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools