Skip to main content
Glama

Epstein

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Epstein Flight Log Search

epstein_flight_log_search
Read-onlyIdempotent

Structured search over Epstein's pilot flight logbook (Government Exhibit 662-RR, USA v. Ghislaine Maxwell, 20-cr-330, S.D.N.Y.) — date, aircraft, tail number, route and the pilot's own passenger/remarks entry for each leg. Passenger initials and names are returned EXACTLY as the pilot wrote them ('JE, GM, SK') — never resolved to a full identity, per design decision C on this build. A token the transcriber could read but not confirm carries a trailing '[?]'; a wholly unreadable token is '[illegible]' — neither stands in for a guessed identity. Only 397 of an estimated 3,000+ logged legs are ingested (23 of 118 exhibit pages, spanning 1991-2005) because the rest requires further page-by-page visual transcription — call epstein_flight_log_search with no filters to see exactly which pages are covered before concluding an absence. Use it to find who is logged on a given tail number, route or date range, or to search the remarks text for a name or initials.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoArrival identifier as printed, e.g. "PBI".
fromNoDeparture identifier as printed, e.g. "TEB".
limitNoMax rows, default 20, max 100.
date_toNoLatest flight date, YYYY-MM-DD.
date_fromNoEarliest flight date, YYYY-MM-DD.
passengerNoSubstring to find in the remarks/passenger entry, e.g. "GM" or "Clinton". Case-insensitive.
tail_numberNoAircraft registration as printed, e.g. "N908JE".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context: passenger initials are returned exactly as written, never resolved to full identity (design decision C), tokens carry '[?]' or '[illegible]' markers, and the coverage limitation is disclosed. This goes beyond the annotations and is critical for interpreting results correctly.

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 paragraph with multiple sentences, each providing necessary information: purpose, coverage limitation, token handling, and usage instruction. It is front-loaded with the main purpose and then elaborates. It is longer than minimal but every sentence earns its place; no filler. Slightly longer than necessary for a simple tool, but given the complexity and caveats, it is well-structured.

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?

Given the tool's complexity (7 optional parameters, no output schema, but annotations cover safety), the description is highly complete. It covers the data source, what fields are returned, how ambiguous tokens are handled, the coverage limitation, and specific usage guidance. An agent can call this tool correctly and interpret results without needing additional context. Nothing essential is missing.

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% (all 7 parameters have descriptions), so the schema already documents each parameter's meaning and format. The description adds no new parameter-specific semantics; it does clarify the passenger parameter's behavior ('substring to find in the remarks/passenger entry') but that is already in the schema. The extra details about output format and coverage are about overall behavior, not parameter semantics. Baseline 3 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 states a specific verb ('Structured search over Epstein's pilot flight logbook') and resource, and lists the fields returned (date, aircraft, tail number, route, passenger/remarks). It explicitly distinguishes itself from sibling tools by being the structured flight log search, whereas epstein_search_documents searches documents. It also states the use case: 'find who is logged on a given tail number, route or date range'.

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?

The description explicitly instructs calling with no filters to see page coverage before concluding an absence, and explains the partial ingestion (397 of 3,000+ legs). It also clarifies that this tool is for structured search over the flight logbook, implying when to use it over other search tools. No exclusions are stated, but the usage context is clearly defined.

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

All Epstein toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources