Skip to main content
Glama

search

Find relevant memories and canonical entities using keyword, full-text, and optional AI similarity before building a query, surfacing saved notes and example queries.

Instructions

Up to three-channel semantic search over memories + canonical entities.

Call this BEFORE query to surface any notes or example queries previously saved against the entities you're considering.

Discovery, not detail: hits come back as one-line descriptions — pick candidate ids here, then read their full bodies with inspect (batching same-kind ids in one call). A broad compact=False search drags full renders into cached context on every later turn for no added signal.

Channel 1 (entity-overlap BM25 over memories): runs when entities and/or query is supplied. Memories whose canonical entity tags overlap the resolved input are ranked.

Channel 2 (tantivy full-text over memories ∪ entities): runs when question is supplied. The in-memory index covers every memory + every searchable entity (datasource / non-hidden model / non-hidden column / named measure / aggregation).

Channel 3 (dense embedding similarity, optional): runs when question is supplied AND the advanced_search extra is installed AND a provider API key is configured for the active embedding model. Cosine similarity between the question embedding and persisted entity/memory embeddings. Skipped with a single warning into SearchResponse.warnings when any precondition fails — tantivy + BM25 continue to work.

All hits (memories, example queries, entities) are fused via Reciprocal Rank Fusion (k=60) into a single ranked results list capped at max_results.

Empty input (no entities, no query, no question) returns the newest memories capped at max_results, with a warning.

Args: entities: Canonical entity reference strings. query: Optional SlayerQuery (dict). Entities are auto-extracted to broaden channel-1 input. question: Free-text query for the tantivy full-text channel. datasource: Optional datasource name. When set, scope all three channels to that one datasource. Entity hits are limited to docs rooted at the datasource (exact match or dotted-path descendant). Memories surface when any of their tagged entities is rooted at the datasource — a memory spanning multiple datasources surfaces from each. BM25 / IDF stats reflect only the filtered subset. Unknown datasource raises ValueError. max_results: Maximum total number of hits to return (default 10). cypher_filter: Optional openCypher MATCH query returning … AS id that pre-filters all three channels to the returned canonical IDs — narrow to one kind so max_results isn't spent on an RRF-fused mix of memories, columns, measures, and models. When advanced_search is not installed, only simple MATCH (n:Label1:Label2) RETURN n.id AS id patterns are supported as a kind filter (multi-label uses union semantics; allowed labels: Memory, Datasource, Model, ModelColumn, Measure, Aggregation — use ModelColumn, not Column, which resolves only on the naive fallback).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
compactNo
entitiesNo
questionNo
datasourceNo
max_resultsNo
cypher_filterNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses empty-input behavior, the warning-on-skip behavior for the dense channel, `ValueError` on unknown datasource, RRF fusion, and the context-cache cost of `compact=False`. This goes well beyond the schema.

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?

The description is long but densely packed and well-structured: a top-line purpose, ordering instruction, channel breakdown, fusion/empty-input behavior, then parameter docs. Every sentence carries operational value for a complex 7-parameter tool, so the length is earned.

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?

Given the tool's complexity, no annotations, and an output schema present, the description covers all invocation concerns: channel preconditions, result fusion, error cases, scoping semantics, and cypher_filter limitations. An agent has enough to call this correctly in varied contexts.

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

Parameters5/5

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

Schema coverage is 0%, so the description must explain every parameter. It provides detailed semantics for `entities`, `query`, `question`, `datasource`, `max_results`, and `cypher_filter`, and explains `compact` in prose. This fully compensates for the schema's lack of descriptions.

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 opening line names a specific operation and resource: 'three-channel semantic search over memories + canonical entities.' It also positions the tool against siblings by stating it is discovery-level and that full bodies should be read via `inspect`, making its role unambiguous.

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 explicitly instructs agents to call this before `query`, tells them to use `inspect` for details, warns against broad `compact=False`, and explains when each channel runs. It also gives concrete cypher_filter guidance, leaving little room for mis-selection.

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