MemAI

search

Retrieve stored memories for AI agents by keyword query across content, tags, and domains, with type and scope filters.

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 (one writer each): 'note', 'reasoning', 'checkpoint', 'anti_pattern', 'handoff', 'diagram'. 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 full burden and does so richly: BM25 ranking with 'lower = better', candidate-set-only semantics ('judge the returned candidates yourself'), active-memories-only default, succeeded_by/collapsed/confidence='contradicted' handling, snippet truncation, and est_tokens accounting. Almost every behavioral trait an agent needs is disclosed.

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?

Strongly front-loaded with purpose and scoring semantics first, then behavioral notes, then filters. Each paragraph earns its place, though the 'SPEND TERMS FREELY' block is somewhat long and occasionally repetitive for a 4-parameter search tool.

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": N}), per-result est_tokens, match_source/fts_rank fields, and the two annotations. Nothing an agent needs to interpret results is 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 coverage is 0%, so the description must compensate and does: it enumerates the type values ('note','reasoning','checkpoint','anti_pattern','handoff','diagram'), explains domain path-scoping with inheritance ('the module and each of its routines'), describes multi-term query semantics, and explains limit via the collapsed mechanism. This exceeds what the bare schema provides.

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 and resource ('Keyword search over memory content+tags+domain: FTS5 BM25') and explicitly distinguishes itself from the recall sibling ('recall() is the sugar for search(type='note')... which also means recall() never surfaces a diagram; use search() for that'). An agent can pick this over near neighbours without opening any schema.

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?

Gives explicit when-to-use and alternative routing: use recall() for note()'d knowledge, use search() when you want diagrams, ask type='diagram' to sweep flows deliberately, and call get_memory(uid) for full records. It also prescribes query construction ('SPEND TERMS FREELY', pile on synonyms) as concrete guidance.

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