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
Scored across 5 tools
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.
Report 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 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.
Create 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.
Anchor 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.
Report 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
read_record1 field changedInput schema / properties / name / descriptionPrevious 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."register_identity2 fields changedInput schema / properties / address / descriptionPrevious value: -"Your Emercoin address to bind to your GitHub identity (the anchor for signature login)."New value: +"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)."Input schema / properties / metadata / descriptionPrevious value: -"Optional free-form JSON metadata to store with the identity record."New value: +"Optional JSON object stored verbatim in the identity record, e.g. {\"agent\": \"my-bot\", \"url\": \"https://...\"}. Omit if unused."store_memory2 fields changedInput schema / properties / content_hash / descriptionPrevious 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."Input schema / properties / metadata / descriptionPrevious value: -"Optional free-form JSON metadata (note, source, tags, …)."New value: +"Optional JSON object stored with the record (note, source, tags, …). Omit if unused."whoami13 fields changedOutput schema / properties / authenticatedAdded value: +{
+ "default": null,
+ "title": "Authenticated",
+ "type": "boolean"
+}Output schema / properties / github_id / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / github_id / defaultAdded value: +nullOutput schema / properties / github_id / typeRemoved value: -"integer"Output schema / properties / github_login / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / github_login / defaultAdded value: +nullOutput schema / properties / github_login / typeRemoved value: -"string"Output schema / properties / hintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hint"
+}Output schema / properties / tariff / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tariff / defaultAdded value: +nullOutput schema / properties / tariff / typeRemoved value: -"string"Output schema / requiredRemoved value: -[
- "github_id",
- "github_login",
- "tariff"
-]Output schema / titlePrevious value: -"Identity"New value: +"WhoAmI"node_statusread_recordregister_identitystore_memorywhoamiClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
