Skip to main content
Glama
RobHudson72

flightlog

by RobHudson72

flightlog_search

Search past Claude Code conversations to recall decisions, plans, code discussions, and debugging sessions using full-text search across all sessions.

Instructions

Search YOUR past Claude Code conversations — every message, tool call, and thinking block from previous sessions. Use this to recall decisions, plans, code discussions, debugging sessions, or anything discussed in prior conversations that you no longer have in context. Returns matching snippets with session IDs and timestamps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoFilter by message role
limitNoMax results to return (default 20)
queryYesSearch terms to find in past conversations (e.g. "auth migration", "wave monitor", "database schema")
date_toNoISO date string, inclusive upper bound
includeNoArray of extra field keys to add to each result. Valid keys: "token_counts" (adds input_tokens, output_tokens, cache_read_tokens, cache_creation_tokens), "version" (Claude Code version string), "uuid" (message ID), "cwd" (working directory). Example: ["token_counts", "version"]. Default results already include session_id, project, timestamp, role, model, git_branch, block_type, tool_name, snippet — use this parameter only when you need fields beyond those.
projectNoFilter by project path (substring match)
date_fromNoISO date string, inclusive lower bound
tool_nameNoFilter to blocks from a specific tool (e.g. "Read", "Bash", "Edit")
block_typeNoFilter to a specific block type: text, thinking, tool_use, tool_result, or user_text
session_idNoFilter to a specific session
snippet_lengthNoMax characters per snippet (default 300). If a result ends with "..." it was truncated — use 0 to return full content with no truncation, or a larger value like 5000. Use flightlog_get_session for full transcripts.
exclude_block_typesNoExclude block types from results (e.g. ["tool_result", "tool_use"] to focus on reasoning and discussion)
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the tool returns matching snippets with session IDs and timestamps, and mentions truncation behavior (results ending with '...' can be expanded via snippet_length parameter). It does not mention read-only nature explicitly, but given the search function, it is implied and no contradictory signals exist.

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?

The description is concise—three sentences that front-load the purpose, immediately state the content type and use case, and provide return value hints. Every sentence adds value, and there is no extraneous information.

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?

Given the tool has 12 parameters (1 required) and no output schema, the description is reasonably complete. It explains what is returned (snippets with session IDs and timestamps), mentions truncation behavior, and flags flightlog_get_session for full transcripts. It could briefly mention default result fields, but the schema covers parameter details.

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 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; it focuses on the tool's purpose and behavior. The parameter descriptions in the schema are already detailed, so the description adequately complements them.

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 the tool searches past Claude Code conversations, listing specific content types (messages, tool calls, thinking blocks) and use cases (recall decisions, plans, code discussions). It distinguishes from sibling tools by mentioning flightlog_get_session for full transcripts, and the context of 'conversations you no longer have in context' sets it apart from other flightlog tools.

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?

The description explicitly tells when to use the tool: to recall past discussions and decisions. It provides context for alternatives by referencing flightlog_get_session for full transcripts. However, it does not explicitly state when NOT to use this tool (e.g., if you need full session content vs. snippets), but the guidance is sufficient.

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/RobHudson72/flightlog'

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