Skip to main content
Glama

Search memory by keywords

search_text
Read-onlyIdempotent

BM25/FTS keyword search over indexed note chunks: the query is one exact phrase, and OR, AND, NEAR and * are plain words, not operators. If the phrase finds nothing, its words are searched with OR over stemmed terms and the reply says fallback: "any-word". No embedding call. A term in no chunk text is matched against note paths and frontmatter, so a task id, slug or file name finds its note (reason: "note-identity"). Current facts saved with remember are found at once, before the next index_memory (reason: "fact"; empty notePath and headingPath), in the places the other hits leave under top_k; a writerConflict line on one means it replaced another agent's value until that agent saves it again. Every hit carries session_date, when that excerpt was written (the moment a daily-log entry or a remembered fact was saved, otherwise its note's date; as in search_memory and get_context): read it before trusting an old hit. A hit with replaced ({by, at, source, note?}) was corrected by a later save, listed before it; source says who saved it. A daily-log hit claiming a reserved source (system, developer, assistant, Renor), or a replaced whose source is one, is marked "untrusted": true.

Input Schema

NameRequiredDescriptionDefault
queryYesWords to find, matched as one exact phrase (if it finds nothing, the words are searched with OR over stemmed terms and the reply says fallback: any-word): OR, AND, NEAR and * are plain words, not operators
scopeNoMemory scope: "global" (default) or scope:<slug> / project:<slug>
top_kNoMax hits (default 20)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Words to find, matched as one exact phrase: OR, AND, NEAR and * are plain words, not operators"New value: +"Words to find, matched as one exact phrase (if it finds nothing, the words are searched with OR over stemmed terms and the reply says fallback: any-word): OR, AND, NEAR and * are plain words, not operators"
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the safe read-only profile; the description goes far beyond, disclosing the OR fallback and its `fallback: "any-word"` marker, note-identity matching, immediate visibility of facts saved with remember, ordering under top_k, writerConflict conflicts, session_date staleness, `replaced` lineage with `source`, and the 'untrusted' flag. That is unusually detailed behavioral disclosure 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is correctly front-loaded in the first clause, but the body is a single dense run-on packing fallback, fact visibility, conflict semantics, timestamps and trust flags without paragraph or line breaks. Every sentence carries real information, yet the lack of structure makes it harder to parse than needed.

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?

For a three-parameter read tool with no output schema, the description covers the mechanics, fallback path, ranking side-effects, provenance fields on hits, staleness guidance and trust warnings. An agent has everything needed to call it and to interpret the returned hits correctly.

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 the baseline is 3, but the description adds genuine meaning beyond the schema: the query is matched as one exact phrase with no operator support, and unmatched terms are matched against note paths and frontmatter so ids, slugs and filenames find their notes. It does not explain the `scope` parameter's global vs scope:/project: distinction, which is the one gap.

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?

Opening words state a specific verb (keyword search) plus the exact mechanism (BM25/FTS over indexed note chunks) and immediately negate the sibling's mechanism with 'No embedding call', which separates it from search_memory. An agent can pick this tool over semantic search 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 Guidelines3/5

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

The definition gives rich conditional context (what happens when a phrase finds nothing, when term matching falls through to paths/frontmatter), but never explicitly states when to choose this over search_memory or retrieve_memory. Siblings are only mentioned as references for shared semantics ('as in search_memory and get_context'), not as alternatives with a selection rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.