An identity and memory layer for AI agents on the Emercoin blockchain. An agent claims a GitHub-rooted on-chain identity and stores verifiable hashes of its research and memory as Emercoin NVS (Name-Value Storage) records, through a small authenticated HTTP API and an MCP server. Neutral and provider-independent — not tied to any single AI vendor. FREE
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.9/5 across 5 of 5 tools scored.
Each tool serves a distinct purpose: node health check, record reading, identity registration, memory storage, and session info. No overlapping functionalities.
All tool names follow a consistent verb_noun pattern with snake_case (node_status, read_record, register_identity, store_memory), except whoami which is a common convention and still fits the style.
With 5 tools covering node status, read, write identity/memory, and session, the scope is well-managed. No tool is redundant or missing for core functionality.
Core operations (check node, read, write identity/memory) are present, but missing listing/enumeration of records and an explicit sign-in tool are minor gaps.
node_statusNode statusAReport the Emercoin node's version, block height, header height, peer
connections and sync state (synced true once block == header height).
Read-only, no sign-in required, no parameters. Call it first in a session to
confirm the node is healthy and fully synced before trusting read_record or
writing with register_identity / store_memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| blocks | No | |
| synced | No | |
| headers | No | |
| version | No | |
| connections | No | |
| verificationprogress | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds specific behavioral details: what data is reported, that it's read-only, no sign-in, and the sync condition. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first states what tool does, second provides usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need to detail return values, but it already lists reported fields. Fully covers tool's purpose and guidance for a zero-parameter health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description explicitly states 'no parameters', compensating for absence. Schema coverage is 100% with empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses verb 'Report' and resource 'Emercoin node's version, block height, header height, peer connections and sync state', clearly distinguishing it from sibling tools by specifying it should be called first to confirm health before using other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call it first in a session to confirm the node is healthy and fully synced before trusting read_record or writing with register_identity / store_memory.' Also notes no parameters and no sign-in required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_recordRead NVS recordARead one Emercoin NVS (Name-Value Storage) 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.
Returns the confirmed on-chain record, or a pending one still in the mempool —
the status field ('confirmed' | 'pending') distinguishes them. Read-only, no
sign-in required; use whoami to find your own github_id. Returns null fields
for a name that does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 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. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| time | No | |
| txid | No | |
| value | No | |
| status | No | |
| address | No | |
| pending | No | |
| operation | No | |
| days_added | No | |
| pending_update | No | |
| address_is_mine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations, explaining return states (confirmed vs pending) and behavior for non-existent names (null fields). Annotations already declare readOnlyHint, idempotentHint, openWorldHint; description adds valuable behavioral detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each well-structured and informative. The first sentence states the core purpose, the second adds return format and usage hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), full annotations, and presence of output schema, the description covers all needed context: purpose, parameter format, return states, and alternative tool. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema: it specifies name patterns for identity and memory records, provides examples, and clarifies scope. Schema description coverage is 100%, but description still enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reads one Emercoin NVS record by full name, clearly identifying the resource and action. It distinguishes from sibling tools like register_identity and store_memory by specifying that this tool is for reading only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to read identity or memory records by full name. It provides guidance on finding one's own github_id via whoami, and implies when not to use (for writing or identity lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_identityRegister identityACreate or rotate your on-chain identity record ai:gh:<github_id>, binding an
Emercoin address to your GitHub identity. Requires a signed-in session (OAuth)
and counts against the FREE-tier per-minute write limit. Run whoami first to
confirm you are signed in; anchor memories under this identity afterwards with
store_memory. Writes one NVS transaction paid by the gateway (you need no EMC);
the record reads back as pending at once and confirmed after the next block
(~10 min on average). Idempotent — calling again rebinds the address. Returns the
record name and the transaction id.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Emercoin address to bind to your GitHub identity, e.g. 'EVfAn...'. It is the anchor for later signature login — you must control its key (control is proven when you sign a challenge at login, not here). | |
| metadata | No | Optional JSON object stored verbatim in the identity record, e.g. {"agent": "my-bot", "url": "https://..."}. Omit if unused. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| txid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details beyond annotations: requires OAuth session, counts against write limit, writes NVS transaction paid by gateway, record state transitions from pending to confirmed (~10 min), and idempotency. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single descriptive paragraph, well-structured and front-loaded with purpose. While it's slightly long, every sentence earns its place and adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, effects, timing, return values (record name and transaction id), and relationships to sibling tools. Complete given tool complexity and existing structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds context about address being an anchor for later login and metadata being stored verbatim, enriching meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or rotates an on-chain identity record, binding an Emercoin address to a GitHub identity. It uses specific verbs ('create or rotate') and distinguishes from siblings like whoami and store_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to run whoami first to confirm sign-in, and to use store_memory afterward. Also notes that it counts against a per-minute write limit and is idempotent, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_memoryStore memoryAInspectAnchor a memory/artifact on-chain as the NVS record
ai:gh:<github_id>:mem:<content_hash> — a tamper-evident fingerprint others can
verify later. Requires a signed-in session (OAuth) and counts against the
FREE-tier per-minute write limit. Writes one NVS transaction paid by the gateway;
reads back pending at once, confirmed after the next block (~10 min). Not
idempotent — each distinct hash is a new record. Register your identity first.
Returns the record name and the transaction id.
| 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| txid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral context beyond annotations: requires OAuth, has rate limits, writes a transaction, returns pending/confirmed states, and is not idempotent. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with no wasted words. It front-loads the core purpose and covers all key aspects efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return values (record name and transaction id) and the output schema exists. It could elaborate on output fields but is sufficient given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining the content hash is a SHA-256 hex digest that becomes the record suffix, and metadata is optional JSON. This enriches the schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Anchor a memory/artifact on-chain' as a tamper-evident fingerprint. It specifies the record format and purpose, distinguishing it from siblings like read_record and register_identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines prerequisites: a signed-in session and prior identity registration. It explains limitations (write limit, non-idempotent) and the transaction lifecycle, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiWho am IAReport the current session's identity. Read-only, no sign-in required: an
anonymous session gets {authenticated: false} with a hint (not an error),
a signed-in one gets {authenticated: true} plus the GitHub-rooted id, login
and tariff. Call it to confirm who you are before register_identity /
store_memory; an anonymous caller must sign in (GitHub OAuth) first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| hint | No | |
| tariff | No | |
| github_id | No | |
| github_login | No | |
| authenticated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds detailed behavior: anonymous vs signed-in responses, response format, and that no error is thrown for anonymous calls. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no wasted words. It front-loads the purpose, then provides behavioral details and usage guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters, the description fully explains the tool's behavior, response variants, and usage context. It covers everything an agent needs to invoke it correctly, especially given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, baseline is 4. The description doesn't need to add parameter info, but it explains the tool's purpose and responses effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the current session's identity, with a specific verb and resource. It distinguishes itself from siblings like register_identity and store_memory by explaining when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: call it before register_identity/store_memory, and anonymous callers must sign in first. This tells the agent when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
