Emer Ai Tools

This connector has been deprecated

Moved to com.steledger/gateway — same service, now at https://api.steledger.com/mcp

Store memory

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 Schema

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.

Output Schema

Name	Required	Description	Default
`name`	Yes
`txid`	Yes
`quota`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedOutput schema / description

Added value: +"The on-chain write: the NVS name written, its transaction id, and the\nwrites this account has left afterwards."

Changed3 schema fields changedSep 23, 2026

addedOutput schema / $defs

Added 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"
+  }
+}

addedOutput schema / properties / quota

Added value: +{
+  "$ref": "#/$defs/Quota"
+}

changedOutput schema / required

Previous value: -[
-  "name",
-  "txid"
-]New value: +[
+  "name",
+  "txid",
+  "quota"
+]

Changed2 schema fields changedJun 15, 2026

changedInput schema / properties / content_hash / description

Previous 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."

changedInput schema / properties / metadata / description

Previous value: -"Optional free-form JSON metadata (note, source, tags, …)."New value: +"Optional JSON object stored with the record (note, source, tags, …). Omit if unused."

First observedJun 15, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses immediate `pending` status, `confirmed` after ~8 minutes, one NVS transaction paid by the gateway, FREE-tier write quota consumption, and that the write is non-idempotent because each distinct hash is a new record. It also explains renewal semantics (term extension, metadata replacement) and lapse behavior, which no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and record shape, then prerequisites, then renewal, then limits — a sensible order with no filler sentences. It is on the long side and repeats the record-name pattern twice, but the repetition serves the hash-format constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even with an output schema present, the description mentions the return (record name and transaction id), covers failure mode, quota cost, timing, and renewal conflict semantics. An agent has everything needed to decide whether and how to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds constraints the schema lacks: hash must be 32–128 chars of letters/digits/'_'/'-' or be rejected with `invalid_hash` before quota is spent, and that the hash is never verified against real content. It also bounds `metadata` under 20 KiB and warns it is public and permanent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: anchor a fingerprint of a memory/artifact on-chain as an NVS record with an explicit naming pattern `ai:gh:<github_id>:mem:<content_hash>`. It clearly delineates what is stored (hash + metadata) versus what is not (content), which distinguishes it from `list_records` and `read_record`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit prerequisites (signed-in OAuth session, register identity first), points to `whoami` for quota and `list_records` for retrieval, and explains the renewal condition (re-submitting an existing hash). It even flags the soft-failure case where an unregistered id still writes but proves little.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Emer Ai Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?