Skip to main content
Glama

recall_multi_session

Recall memories across multiple sessions with synthesis. Connects related facts from different conversations and resolves contradictions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "recall_multi_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results from each session
queryYesWhat to search for across sessions
include_all_sessionsNoSearch across all past sessions or current session only

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose non-obvious behavior — cross-session connection of facts and contradiction resolution — which is more than the schema offers, but says nothing about cost/latency, whether contradictions are surfaced or silently resolved, or what the synthesized result looks like.

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?

Two short sentences, front-loaded with the core action. Slight redundancy between 'across multiple sessions' and 'from different conversations', but no wasted filler.

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?

With 100% schema coverage and only three flat parameters, the main gap is the absence of an output schema, meaning the description should ideally explain the shape of the synthesized answer. That is a real but moderate omission for an otherwise simple read-style 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%, so query, limit, and include_all_sessions are already fully documented. The description adds no semantics beyond the schema — notably it does not clarify that 'limit' applies per session, which the schema states but which interacts with the synthesis behavior.

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 description pairs a specific verb (recall) with a scoped resource (memories across multiple sessions) and adds that results are synthesized. 'Across multiple sessions' implicitly separates it from the single-session 'recall' sibling, but it never names that alternative directly.

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 only implied: the cross-session scope and contradiction-resolution hint suggest this is for broader historical questions rather than current-session lookups. It never states when to prefer this over recall, search_temporal, or find_contradictions, nor any prerequisites.

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.

Resources