# Steledger (remote · api.steledger.com)

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

- Trust score: 65/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

> **Recent critical change**: Authorization (2026-09-24). See the changelog below before you install this server.

## Components

- remote · `api.steledger.com`: 65/100 (this document), [markdown](https://verifymcp.io/servers/com-steledger-gateway/api.md), [page](https://verifymcp.io/servers/com-steledger-gateway/api)
- oci · `ghcr.io/steledger/mcp:latest`: 38/100, [markdown](https://verifymcp.io/servers/com-steledger-gateway/ghcr-io-steledger-mcp-latest.md), [page](https://verifymcp.io/servers/com-steledger-gateway/ghcr-io-steledger-mcp-latest)

## Channel facts

- Endpoint: `https://api.steledger.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.3.0`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (transfer_records).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 7/100
  - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## 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.

### Claude

```bash
claude mcp add --transport http com-steledger-gateway 'https://api.steledger.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-steledger-gateway": {
      "url": "https://api.steledger.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-steledger-gateway": {
      "type": "http",
      "url": "https://api.steledger.com/mcp"
    }
  }
}
```

### Codex

```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
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-steledger-gateway --url 'https://api.steledger.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-steledger-gateway:
    url: "https://api.steledger.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-steledger-gateway": {
      "Transport": "http",
      "Url": "https://api.steledger.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-steledger-gateway -t streamable-http -u 'https://api.steledger.com/mcp'
```

### Other

```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 recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 65, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 65, 0)

- [critical regression] Authorization: unverified → fail
- [security] 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
- [functional regression] Schema quality: 1767 → 2946
- [functional improvement] Stability: unverified → 0.03
- [functional] Destructive annotations: pass → 100
- [functional] New tool “list_records”
- [functional] New tool “store_memory_batch”

### 2026-09-23 (score 65, +61)

- [security regression] DNSSEC: unverified → fail
- [security improvement] Injection markers: unverified → pass
- [security improvement] TLS certificate: unverified → pass
- [security improvement] HSTS header: unverified → pass
- [security improvement] 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.
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] 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

### 2026-09-22 (score 4)

First indexed and scored.

## MCP tools (8)

### `node_status` (~269 tokens)

Node status

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.

Output parameters:

- `blocks`
- `connections`
- `headers`
- `synced`
- `verificationprogress`
- `version`

### `read_record` (~307 tokens)

Read NVS record

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.

Input parameters:

- `name` (string, required): Full 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.

Output parameters:

- `address`
- `address_is_mine`
- `days_added`
- `expired`
- `expires_at`
- `expires_in`
- `name`
- `operation`
- `pending`
- `pending_update`
- `status`
- `time`
- `txid`
- `value`

### `list_records` (~289 tokens)

List records

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.

Input parameters:

- `github_id`: Numeric GitHub id whose records to list. Omit it to list your own (needs a signed-in session; `whoami` shows the id).
- `limit` (integer): Records per page, 1–200.
- `offset` (integer): Where the page starts; use `next_offset` from the previous page.

Output parameters:

- `github_id` (integer)
- `next_offset`
- `offset` (integer)
- `records` (array)
- `total` (integer)

### `whoami` (~296 tokens)

Who am I

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.

Output parameters:

- `authenticated` (boolean)
- `github_id`
- `github_login`
- `hint`
- `quota`
- `tariff`

### `register_identity` (~390 tokens)

Register identity

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.

Input parameters:

- `address` (string, required): Emercoin 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.

Output parameters:

- `name` (string)
- `quota`
- `txid` (string)

### `store_memory` (~512 tokens)

Store memory

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.

Input parameters:

- `content_hash` (string, required): Hash 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.

Output parameters:

- `name` (string)
- `quota`
- `txid` (string)

### `store_memory_batch` (~217 tokens)

Store memories (batch)

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.

Input parameters:

- `records` (array, required): 1–100 items, each {"content_hash": "<digest>", "metadata": {...}}; metadata is optional. Same rules as store_memory for each item.

Output parameters:

- `count` (integer)
- `names` (array)
- `quota`
- `txid` (string)

### `transfer_records` (~458 tokens)

Transfer records

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.

Input parameters:

- `everything` (boolean): Transfer your identity and every live memory at once (up to 100). Use instead of `names`.
- `irreversible` (boolean, required): Must 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_address` (string, required): Emercoin 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.

Output parameters:

- `after` (string)
- `count` (integer)
- `names` (array)
- `quota`
- `to_address` (string)
- `txid` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-steledger-gateway/api#diagnostics

## Score history

- 2026-09-25: 65
- 2026-09-24: 65
- 2026-09-23: 65
- 2026-09-22: 4

## 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.

## Links

- Remote endpoint: https://api.steledger.com/mcp
- Repository: https://github.com/steledger/steledger-gateway
- Website: https://api.steledger.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-steledger-gateway/api.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-steledger-gateway/api.json
- HTML version of this page: https://verifymcp.io/servers/com-steledger-gateway/api