MemAI

search

Find stored memories by keyword across content, tags, and domain paths; returns BM25-ranked candidate snippets with match annotations, then fetch full records by UID.

Instructions

Keyword search over memory content+tags+domain: FTS5 BM25.

Each result is annotated with match_source ("fts", or "uid" for the row a pasted identifier names) and fts_rank (bm25, lower = better). The search only widens the candidate set -- judge the returned candidates yourself.

SPEND TERMS FREELY. Every space-separated term is asked for separately and a row matching more of them ranks higher, so piling on synonyms, the identifier, the routine name and the plain-language phrasing into one query costs one call and finds strictly more. Twenty terms beat ten. Write a sentence if that is what you have -- common words score near zero and cost nothing, so there is nothing to strip.

Only active memories by default.

Returns {"results": [...], "est_tokens": N}. Content is snippet-truncated per result -- call get_memory(uid) for the full record; a result's est_tokens estimates what that full record costs, and the top-level est_tokens is the sum over the results.

Two annotations worth acting on. succeeded_by means something in the store supersedes this memory: read that one instead. collapsed lists near-identical results folded into this one, so a fact written five times spends one slot -- raise limit if you want the copies.

A memory marked confidence='contradicted' sorts behind everything that still holds, but it does come back: knowing a claim was ruled out is worth a slot, and it is what stops it being written again.

A diagram ranks like any other memory: it comes back when it matches the query, in the position its score earns. Nothing lifts a type to the top, so a flow in the results is a flow this query actually hit -- and when one does show up it is worth opening first, because it states a whole routine the surrounding notes only annotate.

type filters: 'note', 'reasoning', 'checkpoint', 'anti_pattern', 'diagram', 'task' (one writer each) and 'handoff' (rows already stored; task() carries unfinished work to the next session); any other type is an error. Ask for type='diagram' to sweep the documented flows on purpose. To recall note()'d knowledge specifically, recall() is the sugar for search(type='note') -- which also means recall() never surfaces a diagram; use search() for that.

domain scopes to a path AND everything under it: domain='acme/x100' searches the module and each of its routines. Give more of the path to narrow it. A domain naming only the deep end of a path ('p200') is resolved to the branches it sits in -- every result carries its real domain, which is where to read what the filter actually covered.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	No
`limit`	No
`query`	Yes
`domain`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Sep 13, 2026

changedInput schema / properties / limit / default
```
Previous value: -30New value: +10
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "searchOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Jul 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the entire burden and does so well: it discloses default active-only filtering, snippet truncation with a pointer to get_memory(uid), the meaning of succeeded_by/collapsed/confidence='contradicted' result annotations, that nothing boosts a type in ranking, and that a deep-end domain filter is resolved to parent branches. This is behavior an agent could not infer from the schema.

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 one-line definition, and organized into topical paragraphs. Some of the query-construction prose is repetitive ('Twenty terms beat ten', 'common words score near zero and cost nothing') and could be tightened, but it is dense with substance rather than filler.

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?

No output schema exists, yet the description documents the return shape ('results' + est_tokens), per-result est_tokens semantics, snippet truncation, and the in-result annotations that drive follow-up actions. For a search tool with four params and type/domain filtering, nothing essential appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description is the only source, and it fully compensates: query (unbounded, more terms rank higher, ranking semantics), type (enumerated values with per-type meaning and an error condition), domain (path-prefix scoping plus deep-end path resolution), and limit (raise it to see collapsed duplicates). All four parameters gain real meaning.

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, resource and mechanism: 'Keyword search over memory content+tags+domain: FTS5 BM25.' It also distinguishes itself from the sibling recall() by naming what recall() cannot do (never surfaces a diagram). An agent can tell exactly what this tool is and how it differs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: use recall() for note()-stored knowledge, but use search() to reach diagrams; use type='diagram' to sweep documented flows; use domain='acme/x100' to scope to a module and its routines. It also gives clear guidance on query construction ('SPEND TERMS FREELY') and when to raise limit. When-to-use and when-to-use-something-else are both covered.

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

search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools