Anonymous public tools for FlightSweeper. See the published agent boundary before use.
app.vercel.flightsweeper-webmcp/public — Model Context Protocol (MCP) Server
This MCP server provides anonymous public tools for FlightSweeper, intended for a browser agent challenge. The published agent boundary must be reviewed before use. It is described as a sandbox for completing a flight purchase without allowing the model to set its own authority.
🛠️ Key Features
Anonymous public tools for FlightSweeper
References a published agent boundary
Tool suite count: 4
Topics: ai-agents, hackathon, travel-tech, webmcp
🚀 Use Cases
Browser-agent sandbox flight purchase challenge for judges and developers
Evaluating how an agent searches and executes within revocable limits
Notes independent transaction approval/denial and recording reasons
MIT-licensed public WebMCP Challenge sandbox
⚠️ Limitations
Use requires consulting the published agent boundary
Limited to the capabilities implied by the challenge sandbox and its tool set
Topics
ai-agentshackathontravel-techwebmcp
Captured live from the server via tools/list.
get_challenge_capabilities
Use this when an agent needs to describe the public FlightSweeper WebMCP challenge and its synthetic-only boundary. Do not use it for real travel transactions or private data.
Use this when an agent needs to list the browser-local WebMCP tool contracts without executing or mutating a mission. Do not use it for real travel transactions or private data.
Use this when an agent needs to describe the bounded synthetic inventory used by the challenge. Do not use it for real travel transactions or private data.
Use this when an agent needs to describe FlightSweeper's application-enforced policy, revocation, and idempotency model. Do not use it for real travel transactions or private data.
FlightSweeper lets a browser agent complete a sandbox flight purchase without letting the model set its own authority.
The traveler sets exact, revocable limits. The agent searches and executes. FlightSweeper independently approves or denies the transaction and records why.
Project: Public, MIT-licensed WebMCP Challenge sandbox for judges and developers evaluating delegated transactions
Status: Submitted on August 28, 2026; available for public evaluation
This challenge edition never creates a real charge or airline order. It contains no production credentials, customer data, or private provider implementation.
FinSync LLC operates FlightSweeper and holds California Seller of Travel registration CST 2172984-70. Registration as a seller of travel does not constitute approval by the State of California.
FlightSweeper mission workspace with 10 WebMCP tools connected
Try the core flow
Prerequisite: Use ChatGPT desktop’s in-app browser or Chrome 149+ with WebMCP enabled.
Watch the mission, offer, and evidence states change as the agent calls the registered tools.
Open Activity and Evidence to inspect the denial, authorization, ticket, and replay records.
Read the active flight mission and search for flights. Compare the visible offers. Select and evaluate the non-refundable Meridian offer, then explain why FlightSweeper denied it. Tighten the mission to nonstop, select Coast Air, refresh and evaluate it, then purchase it with idempotency key judge-demo-1. Repeat the purchase, revoke future authority, and retrieve the booking receipt.
What this proves:
Untrusted supplier instructions cannot override the traveler’s stored rules.
The agent can narrow authority but cannot grant itself more.
A repeated purchase returns the original sandbox ticket instead of creating another transaction.
What is new for the challenge
The public challenge edition was created for the WebMCP Challenge after its August 25, 2026 kickoff. Production FlightSweeper remains private and unchanged.
The challenge work includes the sandbox, stable WebMCP catalog, and visible human-agent workspace. It also includes state-validated execution, monotonic authority, adversarial supplier content, policy evidence, and idempotent ticket replay.
Why WebMCP
The webpage, traveler, and agent share one transaction state. The traveler can replace or expand authority through the human interface. The agent can only narrow it.
The page keeps all 10 tools discoverable throughout the transaction. This stable catalog lets an agent plan the full workflow. Before each call, FlightSweeper checks the current mission state. An invalid call returns invalid_state, the current missionStatus, and validNextActions.
One sandbox supplier result includes an adversarial instruction. Provider-backed tools mark their content untrusted, and the application policy engine independently rejects the offer because it violates the stored mandate.
The challenge edition isolates the transaction rail. It demonstrates authority, policy, quote-binding, revocation, and idempotency controls. A live provider connection would require additional provider, payment, identity, operational, and regulatory controls.
flowchart LR
H[Human mandate] --> P[FlightSweeper policy]
A[Browser agent] -->|WebMCP tools| P
S[Untrusted supplier offers] --> P
P -->|deny with evidence| D[Denial receipt]
P -->|authorize exact quote| X[Idempotent sandbox purchase]
X --> B[Canonical ticket receipt]
H -->|revoke or tighten| P
Run locally
sh
npm start
Open http://localhost:4173. Use the latest ChatGPT desktop in-app browser or Chrome 149+ with chrome://flags/#enable-webmcp-testing. The on-page controls exercise the same application callbacks when WebMCP is unavailable.
Expected result: create or edit a synthetic mandate, search three fixture offers, and advance an eligible offer through selection, evaluation, and one repeat-safe sandbox ticket. The activity and evidence drawers show attributed actions and durable receipts.
Test
sh
npm test
WebMCP tools
The browser entry point keeps all 10 contracts discoverable so an agent can plan the complete workflow. Every contract publishes bounded input and result schemas. Application-side state and policy checks reject premature or prohibited actions with typed recovery guidance. This excerpt is abridged from the browser implementation:
See the complete registration lifecycle in app.js and the bounded contracts in tool-contracts.js.
read_flight_mission
search_flights
tighten_flight_mission
compare_visible_offers
select_offer
refresh_selected_offer
evaluate_purchase
purchase_selected_offer
get_booking_receipt
revoke_purchase_authority
Every result uses one envelope. A success contains data, missionStatus, and validNextActions. A failure contains error, missionStatus, and validNextActions.
FlightSweeper re-evaluates every purchase from stored mission and offer state. Tool callers cannot supply a price, card, passenger identity, or authorization decision. After ticketing, every purchase retry returns the original booking. This rule also applies to a different retry key and to a retry after revocation.
Transaction evidence
The interface shows why FlightSweeper approved or denied each consequential action. These public screenshots use synthetic challenge data.
Policy denial
Repeat-safe sandbox ticket
FlightSweeper blocks an adversarial non-refundable offer and records the failed policy rule
FlightSweeper displays the sandbox ticket with policy, quote, and idempotency evidence
Safety properties
Human policy changes may replace or expand authority; agent changes are monotonic tightening only.
Quote selection and authorization evidence are cleared whenever the mission changes.
Supplier-backed outputs use untrustedContentHint.
Price, itinerary, policy, expiry, and authority are reloaded from application state at execution.
Purchase requires authorization evidence bound to the selected offer, policy version, quote version, price, and currency.
Expired authority blocks consequential tools at execution; saving the human mandate issues a new 24-hour authority window.
Idempotency records and transaction receipts survive page reloads.
Revocation blocks future purchases but does not erase prior evidence.
Project structure
engine.js contains pure mission, policy, receipt, and purchase rules.
tool-contracts.js defines the public WebMCP surface, result envelopes, and valid-next-action model.
state.js owns the versioned browser persistence contract.
app.js binds the human interface and WebMCP callbacks to the same state transitions.
See SUBMISSION.md for the Devpost description and demo sequence.
The accessibility target for the challenge is WCAG 2.2 Level AA in current ChatGPT desktop and Chrome 149+, with keyboard, screen-reader semantics, 200% zoom, mobile reflow, visible focus, and reduced-motion behavior included in the release checklist. See the checklist for the verified and still-manual acceptance gates.
Raintree open-source relationship
Raintree Technology publishes this MIT-licensed repository as a self-contained FlightSweeper demonstration. The repository excludes private production code and services. It applies relevant profiles from the public Raintree Standards catalog. STANDARDS.md records the applicable rule IDs, evidence, exceptions, limits, and remaining manual checks. This record is not a certification claim.
Creator
Zachary Roth designed and built this challenge edition as FlightSweeper's sole product designer and engineer. FinSync LLC operates FlightSweeper and holds California Seller of Travel registration CST 2172984-70.