Moved to com.steledger/gateway — same service, now at https://api.steledger.com/mcp
Scored across 9 tools
Most tools target clearly distinct operations: identity registration, memory writing, reading, listing, transfer, session info, node health, and feedback. The only potential confusion is between store_memory and store_memory_batch, but the descriptions make the single-vs-batch distinction explicit. read_record vs list_records is clearly delineated.
Nearly all names follow a consistent snake_case verb_noun pattern (list_records, read_record, register_identity, store_memory, store_memory_batch, transfer_records, send_feedback). node_status and whoami break the verb_noun convention, but the overall pattern is predictable and readable.
Nine tools is well-scoped for a domain covering identity, memory anchoring, reading, listing, transfer, session and chain-status checks, and feedback. Each tool earns its place with no redundant entries.
The surface covers the full lifecycle well: identity create/rotate, memory write (single and batch), read, list, transfer, session and node status, plus feedback. Gaps are minor — no explicit renew or revoke tool (renewal piggybacks on store_memory) and no multi-id or cross-identity search, but these are documented and workable.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page, 1–200. | |
| offset | No | Where the page starts; use `next_offset` from the previous page. | |
| github_id | No | Numeric GitHub id whose records to list. Omit it to list your own (needs a signed-in session; `whoami` shows the id). |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| offset | Yes | |
| records | Yes | |
| github_id | Yes | |
| next_offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context: only confirmed records appear, expired records are included and flagged as reclaimable, only fingerprints and metadata are returned, and results are cached for about a minute. These are operational facts that the annotations alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, followed immediately by a concrete usage scenario and then operational caveats. Every clause earns its place: auth behavior, freshness, expiry semantics, content location, and caching delay are all relevant and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and safety annotations already present, the description fills the remaining gaps: how authentication works, what is visible, how expired records behave, where content lives, and why recent writes may be invisible. Pagination is already documented in the schema via next_offset, so nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for all three parameters, so the baseline is 3. The description repeats 'omit github_id to list your own' which the schema already says, and its other details like newest-first ordering and hashes relate to output behavior rather than parameter meaning. It adds little parameter-level value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List every record under one GitHub id', then enumerates the identity record and all memories, sorting order, and returned fields. It explicitly differentiates itself from sibling read_record, which needs full names and hashes, making this tool's role as the hash source unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case: an agent starting a fresh session uses this tool to find what it anchored before, and read_record is named as the follow-on that consumes these hashes. It also provides auth usage rules: no sign-in needed to list any id, and omit github_id to list your own when signed in. It does not explicitly enumerate when not to use it versus store_memory or register_identity, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| blocks | No | |
| synced | No | |
| headers | No | |
| version | No | |
| connections | No | |
| verificationprogress | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the readOnlyHint/idempotentHint annotations: synced is based on a 0.9999 verification threshold rather than a simple height comparison, and while it is false, reads may be stale but writes still work. This is exactly the kind of non-obvious runtime behavior an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are tight and front-loaded with the tool's purpose and access requirements. The later paragraphs are longer, especially the expiry/block-rate explanation, but they provide genuinely useful operational context rather than filler, so the description remains earned even if slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only status tool with an output schema and readOnlyHint/openWorldHint/idempotentHint annotations, the description covers everything needed: what the tool checks, what the synced field really means, how it relates to read_record, and authentication expectations. There are no missing gaps that would prevent correct invocation or interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema leaves nothing to explain; the description explicitly confirms 'no parameters' and 'no sign-in required'. This matches the baseline for a parameterless tool and adds no unnecessary param detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Check that the chain node behind this service is healthy and fully synced') and lists the exact fields reported: version, block height, header height, peer connections, and sync state. It does not explicitly name a sibling tool for differentiation, but the domain and scope are unambiguous enough that an agent can distinguish it from read_record, register_identity, and the others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you need to verify node health and sync status, and it explains the implication that a false synced flag may mean read_record reflects an older chain state. It does not explicitly say 'use this instead of X', but it provides enough operational guidance for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 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. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| time | No | |
| txid | No | |
| value | No | |
| status | No | |
| address | No | |
| expired | No | |
| pending | No | |
| operation | No | |
| days_added | No | |
| expires_at | No | |
| expires_in | No | |
| pending_update | No | |
| address_is_mine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/idempotentHint annotations: it explains the confirmed vs pending status field, the expiration caveat where lapsed names still read as confirmed, the error behavior for never-written names, and the 512-byte chain cap. These are non-obvious operational behaviors an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence delivers essential operational detail: record types, verification, status, expiry, read-only nature, error handling, and name format. It is front-loaded with the core purpose and structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description covers expected return nuances, failure modes, expiration, and security/access context without needing to explain the output schema. Agents have enough information to call it correctly and interpret results safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the name parameter at 100% coverage with examples, so the baseline is 3. The description adds value by clarifying the 512-byte cap, reinforcing error semantics, and explaining how identity vs memory names are structured, pushing it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one on-chain record by full name, specifically agent identity or memory records, tying to sibling writers. It distinguishes read_record from register_identity, store_memory, and whoami by naming the resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says records are written by register_identity/store_memory, tells the agent to use whoami to find its github_id, and notes this tool is read-only with no sign-in. This gives clear when-to-use context and points to the relevant sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | 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 | No | Optional JSON object stored verbatim in the identity record, e.g. {"agent": "my-bot", "url": "https://..."}. Omit if unused. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| txid | Yes | |
| quota | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses critical behaviors: it writes one NVS transaction paid by the gateway, the record reads as `pending` then `confirmed` after ~8 minutes, it is idempotent with metadata replaced rather than merged, metadata is stored verbatim and publicly and cannot be deleted, and the address is not parsed/checked here. No contradiction with annotations; it adds substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized into two logical paragraphs: first the core purpose and immediate effects, then the limits and edge cases. Every sentence adds useful information, so it earns its length. It is slightly verbose but not redundant, so a 4 is appropriate rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex write operation with external chain effects, yet the description covers prerequisites (signed-in session), immediate effects (pending/confirmed), idempotency, size/fee limits, privacy implications, and return values (record name and transaction id). With an output schema present, the return is also clarified. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds vital semantics: metadata must stay under 20 KiB or the chain rejects it, every 128 bytes adds ~0.0001 EMC to the gateway fee, and `address` is not validated because control is proven later via a signing challenge. These constraints are not in the schema and materially affect how an agent should call the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Create or rotate your on-chain identity record ai:gh:<github_id>'. It clearly distinguishes the tool from siblings like store_memory and whoami by stating its core function (binding an Emercoin address to a GitHub identity). The purpose is unambiguous and immediately differentiates it from the other tools in the set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to run `whoami` first to confirm sign-in, and to use `store_memory` afterwards to anchor memories. It also notes that the operation counts against FREE-tier write limits and references `whoami` for those limits. This gives clear when-to-use and when-not-to-use guidance, and points to the correct preceding and succeeding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | The tool the message is about, e.g. 'read_record'. | |
| message | Yes | Up to 1000 characters: what you tried, what came back, what you expected. No secrets — a person reads this. | |
| error_code | No | The `error` code you received, if this is about one, e.g. 'not_found'. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | Yes | |
| received | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-readonly, non-idempotent, non-destructive write; the description goes well beyond by disclosing human review over following days, absence of an automatic reply, rate limits (a few messages per day), and the privacy handling of the GitHub id. This is exactly the behavioral context an agent needs before committing a message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then constraints, then privacy, then the routing hint — a logical ordering with no filler. It runs slightly long at six sentences, but each sentence carries distinct operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return formatting need not be explained, and the annotations plus a rich description fully cover safety, delivery, privacy and rate constraints. Nothing needed to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description adds value not in the schema, notably the 'few messages per day' rate constraint and the explicit privacy note that nothing but the GitHub id is retained. It does not add format guidance for the optional tool/error_code params, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource (send feedback about the service) and enumerates the concrete triggers — errors, wrong results, misleading docs, missing tools — which cleanly separates it from every sibling (all record/memory/identity tools). An agent can identify the channel without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use conditions and a strong routing rule: 'Every refusal from this service points here', which tells the agent exactly when this tool is the intended fallback. Constraints (no sign-in, few per day) further scope usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Optional JSON object stored with the record (note, source, tags, …). Omit if unused. | |
| content_hash | Yes | 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| txid | Yes | |
| quota | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-idempotent, but the description goes far beyond: only hash and metadata are stored, writes are gateway-paid, status moves from pending to confirmed after about 8 minutes, same-hash writes renew and replace metadata, records lapse after their term, and invalid hashes are refused before quota. It also discloses that metadata is public, permanent, and limited to 20 KiB, and that the method returns the record name and transaction id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but every sentence earns its place: the opening establishes the core mechanism and trade-off, then later paragraphs efficiently cover renewal, limits, validation, and return values. The description is front-loaded with the record name and the key 'only hash and metadata stored' behavior, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers auth, quota, latency, renewal, expiration, validation failures, public/permanent metadata, and return values. An output schema exists for formal return structure, and the description provides all behavioral context an agent needs to decide and call the tool correctly, including the surprising renewal side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: content_hash must be 32–128 characters of letters, digits, '_' or '-', invalid shapes produce invalid_hash before quota, and the digest itself is not verified. It also clarifies that metadata is stored verbatim, is public and permanent, and must stay under 20 KiB.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies a single verb+resource: anchors the hash of a memory/artifact to an on-chain NVS record and explains the proof it provides. The record-name format makes scope concrete, and it distinguishes itself from sibling list_records by noting that list_records finds earlier records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides rich context: requires an OAuth session, counts against FREE-tier write limits, advises registering identity first, and points to whoami for limits and list_records for finding previous records. It stops short of explicitly mentioning when to choose store_memory_batch instead of this single-record tool, so it lacks a full when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | 1–100 items, each {"content_hash": "<digest>", "metadata": {...}}; metadata is optional. Same rules as store_memory for each item. |
| Name | Required | Description |
|---|---|---|
| txid | Yes | |
| count | Yes | |
| names | Yes | |
| quota | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses all-or-nothing atomicity, write accounting against rate limits, the signed-in session requirement, one transaction id for the whole batch, and pending/confirmed read-back behavior. These are precisely the side effects an agent needs to predict when invoking a batch write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized: core mechanism first, then item format, atomicity, auth and limits, and finally confirmation behavior. Every sentence contributes actionable information, with the most important transaction-level facts front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch write tool with one parameter, the description covers authentication, rate-limit costs, maximum practical batch size, failure atomicity, and return semantics. Since an output schema exists, not restating return fields is appropriate and does not create a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the `records` parameter, and the description adds operationally significant meaning: items are content_hash plus optional metadata, only hashes and metadata are stored, and callers should treat 10 as the practical batch ceiling even though the schema allows 100. It could be slightly more self-contained on hash rules, but it does point to `store_memory` for the same per-item rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: "Anchor many fingerprints in ONE on-chain transaction" and gives the exact record naming format `ai:gh:<github_id>:mem:<content_hash>`. It clearly distinguishes itself from `store_memory` by adding the batch dimension while preserving the same item semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when batching is appropriate: "a session's worth of artifacts without spending a write per minute on each," and states a hard practical limit of 10 items per fresh minute given free-tier limits. It references `store_memory` as the single-item counterpart but does not explicitly say "use `store_memory` for a single item."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No | 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 | No | 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 | No | Transfer your identity and every live memory at once (up to 100). Use instead of `names`. | |
| to_address | Yes | 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 | Yes | Must be true. Confirms you understand the gateway can never change, renew or return these records afterwards. |
| Name | Required | Description |
|---|---|---|
| txid | Yes | |
| after | Yes | |
| count | Yes | |
| names | Yes | |
| quota | Yes | |
| fee_grant | Yes | |
| to_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, non-idempotent, openWorld, but the description adds substantial context beyond them: irreversibility and what it means, the century-long term extension, exact failure modes ('not_held'), the fee_grant rate limit (once per GitHub account, daily budget) and its pre-flight refusal codes. This is rich behavioral disclosure the structured fields do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the IRREVERSIBLE warning, which is the right priority. It is long, and the 'Why you might' paragraph is expansive, but nearly every sentence carries decision-relevant information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an irreversible, open-world mutation with a 5-parameter schema, the description covers preconditions (signed-in session, confirmed records, own-identity-only), cost, failure modes, and downstream effects. The output schema handles return values, so nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the tradeoff of fee_grant (0.01 EMC, ~fifty updates, refused before anything moves) and the nuance of to_address sealing records when no one holds the key. Some of this duplicates the schema descriptions, but the decision rationale is additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('hand your records over from the gateway's wallet to an address you choose, in one transaction') and clearly distinguishes this from siblings like list_records, read_record and store_memory. An agent knows exactly what operation is being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to use it ('with an address whose key you hold, the records are really yours'), when not to ('If you only want proof that something existed at a given time, do not transfer'), and the sealed-address variant. This is a genuine decision guide, not just context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| hint | No | |
| quota | No | |
| tariff | No | |
| github_id | No | |
| github_login | No | |
| authenticated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond that: no sign-in required, anonymous sessions get a hint rather than an error, the tool reads the client-held token without calling GitHub, and it does not prove Emercoin address control. This fully discloses behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: it front-loads the core identity report, then covers usage context, field semantics, write-limit implications, and exclusions. The structure is logical and the length is justified given the tool has no parameters and must explain return semantics and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter identity-check tool, the description is complete: it covers output shape, authentication states, usage before related tools, naming conventions, write limits, quota, and what the tool does not prove. An agent has everything needed to call it correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are inherently minimal; the rubric assigns a baseline of 4 for 0-param tools. The description adds value by explaining the meaning of output fields like github_id, tariff, and quota, which helps the agent interpret the response even though there are no inputs to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report the current session's identity.' It clearly distinguishes this tool from siblings by stating what it does not do—it reports the session only輩and by naming related tools like register_identity and store_memory, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call it to confirm who you are before register_identity / store_memory,' and states when not to rely on it—'it proves nothing about control of an Emercoin address.' It also explains the anonymous vs. signed-in paths and the sign-in requirement, leaving no ambiguity about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
transfer_records4 fields changedInput schema / properties / fee_grantAdded value: +{
+ "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.",
+ "title": "Fee Grant",
+ "type": "boolean"
+}Output schema / $defs / FeeGrantResultAdded value: +{
+ "description": "Network-fee funds sent with a transfer: the amount in EMC, and the id of\nthe transaction that paid it — null if it could not be sent.",
+ "properties": {
+ "amount": {
+ "title": "Amount",
+ "type": "string"
+ },
+ "txid": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Txid"
+ }
+ },
+ "required": [
+ "amount",
+ "txid"
+ ],
+ "title": "FeeGrantResult",
+ "type": "object"
+}Output schema / properties / fee_grantAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FeeGrantResult"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "txid",
- "count",
- "names",
- "to_address",
- "after",
- "quota"
-]New value: +[
+ "txid",
+ "count",
+ "names",
+ "to_address",
+ "after",
+ "fee_grant",
+ "quota"
+]send_feedbacktransfer_recordslist_recordsregister_identity3 fields changedOutput schema / $defsAdded value: +{
+ "Quota": {
+ "description": "Writes this account has left on its tier. `writes_open_on` (a UTC date)\nappears only while the GitHub account is too new to write.",
+ "properties": {
+ "writes_left_this_minute": {
+ "title": "Writes Left This Minute",
+ "type": "integer"
+ },
+ "writes_left_today": {
+ "title": "Writes Left Today",
+ "type": "integer"
+ },
+ "writes_open_on": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Writes Open On"
+ }
+ },
+ "title": "Quota",
+ "type": "object"
+ }
+}Output schema / properties / quotaAdded value: +{
+ "$ref": "#/$defs/Quota"
+}Output schema / requiredPrevious value: -[
- "name",
- "txid"
-]New value: +[
+ "name",
+ "txid",
+ "quota"
+]store_memory3 fields changedOutput schema / $defsAdded value: +{
+ "Quota": {
+ "description": "Writes this account has left on its tier. `writes_open_on` (a UTC date)\nappears only while the GitHub account is too new to write.",
+ "properties": {
+ "writes_left_this_minute": {
+ "title": "Writes Left This Minute",
+ "type": "integer"
+ },
+ "writes_left_today": {
+ "title": "Writes Left Today",
+ "type": "integer"
+ },
+ "writes_open_on": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Writes Open On"
+ }
+ },
+ "title": "Quota",
+ "type": "object"
+ }
+}Output schema / properties / quotaAdded value: +{
+ "$ref": "#/$defs/Quota"
+}Output schema / requiredPrevious value: -[
- "name",
- "txid"
-]New value: +[
+ "name",
+ "txid",
+ "quota"
+]store_memory_batchwhoami2 fields changedOutput schema / $defsAdded value: +{
+ "Quota": {
+ "description": "Writes this account has left on its tier. `writes_open_on` (a UTC date)\nappears only while the GitHub account is too new to write.",
+ "properties": {
+ "writes_left_this_minute": {
+ "title": "Writes Left This Minute",
+ "type": "integer"
+ },
+ "writes_left_today": {
+ "title": "Writes Left Today",
+ "type": "integer"
+ },
+ "writes_open_on": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Writes Open On"
+ }
+ },
+ "title": "Quota",
+ "type": "object"
+ }
+}Output schema / properties / quotaAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Quota"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}read_record3 fields changedOutput schema / properties / expiredAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expired"
+}Output schema / properties / expires_atAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expires At"
+}Output schema / properties / expires_inAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expires In"
+}read_record1 field changedInput schema / properties / name / descriptionPrevious value: -"Full NVS record name, e.g. 'ai:gh:<github_id>:mem:<sha256-hex>'."New value: +"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."register_identity2 fields changedInput schema / properties / address / descriptionPrevious value: -"Your Emercoin address to bind to your GitHub identity (the anchor for signature login)."New value: +"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)."Input schema / properties / metadata / descriptionPrevious value: -"Optional free-form JSON metadata to store with the identity record."New value: +"Optional JSON object stored verbatim in the identity record, e.g. {\"agent\": \"my-bot\", \"url\": \"https://...\"}. Omit if unused."store_memory2 fields changedInput schema / properties / content_hash / descriptionPrevious value: -"Content hash (e.g. SHA-256 hex) of the artifact/memory; the body itself is stored off-chain."New value: +"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."Input schema / properties / metadata / descriptionPrevious value: -"Optional free-form JSON metadata (note, source, tags, …)."New value: +"Optional JSON object stored with the record (note, source, tags, …). Omit if unused."whoami13 fields changedOutput schema / properties / authenticatedAdded value: +{
+ "default": null,
+ "title": "Authenticated",
+ "type": "boolean"
+}Output schema / properties / github_id / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / github_id / defaultAdded value: +nullOutput schema / properties / github_id / typeRemoved value: -"integer"Output schema / properties / github_login / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / github_login / defaultAdded value: +nullOutput schema / properties / github_login / typeRemoved value: -"string"Output schema / properties / hintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hint"
+}Output schema / properties / tariff / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tariff / defaultAdded value: +nullOutput schema / properties / tariff / typeRemoved value: -"string"Output schema / requiredRemoved value: -[
- "github_id",
- "github_login",
- "tariff"
-]Output schema / titlePrevious value: -"Identity"New value: +"WhoAmI"node_statusread_recordregister_identitystore_memorywhoami
Add one secure layer between your agents and this server.