Skip to main content
Glama

search

Retrieve relevant memories, saved example queries, and entities using semantic, full-text, and entity-overlap matching to inform follow-up questions.

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.

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. 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, Column, Measure, Aggregation).

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. Dates show when Glama detected each change.

  1. First observedv0.10.0

TDQS

A4.9/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 transparency burden, and it excels: it discloses channel preconditions, advanced_search/API-key fallback behavior, Reciprocal Rank Fusion, max_results capping, datasource scoping rules, ValueError conditions, cypher_filter restrictions, and warning emission. This level of behavioral disclosure is unusually complete.

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 well-structured: a front-loaded purpose, a bolded usage directive, numbered channel explanations, fusion/empty-input behavior, and an Args list. Each segment maps to a decision the agent must make or a behavior it should know. It is dense yet not padded.

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 complex tool with no annotations and a bare input schema, this description covers the essential surface: optional channels, installation/API-key prerequisites, datasource scoping, unknown-datasource errors, and cypher_filter limitations. Since an output schema exists, omitting detailed return-shape documentation is acceptable. The only minor gap is the undocumented `compact` parameter, already penalized under parameter semantics.

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 description coverage is 0%, so the Args section is essential, and it adds real meaning to entities, query, question, datasource, max_results, and cypher_filter. However, the `compact` boolean parameter is never mentioned in the description, leaving its effect undocumented. The description compensates strongly for the bare schema but does not fully cover every parameter.

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 sentence names a specific operation: three-channel semantic search over memories and canonical entities. The description further enumerates the channels, fusion method, and result capping, and distinguishes the tool from the `query` sibling with the instruction to call it before `query`. This is far more specific than a generic verb-plus-resource statement.

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 says 'Call this BEFORE `query`' and explains the exact input conditions under which each channel runs. It also documents empty-input behavior so an agent knows this tool still returns newest memories when no search terms are provided. This gives clear guidance on when to use the tool without requiring inference.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MotleyAI/slayer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server