Skip to main content
Glama
shinpr

Local RAG

by shinpr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

query_documents

Search ingested local documents using hybrid keyword and semantic matching to retrieve relevant chunks with source file and context. Restrict results by file path prefixes for targeted lookups.

Instructions

Search ingested documents with hybrid keyword + semantic matching. Use the returned order as the ranking; score may disagree with it. Each has filePath, chunkIndex, text, fileTitle, score (lower is closer), and source (for ingest_data items).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 10, range 1-100). Lower favors precision, higher recall.
queryYesSearch query. Preserve specific user terms (for keyword match); add context when the query is vague (for semantic match).
scopeNoOptional absolute path prefix(es) — one string or a list (unioned) — restricting results to a filePath equal to or under a prefix. "/docs/api" matches "/docs/api/auth.md" but not "/docs/apiv2". Must be absolute (server OS style); a relative prefix matches nothing — derive one from a filePath returned by an earlier query, or omit scope.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.19.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 10, range 1-20). Lower favors precision, higher recall."New value: +"Max results (default 10, range 1-100). Lower favors precision, higher recall."
    • changedInput schema / properties / limit / maximum
      Previous value: -20New value: +100
  2. Changed3 schema fields changedv0.15.3
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of results to return (default: 10, range: 1-20). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."New value: +"Max results (default 10, range 1-20). Lower favors precision, higher recall."
    • changedInput schema / properties / query / description
      Previous value: -"Search query. Include specific terms and add context if needed."New value: +"Search query. Preserve specific user terms (for keyword match); add context when the query is vague (for semantic match)."
    • addedInput schema / properties / scope
      Added value: +{
+  "description": "Optional absolute path prefix(es) — one string or a list (unioned) — restricting results to a filePath equal to or under a prefix. \"/docs/api\" matches \"/docs/api/auth.md\" but not \"/docs/apiv2\". Must be absolute (server OS style); a relative prefix matches nothing — derive one from a filePath returned by an earlier query, or omit scope.",
+  "oneOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ]
+}
  3. Changed3 schema fields changedv0.15.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of results to return (default: 10). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."New value: +"Maximum number of results to return (default: 10, range: 1-20). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."
    • addedInput schema / properties / limit / maximum
      Added value: +20
    • addedInput schema / properties / limit / minimum
      Added value: +1
  4. Changed2 schema fields changedv1.0.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of results to return (default: 5, max recommended: 20)"New value: +"Maximum number of results to return (default: 10). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."
    • changedInput schema / properties / query / description
      Previous value: -"Natural language search query (e.g., \"transformer architecture\", \"API documentation\")"New value: +"Search query. Include specific terms and add context if needed."
  5. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does it well: it explains the hybrid matching strategy, warns that returned order — not score — is the ranking, and clarifies 'score (lower is closer)'. These are non-obvious behaviors an agent must know before interpreting results. It stops short of stating read-only safety or empty-result behavior, but for a search tool that is a minor gap.

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?

Three sentences with zero filler; the core purpose is front-loaded in sentence one, and sentences two and three each add distinct, high-value behavioral and return-format facts. Every clause earns its place.

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?

Complete for a search tool with a rich schema: it documents the return shape (critical since there is no output schema), the ranking-vs-score nuance, and the conditional 'source' field. Remaining gaps — pagination beyond limit=100, empty-result behavior, and an explicit read-only statement — are minor given the tool's simplicity.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail, including limit's default/range and scope's prefix-matching semantics. The description adds modest value by explaining what score means and that order is authoritative, which gives semantic weight to the limit tradeoff, but it does not need to compensate for any coverage 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?

Names a specific verb ('Search'), a resource ('ingested documents'), and a method ('hybrid keyword + semantic matching'), which cleanly separates it from siblings like list_files, read_chunk_neighbors, and the ingest/sync tools. The result-field list (filePath, chunkIndex, text) makes it unambiguous that this searches document content rather than listing the file tree.

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?

Parameter-level guidance is strong: the query description tells when to preserve user terms vs. add context, and the scope description warns that relative prefixes match nothing and suggests deriving one from an earlier filePath. However, the description never explicitly states when to choose query_documents over a sibling such as list_files or read_chunk_neighbors; the use case is implied by the word 'search' rather than stated.

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

Deploy Server

Other Tools