Skip to main content
Glama

Search Indexed Content

ctx_search
Read-onlyIdempotent

Search a unified knowledge base of indexed content and session memory using multi-strategy ranking with typo correction and proximity scoring. Retrieve ranked snippets across stored data and auto-captured events.

Instructions

Search a unified knowledge base with a multi-strategy ranking pipeline. Two parallel matchers run on every query: a Porter-stemming matcher ("caching" finds "cached", "caches", "cach") and a trigram-substring matcher ("useEff" finds "useEffect"). Their ranked lists are merged via Reciprocal Rank Fusion, so a document that ranks well in both surfaces above one that wins only on a single strategy. Multi-term queries get an additional proximity-rerank pass that boosts passages where the query terms appear close together. Typos are corrected via Levenshtein distance and re-searched. Result snippets are window-extracted around the matched terms, not blindly truncated.

The knowledge base is unified: queries reach indexed content you stored (ctx_index, ctx_fetch_and_index, ctx_batch_execute output) AND auto-captured session memory written by hooks (decisions, errors, blockers, plans, user prompts, rejected approaches, tool failures, compaction guides — 26 event categories). File-backed sources carry a content hash and auto-flag staleness when the source file changes.

WHEN:

  • You want to recall something that exists in storage (recently indexed content, prior session events, auto-memory) instead of re-reading raw sources

  • You have multiple related questions about the same body of knowledge — batch every question into one call (the ranking pipeline runs per-query but the round-trip cost is paid once)

  • You want to scope the query to one labelled source (pass source — partial match is fine)

  • You want a chronological view across current session + prior sessions + persistent auto-memory (pass sort: "timeline" — the default relevance mode only ranks within the current session)

  • You want to filter ranked results by content shape (pass contentType: "code" to surface implementation snippets or contentType: "prose" to surface explanations)

WHEN NOT:

  • The data you want to query has never been stored in the knowledge base AND no session memory has accumulated around it — capture first (run a gather-and-index call), then come back here to query

  • You have one ad-hoc question against data that is not in the knowledge base — answer it inline by running code in the sandbox tool; one round-trip instead of capture-then-query

RETURNS: Per-query ranked sections with window-extracted snippets. Use 2-4 specific technical terms per query. Common session-memory source labels: decision (user corrections / preferences), error and error-resolution (past failures + their fixes), blocker, plan, user-prompt, rejected-approach, compaction (post-compact session guide). See ctx_stats for live category counts. Each response carries a throttle counter (call #N/M in the rolling time window); results taper toward the soft cap and calls block after the hard cap. Tune via CONTEXT_MODE_SEARCH_WINDOW_MS, CONTEXT_MODE_SEARCH_MAX_RESULTS_AFTER, CONTEXT_MODE_SEARCH_BLOCK_AFTER.

EXAMPLE: ctx_search(queries: ["root cause", "proposed fix", "test coverage"], source: "issue-#683") EXAMPLE: ctx_search(queries: ["what did we decide about caching"], source: "decision", sort: "timeline") EXAMPLE: ctx_search(queries: ["useEffect cleanup pattern"], source: "react-docs", contentType: "code", limit: 5) EXAMPLE: ctx_search(queries: ["last user prompt", "active skills", "open blockers"], sort: "timeline")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort mode. 'relevance' (default): BM25 ranked, current session only. 'timeline': chronological across current session, prior sessions, and auto-memory.relevance
limitNoResults per query (default: 3)
sourceNoFilter to a specific indexed source (partial match).
queriesNoArray of search queries. Batch ALL questions in one call.
contentTypeNoFilter results by content type: 'code' or 'prose'.
Behavior5/5

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

Goes far beyond annotations by detailing the multi-strategy ranking pipeline (Porter stemmer, trigram, RRF fusion, proximity rerank, typo correction, window extraction), throttle counters, soft/hard caps, and tunable parameters. No contradiction with readOnly, idempotent, non-destructive hints.

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?

Well-structured with clear sections (algorithm, when/when-not, returns, configuration, examples). Slightly verbose but every sentence adds value. Front-loaded with main purpose. Minor redundancy (e.g., ranking details repeated) could be tightened.

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?

Comprehensively covers ranking algorithm, usage guidance, parameter semantics, return behavior (ranked sections with snippets), throttling, and examples. Adequate for a search tool without output schema, addressing all essential aspects.

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%, but the description adds significant context: batching queries, partial match for source, sort mode differences (relevance vs timeline), contentType filtering, and examples illustrating usage. Far exceeds schema descriptions.

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 'Search a unified knowledge base with a multi-strategy ranking pipeline.' The verb 'search' and resource 'unified knowledge base' are specific. The description distinguishes from sibling tools by explaining when to use this tool versus capture-then-query or inline sandbox answers.

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?

Includes explicit 'WHEN' and 'WHEN NOT' sections with concrete scenarios (e.g., recall stored content, batch questions, scope by source) and alternatives (capture-then-query, sandbox inline). Provides clear prerequisites and exclusions.

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/mksglu/context-mode'

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