Skip to main content
Glama
Vortx-AI

emem

by Vortx-AI
OverviewSchemaSourceRelated ServersDiscussions(2)Admin
Rust
Remote

Attest that a phrasing/id denotes an existing object

emem_entity_link
Idempotent

Record a signed, attributed claim binding a label or external ID (GERS, OSM, Wikidata) to an existing entity, or dispute another key's binding in shared memory.

Instructions

Record a signed, ATTRIBUTED claim that a label or an external id (GERS, OSM, Wikidata) names an existing object. With stance: "disputes", record that it does not. This is a write to the shared space: it changes what other agents resolve. The responder stores it with your key, limits the rate for each key, and weighs it by how many INDEPENDENT keys agree. Every reader sees the binding of one key as the claim of one key, never as the answer.

When to use: Call this when you can confirm that two names mean one object, or to attach an authoritative external id. Your key goes on the record. Use stance: "disputes" when the binding of another key is wrong. The dispute goes beside it and deletes nothing. A second key on a correct single-key binding is useful by itself.

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

Input 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.
attesterNoed25519 binding, verified. Omit it and the refusal's details.how_to_sign gives the digest to sign.
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. Changed2 schema fields changedv2.4.4
    • addedInput schema / properties / attester
      Added value: +{
+  "description": "ed25519 binding, verified. Omit it and the refusal's details.how_to_sign gives the digest to sign.",
+  "properties": {
+    "pubkey_b32": {
+      "type": "string"
+    },
+    "sig_b32": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "pubkey_b32",
+    "sig_b32"
+  ],
+  "type": "object"
+}
    • 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. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover only the safety/idempotency profile; the description adds what they cannot: attribution to your key, per-key rate limiting, weighting by independent keys, that a dispute is shown beside the binding and deletes nothing, and that readers never see one key's binding as the answer. These are exactly the behavioral traits an agent must know before writing to a shared space.

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 purpose, then mechanism, then 'When to use:', then example arguments. Every sentence carries information, though the mechanism sentence is dense and packed with several distinct claims.

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 6-parameter signed write with nested objects and no output schema, the description covers intent, signing/attribution, rate limits, dispute semantics and an example. It does not describe the success response (e.g., a receipt or CID), which is the only notable 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 baseline is 3, but the description adds stance semantics in prose ('with stance: "disputes", record that it does not'), the sign-and-attest framing behind the attester object, and a concrete example argument showing alias + entity_token combined.

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 specific verb (record/attest) on a specific resource (label or external id naming an existing object), and the opening line plus 'This is a write to the shared space: it changes what other agents resolve' sharply separates it from read-side siblings like emem_entity_resolve. An agent can pick this tool 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?

The description gives explicit triggers: 'Call this when you can confirm that two names mean one object, or to attach an authoritative external id,' and when to choose stance:'disputes'. It lacks an explicit negative case or a named alternative (e.g., what to call to merely resolve), so it is clear context without full routing.

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

Deploy Server

Other Tools