Flight Fare Watch

What it does

Flight Fare Watch monitors flight fares for a route/date against a target price and emits a structured, grounded alert. It is read-only and never books or purchases. Given fare offers (provided by you or from built-in mock fixtures), it deterministically computes the lowest and average fare, the change/trend vs a previous observation, and whether the fare hit your target — every number and the alert decision are code-derived. An LLM (with a deterministic template fallback) only humanizes the alert message; it never decides whether to alert and never invents a price. Every message carries a fare-volatility disclaimer. This published build runs on your own caller-provided offers or built-in mock fixtures, so you can evaluate fares with zero setup. (The repo also ships a connector-ready read-only fare client gated behind an API key for a live sandbox; the hosted listing is designed around passing offers in as data.) Guardrails: read-only (no booking/purchase), prompt-injection defang on source free text, no fabrication when fares are unavailable, and a volatility disclaimer on every alert. Tools: - run_full — end-to-end: fetch fares (provided/mock), deterministically evaluate vs target, synthesize an alert message, return the full AgentResult JSON. - fetch_fares — read-only fare lookup for a route/date (mock/provided). Never books or purchases. - evaluate_threshold — deterministic trigger logic only (no LLM, no network): from offers + a target, compute lowest/average, change vs previous, and whether the alert triggers. - validate_alert — validate an AgentResult for numeric and schema consistency (trigger matches lowest ≤ target, required fields present). - list_capabilities — static capabilities: tools, credential slots, guardrails. - plan_inputs — interview helper returning questions, JSON schema, and a ready-to-edit example for a tool. Provide offers as [{ airline, price, stops?, depart? }] with a target_price. Array/object arguments may be passed as JSON or a JSON string. Missing required inputs return a structured needs_input payload (questions + schema + example) instead of erroring, and upgrade to a native elicitation form on clients that support it.

Example prompts

• Run run_full for IST→LHR on 2026-08-01 with target_price 300 and these offers, and tell me if it triggers.
• Use evaluate_threshold on these fare offers with target 250 and previous_lowest 340 — lowest, average, and trend?
• Watch fares for a round trip and alert me when the lowest drops to or below my target.
• Validate this AgentResult with validate_alert — are the numbers and trigger internally consistent?
• Use plan_inputs for run_full and show me the questions, schema, and a ready-to-edit example.

Tools (6)

Tools the agent exposes — your AI client calls them automatically when it needs them.

• run_full — Run end-to-end: fetch fares (read-only), deterministically evaluate vs target, and synthesize an alert message. Returns the full AgentResult JSON.
• fetch_fares — READ-ONLY: look up current fares for a route/date (mock fixture / provided data). Never books or purchases.
• evaluate_threshold — DETERMINISTIC trigger logic only (no LLM, no network): given fare offers + a target, compute lowest/average, change vs previous, and whether the alert triggers.
• validate_alert — Validate an AgentResult: numbers are internally consistent (lowest <= average-band, trigger matches lowest<=target), required fields present, schema valid.
• list_capabilities — List the agent's static capabilities: tools, credential slots, and guardrails.
• plan_inputs — Plan/brainstorm the inputs for a tool: returns the questions, schema and a ready-to-edit example.