Skip to main content
Glama
Sign In
DMT Receipts

DMT Receipts

by Colchora
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

verify_inscription

Recompute a dmt-memory/v1 SHA-256 hash and compare it against Bitcoin Ordinals inscription content bytes to confirm integrity, with optional Trac index metadata and explorer links.

Instructions

Recompute the canonical SHA-256 of a dmt-memory/v1 object and, when inscription_id is provided, attempt to fetch Ordinals content and compare bytes. Extension fields on memory are included in the hash. Optionally enrich with soft-fail Trac Network TAP/DMT index metadata (deployment, mint holder, transfer amount, accumulator). Returns explorer links plus a trac object. Does not use calendar digest proofs. Browser UI: https://misty-flame-3nw3.here.now/#verify

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "memory": "<memory>"
    },
    "name": "verify_inscription"
  }
}

Input Schema

NameRequiredDescriptionDefault
txidNoOptional Bitcoin transaction id
memoryYesFull dmt-memory/v1 object (agent_id, key, content, tags, created_at). Optional extension fields are hashed.
sha256NoOptional expected hex digest to cross-check
include_tracNoWhen inscription_id is set, query Trac TAP/DMT index metadata (default true). Soft-fails if Trac is down.
fetch_contentNoFetch inscription content from ordinals.com when inscription_id is set (default true)
inscription_idNoBitcoin Ordinals inscription id (txid + 'i' + index)
trac_rest_baseNoOptional self-hosted tap-reader REST origin. Falls back to env DMT_TRAC_REST, then public Socket.IO at tap.trac.network.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses that extension fields are included in the hash, that Trac enrichment is soft-fail and can be disabled, that failures on the Trac side do not abort, and that external fetches go to ordinals.com and public Socket.IO at tap.trac.network. It stops short of stating whether the call is read-only end to end and what happens when a fetched byte comparison fails, so the side-effect and error surface remain partly inferred.

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

Conciseness4/5

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

The core action is front-loaded and every clause carries information — hashing scope, network comparison, soft-fail enrichment, exclusions. It is dense but not padded, though the final two sentences (calendar-proof exclusion and browser UI URL) read as trailing notes that dilute the main thread.

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

Completeness3/5

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

For a 7-parameter tool with a nested object, no annotations and no output schema, the description covers inputs and network behavior well but leaves the verdict underspecified. It says it returns 'explorer links plus a trac object' yet never states the core outcome shape (matched vs mismatched, expected vs computed digest), which is exactly what the caller needs. An agent can invoke it, but cannot confidently script against the response.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description earns above that by clarifying that extension fields on memory participate in the hash and by enumerating what the Trac enrichment actually yields (deployment, mint holder, transfer amount, accumulator). That meaning is not deducible from the schema's terse parameter descriptions. Only the sha256 and txid parameters get no added explanation beyond their schema text.

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

Purpose4/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: 'Recompute the canonical SHA-256 of a dmt-memory/v1 object' and then says it compares bytes against Ordinals content. That is far more than a restatement of the name, and the conditional 'when inscription_id is provided' scopes it precisely. It never names the sibling prepare_memory, so an agent must infer the prepare-vs-verify split from the names alone.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: you call it to check a memory against an inscription, and supplying inscription_id opts into the network comparison. There are no explicit when-to-use or when-not statements, and no pointer to prepare_memory as the alternative for the pre-inscription path. The negative scope note 'Does not use calendar digest proofs' is helpful but is a boundary of method, not of use case.

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

Deploy Server

Other Tools