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

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

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. Changed15 schema fields changed
    • addedOutput schema / description
      Added value: +"An NVS record (confirmed from the name DB, or pending from the mempool).\nA field that does not apply is left out: a pending record omits several.\n`status` says whether the write landed; `expired` says\nwhether the name is still held — a lapsed record still reads back as\n'confirmed'."
    • removedOutput schema / properties / address / default
      Removed value: -null
    • removedOutput schema / properties / address_is_mine / default
      Removed value: -null
    • removedOutput schema / properties / days_added / default
      Removed value: -null
    • removedOutput schema / properties / expired / default
      Removed value: -null
    • removedOutput schema / properties / expires_at / default
      Removed value: -null
    • removedOutput schema / properties / expires_in / default
      Removed value: -null
    • removedOutput schema / properties / name / default
      Removed value: -null
    • removedOutput schema / properties / operation / default
      Removed value: -null
    • removedOutput schema / properties / pending / default
      Removed value: -null
    • removedOutput schema / properties / pending_update / default
      Removed value: -null
    • removedOutput schema / properties / status / default
      Removed value: -null
    • removedOutput schema / properties / time / default
      Removed value: -null
    • removedOutput schema / properties / txid / default
      Removed value: -null
    • removedOutput schema / properties / value / default
      Removed value: -null
  2. 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"
      +}
  3. 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."
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses important behavior: records may be `confirmed` or `pending`, expired names still read back as confirmed but can be re-registered, no sign-in is required, and missing names are errors. These are exactly the operational traits an agent needs before trusting or invoking the tool.

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 information-dense and front-loaded: it defines the resource, gives name formats, explains return status and expiration semantics, then closes with error-handling guidance. Every sentence contributes 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?

Given the single required parameter, existing output schema, and rich annotations, the description is complete enough for correct invocation. It explains the important return fields (`status`, `expired`, `expires_in`) and the key failure mode without redundantly documenting the whole output schema.

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 carries the main parameter documentation. The description still adds useful meaning by emphasizing that `name` is the full NVS name, capped at 512 bytes by the chain, and by clarifying the identity versus memory naming forms.

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: read one on-chain NVS record by full name. It clearly distinguishes identity records from memory records and names the sibling tools that create them (`register_identity` / `store_memory`).

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: read one record by full name, use `whoami` to find your github_id, and treat a never-written name as an error rather than an empty record. It does not explicitly route listing/unknown-name cases to `list_records`, so it falls short of full alternative guidance.

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