FlightSweeper WebMCP Challenge Edition

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

Live challenge app: webmcp.flightsweeper.com

Source: github.com/raintree-technology/flightsweeper-webmcp

Submitted project: FlightSweeper on Devpost

Demo: Watch the 2:23 public video

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.

Try the core flow

Prerequisite: Use ChatGPT desktop’s in-app browser or Chrome 149+ with WebMCP enabled.

1. Open the live challenge app.
2. Send the prompt below to the browser agent.
3. Watch the mission, offer, and evidence states change as the agent calls the registered tools.
4. 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

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

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:

await document.modelContext.registerTool({
  name: contract.name,
  description: contract.description,
  inputSchema: contract.inputSchema,
  outputSchema: contract.outputSchema,
  annotations: {
    readOnlyHint: contract.readOnlyHint,
    untrustedContentHint: contract.untrustedContentHint,
  },
  async execute(rawInput) {
    assertToolIsValid(contract.name);
    return toolResult(
      await toolExecutors[contract.name](
        validateToolInput(contract, normalizeInput(rawInput)),
      ),
    );
  },
}, { signal: toolController.signal });

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

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.

Challenge evidence

• Agent task and authority contract
• Public agent API contract
• Asset provenance
• Release and accessibility checklist
• Raintree standards application
• Challenge data and privacy
• Public Terms of Use
• Public Privacy Policy
• Legal scope and review record
• Security policy

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.

Contributing, security, and license

Read CONTRIBUTING.md before proposing a change and SECURITY.md for private reporting guidance.

MIT