mnema

Official

by mnema-work

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Search: find what has been recorded

search

Read-onlyIdempotent

Find memories, observations, decisions, tasks, and skills by words across projects, or list recent records when no term is given. Check what was recorded or decided before assuming nothing exists.

Instructions

Search everything recorded in EVERY project of this workspace and on this machine (memories, observations, decisions, tasks and skills) by the words a person wrote in them. Use it to answer "have we written about X?" or "what did we decide about Y?" BEFORE assuming nothing is recorded. With NO term it lists the most recent records instead ("what has been going on here": call it with an empty argument object). Narrow with kind, scope, state or a time window. Returns an INDEX (id, kind, tree, project, when, and one line each), not the bodies; take an id to read_record for the whole thing. It searches every tree it can see (the team’s, this machine’s, your own) in every project you have open, and each hit says which project and which tree hold it. Two limits worth knowing: each tree ranks its own matches against its own words, so the merged order is a good approximation and not one global ranking; and limit can fill the answer from one project: when it leaves another project’s matches out entirely, the reply names that project under hidden, and asking again with a larger limit reaches them. The order is when each was RECORDED, not when it last moved, and kind is the catalog’s own name, taken verbatim, the one unread hands you. Read-only.

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": "search"
  }
}

Input Schema

Name	Required	Description
`to`	No	only records at or before this ISO-8601 instant (inclusive). A window (`from`/`to`) selects RECORDS by the instant each was RECORDED, never by when one last moved, and never by the state it is in now.
`from`	No	only records at or after this ISO-8601 instant (inclusive). A window (`from`/`to`) selects RECORDS by the instant each was RECORDED, never by when one last moved, and never by the state it is in now.
`kind`	No	Only this kind of record.
`term`	No	Words to look for; omit to list the most recent records.
`limit`	No	How many hits to return (default 20, max 200).
`scope`	No	Only this tree; omitted, every tree this session can see.
`state`	No	Only records in this state (excludes kinds that have none).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: returns an index not bodies, per-tree ranking means the merged order is approximate, limit can silently exclude another project's matches which are then named under `hidden`, and ordering is by record time, not last movement. That is exactly the kind of behavior an agent could not infer from structured fields.

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 purpose, then usage, then return shape, then caveats — a sensible progression. It is fairly long (~200 words) and the nested parentheticals around queries and the empty-argument case add density, but essentially every sentence carries information an agent needs.

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?

With seven all-optional parameters and no output schema, the definition still describes the return value (index of id, kind, tree, project, when, one line), the read_record follow-up, the ranking caveat, and the truncation behavior. Nothing material is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds real meaning on top: omitting `term` switches to a most-recent listing, and `limit` has a side effect (truncating by project, echoed in `hidden`) that the schema's 'how many hits to return' does not convey. It stops short of explaining `state`/`scope` semantics beyond the schema, so not a 5.

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 (search) and resource (every recorded memory, observation, decision, task, skill across every project and tree), and explicitly distinguishes itself from read_record, which returns whole bodies. An agent can tell exactly what this does without opening the 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 concrete when-to-use triggers ('have we written about X?', 'what did we decide about Y?') plus an explicit pre-condition ('BEFORE assuming nothing is recorded'), names the empty-argument listing mode, and routes the agent to read_record for bodies. Exclusions and alternatives are both present.

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