Skip to main content
Glama

query_documents

Hybrid search: semantic similarity plus a keyword boost for exact terms.

Instructions

Hybrid search: semantic similarity plus a keyword boost for exact terms.

Returns results — ranked chunks with text, source, title, chunkIndex, score and parentId — sources, the distinct sources in rank order each with a hits count and a displayPath to show the user (source stays absolute and is what the other tools take), and parents, a map from parentId to section text. Use sources to answer "which documents cover this topic" without inspecting individual chunks.

text is the passage that matched and that score describes. parentId names the section it sits in — a transcript time window, a heading section, a slide, a table. Look it up in parents to read the whole section when the match alone is too small to act on. A chunk indexed before parent sections existed has parentId null and no entry; re-sync to fill it in.

topK must be at least 1 and is capped at 100; a larger value is silently clamped to the cap rather than rejected.

When nothing matches because nothing could — an empty index, or a scope no indexed document is under — notice says which.

Cite what you take, so the user can verify it, in whatever language you answer: end with a Sources list, one line per document you actually used, each line just that document's displayPath copied verbatim — no [n] markers, nothing else on the line. Plain text, never a markdown link or file://.

labels ({facet: value or [values]}) and dateFrom/dateTo (YYYY-MM-DD, inclusive) narrow the search to labelled documents when the corpus has a classify.toml; status lists its facets and values under labels — map an approximate name to a value from there. filterCounts then says how many documents in scope were left out only for having no label or no date; each sources row carries its labels and date.

Input Schema

NameRequiredDescriptionDefault
topKNo
queryYes
scopeNo
dateToNo
labelsNo
dateFromNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.0
    • addedInput schema / properties / dateFrom
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / dateTo
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / labels
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        ]
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With zero annotations the description carries the full burden and does so: it discloses topK clamping at 100 (silently, not rejected), that a pre-parent-section chunk has parentId null and requires re-sync, and that `notice` reports empty-index or out-of-scope empty results. It also explains filterCounts and per-source label/date fallback, which an agent could not infer otherwise.

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?

Purpose is front-loaded and each paragraph covers a distinct concern (returns, parents, topK, empty results, citation, filters). It is long and the citation-format paragraph is dense, but nearly every sentence carries operational information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-param tool with no annotations, the definition covers return shape, edge cases, clamping, and filtering adequately, and the citation convention is spelled out so the agent knows what the user expects. The unexplained `scope` parameter is the notable omission; the heavy return-value explanation is somewhat redundant given the output schema exists.

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 0%, so the description must compensate, and it does for most params: topK bounds and clamp behavior, `labels` shape ({facet: value or [values]}) with the instruction to map approximate names via the `status` tool's facets, and dateFrom/dateTo as inclusive YYYY-MM-DD. `scope` is left entirely undefined despite accepting a string, array, or null — the one real 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?

Opens with a specific mechanism: hybrid search combining semantic similarity with a keyword boost for exact terms. That verb+resource framing plus the mechanism distinguishes it cleanly from read_file, list_files, and read_chunk_neighbors, which retrieve rather than search.

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?

Gives usage guidance for outputs (use `sources` to answer 'which documents cover this topic' without inspecting chunks) and for edge cases (`notice` when nothing could match), but never states when to choose this over read_file or read_chunk_neighbors, nor any exclusions. The routing guidance is implied rather than explicit.

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