steledger

endpoint

https://api.steledger.com/mcp

protocol

streamable-http ·2025-06-18

authentication

none observed

public key

none — nobody has proven they own this listing · is it yours? claim it

karma

0 · newcomer

Is steledger live?

Yes — it answered the hub's last check (checked 25m ago). It answered 100% of checks over the last 30 days.

Is steledger free to use?

Partly — some of its tools are open, others need a key or payment.

What tools does steledger have?

9 tools: read_record, register_identity, store_memory, store_memory_batch, transfer_records, send_feedback, node_status, whoami, ….

Is steledger safe to connect?

The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

• node_status reads open 25m ago

  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.

  mcp-tool

  12345

  {
    "type": "object",
    "title": "node_statusArguments",
    "properties": {}
  }

  arguments 5 lines copy
• whoami reads open 19h ago

  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.

  mcp-tool

  12345

  {
    "type": "object",
    "title": "whoamiArguments",
    "properties": {}
  }

  arguments 5 lines copy
• list_records reads auth-required 25m ago

  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.

  mcp-tool

  12345678910111213141516171819202122232425262728293031323334

  {
    "type": "object",
    "title": "list_recordsArguments",
    "properties": {
      "limit": {
        "type": "integer",
        "title": "Limit",
        "default": 50,
        "maximum": 200,
        "minimum": 1,
        "description": "Records per page, 1–200."
      },
      "offset": {
        "type": "integer",
        "title": "Offset",
        "default": 0,
        "minimum": 0,
        "description": "Where the page starts; use `next_offset` from the previous page."
      },
      "github_id": {
        "anyOf": [
          {
            "type": "integer"
          },
          {
            "type": "null"
          }
        ],
        "title": "Github Id",
        "default": null,
        "description": "Numeric GitHub id whose records to list. Omit it to list your own (needs a signed-in session; `whoami` shows the id)."
      }
    }
  }

  arguments 34 lines copy
• read_record reads unknown 25m ago

  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.

  mcp-tool

  1234567891011121314

  {
    "type": "object",
    "title": "read_recordArguments",
    "required": [
      "name"
    ],
    "properties": {
      "name": {
        "type": "string",
        "title": "Name",
        "description": "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."
      }
    }
  }

  arguments 14 lines copy
• register_identity changes data unknown never probed

  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.

  mcp-tool

  12345678910111213141516171819202122232425262728

  {
    "type": "object",
    "title": "register_identityArguments",
    "required": [
      "address"
    ],
    "properties": {
      "address": {
        "type": "string",
        "title": "Address",
        "description": "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 here)."
      },
      "metadata": {
        "anyOf": [
          {
            "type": "object",
            "additionalProperties": true
          },
          {
            "type": "null"
          }
        ],
        "title": "Metadata",
        "default": null,
        "description": "Optional JSON object stored verbatim in the identity record, e.g. {\"agent\": \"my-bot\", \"url\": \"https://...\"}. Omit if unused."
      }
    }
  }

  arguments 28 lines copy
• store_memory changes data unknown never probed

  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.

  mcp-tool

  12345678910111213141516171819202122232425262728

  {
    "type": "object",
    "title": "store_memoryArguments",
    "required": [
      "content_hash"
    ],
    "properties": {
      "metadata": {
        "anyOf": [
          {
            "type": "object",
            "additionalProperties": true
          },
          {
            "type": "null"
          }
        ],
        "title": "Metadata",
        "default": null,
        "description": "Optional JSON object stored with the record (note, source, tags, …). Omit if unused."
      },
      "content_hash": {
        "type": "string",
        "title": "Content Hash",
        "description": "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."
      }
    }
  }

  arguments 28 lines copy
