apex-memory

search

Locate notes, sections, and log entries by keyword, exact phrase, or regex, with scoped results and snippets to quickly find relevant memory content.

Instructions

Search note titles and summaries, sections and log entries. mode: 'bm25' (ranked keywords; hits that hold more of the query terms rank higher, and weak hits holding few of them drop out), 'exact' (whole words or phrase, ignoring case, e.g. ids and hashes) or 'regex' (Python syntax). scope: a domain or folder such as 'project/docs'; empty searches every domain. Hits carry path, section id, heading path, version and a snippet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Default
`mode`	No	bm25
`limit`	No
`query`	Yes
`scope`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does reasonably well: it discloses ranking behavior (weak hits holding few query terms drop out), case handling in exact mode, and that an empty scope searches every domain. It also lists what hits carry (path, section id, heading path, version, snippet). It never states that the operation is read-only or says anything about result limits or cost, leaving a gap for a no-annotation tool.

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?

It is front-loaded with the purpose, then walks parameter by parameter ('mode:', 'scope:') and closes with return fields. Dense but every clause carries information an agent needs; nothing is repeated from the schema and nothing is filler.

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?

For a four-parameter read tool with no annotations and no output schema, the description covers purpose, mode semantics, scope semantics, and return shape, which is nearly everything an agent needs. The omissions are 'limit' behavior and any statement about read-only/side-effect profile, both of which matter given zero annotation coverage.

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 0% and the schema supplies no enums, so the description is doing all the work: it enumerates the three mode values with distinct semantics, explains scope as a domain or folder path including the empty-string case, and defines query as the search terms. The 'limit' parameter is never mentioned — no default, no maximum, no effect on pagination — which is the one real hole.

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 opens with a specific verb+resource list: 'Search note titles and summaries, sections and log entries,' which tells an agent exactly what corpus is searched. It does not name a sibling to contrast with (log_query and read are the closest neighbors), so it falls short of a 5, but the scope is unambiguous on its own.

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?

It gives real selection guidance for the mode parameter: bm25 for ranked keywords, exact for 'whole words or phrase, ignoring case, e.g. ids and hashes', regex for Python syntax. That is concrete when-to-use-which guidance. It never states when NOT to use this tool versus log_query or read, which keeps it at 4.

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

Deploy Server