recordari

search

Read-only

Search memories by keyword. The query must use vocabulary that appears in stored labels, descriptions, or tags — not intent summaries or paraphrases. Pass node_kind (space-separated) to list or search within specific kinds — unrelated kinds that happen to match query text are excluded. Omit query with node_kind set to list matching kinds ordered by most-recently-updated. Default limit: 10. Use exact=true for identifiers (ticket numbers, short codes with hyphens) — FTS tokenises hyphens away so 'PROJ-042' is not found by default. If search returns zero or truncated results, use orient (with domain) to browse all memories, then recall by ID, then follow connections from a known memory. Returns lean results only — id, label, and a truncated why_matters excerpt; call recall(id) for full content. When a list or section has 2 or more results, each is rendered as a single compact text line — "[id] label — excerpt (domain, node_kind)" — instead of a JSON object; exactly one result is returned as a full object. exact=true is exempt — it always returns full objects, regardless of result count. state (space-separated union) post-filters results to memories with any of the given lifecycle states: none | resolved | superseded | contested. On failure, content[0].text is JSON: {"error_class": "retryable|forbidden|internal", "message": "..."}. Switch on error_class: retry on retryable.

Input Schema

TableJSON Schema

Name	Required	Description
`exact`	No	When true, use label substring (ILIKE) matching instead of FTS. Results are ordered by updated_at DESC with no semantic_distance. Use for identifiers like ticket numbers or short codes where FTS tokenisation loses the match.
`limit`	No	Maximum results to return. Default: 10. If truncated is true in the response, raise the limit or narrow the query.
`query`	No	Words to match against stored labels, descriptions, and tags. Use vocabulary from the stored content — if zero results, try words that are likely in the stored text rather than intent or paraphrase.
`state`	No
`domain`	No
`memory_id`	No	Restrict search to nodes directly connected to this memory ID. Useful for searching within a workstream. Applied before FTS/exact scoring, not as a post-filter. When omitted, all nodes in the workspace (or domain) are searched.
`node_kind`	No	Optional filter: space-separated node kinds (union match, same convention as tags). E.g. 'option standing' returns memories whose node_kind is option OR standing. Negation and wildcards are not supported.
`max_distance`	No	When set (e.g. 0.35), only vector-search results whose semantic_distance is at or below this value are returned. Absent (or 0) means no distance filtering — all ranked results up to limit are returned. Use this from hooks to suppress low-relevance injections (STORY-315).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 1, 2026

addedInput schema / properties / max_distance

Added value: +{
+  "description": "When set (e.g. 0.35), only vector-search results whose semantic_distance is at or below this value are returned. Absent (or 0) means no distance filtering — all ranked results up to limit are returned. Use this from hooks to suppress low-relevance injections (STORY-315).",
+  "type": "number"
+}

First observedAug 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Even with readOnlyHint=true and destructiveHint=false annotations, the description adds substantial behavioral detail: exact=true returns full objects regardless of count, multi-result lists render as compact text lines, state is a post-filter, FTS tokenisation drops hyphens, and failures return a structured error_class JSON. These details go well beyond the safety profile captured by annotations.

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?

The description is dense but every clause earns its place, covering query semantics, listing behavior, exact-match nuance, result rendering, fallback guidance, state filtering, and error handling. It is front-loaded with the core purpose and then layers edge cases in a logical order. It is arguably long, but for a tool with eight parameters and no output schema, the length is justified.

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 no output schema, the description carries the full burden of explaining return behavior, and it does so thoroughly: lean result fields, compact text-line rendering versus full objects, exact=true exemption, and error JSON with retry semantics. It also covers failure fallbacks and sibling routing, leaving an agent well-equipped to invoke the tool correctly and interpret its results.

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 75%, and the description adds meaning beyond the schema for key parameters: query must echo stored vocabulary, node_kind excludes unrelated matching kinds, exact=true bypasses FTS hyphen issues, and state values are enumerated. The main gap is that the domain parameter is never directly explained in the description, and max_distance is left entirely to the schema, so the description doesn't fully carry the parameter-semantics burden.

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?

The description opens with 'Search memories by keyword,' giving a clear verb and resource, and is further sharpened by the title 'Search memories.' It distinguishes itself from siblings by explicitly routing full-content retrieval to recall(id) and browsing to orient, so an agent can tell this tool apart even though the tool name is the generic 'search.'

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?

The description gives explicit guidance on when to use keyword vocabulary, when to set exact=true for identifiers, and how to use node_kind for listing. It also provides a fallback escalation path—'use orient (with domain) to browse all memories, then recall by ID, then follow connections'—and names the alternatives directly. This is exceptional contextual routing beyond what schemas or annotations provide.

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

All recordari tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Each tool targets a distinct operation—lifecycle (remember/revise/forget), graph edges (connect/disconnect/why_connected), retrieval (recall/search/recent/history/orient/significance)—and the descriptions carefully disambiguate overlaps. However, the read/analysis cluster (recent, history, orient.recent, significance) could still cause initial misselection before reading the detailed descriptions.

Naming Consistency3/5

Names are readable and consistently lowercase, but they do not follow a single convention: most are bare verbs (connect, remember, revise, search, visualise) while others are nouns (domains, history, recent, significance) and two are multiword phrases (suggest_connections, why_connected). This mix is still predictable enough to navigate, but less coherent than a uniform verb_noun surface.

Tool Count4/5

16 tools is slightly above the typical 3–15 band, but the scope of a knowledge-graph memory server justifies the breadth: CRUD, connections, domain admin, and multiple query/analysis tools are all represented. No tool feels redundant enough to cut, though the set is at the heavy end.

Completeness4/5

Core lifecycle is well covered: create/read/update/archive/purge, connection creation/removal, domain admin, and multiple query/analysis modes. The main gap is that bulk domain merge (merge_domains) is referenced in tool descriptions but not exposed as an MCP tool, so agents must direct users to an external admin interface for that operation.

Resources

Need Help?