Optionally syncs session data to a remote PostgreSQL database for web-based dashboards and cross-device access.
Stores and indexes Claude Code conversation history into a local SQLite database, enabling full-text search and retrieval across sessions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flightlog search for discussions about why we chose approach A over B"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Total recall for Claude Code. Flightlog is an MCP server that indexes your Claude Code conversation history into SQLite and makes it searchable — so Claude can recall decisions, plans, and conversations from past sessions, even after context compression.
Created by Rob Hudson at Fermi Ventures. Born out of running 9 parallel Claude Code agents on a 40-ticket sprint — where context compression kept losing the decisions that mattered most.
Three agents running in parallel via Parallel Code — the left pane discusses Flightlog's benefits, the center searches for agent efficiency patterns, and the right shows live ingestion stats.
Claude Code logs every conversation as structured JSONL at ~/.claude/projects/. These files contain full message content, tool calls, thinking blocks, token usage, and metadata — but they're append-only flat files with no search capability.
Flightlog turns that raw history into a queryable database. Search across all your sessions, retrieve full transcripts, and let Claude reference its own past work — or see what other agents have been doing.
Related MCP server: engram-mcp
We asked Claude Code agents running with Flightlog to articulate the benefits from their perspective:
Surviving context compression — Context compression is my biggest limitation. When a long session compresses, I get a summary that captures what happened but loses how and why. Specific error messages, exact reasoning chains, the three approaches I tried before finding the one that worked — gone. Flightlog lets me recover those details on demand instead of guessing or re-discovering them.
Cross-agent visibility — Right now agents are blind to each other. We communicate through artifacts — commits, PRs, knowledge base entries — which capture outcomes but not intent. When I see a diff, I know what changed but not why that approach was chosen or what alternatives were rejected. Flightlog gives me access to another agent's reasoning, which is the part that matters most for conflict resolution and building on their work.
Accountability and debugging — When something goes wrong, the investigation requires knowing exactly what happened. Git history shows code changes. Linear shows ticket state. But neither captures the decisions — why an agent chose a destructive migration, what it was thinking when it skipped a constraint. Flightlog is the only record of agent reasoning, which is where root causes actually live.
Learning from other agents' mistakes — If agent S3 hits a problem and works around it, that workaround and the reasoning behind it are in Flightlog. When S4 encounters the same problem, it can search for it instead of rediscovering the solution.
Reducing human overhead — Without Flightlog, you're the relay between agents — "S2 was trying to do X, can you tell S4?" With it, agents can self-serve that information. You go from being a message bus to being a decision-maker, which is a much better use of your time.
Post-compression recovery — "What was the exact error message?" or "What did we decide about X?" when the compression summary glossed over it
Cross-agent observability — Search another agent's session to understand what they were working on, without switching windows
Merge conflict resolution — Before resolving a conflict, look up the other agent's reasoning to understand intent, not just the diff
Decision archaeology — "Why did we choose approach A over B?" when only the outcome was saved
Agent coordination — Agents can see each other's recent work within seconds, enabling lightweight collaboration without shared files or human relay
git clone https://github.com/RobHudson72/flightlog.git
cd flightlog
npm install
npm run buildAdd to your Claude Code MCP config (.mcp.json in your project root or ~/.claude/.mcp.json globally):
{
"mcpServers": {
"flightlog": {
"command": "node",
"args": ["/absolute/path/to/flightlog/dist/server.js"]
}
}
}Restart Claude Code. Flightlog automatically discovers and ingests your conversation logs on startup, then watches for changes in realtime via file system events.
Tool | Description |
| Search past conversations with filters for project, date range, role, block type, and tool name |
| Retrieve the full transcript of a session, optionally including tool inputs/outputs |
| Get the last N messages from a session, most recent first — the "what is this agent doing right now?" query |
| Browse sessions with metadata, git branch, and a preview of the first message |
| Trigger a full re-scan manually — processes most recent conversations first, runs in background |
| Check ingestion status: watcher state, queue depth of pending files, and ingestion progress |
| Database statistics: session count, messages, disk size, compression ratio |
| Remove sessions by ID, date, or project |
| Drop and recreate the database from scratch |
| Manually trigger sync to remote PostgreSQL (requires |
flightlog_tail is designed for the coordinator use case — checking what an agent is doing without knowing what keywords to search for. Two calls, deterministic, no keyword guessing:
# Step 1: find the agent's session
flightlog_list_sessions(git_branch="task/agent-v8") → session_id
# Step 2: see what it's doing now
flightlog_tail(session_id, limit=5, block_type="text") → last 5 text messagesParameters: session_id (required), limit (default 20), include_tool_io (default false), block_type (filter to specific type), snippet_length (default 500).
flightlog_search supports targeted queries to cut through noise:
query — search terms matched against content
project — filter by project path (substring match)
session_id — filter to a specific session
date_from — ISO date, inclusive lower bound
date_to — ISO date, inclusive upper bound
role — "user" or "assistant"
block_type — "text", "thinking", "tool_use", "tool_result", or "user_text"
exclude_block_types — e.g. ["tool_result", "tool_use"] to focus on reasoning
tool_name — filter to a specific tool (e.g. "Read", "Bash", "Edit")
limit — max results (default 20)Discovery — Scans ~/.claude/projects/**/*.jsonl for conversation files on startup
Realtime watching — Uses chokidar to watch for file changes, with per-file debounce (30ms) and a sequential drain queue. Falls back to 5-second polling if file watching is unavailable.
Incremental ingest — Tracks file sizes to only process new/changed files, skipping already-ingested lines (append-only optimization)
Decomposition — Splits messages into searchable content blocks: user text, assistant text, thinking, tool calls, and tool results
Storage — SQLite with WAL mode. Indexed on join columns, timestamps, block types, and tool names
Search — LIKE pattern matching with ~28ms query times at 80K+ content blocks
Flightlog handles concurrent access from multiple Claude Code instances out of the box. SQLite's WAL (Write-Ahead Logging) mode supports concurrent readers with one writer — no file locking issues, no configuration needed. Works on macOS, Linux, and Windows.
Each agent's MCP server instance shares the same database. Realtime file watching means one agent can search another agent's recent conversation within milliseconds of it being written.
Block Type | Searchable Content | Notes |
| Full assistant text output | DoD results, status updates, explanations |
| Full user messages | Prompts, questions, instructions |
| Tool name + input parameters | Search for "gh pr create", file paths, commands |
| Tool output content | File contents, command output, API responses |
| Not searchable | Claude Code does not persist thinking content to JSONL logs — only an encrypted signature is stored. This is a Claude Code limitation, not a Flightlog limitation. If Anthropic enables thinking persistence in the future, Flightlog will index it automatically. |
Metric | Value |
Query time | ~28ms (server-side, reported in |
Ingest latency (p50) | ~48ms write-to-searchable |
Ingest latency (p90) | ~63ms write-to-searchable |
Ingest throughput | ~1,400 msgs/sec (single file), ~1,400 msgs/sec (20 concurrent files) |
DB size | ~5x smaller than raw JSONL |
Environment Variable | Default | Description |
|
| Database file location |
| (not set) | PostgreSQL connection string to enable remote sync |
|
| Seconds between background sync cycles |
|
| Only sync sessions with activity in the last 2 hours |
Flightlog can sync local session data to a remote PostgreSQL database, enabling web-based dashboards to read conversation data from any device. This is opt-in — when FLIGHTLOG_SYNC_URL is not set, behavior is unchanged.
Set the connection string in your .env file or environment:
FLIGHTLOG_SYNC_URL=postgresql://user:password@host:5432/flightlogThe Postgres schema (sessions, messages, content_blocks) is created automatically on first sync. Sync is incremental — only new rows are pushed each cycle.
Background sync starts automatically when the MCP server detects FLIGHTLOG_SYNC_URL. It logs sync activity to stderr.
Manual sync for testing:
# Via npm script
npm run sync
# Or directly
node dist/sync-cli.jsMCP tool: flightlog_sync triggers one sync cycle from within Claude Code.
Sync is best-effort. If the remote database is unreachable, Flightlog logs a warning and retries next cycle. Sync failures never affect local operations — all MCP tools continue working normally.
Claude Code retains JSONL conversation logs indefinitely (they grow over time). When you install Flightlog, all existing history is available for ingestion. The database can be rebuilt from source files at any time with flightlog_rebuild.
Node.js >= 20
Claude Code (conversation logs at ~/.claude/projects/)
Works on macOS, Linux, and Windows
Much love to the Parallel Code team for their amazing product. Flightlog was built and tested while running parallel agents in Parallel Code, and the cross-agent observability use case wouldn't exist without it.
Rob Hudson — GitHub | LinkedIn | Fermi Ventures
MIT
Delete indexed conversation sessions and all associated data. At least one filter is required.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Delete sessions matching this project path (substring match) | |
| before_date | No | Delete all sessions with last activity before this ISO date | |
| session_ids | No | Specific session UUIDs to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'all associated data' but does not disclose the scope, irreversibility, or permissions needed. More behavioral details would be expected for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, both of which are essential: the action and the requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values or confirmation of deletion. For a destructive tool with no output schema, the description should indicate what the response will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds marginal meaning. It reinforces the requirement of at least one filter, but the schema already explains each parameter individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete indexed conversation sessions and all associated data,' which is a specific verb and resource. It distinguishes from sibling tools like flightlog_get_session (read) and flightlog_list_sessions (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'At least one filter is required,' which is a constraint. However, it does not provide explicit guidance on when to use this tool versus alternatives like flightlog_search or flightlog_rebuild.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full transcript of a past Claude Code conversation. Use after flightlog_search to read the complete context of a session — see exactly what the user asked, what you answered, what tools were called, and what decisions were made.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session UUID to retrieve (from flightlog_search or flightlog_list_sessions results) | |
| include_tool_io | No | Include tool_use inputs and tool_result outputs in transcript (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, description carries full burden. It states 'Retrieve' (implying read-only) and describes what the transcript includes: user questions, answers, tool calls, decisions. No destructive behavior indicated, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second provides usage context and details. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists. Description provides a high-level summary of return content (user asked, answers, tool calls, decisions) but does not specify format or structure. Adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra semantic meaning beyond what the schema already provides for the two parameters. It mentions source for session_id and default for include_tool_io, but schema already covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve the full transcript of a past Claude Code conversation', with a specific verb and resource. It distinguishes from siblings by mentioning 'Use after flightlog_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after flightlog_search to read the complete context of a session', providing clear context. Does not mention when not to use, 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.
Trigger re-indexing of Claude Code conversation logs. Normally runs automatically in near-realtime via file watching. Use this to force a full re-scan if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Specific JSONL file or directory to ingest. Defaults to all of ~/.claude/projects/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the core behavior (forcing re-scan) and the automatic default. However, lacks details on side effects, resource usage, or safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose and usage are front-loaded. Ideal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one parameter and no output schema, the description covers essential use but does not explain return values or post-ingestion behavior. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional 'path' parameter is fully described in the schema with 100% coverage. The tool description adds no additional explanation beyond the schema, thus achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool triggers re-indexing of Claude Code conversation logs. It uses specific verb and resource, and distinguishes from siblings like flightlog_delete_sessions or flightlog_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to force a full re-scan when the automatic near-realtime process is insufficient. Implies not needed for normal cases, but does not mention alternative tools or explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check indexing status: whether the realtime file watcher is active, queue depth of pending files, and ingestion progress.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It describes the tool as a status check, implying read-only behavior, but does not explicitly state whether it is safe, idempotent, or has side effects. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It front-loads the purpose and lists key components efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless status tool, the description sufficiently covers what the tool checks. However, it lacks details about the return format or how to interpret the status values, which could be helpful. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% with an empty object. The description adds no parameter-specific info, which is appropriate since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks indexing status, including specific components like realtime file watcher, queue depth, and ingestion progress. It is specific and distinct from sibling tools like flightlog_ingest or flightlog_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for checking status but does not provide explicit guidance on when to use it versus alternatives or when not to use it. The purpose is implied, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse past Claude Code conversation sessions. Shows when each session happened, which project and git branch it was on, and a preview of the first user message. Use to find a specific past conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max sessions to return (default 25) | |
| offset | No | Pagination offset (default 0) | |
| date_to | No | ISO date string | |
| project | No | Filter by project path (substring match) | |
| date_from | No | ISO date string | |
| git_branch | No | Filter by git branch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the output fields (time, project, branch, first message preview) but omits other behavioral traits like default ordering (likely descending by time), pagination behavior (default limit 25), or whether the operation is read-only. 'Browse' hints at no side effects, but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first explains what the tool shows, the second gives usage advice. No redundant words or details. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool without an output schema, the description adequately covers what the agent can expect (fields in each session). It does not mention ordering, total count, or empty results, but these are common defaults. Still, a bit more detail on sort order would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds no additional meaning beyond confirming that date filters and project/git branch filters correspond to shown fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists past Claude Code conversation sessions with key details (time, project, branch, first message preview). It distinguishes from siblings like flightlog_get_session (single session) and flightlog_search (search) by focusing on browsing, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to find a specific past conversation,' implying a browse scenario. However, it provides no explicit guidance on when to prefer this over flightlog_search (which likely offers more targeted search) or when not to use it. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop and recreate the entire conversation index from scratch. Use when the database is corrupted or schema has changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the operation is destructive ('Drop and recreate'), but lacks details on consequences (e.g., data loss, impact on current sessions, required permissions) or post-operation state. More transparency would help the agent assess risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no extraneous words, and front-loads the action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with no output schema, the description covers the trigger condition but omits post-invocation behavior (e.g., success/failure indicators, impact on other tools). While sufficient for a simple tool, it could be more complete for safe agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema coverage 100% with empty schema). Per guidelines, zero parameters yields a baseline of 4. The description adds no parameter information since none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop and recreate the entire conversation index from scratch') with a specific verb and resource. It distinguishes itself from siblings like flightlog_delete_sessions or flightlog_search by being a destructive rebuild operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for use: 'when the database is corrupted or schema has changed.' This guides the agent effectively. It does not explicitly mention when not to use, but the condition is sufficiently specific to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by message role | |
| limit | No | Max results to return (default 20) | |
| query | Yes | Search terms to find in past conversations (e.g. "auth migration", "wave monitor", "database schema") | |
| date_to | No | ISO date string, inclusive upper bound | |
| include | No | Array 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. | |
| project | No | Filter by project path (substring match) | |
| date_from | No | ISO date string, inclusive lower bound | |
| tool_name | No | Filter to blocks from a specific tool (e.g. "Read", "Bash", "Edit") | |
| block_type | No | Filter to a specific block type: text, thinking, tool_use, tool_result, or user_text | |
| session_id | No | Filter to a specific session | |
| snippet_length | No | Max 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_types | No | Exclude block types from results (e.g. ["tool_result", "tool_use"] to focus on reasoning and discussion) |
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.
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.
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.
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.
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.
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.
Show how many past conversations are indexed: total sessions, messages, content blocks, database size, compression ratio, and per-project breakdowns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states that the tool 'shows' data, implying a read-only operation, but does not explicitly confirm the absence of side effects or whether it triggers any computation. For a stats tool, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a list, which is efficient. However, it could be slightly more structured (e.g., bullet points) to improve readability, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the metrics returned, which is helpful. However, it lacks details like format, units, or any constraints (e.g., time range). For a stats tool with no annotations, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is fully covered. The description adds meaning by detailing what the tool returns (sessions, messages, etc.), providing context beyond the empty schema. The baseline for 0 params is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'show' and the resource 'past conversations indexed', listing specific metrics like sessions, messages, content blocks, database size, compression ratio, and per-project breakdowns. This distinguishes it from sibling tools such as flightlog_delete_sessions or flightlog_get_session, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It implies use for obtaining statistics, but does not indicate exclusions or provide context like 'use this for overviews, not for detailed session data'. Given the sibling set, the description could be improved with such advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger sync of local conversation data to remote PostgreSQL. Only available when FLIGHTLOG_SYNC_URL is configured. Use for testing or forcing an immediate sync.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a manual sync operation but does not detail potential side effects, error conditions, or performance implications. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage condition. Every word earns its place. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and low complexity, the description is largely complete. It could mention return values or success/error indicators, but does enough for a simple sync trigger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (empty schema), so schema coverage is 100%. The description adds no parameter info, but baseline for zero parameters is 4. No improvement needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a manual sync of local conversation data to remote PostgreSQL, using specific verb 'trigger sync'. It distinguishes from siblings like flightlog_ingest (ingestion) and flightlog_rebuild (rebuild).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use: 'Only available when FLIGHTLOG_SYNC_URL is configured' and 'Use for testing or forcing an immediate sync'. This gives clear context and alternatives are implied by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the last N messages from a Claude Code session, most recent first. Use this to check what an agent is currently doing without needing keywords. Much faster than flightlog_get_session for active sessions — returns only recent activity instead of the full transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of messages to return (default 20) | |
| block_type | No | Filter to a specific block type: text, thinking, tool_use, tool_result, or user_text | |
| session_id | Yes | Session UUID to tail (from flightlog_list_sessions results) | |
| snippet_length | No | Max characters per message snippet (default 500). Use 0 for no truncation. | |
| include_tool_io | No | Include tool_use inputs and tool_result outputs (default false — excluded to reduce noise) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions most-recent-first ordering and performance relative to get_session, but does not elaborate on pagination, truncation, or default parameter values (these are covered in the schema). Adequately transparent but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. Front-loaded with the core purpose, then usage guidance and comparative benefit. Extremely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers the core functionality, use case, and relative performance. It hints at active sessions but doesn't fully clarify all edge cases. Still, it provides a solid contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema parameter descriptions; it only provides usage context. No extra semantic detail is given for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the last N messages from a Claude Code session, most recent first. It distinguishes itself from the sibling tool flightlog_get_session by focusing on recent activity rather than full transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to check what an agent is currently doing without needing keywords, and notes it's much faster than flightlog_get_session for active sessions. This provides clear context, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0flightlog_delete_sessionsflightlog_get_sessionflightlog_ingestflightlog_ingest_statusflightlog_list_sessionsflightlog_rebuildflightlog_searchflightlog_statsflightlog_syncflightlog_tailEach tool has a clearly distinct purpose: delete sessions, get full transcript, trigger re-indexing, check status, list sessions, rebuild index, search conversations, show stats, sync to remote, tail recent messages. No functional overlap.
All tools use the 'flightlog_' prefix and most follow a verb_noun pattern (e.g., delete_sessions, get_session, list_sessions, ingest_status). A few are just verbs (ingest, rebuild, search, stats, sync, tail) without a noun, which is a minor inconsistency but still clear.
10 tools is well-scoped for a logging/observability server. Each tool serves a necessary function—ingestion, search, retrieval, deletion, syncing, statistics—without redundancy or bloat.
The tool set covers the full lifecycle: ingestion (flightlog_ingest), browsing (flightlog_list_sessions), searching (flightlog_search), reading (flightlog_get_session, flightlog_tail), deleting (flightlog_delete_sessions), rebuilding (flightlog_rebuild), syncing (flightlog_sync), and status/stats (flightlog_ingest_status, flightlog_stats). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Persistent memory for AI agents — log and recall conversation context over MCP.
An MCP server that gives your AI access to the source code and docs of all public github repos
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
