Skip to main content
Glama

Emer Ai Tools

This connector has been deprecated

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

Store memories (batch)

store_memory_batch

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.

Input Schema

NameRequiredDescriptionDefault
recordsYes1–100 items, each {"content_hash": "<digest>", "metadata": {...}}; metadata is optional. Same rules as store_memory for each item.

Output Schema

NameRequiredDescriptionDefault
txidYes
countYes
namesYes
quotaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / description
      Added value: +"One transaction for the whole batch: its id, every name written, and the\nwrites this account has left afterwards."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: all-or-nothing atomicity, signed-in session requirement, per-item naming, hash-only storage, batch consumption of FREE-tier write limits, and return semantics including transaction id and pending/confirmed status.

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?

The definition is front-loaded with the main purpose and then covers atomicity, auth, limits, and return status efficiently. It is slightly longer than minimal but nearly every sentence carries operational value.

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?

For a batch mutation with authentication, rate limiting, atomicity, and asynchronous confirmation behavior, the description covers the information an agent needs to invoke it correctly. The output schema exists, but the description still appropriately explains the important return status behavior.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema handles the basic shape. The description still adds useful meaning by explaining that `content_hash` determines the on-chain name and that only hashes and metadata are recorded, never content.

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?

The description states a specific verb and resource: anchoring many fingerprints in one on-chain transaction. It distinguishes the batch operation from the sibling `store_memory` by explaining that each item becomes the same kind of memory record but in a single transaction.

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?

It gives clear usage context: recording a session's worth of artifacts without one write per minute, and it references `store_memory` for the per-item behavior. It does not explicitly say when a caller should use single `store_memory` instead, but the batching use case is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources