Clarifyprompt-MCP

memory_list_facts

List live memory facts, filtered by scope and predicate, to inspect known data or locate fact IDs for removal.

Instructions

List live (non-invalidated) facts in persistent memory, optionally filtered by scope and predicate. Sorted by most-recently-observed first. Useful for inspecting what the engine knows, or finding fact ids to forget.

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

Input Schema

Name	Required	Description	Default
`scope`	No	Memory scope to filter by. Default 'user'. Examples: 'user', 'project:myapp', 'session:abc'.	user
`predicate`	No	Optional predicate filter (e.g., only 'prefers' facts).
`limit`	No	Max facts to return. Default 50, hard max 100.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.8Jun 2, 2026

TDQS

A4/5.0

Behavior3/5

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

Discloses core behaviors: lists live/non-invalidated facts, sorted by recency, optional filters. With no annotations, description carries full burden; missing details like pagination behavior, empty result handling, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states operation and sorting, second provides use cases. No redundant information, well front-loaded.

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?

Covers purpose, filtering, sorting, and use cases. Lacks description of return format (e.g., fields like fact_id, predicate, value) but no output schema exists; would benefit from a brief hint about output structure.

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 baseline 3. Description mentions filtering by scope and predicate but adds no new meaning beyond schema descriptions which already detail defaults and examples. Limit parameter is not explicitly mentioned in description.

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?

Clearly states verb 'List' and resource 'live facts in persistent memory', with optional filtering by scope and predicate. Distinguishes from sibling tools like memory_search and memory_forget by specifying 'non-invalidated' facts and sorting order.

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?

Provides explicit use cases: 'inspecting what the engine knows' and 'finding fact ids to forget'. Implicitly excludes mutation or search operations, but does not explicitly state when not to use or name alternatives.

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