Skip to main content
Glama
contextq

@contextq/mcp

Official
by contextq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ctx_search

Search saved knowledge and memories using hybrid full-text and semantic ranking to answer 'what do I know about X' or 'did I already save this'.

Instructions

Search / recall saved knowledge and memories using hybrid full-text + semantic search ranked by relevance — the default tool for 'what do I know about X' or 'did I already save this'. Use this when you need to find, remember, or look up existing knowledge by keyword or phrase. Set chunk_search=false to disable per-chunk passage matching, lifecycle_boost=false for legacy ranking, or include_archived=true to surface retired notes. Results may include lifecycle, quality_score, and matched_chunk per hit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoFilter by tags (all must match)
typeNoFilter by context type
levelNoLayered representation level. 'full' (default) keeps the stored description; 'paragraph' replaces it with a ~120-word distill; 'sentence' replaces it with a ~25-word claim. Use 'sentence' for cheap high-density agent prompts where every token matters. Falls back to the stored description when the distill is not yet populated for a row.
limitNoMax results to return (default 20)
queryYesSearch query (full-text + semantic)
scopeNoFilter by visibility scope
offsetNoOffset for pagination
projectNoFilter by project identifier
subjectIdNoFilter to memories scoped to a single end-user (Mem0-parity user_id axis). Matches the subjectId used when the memory was created via ctx_remember / POST /api/memory. Omit to search across all subjects.
workspaceNoFilter by workspace identifier
memoryKindNoFilter to a single taxonomy kind: 'episodic' (events/interactions), 'semantic' (durable reference knowledge), or 'procedural' (how-to / lessons). Omit to search across all kinds.
chunk_searchNoWhen true (default), search at the chunk level so individual passages can match. When false, only whole-context fields are scored.
epistemicMinNoEpistemic floor (T358): only return contexts at or above this confidence tier (weakest->strongest: assumed < inferred < told < observed). E.g. 'told' excludes 'assumed'/'inferred' rows. Omit to search across all tiers.
lifecycle_boostNoWhen true (default), apply the evergreen/fleeting lifecycle multipliers to the ranking. Set false for legacy ts_rank * tagBoost * recencyBoost only.
include_archivedNoWhen true, include lifecycle='archived' rows. Default false — archived notes are excluded from regular searches.
trace_session_idNoScope trace-event fusion to one agent session (omit to search across the tenant's trace events). Ignored unless include_trace_events is true.
include_trace_eventsNoT375: when true, ALSO search episodic tool-call trace summaries ('what did I try before this worked?') and return them in a separate `traceEvents` field. Default false — this is fully additive and never changes `results` or its ranking. Combine with trace_session_id to scope to one session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely meets it: it discloses the hybrid ranking approach, the effect of include_archived (surfaces retired notes), and the return fields (lifecycle, quality_score, matched_chunk). It omits auth/permission requirements and pagination semantics, so it isn't fully transparent.

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 core purpose is front-loaded and the whole thing is a tight four sentences. The second sentence ("find, remember, or look up") partly restates the first, a minor redundancy, but nothing else is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter tool with 100% schema coverage and no output schema, the description covers the essence plus the key non-obvious flags and the return field shape. It leaves newer features (include_trace_events, epistemicMin tiers, memoryKind filtering) entirely to the schema, which is acceptable given full coverage but not fully self-contained.

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 documents all 17 parameters and the baseline is 3. The description adds light rationale beyond the schema (legacy ranking for lifecycle_boost=false, surfacing retired notes for include_archived), so it earns slightly above baseline.

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/recall) plus resource (saved knowledge and memories), names the mechanism (hybrid full-text + semantic), and positions itself as "the default tool for 'what do I know about X'" — implicitly distinguishing it from save/get/list siblings. An agent can tell what this does and roughly where it fits without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear triggering contexts ("find, remember, or look up existing knowledge by keyword or phrase") and even per-parameter usage advice (chunk_search=false, lifecycle_boost=false, include_archived=true). It does not name explicit alternatives among the many ctx_* siblings or state when NOT to use it, so it stops short of a 5.

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