Skip to main content
Glama

Search Indexed Content

ctx_search

Search a unified knowledge base of indexed content and session memory using multi-strategy ranking. Batch queries, filter by source or content type, and sort by timeline for relevant results.

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

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

No annotations are provided, so the description carries full burden. It extensively details the ranking pipeline (stemming, trigram, RRF, proximity rerank, typo correction), snippet extraction, knowledge base contents (indexed content and auto-memory), staleness detection, throttle counter, and tuning parameters. No contradictions.

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?

The description is well-structured with clear sections and front-loaded with important ranking details. While verbose, every sentence adds value, and the organization makes it easy to parse.

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?

Without an output schema, the description adequately explains return values (ranked sections with snippets, throttle counter). It covers complex aspects like the knowledge base contents, staleness, tuning, and provides examples covering various use cases.

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?

Although schema description coverage is 100%, the description adds significant meaning beyond the schema. It explains the effect of each parameter (e.g., sort modes, source partial match, contentType filtering) and provides examples demonstrating usage.

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 clearly states that the tool searches a unified knowledge base, explains the ranking pipeline, and distinguishes itself from sibling tools like ctx_index (for storing) and ctx_stats (for statistics). It uses specific verbs and resources.

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 description provides explicit 'WHEN' and 'WHEN NOT' sections, detailing when to use this tool (e.g., recalling stored content, batching multiple questions) and when not (e.g., data not yet stored). It also suggests alternatives like sandbox tools for ad-hoc queries.

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