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

TableJSON 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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.8/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?