Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

by io.github.Vortx-AI
OverviewDiscussionsAdmin

Attest that a phrasing/id denotes an existing object

emem_entity_link
Idempotent

Record a signed, ATTRIBUTED claim that a label or external id (GERS / OSM / Wikidata) denotes an existing object, or with stance: "disputes" that it does not. A shared-space write: it changes what other agents resolve, so it is stored with your key, rate-limited per key, and weighed by how many INDEPENDENT keys agree. One key's binding is shown to every reader as one key's claim, never as the answer.

When to use: Call when you can vouch that two phrasings denote one object, or to attach an authoritative external id; your key goes on the record. Use stance: "disputes" when another key's binding is wrong: recorded beside it, deletes nothing. Corroborating a correct single-key binding is useful in itself.

Example arguments: {"entity_token":"emem:entity:0a1b2c3d4e5f60718293","alias":"the north dam"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aliasNoAn alternate label/phrasing that should resolve to this object.
stanceNo`asserts` (default): this phrasing denotes this object. `disputes`: it does not. Both are attributed to your key and recorded append-only; a dispute is shown beside the binding it answers and deletes nothing.
entity_cidNoThe canonical object to attach an equivalence to. Provide entity_cid OR entity_token.
entity_tokenNoA `emem:entity:<entity_cid>` handle for the same.
external_idsNoStable ids to bind to this object.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / stance
      Added value: +{
+  "description": "`asserts` (default): this phrasing denotes this object. `disputes`: it does not. Both are attributed to your key and recorded append-only; a dispute is shown beside the binding it answers and deletes nothing.",
+  "enum": [
+    "asserts",
+    "disputes"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / entity_token / description
      Previous value: -"A `meme:<entity_cid>` handle for the same."New value: +"A `emem:entity:<entity_cid>` handle for the same."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say this is a non-destructive, idempotent, open-world write; the description goes well beyond with the important traits: signed and attributed to your key, shared-space effect on other agents' resolution, per-key rate limiting, agreement weighted by independent keys, append-only recording, and the guarantee that a dispute deletes nothing.

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?

Front-loaded with the core claim before the 'When to use' block and example; every sentence carries information about behavior or selection. The all-caps emphasis and dense clauses make it slightly heavier than needed, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter, nested-object, no-output-schema write tool, the description covers attribution, rate limits, dispute handling, and external id binding well. It stops short of describing the success/return behavior or what happens if an alias conflicts, which is the only remaining gap.

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 100%, so the baseline is 3, but the description adds real meaning: it explains the stance semantics and their consequence (a dispute is shown beside the binding it answers), names the external id systems (GERS/OSM/Wikidata), and provides a worked example using entity_token and alias.

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?

States a precise verb and resource: recording a signed, attributed claim that a label or external id denotes an existing object, plus the dispute variant. An agent can tell this is a write-side attestation tool rather than a read-side resolver like emem_entity_resolve without opening the schema.

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?

A dedicated 'When to use' block names the triggering conditions (vouching two phrasings denote one object, attaching an authoritative external id) and when to choose stance 'disputes' (another key's binding is wrong), plus that mere corroboration is useful. It does not explicitly point to a sibling for the read path, so it stops just short of full routing guidance.

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

All emem, the verifiable memory protocol for the physical world toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources