Skip to main content
Glama
Sign In
Connapse

Connapse

by Destrayon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

memory_recall

Read-onlyIdempotent

Read facts from memory as of now or a past date, filter by space, subject, attribute, or query, and include history to track corrections and changes.

Instructions

Read facts from memory: what is true now, or on a past date with asOf. Name a space to read one space, or leave it out to read every space you can see. Filter by subject or attribute, or pass a question as query. Each fact comes with its space, whether it is personal (only you see it) or team, its dates, author and sources. Use includeHistory to also get ended and corrected facts (for "which ticket changed X" or "when did X change"). Reading one named space without asOf or attribute returns nextCursor when there are more facts: pass it back as cursor for the next page.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "memory_recall"
  }
}

Input Schema

NameRequiredDescriptionDefault
asOfNoFacts true on this date (YYYY-MM-DD or ISO 8601). Default: now
limitNoAt most this many facts (1-100). Default 10
queryNoWords to match against subject, attribute, value and reason
spaceNoSpace ID or name to read. Omit to read every space you can see
cursorNoThe `nextCursor` of the previous page, to read the next one
subjectNoOnly this subject (exact, any case)
attributeNoOnly this attribute (exact, any case)
containerIdNoOlder name for `space`
includeHistoryNoAlso return ended and corrected facts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly and idempotent; the description adds real behavioral context beyond that: the per-fact return payload (space, personal vs team visibility, dates, author, sources), the effect of includeHistory (ended and corrected facts included), and the precise condition under which `nextCursor` appears. This is more than the annotations carry.

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?

Front-loaded with the core action, then scoping, then return shape, then the pagination edge case — a logical progression with no filler. The final pagination sentence is dense and conditional, but it carries information an agent would otherwise get wrong.

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 9 optional parameters and no output schema, the description carries the burden of describing results and does so (fact fields, visibility, history). Filtering, space scoping, and cursor round-tripping are all covered, so an agent can call this correctly without further inference.

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; the description still adds interaction semantics the schema cannot express, notably that omitting `space` reads every visible space and that `nextCursor` is only returned for a single named space without `asOf` or `attribute`. It does not mention the `containerId` legacy alias, leaving one parameter's purpose to the schema alone.

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?

States a specific verb and resource ('Read facts from memory') plus the exact temporal scope ('what is true now, or on a past date with `asOf`'). The read-oriented framing clearly separates it from the write/mutate siblings memory_remember, memory_correct, and memory_forget without needing to name them.

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?

Gives concrete when-to-use cues: name a `space` for one space, omit it for all visible spaces, use `includeHistory` for questions like 'which ticket changed X' or 'when did X change', and the pagination condition. It stops short of naming alternatives such as memory_timeline or search_knowledge for related lookups, so there is no explicit exclusion guidance.

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

Deploy Server

Other Tools