Skip to main content
Glama
zademy

Context Mode

Official
by zademy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search Indexed Content

ctx_search
Read-onlyIdempotent

Search a unified knowledge base of indexed content plus auto-captured session memory to recall decisions, errors, plans, and blockers, returning ranked snippets and cross-session results.

Instructions

Search the unified knowledge base: content you indexed plus auto-captured session memory (decisions, errors, blockers, plans, user prompts, compaction guides — 26 categories). Stemming, trigram and typo-tolerant matchers rank each query.

WHEN:

  • You want to recall something already in storage instead of re-reading raw sources

  • You have several related questions about one body of knowledge — batch them into one call

  • You want one labelled source (pass source — partial match is fine) or a cross-session view (pass sort: "timeline")

  • You want to filter by content shape (contentType: "code" or "prose")

WHEN NOT:

  • The data was never indexed and no session memory surrounds it — capture first, then query

  • You have one ad-hoc question about unindexed data — run code in the sandbox tool instead

RETURNS: Per-query ranked sections with window-extracted snippets. Use 2-4 technical terms per query. Labels: decision, error, blocker, plan, user-prompt, compaction. Results taper in the rolling time window and block after the hard cap (CONTEXT_MODE_SEARCH_WINDOW_MS).

EXAMPLE: ctx_search(queries: ["root cause", "proposed fix"], source: "issue-#683")

Input 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)
queryNoSingle search query. Equivalent to queries: [query].
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'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by disclosing match mechanics (stemming, trigram, typo-tolerant ranking), the return shape (per-query ranked sections with window-extracted snippets), result tapering in the rolling time window, and a hard cap (CONTEXT_MODE_SEARCH_WINDOW_MS) that blocks further results. These are behavioral traits the annotations do not carry.

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 WHEN / WHEN NOT / RETURNS / EXAMPLE structure is highly scannable and front-loads the key constraint (recall, not ingestion). It runs a bit long, and the label list plus time-window detail could be trimmed, but nearly every sentence carries actionable content.

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?

There is no output schema, and the RETURNS block compensates by describing ranked sections, snippet extraction, and result labels. Combined with the batching guidance and the index-first prerequisite, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already defines sort, limit, query, queries, source and contentType. The description still adds value with authoring guidance not in the schema — 'use 2-4 technical terms per query' — and by tying source to partial matching and sort: "timeline" to the cross-session view in a usage context rather than a field definition.

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?

States a specific verb (Search) and a specific resource scope (the unified knowledge base: indexed content plus auto-captured session memory across 26 categories), and it distinguishes itself from siblings like ctx_index and ctx_fetch_and_index by framing the tool as a recall/query operation rather than an ingestion one.

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 WHEN / WHEN NOT blocks are explicit: use it to recall already-stored material and batch related questions into one call; do not use it when the data was never indexed and no session memory surrounds it, in which case run code in the sandbox tool instead. The alternative path is named, and concrete triggers (source filtering, sort: "timeline" for cross-session, contentType) are given.

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