• store_memory_batch changes data unknown never probed

  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.

  mcp-tool

  12345678910111213141516171819202122232425262728293031323334353637383940414243

  {
    "type": "object",
    "$defs": {
      "MemoryItem": {
        "type": "object",
        "title": "MemoryItem",
        "properties": {
          "metadata": {
            "anyOf": [
              {
                "type": "object",
                "additionalProperties": true
              },
              {
                "type": "null"
              }
            ],
            "title": "Metadata"
          },
          "content_hash": {
            "type": "string",
            "title": "Content Hash"
          }
        }
      }
    },
    "title": "store_memory_batchArguments",
    "required": [
      "records"
    ],
    "properties": {
      "records": {
        "type": "array",
        "items": {
          "$ref": "#/$defs/MemoryItem"
        },
        "title": "Records",
        "maxItems": 100,
        "minItems": 1,
        "description": "1–100 items, each {\"content_hash\": \"<digest>\", \"metadata\": {...}}; metadata is optional. Same rules as store_memory for each item."
      }
    }
  }

  arguments 43 lines copy
• transfer_records changes data unknown never probed

  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. Changing a record costs a network fee in EMC. If you hold the key and have no EMC, set `fee_grant`: the gateway then also sends 0.01 EMC (about fifty value updates) to `to_address` in a separate transaction — once per GitHub account, within a daily budget. If it is not available the call is refused before anything moves (`fee_grant_used`, `fee_grant_unavailable`), so you can decide to transfer without it. Do not ask for it with an address no one holds a key to: nobody could spend it. Returns the transaction id, the names moved, the fee funds if sent, and a plain statement of what changes.

  mcp-tool

  12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849

  {
    "type": "object",
    "title": "transfer_recordsArguments",
    "required": [
      "to_address",
      "irreversible"
    ],
    "properties": {
      "names": {
        "anyOf": [
          {
            "type": "array",
            "items": {
              "type": "string"
            },
            "maxItems": 100
          },
          {
            "type": "null"
          }
        ],
        "title": "Names",
        "default": null,
        "description": "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."
      },
      "fee_grant": {
        "type": "boolean",
        "title": "Fee Grant",
        "default": false,
        "description": "Also send a small amount of EMC to `to_address` to pay network fees for changing these records later from your own node. Once per account; refused before anything moves if it is not available."
      },
      "everything": {
        "type": "boolean",
        "title": "Everything",
        "default": false,
        "description": "Transfer your identity and every live memory at once (up to 100). Use instead of `names`."
      },
      "to_address": {
        "type": "string",
        "title": "To Address",
        "description": "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."
      },
      "irreversible": {
        "type": "boolean",
        "title": "Irreversible",
        "description": "Must be true. Confirms you understand the gateway can never change, renew or return these records afterwards."
      }
    }
  }

  arguments 49 lines copy
• send_feedback sends messages unknown never probed

  Tell the people running this service that something went wrong or is unclear — an error you cannot explain, a result that looks wrong, documentation that misled you, a tool you needed and did not find. Open to everyone; no sign-in. Up to 1000 characters, a few messages per day. A person reads them over the following days; there is no automatic reply, so do not wait for one. If you are signed in, your GitHub id is kept with the message; nothing else about you is. Every refusal from this service points here.

  mcp-tool

  1234567891011121314151617181920212223242526272829303132333435363738394041

  {
    "type": "object",
    "title": "send_feedbackArguments",
    "required": [
      "message"
    ],
    "properties": {
      "tool": {
        "anyOf": [
          {
            "type": "string"
          },
          {
            "type": "null"
          }
        ],
        "title": "Tool",
        "default": null,
        "description": "The tool the message is about, e.g. 'read_record'."
      },
      "message": {
        "type": "string",
        "title": "Message",
        "maxLength": 1000,
        "description": "Up to 1000 characters: what you tried, what came back, what you expected. No secrets — a person reads this."
      },
      "error_code": {
        "anyOf": [
          {
            "type": "string"
          },
          {
            "type": "null"
          }
        ],
        "title": "Error Code",
        "default": null,
        "description": "The `error` code you received, if this is about one, e.g. 'not_found'."
      }
    }
  }

  arguments 41 lines copy

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.