Skip to main content
Glama
Sign In
MemAI

MemAI

by Filipe-Soares-de-Almeida
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

diagram_link

DestructiveIdempotent

Attach a memory to a specific diagram step so notes, anti-patterns, or reasoning explain why that step exists.

Instructions

Attach another memory to one specific step of a diagram.

What turns a diagram into an index of its domain: the step states what happens, the linked note/anti_pattern/reasoning states why it is that way. Point at the step the memory actually concerns -- for an edge to the diagram as a whole use link_memories() instead, and to say the branch continues in another flow, diagram_jump().

get_memory() on the linked memory reports the diagrams that reference it, so the connection is visible from both ends.

Returns {"ok": True}, or {"ok": False, "errors": [...]} for an unknown diagram, step or memory, a link from a diagram to itself, or a delete with no such link.

Input Schema

NameRequiredDescriptionDefault
uidYesthe diagram.
deleteNoremoves the link between node_key and target_uid.
node_keyYesthe step the memory explains.
target_uidYesthe memory to attach.
relation_typeNohow the memory relates to the step; 'explains' unless given. Linking the same step and memory again replaces it.explains

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.16.1
    • addedInput schema / properties / delete / description
      Added value: +"removes the link between node_key and target_uid."
    • removedInput schema / properties / delete / title
      Removed value: -"Delete"
    • addedInput schema / properties / node_key / description
      Added value: +"the step the memory explains."
    • removedInput schema / properties / node_key / title
      Removed value: -"Node Key"
    • addedInput schema / properties / relation_type / description
      Added value: +"how the memory relates to the step; 'explains' unless given. Linking the same step and memory again replaces it."
    • removedInput schema / properties / relation_type / title
      Removed value: -"Relation Type"
    • addedInput schema / properties / target_uid / description
      Added value: +"the memory to attach."
    • removedInput schema / properties / target_uid / title
      Removed value: -"Target Uid"
    • addedInput schema / properties / uid / description
      Added value: +"the diagram."
    • removedInput schema / properties / uid / title
      Removed value: -"Uid"
    • removedInput schema / title
      Removed value: -"diagram_linkArguments"
  2. Addedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is partly covered; the description adds real value on top by enumerating failure modes (unknown diagram/step/memory, self-link, delete with no such link) and the exact return shape {ok, errors}. It does not spell out permission or reversibility implications of the destructive delete path beyond what the schema states, so it falls short of a 5.

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?

The action statement is front-loaded, followed by usage context, alternatives, and error/return behavior in logical order. The 'what turns a diagram into an index of its domain' framing is mildly rhetorical but does convey the why, so it mostly earns its place; only slightly longer than needed.

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?

For a 5-param mutation tool with no output schema, the description covers purpose, alternatives, error conditions on invalid inputs, and the return envelope, plus the bidirectional visibility via get_memory. Nothing an agent needs to call it correctly is missing.

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 conceptual meaning the schema lacks: node_key is the step the memory 'actually concerns' and relation_type defaults to 'explains' with replacement semantics on re-linking. These clarify intent beyond the terse schema strings.

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?

Opening sentence gives a specific verb+resource: attach a memory to one specific step of a diagram. It then explicitly differentiates from the nearest siblings (link_memories for whole-diagram edges, diagram_jump for branch continuation), so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternatives and the exact condition that selects each one ('for an edge to the diagram as a whole use link_memories()', 'to say the branch continues in another flow, diagram_jump()'). It also explains the intended granularity: point at the step the memory actually concerns, not the diagram.

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