Retrieve stored memories in reverse chronological order using pagination, filter by tag or category, and browse historical records without needing keyword search.
Read memories with pagination (newest first). Use search_memories for keyword lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| page | No | Page number (default 1) | |
| limit | No | Items per page (default 8, max 20) | |
| category | No | Filter by category |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description’s verb 'Read' makes the non-destructive nature clear, and it discloses pagination and newest-first ordering. It does not mention error handling or rate limits, but for a read operation these are minor gaps; the description adds meaningful behavioral context beyond the bare tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. The primary purpose and ordering are stated first, followed by the routing alternative. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description is mostly complete. It states what is read and the ordering, but does not specify what the returned memory objects contain. Given the tool’s low complexity and clear purpose, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description only adds the pagination context, which aligns with page and limit, but does not explain the filtering semantics of tag/category or how they combine. This meets the baseline for high schema coverage without adding much extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads memories with pagination and newest-first ordering, and it explicitly distinguishes itself from search_memories by directing keyword lookups to that sibling. This gives an agent a precise understanding of what the tool does and how it differs from a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct usage rule: use read_memories for general paginated reading, and use search_memories when keyword lookup is needed. This explicit routing makes it easy for an agent to choose between the two most similar tools without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.