Skip to main content
Glama
PlainTxtOffice

Plain Text Memory MCP

Merge entities

merge_entities
DestructiveIdempotent

Fold a source entity into a target, move its observations and relations, then delete the source. It skips duplicates and fails without saving if either entity is missing.

Instructions

Fold one entity into another and delete the first.

Moves the source's observations to the target with their original tags; a text the target already has keeps the target's copy. Points the source's relations at the target, dropping any that would repeat an existing relation or point the target at itself. The target keeps its own name and type. Returns the merged target and the relations moved to it. Fails without saving when either entity does not exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNameYesEntity to fold in and delete, such as a typo.
targetNameYesEntity that receives everything and stays.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
entityYes
messageYes
movedRelationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description goes well beyond them: observations move with original tags, duplicate texts keep the target's copy, relations are repointed with duplicate and self-relations dropped, and the operation aborts without saving when either entity is absent.

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 destructive action is front-loaded in sentence one, and the following sentences each carry distinct behavioral facts. It is dense but every clause earns its place; a slightly tighter phrasing of the dedup rules could cut a few words.

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 destructive two-parameter merge, the description covers the edge cases an agent needs (missing entities, duplicate text, duplicate/self relations, target identity preservation), and since an output schema exists it does not need to detail return fields.

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, and the description adds real semantic meaning on top: the source is the one deleted and its data migrated, while the target retains its own name and type. That clarifies the role distinction beyond the schema's terse parameter blurbs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource with unambiguous direction: 'Fold one entity into another and delete the first.' This is clearly distinct in behavior from siblings like rename_entity or delete_entities, though the description never names those siblings to route the agent explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated – the schema notes the source is 'such as a typo,' which hints at the dedup use case, and the description explains failure when an entity is missing. But there is no explicit when-to-use guidance or comparison against rename_entity, delete_entities, or edit_observation.

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