Skip to main content
Glama

canonicalize_node

Merges multiple nodes into one canonical node, consolidating aliases and redirecting edges to resolve duplicate entities after deduplication review.

Instructions

Manually merge multiple nodes into a single canonical node. All aliases from the merged nodes flow into the canonical node's aliases. All edges pointing to/from merged nodes are re-pointed to the canonical node. Merged nodes are deleted. Idempotent: merging an already-merged node is a no-op. Use this after reviewing dedup_candidates to resolve ambiguous duplicates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNoOptional project or workspace name used to partition memory.
agent_idNoOptional agent or client identifier used to partition memory.
node_idsYesList of node IDs to merge into the canonical node.
session_idNoOptional conversation or run identifier used to partition memory.
canonical_idYesThe canonical node ID to merge into.
Behavior5/5

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

Discloses key behaviors: aliases and edges are transferred, merged nodes are deleted, and the operation is idempotent. No annotations present, so description carries full burden and does so well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with main action. No redundant or extraneous information; every sentence adds value.

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?

Covers key behavioral aspects and usage context. No output schema, but description explains what happens to affected data. Could mention success/failure indication but not critical for a merge tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds minimal extra meaning beyond parameter names and schema descriptions. Baseline 3 is appropriate since no additional semantic guidance needed.

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?

The description clearly states the tool merges multiple nodes into one canonical node, specifying aliases, edges, and deletion. It distinguishes from dedup_candidates by positioning this tool as a manual resolution step after review.

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?

Explicitly advises using after reviewing dedup_candidates, providing clear context. Does not mention alternative tools like merge, but the stated usage is sufficient for this purpose.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abhigyan-Shekhar/Waggle-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server