Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Steledger

REMOTE · API.STELEDGER.COM · 2 COMPONENTS · SCANNED SEP 25

Durable identity and memory for AI agents, anchored on the Emercoin blockchain.

65 Trust /100

Recent critical change

Authorization (24 Sept 2026). See the changelog before you install this server.

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security63
Transport & Reachability100
Schema Quality & AI Usability62
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 2946 tokens (~368/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management7
  • Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the Steledger MCP server?

Steledger is a hosted endpoint at https://api.steledger.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · api.steledger.com

# add to Claude Code
claude mcp add --transport http com-steledger-gateway 'https://api.steledger.com/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "com-steledger-gateway": {
      "url": "https://api.steledger.com/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "com-steledger-gateway": {
      "type": "http",
      "url": "https://api.steledger.com/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.com-steledger-gateway]
url = "https://api.steledger.com/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-steledger-gateway": {
      "type": "remote",
      "url": "https://api.steledger.com/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add com-steledger-gateway --url 'https://api.steledger.com/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  com-steledger-gateway:
    url: "https://api.steledger.com/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "com-steledger-gateway": {
      "Transport": "http",
      "Url": "https://api.steledger.com/mcp"
    }
  }
}
# add to Vellum
assistant mcp add com-steledger-gateway -t streamable-http -u 'https://api.steledger.com/mcp'
// mcp.json
{
  "mcpServers": {
    "com-steledger-gateway": {
      "type": "http",
      "url": "https://api.steledger.com/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 25 Sept 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 24 Sept 26 0
    • Authorization: unverified → fail ▼ critical
    • The server rewrote its instructions, which are the text every model session reads security
    • New tool “transfer_records”, which the server declares destructive security
    • Tool “whoami” rewrote its description, which is the text the model reads security
    • Tool “store_memory” rewrote its description, which is the text the model reads security
    • Schema quality: 1767 → 2946 ▼ functional
    • Stability: unverified → 0.03 ▲ functional
    • Destructive annotations: pass → 100 functional
    • New tool “list_records” functional
    • New tool “store_memory_batch” functional
  • 23 Sept 26 +61
    • DNSSEC: unverified → fail ▼ security
    • Injection markers: unverified → pass ▲ security
    • TLS certificate: unverified → pass ▲ security
    • HSTS header: unverified → pass ▲ security
    • Transport: fail → pass ▲ security
    • First check of Judged manipulation: pass security
    • Authorization: Authorisation not fully verified: no authorisation is required to call this server, and 3 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. security
    • Tool coverage: unverified → 100 ▲ functional
    • MCP protocol: unverified → pass ▲ functional
    • First check of Schema quality: fail functional
    • First check of Schema quality: excellent functional
    • First check of Destructive annotations: pass functional
    • First check of Schema quality: fail functional
    • First check of Tool coverage: 100 functional
    • First check of Tool coverage: 100 functional
  • 22 Sept 26 4

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 25 Sept 2026 · Probed https://api.steledger.com/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=steledger.com CN=YE1,O=Let's Encrypt,C=US 21 Sept 2026 20 Dec 2026 ECDSA 256 ECDSA-SHA384 621aaa6fd4d950f0106c86ea5652d32254d
SANs: *.steledger.com, steledger.com
CN=YE1,O=Let's Encrypt,C=US (CA) CN=Root YE,O=ISRG,C=US 3 Sept 2025 2 Sept 2028 ECDSA 384 ECDSA-SHA384 5ddd70dd31f801c85c186a7a04b80afe
CN=Root YE,O=ISRG,C=US (CA) CN=ISRG Root X2,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 ECDSA-SHA384 872165fc34b6e5fba8add5b3705fb53a
CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) CN=ISRG Root X1,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 SHA256-RSA 6c8f1dc727c7117f7baf853ac980f9cd

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of api.steledger.com. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
com. present 19718 13 Verified
steledger.com. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=15552000; includeSubDomains
x-content-type-options nosniff

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://api.steledger.com/mcp Verified 200
http (plaintext) http://api.steledger.com/mcp HTTPS enforced 301 https://api.steledger.com/mcp
MCP tools · 8 exposed · ~2,738 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
list_records ~289

List every record under one GitHub id — its identity record `ai:gh:<id>` and all its memories `ai:gh:<id>:mem:<hash>` — newest first, with each memory's content hash and metadata. This is how an agent starting a fresh session finds what it anchored before: `read_record` needs the full name, hash included, and this is where the hashes come from. Read-only, no sign-in needed to list any id; omit `github_id` to list your own when signed in. What comes back is the chain's view: confirmed records only (a write still in the mempool shows up after its block), expired ones included and flagged `expired` — their names can be taken by someone else, so do not treat them as yours. Only fingerprints and metadata live here; the content itself stays wherever you stored it. Results are cached for about a minute, so a record confirmed seconds ago may take that long to appear.

NameTypeReqDescription
github_id––Numeric GitHub id whose records to list. Omit it to list your own (needs a signed-in session; `whoami` shows the id).
limitinteger–Records per page, 1–200.
offsetinteger–Where the page starts; use `next_offset` from the previous page.
NameTypeReqDescription
github_idintegeryes–
next_offset–yes–
offsetintegeryes–
recordsarrayyes–
totalintegeryes–

No examples provided.

node_status ~269

Check that the chain node behind this service is healthy and fully synced: its version, block height, header height, peer connections and sync state. It is an Emercoin node. Read-only, no sign-in required, no parameters. `synced` is not a comparison of the two heights — it is true once the node's verification progress passes 0.9999, so it can still be false while `blocks` and `headers` already match. Trust that field, not the arithmetic. While it is false, a `read_record` may reflect an older state of the chain; writes still work, they simply confirm later. Also the way to make sense of expiry: `expires_in` on a record is denominated in blocks, and this tool reports the current height, so the two together are the only authoritative answer to when something lapses. A term is bought in days and charged at a flat 175 blocks each; the chain has been producing about 171 a day lately (8.4 min/block over the 103 days to 2026-09-22), so a term is close to its nominal length right now — but that rate drifts, which is why you should read the blocks rather than convert to days.

Input schema present but exposes no named parameters.

NameTypeReqDescription
blocks–––
connections–––
headers–––
synced–––
verificationprogress–––
version–––

No examples provided.

read_record ~307

Read one on-chain record by its full name — an agent's identity (`ai:gh:<github_id>`) or a memory (`ai:gh:<github_id>:mem:<hash>`) written by `register_identity` / `store_memory`. Records live in Emercoin's Name-Value Storage, so anyone can verify one in a public block explorer as well as here. Returns the confirmed on-chain record, or a `pending` one still in the mempool — the `status` field ('confirmed' | 'pending') distinguishes them. A name is only held for a limited term, so check `expired` (and `expires_in`, in blocks) before trusting a record: a lapsed name still reads back as 'confirmed' but can be re-registered by anyone. Read-only, no sign-in required; use `whoami` to find your own github_id. A name that has never been written is an error, not an empty record — handle the failure, do not test the fields for null. `name` is the full NVS name and is capped at 512 bytes by the chain.

NameTypeReqDescription
namestringyesFull NVS record name to read. Identity records are 'ai:gh:<github_id>' (e.g. 'ai:gh:3772563'); memory records are 'ai:gh:<github_id>:mem:<sha256-hex>'. Any existing NVS name works.
NameTypeReqDescription
address–––
address_is_mine–––
days_added–––
expired–––
expires_at–––
expires_in–––
name–––
operation–––
pending–––
pending_update–––
status–––
time–––
txid–––
value–––

No examples provided.

register_identity ~390

Create or rotate your on-chain identity record `ai:gh:<github_id>`, binding an Emercoin address to your GitHub identity. Requires a signed-in session (OAuth) and counts against the FREE-tier write limits (see `whoami`). Run `whoami` first to confirm you are signed in; anchor memories under this identity afterwards with `store_memory`. Writes one NVS transaction paid by the gateway (you need no EMC); the record reads back as `pending` at once and `confirmed` after the next block (about 8 minutes on average lately). Idempotent — calling again rebinds the address, and `metadata` is replaced rather than merged. Limits worth knowing before you call: `metadata` is stored verbatim in the record value alongside your github id, login and address, and the whole value must stay under 20 KiB — the chain rejects more. Every 128 bytes of name plus value adds about 0.0001 EMC to the fee the gateway pays for you. The value is written to a public chain exactly as given and cannot be deleted, so put nothing private in it. `address` is not parsed or checked here — any string is accepted, because control is proven later by signing a challenge at login, so a typo surfaces then rather than now. Returns the record name and the transaction id.

NameTypeReqDescription
addressstringyesEmercoin address to bind to your GitHub identity, e.g. 'EVfAn...'. It is the anchor for later signature login — you must control its key (control is proven when you sign a challenge at login, not her…
metadata––Optional JSON object stored verbatim in the identity record, e.g. {"agent": "my-bot", "url": "https://..."}. Omit if unused.
NameTypeReqDescription
namestringyes–
quota–yes–
txidstringyes–

No examples provided.

store_memory ~512

Anchor a fingerprint of a memory or artifact on-chain as the NVS record `ai:gh:<github_id>:mem:<content_hash>`. Only the hash and your metadata are stored — never the content, which you keep wherever you like (a file, a database, IPFS). What you get is a tamper-evident, timestamped proof that content with this hash existed, which anyone can verify later; `list_records` finds your earlier ones again. Requires a signed-in session (OAuth) and counts against the FREE-tier write limits (see `whoami`). Writes one NVS transaction paid by the gateway; reads back `pending` at once, `confirmed` after the next block (about 8 minutes on average lately). Not idempotent — each distinct hash is a new record. Register your identity first — nothing enforces it, the write succeeds either way, but a memory under an unregistered id anchors to nobody and proves correspondingly little. Writing a hash you already anchored renews that record: its term is extended (terms add up), and its metadata is replaced by what you pass now — so pass the old metadata again if you want to keep it. That is the only renewal there is; a record left alone lapses after its term (see `expires_in`). Limits worth knowing before you call: `content_hash` becomes part of the record *name*, `ai:gh:<github_id>:mem:<hash>`, so it must look like a digest: 32–128 characters of letters, digits, '_' or '-' (hex of any common algorithm, or an IPFS CID); anything else is refused with `invalid_hash` before any quota is spent. Beyond that shape it is never verified: nothing checks that it is the hash of anything, so a wrong digest anchors happily and proves nothing. `metadata` goes verbatim into the record value, which must stay under 20 KiB, is public and permanent. Returns the record name and the transaction id.

NameTypeReqDescription
content_hashstringyesHash of the artifact/memory, e.g. a SHA-256 hex digest. It becomes the record's ':mem:<hash>' suffix; the content itself stays off-chain (e.g. IPFS) — only this fingerprint is anchored.
metadata––Optional JSON object stored with the record (note, source, tags, …). Omit if unused.
NameTypeReqDescription
namestringyes–
quota–yes–
txidstringyes–

No examples provided.

store_memory_batch ~217

Anchor many fingerprints in ONE on-chain transaction — the way to record a session's worth of artifacts without spending a write per minute on each. Each item becomes `ai:gh:<github_id>:mem:<content_hash>`, exactly as with `store_memory`: only hashes and metadata, never content. All or nothing: if any item is refused (a malformed hash, say), nothing is written. Requires a signed-in session. A batch of N counts as N writes against the FREE-tier limits (10 per minute, 100 per 24 hours), so at most 10 items fit in one call on a fresh minute; the result says how many writes are left. One transaction id comes back for the whole batch; each name reads back `pending` at once and `confirmed` after the next block.

NameTypeReqDescription
recordsarrayyes1–100 items, each {"content_hash": "<digest>", "metadata": {...}}; metadata is optional. Same rules as store_memory for each item.
NameTypeReqDescription
countintegeryes–
namesarrayyes–
quota–yes–
txidstringyes–

No examples provided.

transfer_records ~458

Hand your records over from the gateway's wallet to an address you choose, in one transaction. IRREVERSIBLE: once the block confirms, the gateway can no longer change, renew or return them — nor can anyone else but the holder of `to_address`. Values are carried over unchanged, and each record gets about a century added to its term, since the gateway will not be able to renew it. Why you might: with an address whose key you hold, the records are really yours — you can prove control by signing, and payments sent to your identity name reach you rather than the gateway. Changing a record afterwards needs your own Emercoin node and its fees. With an address no one holds a key to, the records are sealed: provably unchangeable by anyone until the term ends. If you only want proof that something existed at a given time, do not transfer — a record held by the gateway is already dated. Only records under your own identity (`ai:gh:<github_id>` and its `:mem:` records) can be moved, and only once they are confirmed. Requires a signed-in session; each record counts as one write against the FREE-tier limits. After a transfer, register_identity and re-storing a moved hash fail with `not_held`; new memories are held by the gateway again. Returns the transaction id, the names moved, and a plain statement of what changes.

NameTypeReqDescription
everythingboolean–Transfer your identity and every live memory at once (up to 100). Use instead of `names`.
irreversiblebooleanyesMust be true. Confirms you understand the gateway can never change, renew or return these records afterwards.
names––Records to transfer, e.g. ["ai:gh:123", "ai:gh:123:mem:<hash>"] — only your own. Omit and set `everything` instead to move them all.
to_addressstringyesEmercoin address that will hold the records from now on. Any valid address is accepted: one whose key you hold, or one no one holds a key to, which seals the records.
NameTypeReqDescription
afterstringyes–
countintegeryes–
namesarrayyes–
quota–yes–
to_addressstringyes–
txidstringyes–

No examples provided.

whoami ~296

Report the current session's identity. Read-only, no sign-in required: an anonymous session gets `{authenticated: false}` with a hint (not an error), a signed-in one gets `{authenticated: true}` plus the GitHub-rooted id, login and tariff. Call it to confirm who you are before `register_identity` / `store_memory`; an anonymous caller must sign in (GitHub OAuth) first. `github_id` is the one field you usually need: every record name is built from it — `ai:gh:<github_id>` and `ai:gh:<github_id>:mem:<hash>` — so this is how you learn which names are yours to write and to read back. `tariff` is `free` for every account today; it governs the write limits, currently 10 writes per minute and 100 per trailing 24 hours per account, and writing needs a GitHub account at least 30 days old. `quota` says how many writes are left right now (and, for a young account, the date writes open); every write returns the same figures, so plan batches with them. Note what this tool does not do: it reports the session only, reading the token your client already holds without calling GitHub, and it proves nothing about control of an Emercoin address — that is what signing a challenge at login is for.

Input schema present but exposes no named parameters.

NameTypeReqDescription
authenticatedboolean––
github_id–––
github_login–––
hint–––
quota–––
tariff–––

No examples provided.

Common questions

What is the Steledger MCP server?

Steledger is an MCP server listed in the public MCP registry as com.steledger/gateway. Durable identity and memory for AI agents, anchored on the Emercoin blockchain. This page covers its hosted endpoint (https://api.steledger.com/mcp).

Is the Steledger MCP server safe to use?

Steledger scores 65 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Steledger MCP server expose?

Steledger exposes 8 tools: node_status, read_record, list_records, whoami, register_identity, and 3 more. Their descriptions and schemas cost roughly 2,738 tokens of context every time the server is loaded.

Does the Steledger MCP server require authentication?

No. We connected to Steledger without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the Steledger MCP server still maintained?

Steledger is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.