Skip to main content
Glama
Sign In
Connapse

Connapse

by Destrayon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

memory_timeline

Read-onlyIdempotent

Track how a subject's values changed over time by reading dated facts, including ended and corrected entries; filter by space, date window, subject, or attribute.

Instructions

A subject's facts in date order, ended and corrected ones included: how its values changed over time. Name a space to read one space, or leave it out to read every space you can see; each fact says which space it is in. With from/to, only the facts that started or ended in that window ("what changed between A and B"). Reading one named space without from, to or attribute returns the newest facts first a page at a time, each page in date order, with nextCursor when older facts remain: pass it back as cursor.

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_timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoWindow end
fromNoWindow start (YYYY-MM-DD or ISO 8601)
limitNoAt most this many facts (1-100). Default 50
queryNoWords to match, when the subject is not known exactly
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
containerIdNoOlder name for `space`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare read-only and idempotent, but the description adds real behavioral facts the agent could not otherwise know: tombstoned/corrected facts are included, the visibility scope is "every space you can see" with per-fact space attribution, ordering flips to newest-first paging only in the named-space-without-window case, each page is internally date-ordered, and `nextCursor` must be echoed back as `cursor`.

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 purpose, then scope, then window semantics, then pagination — a sensible progression with no filler. The final pagination sentence is dense and requires a second read, which is the main cost.

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 nine optional parameters and no output schema, the description correctly carries the burden of return behavior: ordering, page size semantics and the cursor contract are all spelled out. It says nothing about `query`, `limit` or the `containerId` alias, though those are fully documented in the schema, so the gap is minor.

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?

Coverage is 100% so the schema baseline already applies, yet the description adds meaning beyond it: `space` omission means all visible spaces, and `from`/`to` select facts that started OR ended in the window rather than simply filtering on a date field. It also ties the ordering/paging behavior to a specific combination of `space`, `from`/`to` and `attribute`, which no single schema entry conveys.

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 states a specific resource and shape of result: a subject's facts in date order, explicitly including ended and corrected facts, i.e. value history over time. That temporal-history framing implicitly separates it from a current-state recall tool, but no sibling is named outright, so the differentiation is left for the agent to infer.

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?

It gives concrete usage contexts: omit `space` to read every visible space, use `from`/`to` for "what changed between A and B", and use the paged path for a single named space. It never states when this tool should be preferred over memory_recall or memory_correct, so the alternative-selection guidance is incomplete rather than absent.

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