Skip to main content
Glama

search_docs

Search documentation via keyword or BM25 queries, with filters for pack, limit, and response detail. Returns compact summaries and previews to support fast context retrieval.

Instructions

Search documentation chunks using keyword/BM25 search.

RECOMMENDED PATTERN (most token-efficient):

  1. list_packs → discover available packs

  2. search_docs (response_mode="compact") → get chunk IDs and summaries (~50 tokens/chunk)

  3. get_chunk (for relevant IDs) → get full content on demand

Token cost guide: compact: ~50 tokens/chunk (summary only) standard: ~115 tokens/chunk (summary + preview) [default] full: ~250 tokens/chunk (full content)

Result is always a structured JSON object — never null. Empty results include scanned counts and a suggestion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packNoFilter to specific pack(s). Supports glob patterns (e.g. 'react*').
limitNoMax chunks to return (default 5, max 10).
queryYesSearch query. Supports camelCase and snake_case symbols.
token_budgetNoMax tokens for response. System packs as many chunks as possible within budget.
response_modeNoResponse detail level. 'compact' = summary only (~50 tok/chunk). 'standard' = summary + preview (~115 tok/chunk).
min_confidenceNoMinimum confidence level. 'high' = BM25 score ≥ 6.0, 'any' = above floor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations provided, the description takes on full responsibility. It discloses that results are always structured JSON, never null, and that empty results include scanned counts and a suggestion. It also details token costs per response mode. It stops short of explicitly stating read-only semantics, but the content strongly implies no side effects.

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?

Well-organized with clear sections: purpose, recommended pattern, token cost guide, and result note. Front-loaded with the main purpose and every sentence adds value. No redundancy or filler.

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?

Despite no output schema, the description explains the return format, empty-result behavior, and provides a usage flow integrating with sibling tools. All six parameters are effectively explained both in schema and description, making the tool fully callable without additional context.

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 100%, yet the description adds meaningful context: token cost for each response_mode, BM25 score thresholds for min_confidence, and how token_budget packs chunks. This goes well beyond the parameter descriptions and helps the agent choose effective values.

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?

Clearly states the tool searches documentation chunks using keyword/BM25 search, distinguishing it from sibling tools that list packs or retrieve full chunks. The verb+resource+method are specific and not a tautology.

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?

Provides a recommended workflow (list_packs → search_docs → get_chunk) with token cost guidance, explicitly showing when to use this tool versus siblings. It also explains response_mode and token_budget options for controlling output size.

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