Skip to main content
Glama

find_sessions

Search all Claude accounts for sessions matching a keyword in title, previous titles, ID, or working directory, returning account details and transcript path for direct access.

Instructions

Find sessions whose title, previous titles, working directory or id contain query, in any account.

Returns, most recent first, the account, title, cwd, cli session id and the transcript path on disk, so the caller can open the transcript directly even when the session belongs to another account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral responsibility. It discloses ordering ('most recent first'), the exact return fields, and the cross-account behavior (transcript path on disk, allowing direct opening). It does not cover limit semantics or auth, but for a read-only search tool this is solid behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs front-load the core action and then detail the return value and use case. Every sentence adds distinct information, with no filler or repetition of schema fields.

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?

The description covers what the tool searches, what it returns, ordering, and the cross-account transcript-opening use case. Minor gaps include limit behavior and exact query matching rules (case sensitivity, substring), but given the simplicity and the schema default, the description is nearly complete for an agent to call the tool correctly.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It adds strong meaning for the query parameter by specifying the fields it matches (title, previous titles, working directory, id). However, the limit parameter is completely absent from the description, leaving its semantics to inference from the schema's default value.

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 uses a specific verb ('Find') with a clear resource ('sessions') and enumerates the searchable fields (title, previous titles, working directory, id). The phrase 'in any account' sets an unmistakable scope and implicitly distinguishes this from sibling tools like list_accounts or terminal_only_sessions.

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

Usage Guidelines3/5

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

The description implies when to use the tool by stating it searches across any account and returns transcript paths, which suggests cross-account lookup use cases. However, it does not explicitly state when not to use it or which sibling tool to prefer instead, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.