KeyFlight PNR Converter

decode_pnr (parse PNR to text/JSON) and make_ticket (render a PDF e-ticket) have clearly distinct outputs, so an agent can pick correctly. The minor overlap is that both consume a raw PNR and make_ticket internally parses it, which could briefly make an agent wonder whether ticket generation is a superset of decoding.

Both names follow a snake_case verb_noun pattern (decode_pnr, make_ticket), which is predictable. The only soft spot is that 'make' is vaguer than a more specific verb like 'generate' or 'render', but the convention is clearly consistent.

Two tools is thin for a server that exposes a PNR API surface; it works for a narrow converter but leaves little room for adjacent operations. It sits at the borderline of feeling under-scoped rather than mis-scoped.

The two core workflows (decode to readable/structured itinerary, and produce a PDF e-ticket) are fully covered with no dead ends for the stated purpose. Minor gaps exist, such as no lightweight validate/inspect call or batch handling, but agents can work around them by calling decode_pnr first.