otskit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_timestampA | Creates a verifiable Bitcoin timestamp for a SHA-256 hash using the OpenTimestamps protocol. Submits the hash to four public OTS calendars (alice.btc, bob.btc, finney, catallaxy) and stores a pending proof locally. Returns a stamp ID to track confirmation status. Confirmation typically takes ~60 minutes but can take several hours during network congestion. |
| upgrade_timestampA | Attempts to upgrade a pending OpenTimestamps proof by fetching the latest merkle tree from the calendars. If Bitcoin has included the timestamp, the proof becomes confirmed and the bitcoin_block is recorded. Safe to call repeatedly — if not yet confirmed, it schedules the next retry automatically. |
| verify_timestampA | Verifies a timestamp proof against the Bitcoin blockchain via an Esplora API. Proves that a specific hash existed before a given Bitcoin block height. Does NOT affirm document authorship, content truth, or legal validity — it only provides a cryptographic proof of existence at a point in time. |
| verify_external_proofA | Verifies an external OpenTimestamps .ots file against its covered local file. Both paths must pass the configured directory whitelist; the covered file uses the preservation size cap and the receipt has a separate 1 MiB cap. It does not read or modify the local stamp store. A confirmed result proves the file hash existed before the reported Bitcoin block; it does NOT prove authorship, content truth, legal validity, or preservation of linked assets. |
| inspect_timestampA | Reads a stored proof file from disk without any network calls. Returns proof metadata including size, number of calendar attestations (pending promises from OTS servers) and Bitcoin attestations. has_bitcoin_attestation reports only what the file claims — it is a structural check, not evidence that Bitcoin backs the claim. Use verify_timestamp, which checks the block header on-chain, before telling a user that a stamp is confirmed. |
| list_pendingA | Lists stamp records from the local database with their current status, retry count, and next scheduled upgrade time. Filter by status (pending, confirmed, failed), page through results, or find stamps older than N hours. Use this to monitor the state of all timestamped hashes. |
| hash_fileA | Computes the SHA-256 hash of a local file and returns it as a 64-character hex string. Purely local — no network calls, no data stored. Use this to get the hash before calling create_timestamp, or to verify the integrity of a file independently. |
| stamp_fileA | Convenience tool that hashes a local file and stamps it on Bitcoin in one step. Computes the SHA-256 of the file, then submits it to four public OTS calendars. The file contents are never sent externally — only the hash is. Returns a stamp ID for tracking confirmation. |
| watchA | Opens a new terminal window that continuously monitors pending stamps and attempts due upgrades at each interval. Useful for long-running monitoring sessions after stamping. The window remains open so the user can watch confirmation progress in real time. Minimum interval is 15 minutes to avoid hammering OTS calendars. |
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 9 tools
Each tool maps to a distinct stage of the timestamping workflow: hashing, stamping, monitoring, upgrading, and verifying. Even the overlapping create_timestamp and stamp_file are clearly differentiated as hash-based vs. file convenience operations.
Most tools follow a clear verb_noun snake_case pattern such as hash_file, create_timestamp, and verify_external_proof. The single-verb watch and adjective-based list_pending are minor deviations from an otherwise predictable scheme.
Nine tools is a well-scoped count for an OpenTimestamps-based server. Each tool serves a meaningful step in the lifecycle without unnecessary redundancy, and the convenience tools are justified by common workflows.
The tool set covers the full OpenTimestamps lifecycle: hashing, creating timestamps, stamping files, listing pending proofs, upgrading, and verifying both internal and external proofs. No critical missing operation is apparent for the domain.