AiAkiv Memory

find_memory_connections

Read-onlyIdempotent

Walk the entity-event graph outward from what a sentence finds, one or two hops.

Search returns the closest events; this returns events connected to them
through shared entities the vector ranking left outside the top hits, each
candidate carrying its bridge entity, path, and evidence.

Use this when the user asks what is linked to something that a ranked search
did not surface. Do not use it for a direct answer to a question; use
`search_memory` for that. Do not use it when the request states a pattern to
match; use `query_memory_graph` for that.

Read-only. Candidates are unverified pointers, not established facts.

Args:
    sentence: One complete sentence, not keywords. Required for every
        relation except `explore`, which forbids it.
    anchor_entity_id: An entity id to walk from instead of a vector entry;
        this path does not depend on the ranking. Required for
        `relation="explore"`.
    relation: `similar` (default, time-stratified), `before`, `after`,
        `evolution`, `contrast`, or `explore`. `before` and `after` require
        exactly one of `reference_time` or `anchor_event_id`; there is no
        implicit "now". `contrast` returns candidates narrowed by cosine
        without judging opposition, which the reader does. `explore` needs
        `anchor_entity_id`, forbids `sentence`, and returns
        `grounding="exploration"`.
    reference_time: ISO 8601 basis for `before` and `after`.
    anchor_event_id: Event basis for `before` and `after`.
    top_n: Max candidates per round (server-capped).
    expansion_rounds: 1 (default) or 2. Round 2 re-expands from the round-1
        picks through bridges not used in round 1, reaching things two
        structural steps away, so a 2-round call can return up to twice
        `top_n` in total. Each candidate carries its `round`.

Returns:
    `{candidates: [{event_id, summary, path, bridge_entity_id, cosine,
    cosine_percentile, timestamp}], grounding, grounding_basis, bridges,
    entry, searched_scope, truncations}`. `grounding` is `grounded`, `weak`,
    `absent`, or `exploration`; `absent` means no neighbourhood exists for
    this sentence in scope, an honest empty rather than a failure.
    `event_id` feeds `get_memory_content`.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`top_n`	No	Max candidates per round (server-capped).
`relation`	No	`similar` (default, time-stratified), `before`, `after`, `evolution`, `contrast`, or `explore`. `before` and `after` require exactly one of `reference_time` or `anchor_event_id`; there is no implicit "now". `contrast` returns candidates narrowed by cosine without judging opposition, which the reader does. `explore` needs `anchor_entity_id`, forbids `sentence`, and returns `grounding="exploration"`.	similar
`sentence`	No	One complete sentence, not keywords. Required for every relation except `explore`, which forbids it.
`reference_time`	No	ISO 8601 basis for `before` and `after`.
`anchor_event_id`	No	Event basis for `before` and `after`.
`anchor_entity_id`	No	An entity id to walk from instead of a vector entry; this path does not depend on the ranking. Required for `relation="explore"`.
`expansion_rounds`	No	1 (default) or 2. Round 2 re-expands from the round-1 picks through bridges not used in round 1, reaching things two structural steps away, so a 2-round call can return up to twice `top_n` in total. Each candidate carries its `round`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond those: results are 'unverified pointers, not established facts', the semantics of `grounding` values (including 'absent' as an honest empty), and the expansion_rounds behavior (re-expansion through unused bridges). This is valuable transparency beyond what annotations state.

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 description is long but structured: it leads with the core behavior, then usage guidance, then parameter details. The parameter section duplicates the schema text nearly exactly, which is redundant and could be trimmed. However, the redundancy is not fluff; it is informative for agents that may not parse the schema deeply. It is appropriately sized for the tool's complexity, but not maximally concise.

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?

The description is exceptionally complete for a tool with 7 parameters and an output schema. It covers all relation-specific constraints (e.g., `before`/`after` require exactly one time reference, `explore` forbids `sentence`), explains the return object shape, defines `grounding` values, and clarifies edge cases like 'absent'. The output schema also documents return fields, but the description goes beyond that to explain semantics, leaving no gaps for correct invocation.

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 description coverage is 100% – the input schema already contains nearly identical, detailed descriptions for every parameter. The description repeats most of that verbatim (e.g., relation requirements, top_n cap). It adds no new meaning beyond the schema, so the baseline of 3 applies. Minor additions like the round behavior for expansion_rounds are also in the schema, so no extra credit.

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 opens with a specific verb ('walk') and resource ('entity-event graph'), and clearly distinguishes itself from siblings: 'Search returns the closest events; this returns events connected to them through shared entities...' It explicitly names alternatives (`search_memory`, `query_memory_graph`) and the conditions that route to them, making the tool's unique role unmistakable.

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?

The description gives an explicit use case ('when the user asks what is linked to something that a ranked search did not surface') and explicit negative cases ('Do not use it for a direct answer to a question; use `search_memory` for that. Do not use it when the request states a pattern to match; use `query_memory_graph` for that.'). This is textbook guidance, leaving no ambiguity.

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

All AiAkiv Memory tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.