flightlog

by RobHudson72

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![flightlog MCP server](https://glama.ai/mcp/servers/RobHudson72/flightlog/badges/card.svg)](https://glama.ai/mcp/servers/RobHudson72/flightlog)

Score Badge

Copy to your README.md:

[![flightlog MCP server](https://glama.ai/mcp/servers/RobHudson72/flightlog/badges/score.svg)](https://glama.ai/mcp/servers/RobHudson72/flightlog)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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