Skip to main content
Glama

connect

Connect memories to build knowledge graphs.

After using 'store', immediately connect related memories using these relationship types:

## Knowledge Evolution
- **supersedes**: This replaces → outdated understanding
- **updates**: This modifies → existing knowledge
- **evolution_of**: This develops from → earlier concept

## Evidence & Support
- **supports**: This provides evidence for → claim/hypothesis
- **contradicts**: This challenges → existing belief
- **disputes**: This disagrees with → another perspective

## Hierarchy & Structure
- **parent_of**: This encompasses → more specific concept
- **child_of**: This is a subset of → broader concept
- **sibling_of**: This parallels → related concept at same level

## Cause & Prerequisites
- **causes**: This leads to → effect/outcome
- **influenced_by**: This was shaped by → contributing factor
- **prerequisite_for**: Understanding this is required for → next concept

## Implementation & Examples
- **implements**: This applies → theoretical concept
- **documents**: This describes → system/process
- **example_of**: This demonstrates → general principle
- **tests**: This validates → implementation or hypothesis

## Conversation & Reference
- **responds_to**: This answers → previous question or statement
- **references**: This cites → source material
- **inspired_by**: This was motivated by → earlier work

## Sequence & Flow
- **follows**: This comes after → previous step
- **precedes**: This comes before → next step

## Dependencies & Composition
- **depends_on**: This requires → prerequisite
- **composed_of**: This contains → component parts
- **part_of**: This belongs to → larger whole

## Quick Connection Workflow
After each memory, ask yourself:
1. What previous memory does this update or contradict? → `supersedes` or `contradicts`
2. What evidence does this provide? → `supports` or `disputes`
3. What caused this or what will it cause? → `influenced_by` or `causes`
4. What concrete example is this? → `example_of` or `implements`
5. What sequence is this part of? → `follows` or `precedes`

## Example
Memory: "Found that batch processing fails at exactly 100 items"
Connections:
- `contradicts` → "hypothesis about memory limits"
- `supports` → "theory about hardcoded thresholds"
- `influenced_by` → "user report of timeout errors"
- `sibling_of` → "previous pagination bug at 50 items"

The richer the graph, the smarter the recall. No orphan memories!

Args:
    from_memory: Source memory UUID
    to_memory: Target memory UUID
    relationship_type: Type from the categories above
    strength: Connection strength (0.0-1.0, default 0.5)
    ctx: MCP context (automatically provided)
    
Returns:
    Dict with success status, relationship_id, and connected memory IDs

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
strengthNo
to_memoryYes
from_memoryYes
relationship_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate write operation (readOnlyHint=false). Description adds context: creates links, returns success/IDs. Does not contradict annotations, but could mention if connections are reversible or list any side effects like overwriting.

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?

Moderately long but well-structured with headings, bulleted categories, workflow steps, and example. Every section adds value; no redundancy. Could be slightly shorter but earns its length.

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?

With output schema existing, description covers all needed: parameter details, relationship semantics, usage guidance. No gaps remain for an agent to misuse the tool.

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

Parameters5/5

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

Schema has 0% description coverage, but description compensates fully: explains from_memory/to_memory as source/target, lists all relationship types with meanings, gives strength range and default (0.5) despite schema default null. This is thorough.

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 connects memories to build knowledge graphs, and distinguishes from 'store' by recommending immediate use after storing. The extensive relationship taxonomy and workflow make the purpose unambiguous.

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?

Provides explicit timing ('After using store'), a structured workflow with questions, and an example. It implicitly advises against connecting unrelated memories by emphasizing relevance through relationship categories.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.