Skip to main content
Glama

search_sessions

Search stored coding-agent sessions by text, with filters for agent, scope, and boolean logic; sort by relevance, date, or meaning, and redact secrets.

Instructions

Case-insensitive search across sessions.

Args: query: Search string. Supports: * Bare words: pwa manifest (AND default) * Quoted phrases: "exact phrase" * Negative prefix: -claude (Google-style, always excluded) agent: Optional agent filter (claude/codex/opencode/antigravity/pi). scope: Where to look. * "title" — only session.title (default, backward-compat) * "body" — message text + tool_use[*].input + tool_result[*].content * "all" — title OR body operator: How to combine positive terms. * "AND" — all positive terms must appear (default) * "OR" — at least one positive term must appear * "NOT" — no term (positive or negative) may appear Negative -term prefixes are always excluded regardless of operator. limit: Maximum number of results. 0 or negative = no limit. Applied after sorting, so it keeps the top-ranked matches. sort: Result ordering. * "relevance" — BM25 relevance over the matched text (default). Pure-stdlib scoring; ties keep newest-first. * "date" — newest-first by session date (the historical pre-ranking order). * "semantic" — F5.1 (optional ai-r[semantic]): the BM25 top-50 candidates re-ranked by meaning with a local multilingual embedding model (cross-lingual ru↔en, synonyms); the response carries a semantic dict — either the active ranking (active: true, model, candidate count, blend weight) or the honest degradation notice (active: false + plain-words reason + fallback: "bm25", order stays BM25 — never a crash). noise: Noise filter — a session is noise when it is a spawned subagent (kind == "subagent" or parent_uuid set). * "include" — no filtering (default). * "exclude" — search only top-level agent sessions. * "only" — search only subagent sessions. Applied before matching, so excluded sessions never pay the body-scan cost. redact: When True (default) secrets in the emitted title / snippet / extra fields are masked as [REDACTED_<TYPE>] and the response carries a redactions type→count dict when any replacement happened; False returns raw content. Matching always runs on the RAW stored text, so searching for a literal secret still finds its session — only the displayed snippet is masked. include_thinking: When True fold model reasoning (message.thinking) into the body/all search haystack so a search matches text that lives only in the model's thoughts. Default False: reasoning is excluded from matching to save the caller's budget (turn it on only when a query must reach into reasoning). No effect on scope="title". The two modes are cached under separate keys, so toggling never serves a stale haystack of the other mode.

Returns: A dict {"results": [...], "count": N} where results is the list of session summaries and count is their total. When scope is "body" or "all" and a match is found, each summary includes a "snippet" field with the first matching message excerpt (up to 200 chars) and may carry body_truncated. When a scan matches nothing (count == 0), the dict additionally carries diagnostics (scanned agents + session counts, corpus date bounds, cause hints) so an empty result is explainable. With sort="semantic" the dict also carries a semantic report (active ranking vs BM25 fallback + reason).

Errors are returned as a top-level {"error": ..., "message": ...} dict (matches the existing convention).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNorelevance
agentNo
limitNo
noiseNoinclude
queryYes
scopeNotitle
redactNo
operatorNoAND
include_thinkingNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully carries the transparency burden and does so excellently. It discloses case-insensitivity, search operators, negative-prefix behavior, noise filter semantics, redaction that still allows raw matching, include_thinking budget implications, caching behavior, and honest degradation for semantic sort. It even documents error return format. Exceptionally 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 description is long, but it's a complex tool with 9 parameters and subtle behaviors. It is well-structured: opening line, Args block, Returns block, Errors note. Every sentence adds necessary detail; no filler. Slightly verbose for a quick read, but appropriate given the tool's complexity, so not a 5.

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 is complete for a complex search tool. It defines the result dict, count, snippet field, body_truncated, diagnostics on empty results, and the semantic report. It covers edge cases, fallback behavior, and error convention. No critical behavioral aspect is left unexplained. Given the tool's complexity, this is fully complete.

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 has 0% description coverage, and the description thoroughly compensates. Every one of the 9 parameters is explained beyond type alone: query supports special syntax (quoted phrases, negative prefix), scope enumerates options with examples, operator explains AND/OR/NOT and negative-term interplay, limit describes post-sort application, sort details BM25 vs date vs semantic with fallback, noise defines 'noise' precisely, redact explains masking and raw-search behavior, include_thinking covers haystack modes and caching. This is exemplary parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opening line is clear: 'Case-insensitive search across sessions.' Specific verb+resource. Does not explicitly differentiate from siblings like list_sessions or query, but the search semantics are apparent. Loses one point for not naming alternatives, but purpose itself is unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs siblings. Does not mention list_sessions, query, find_tool_calls, etc., or provide any exclusionary context. The detailed Args section explains how to configure the search, but not when the tool should be preferred. Thus, only implied usage, no explicit decision framework.

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/pro-target/ai-r'

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