Skip to main content
Glama

search_knowledge

Search a knowledge base using hybrid semantic and keyword matching, with cross-encoder reranking for relevant results. Filter by category and tune search parameters.

Instructions

Hybrid search combining semantic search + BM25 keyword search with cross-encoder reranking.

Read-only. No side effects.

Args: query: Search query text (1–3 keywords recommended; phrase queries also work) max_results: Maximum number of results (default: 5, max: 20) category: Optional category filter — one of: security, ctf, logscale, development, general, redteam, blueteam. Call list_categories() first to see available categories and counts. hybrid_alpha: Balance between semantic and keyword search. 0.0 = keyword-only (best for exact technical terms like CVE IDs or tool names), 0.3 = balanced default, 1.0 = semantic-only (best for conceptual or natural-language queries). min_score: Minimum normalized relevance score (0.0–1.0) to include a result. Results scoring below this threshold are discarded. Default 0.0 returns all results. Use 0.2–0.4 to cut low-relevance noise. snippet_mode: When true (default), truncates content to ~500 characters at a natural break point and adds a content_length field with the original size. Use get_document() to fetch full content when needed. Set to false to return full chunk content. search_method: Dispatch selector (v4.8.2+). One of "auto" (router picks FTS5 fast-path for lexical queries when enabled, hybrid otherwise), "hybrid" (force hybrid path — kill switch for suspected router misclassification), or "fts5" (force FTS5 fast-path — debug/testing; errors out when the feature is disabled or the index is not ready). Default "auto" preserves pre-v4.8.2 behavior byte-for-byte when the fast-path is disabled in config.

Returns: JSON string with results including content chunks, source filepath, relevance score, and search method used. Returns chunks, not full document content.

Usage: Primary search tool — use for any topic or keyword lookup. Prefer search_similar() when you already have a reference document and want more like it. Prefer get_document() when you already know the exact filepath and need the full content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
categoryNo
min_scoreNo
max_resultsNo
hybrid_alphaNo
snippet_modeNo
search_methodNoauto

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries full burden and does so thoroughly. It discloses read-only nature ('Read-only. No side effects.'), snippet truncation behavior, min_score filtering, search_method dispatch behavior including compatibility notes, and return format.

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?

While long, the description is well-structured with sections (overview, read-only, Args, Returns, Usage) and each sentence earns its place. It is front-loaded with the primary purpose, and the parameter details are necessary for correct invocation.

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?

The description covers the return format (JSON string with content chunks, source filepath, relevance score, search method), parameter semantics, alternatives, and edge cases like FTS5 fast-path errors. Given the tool has 7 parameters and an output schema, this description is complete without relying on external documentation.

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 description coverage is 0%, so the description must compensate, and it excels. Every parameter is explained with practical guidance: query recommendations (1-3 keywords), hybrid_alpha semantics (keyword vs semantic), min_score tuning (0.2-0.4 to cut noise), and search_method behavior including a kill switch and debug use case.

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 description opens with 'Hybrid search combining semantic search + BM25 keyword search with cross-encoder reranking,' clearly stating the tool's specific action (search) and resource (knowledge). It also differentiates from siblings by noting it 'Returns chunks, not full document content' and referencing search_similar and get_document.

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 Usage section explicitly states this is the 'Primary search tool' and names direct alternatives: 'Prefer search_similar() when you already have a reference document...' and 'Prefer get_document() when you already know the exact filepath...' This provides explicit when-to-use vs when-not-to-use guidance.

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

Install Server

Other Tools

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/lyonzin/knowledge-rag'

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