MemScope

Search memories

search_memories

Read-onlyIdempotent

Use this when starting a task, or when the person asks what the organization knows or decided about something. query is the semantic search phrase: its wording drives relevance. topics and teams are explicit structured filters, not search text: every result matches each one given; values that cannot be applied are listed in the JSON's filters block (never why), and when none of a filter's values can be applied the call returns NO results. list_teams and list_topics give the valid values. team/project are older soft narrowing hints; the response's narrowed_by shows which matched (null = ignored). Each result has id, content (a preview with detail: "brief"), audience bucket, a short why, a citation and, when known, author, client and version. max_chars caps the text returned; when results are cut, truncated is true and hint says how to narrow. Memories past valid_until, or replaced by a newer one, are skipped unless include_expired / include_superseded. Not for browsing (use list_memories) or one memory in full (use get_memory). With the terminal table on, the JSON is the last text block.

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_memories"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Only this kind.
`team`	No	Soft hint toward one team (id, slug or name). Unknown values are ignored.
`limit`	No	Results to return, 1-50. Default: the configured number (10 unless changed).
`query`	No	The semantic search phrase: a topic, question or keywords, up to 2000 characters. Required, except for a handoff board.
`teams`	No	Hard filter: up to 20 teams you belong to (id, slug or name); blank values are rejected, an empty list means no filter.
`detail`	No	'full' (default): each result's whole content. 'brief': a 200-character preview instead; open one with `get_memory`.
`run_id`	No	Only this run's.
`topics`	No	Hard filter: up to 20 sensitive-topic keys, names or ids; blank values are rejected, an empty list means no filter.
`project`	No	Soft hint toward one project (id, slug or name). Unknown values are ignored.
`max_chars`	No	Budget for the total content (or preview) characters across results, 200-100000. Results past it are left out and `truncated` is true.
`include_expired`	No	Also return memories past their valid_until.
`include_superseded`	No	Also return memories replaced by a newer one.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: hard filters must all match, unapplicable filter values are surfaced in a `filters` block, and an entirely unappliable filter yields NO results. It further discloses soft-hint behavior via `narrowed_by` null=ignored, truncation via `truncated`/`hint`, and default skipping of expired/superseded memories.

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?

Dense but nearly every clause earns its place, and the usage trigger is front-loaded. Readability suffers from a single long paragraph with stacked parentheticals (e.g. the `filters` block aside and the trailing terminal-table note), which slows scanning for a 12-parameter 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?

With 12 parameters and no output schema, the description carries the return-shape burden itself and does so: it enumerates result fields (id, content, bucket, why, citation, author, client, version) and explains truncation metadata. Combined with filter semantics and sibling routing, nothing essential for a correct call is missing.

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 real meaning: `query` wording drives semantic relevance, `topics`/`teams` are structured hard filters rather than search text, and `team`/`project` are legacy soft hints whose effect is reported in `narrowed_by`. The hard-vs-soft filter distinction is the key semantic that the schema alone labels but does not fully operationalize.

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 makes clear this is a semantic search over memories whose wording drives relevance, and it explicitly points away from list_memories (browsing) and get_memory (single memory in full). The purpose is stated as usage context rather than a front-loaded verb+resource, and it never contrasts with grep_memories or recall, so an agent must infer those distinctions.

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?

It gives both a positive trigger ('when starting a task, or when the person asks what the organization knows or decided about something') and explicit exclusions routing to list_memories and get_memory. It also names list_teams and list_topics as the way to obtain valid filter values, closing the loop on how to use the filters correctly.

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

All MemScope tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?