com.steledger/gateway

Est-ce que com.steledger/gateway est sûr ?

Au dernier audit MCP Hub, le serveur MCP « com.steledger/gateway » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 9 outils

• list_records≈ 762 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

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

  Exemple d'appel

  {"name": "list_records", "arguments": {"limit": 1, "offset": 1, "github_id": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"total": 1, "offset": 1, "records": [], "github_id": 1, "next_offset": "texte"}}

• node_status≈ 516 tokens

  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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "node_status", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"blocks": "texte", "synced": "texte", "headers": "texte", "version": "texte", "connections": "texte", "verificationprogress": "texte"}}

• read_record≈ 743 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • name · string · requis
    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.

  Exemple d'appel

  {"name": "read_record", "arguments": {"name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"name": "texte", "time": "texte", "txid": "texte", "value": "texte", "status": "texte", "address": "texte", "expired": "texte", "pending": "texte", "operation": "texte", "days_added": "texte", "expires_at": "texte", "expires_in": "texte"}}

• register_identity≈ 716 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • address · string · requis
    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 · ? · optionnel
    Optional JSON object stored verbatim in the identity record, e.g. {"agent": "my-bot", "url": "https://..."}. Omit if unused.

  Exemple d'appel

  {"name": "register_identity", "arguments": {"address": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"name": "texte", "txid": "texte", "quota": "texte"}}

• send_feedback≈ 413 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • tool · ? · optionnel
    The tool the message is about, e.g. 'read_record'.
  • message · string · requis
    Up to 1000 characters: what you tried, what came back, what you expected. No secrets — a person reads this.
  • error_code · ? · optionnel
    The `error` code you received, if this is about one, e.g. 'not_found'.

  Exemple d'appel

  {"name": "send_feedback", "arguments": {"message": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"id": "texte", "note": "texte", "received": true}}

• store_memory≈ 837 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • metadata · ? · optionnel
    Optional JSON object stored with the record (note, source, tags, …). Omit if unused.
  • content_hash · string · requis
    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.

  Exemple d'appel

  {"name": "store_memory", "arguments": {"content_hash": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"name": "texte", "txid": "texte", "quota": "texte"}}

• store_memory_batch≈ 605 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • records · array · requis
    1–100 items, each {"content_hash": "<digest>", "metadata": {...}}; metadata is optional. Same rules as store_memory for each item.

  Exemple d'appel

  {"name": "store_memory_batch", "arguments": {"records": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"txid": "texte", "count": 1, "names": [], "quota": "texte"}}

• transfer_records≈ 1208 tokens

  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.

  Paramètres, retour & exemple (5)

  Paramètres

  • names · ? · optionnel
    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 · boolean · optionnel
    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 · boolean · optionnel
    Transfer your identity and every live memory at once (up to 100). Use instead of `names`.
  • to_address · string · requis
    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 · boolean · requis
    Must be true. Confirms you understand the gateway can never change, renew or return these records afterwards.

  Exemple d'appel

  {"name": "transfer_records", "arguments": {"to_address": "texte", "irreversible": true}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"txid": "texte", "after": "texte", "count": 1, "names": [], "quota": "texte", "fee_grant": "texte", "to_address": "texte"}}

• whoami≈ 644 tokens

  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.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "whoami", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"hint": "texte", "quota": "texte", "tariff": "texte", "github_id": "texte", "github_login": "texte", "authenticated": true}}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://api.steledger.com/mcp