MMW

Search memories

search

Read-onlyIdempotent

Search memories and annotate provenance, stale and conflict status. Each result is a saved record with its source and date; when one is superseded, the newer version is the one in force. Explain decisions only from what the records say: if no record gives the reason, say the reason is not recorded instead of guessing.

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of memory results to return (1-50)
`query`	Yes	Semantic or keyword query text to search across memories
`scope`	No	Optional scope filter (e.g. shared, private)
`workspace`	No	Workspace to search memories within	default
`exclude_stale`	No	Whether to filter out stale memories from results
`current_source_hash`	No	Optional current source hash to detect stale memories

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

addedOutput schema / $defs / SearchItem / properties / superseded_by

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "ID of the newer version saved under the same fact_key; when set, prefer that version. Newest versions are ranked first",
+  "title": "Superseded By"
+}

Changed2 schema fields changedOct 5, 2026

addedOutput schema / $defs / SearchItem / properties / derived_from

Added value: +{
+  "description": "IDs of the memories this one summarizes (lineage)",
+  "items": {
+    "type": "string"
+  },
+  "title": "Derived From",
+  "type": "array"
+}

changedOutput schema / $defs / SearchItem / properties / status / description

Previous value: -"Freshness and trust status: verified, unverified, stale, conflict"New value: +"Freshness and trust status: unverified, stale or conflict. A hash supplied by the client does not verify a memory; a summary inherits the conflict or staleness of the memories it was derived from"

Changed1 schema field changedOct 4, 2026

changedOutput schema / $defs / SearchItem / properties / confidence / description

Previous value: -"Confidence score between 0.0 and 1.0"New value: +"How confident the user is in this fact, from 0.0 (uncertain) to 1.0 (certain). Default: 0.5."

First observedSep 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds real value beyond that: results are saved records with source and date, superseded versions are not authoritative, and the agent should report "not recorded" rather than guess. This is useful behavioral context not in the annotations.

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?

Three sentences, front-loaded with the core action before the interpretive constraints, with no filler. The final sentence reads more like agent instruction than tool description but it is relevant and earns its place.

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?

An output schema exists, so return-value structure needn't be described, and safety is covered by annotations. The description is complete enough for correct invocation and interpretation, missing only sibling differentiation.

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 description coverage is 100% with 6 parameters, so the schema already documents limit, scope, workspace, exclude_stale and current_source_hash. The description's mention of stale/conflict status loosely relates to exclude_stale and current_source_hash but adds no syntax or format detail, so the baseline 3 applies.

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 verb and resource ("Search memories") and adds that results carry provenance, stale and conflict annotations, so the agent knows what it gets back. It does not, however, differentiate itself from the sibling search_history, leaving some ambiguity about which search to pick.

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?

There is implicit guidance on how to use the results ("Explain decisions only from what the records say..."), but no explicit when-to-use/when-not or naming of alternatives such as search_history. The agent must infer the selection context.

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

All MMW tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?