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

Read NVS record

read_record
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesFull 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
timeNo
txidNo
valueNo
statusNo
addressNo
expiredNo
pendingNo
operationNo
days_addedNo
expires_atNo
expires_inNo
pending_updateNo
address_is_mineNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / expired
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Expired"
      +}
    • addedOutput schema / properties / expires_at
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Expires At"
      +}
    • addedOutput schema / properties / expires_in
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Expires In"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous 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."
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources