Agent Tools and Trip Watch

Once an assistant can do more than answer questions, two problems appear at the same time. The first is access: an agent acting for a traveler or a host needs a defined set of operations, not a free hand, and the difference between reading a listing and cancelling a booking has to be visible before anyone connects a client. The second is attention: the things worth acting on during a trip — a price that moved, a host cancellation, a weekend that is not filling — happen while nobody is watching. This concept covers both, and keeps a person at the point of decision in each.

The first illustration is a catalog of the operations exposed to agents through a Model Context Protocol server. The server is summarized with a connected badge, a status badge showing that publishing is on hold, and counts of tools, reusable instruction templates and resources. A table lists each operation with the group it belongs to — properties, tours, activities, events, trips, bookings, providers, favorites, analytics — and marks it as read or write. A separate gate column is where the design does its governance work: write operations are flagged as not gated, a toggle-style operation is labelled idempotent, and a banner at the foot of the page states plainly that four write operations have no confirmation step and that write access should be granted deliberately. Side panels cover the two instruction templates, the available resources, and the authentication model, including a device-code sign-in, a locally stored token with restricted permissions, automatic refresh, and enforcement at the public gateway using the operator's own permissions.

The second illustration shows what background agents produce. An agent-activity view runs on a fixed cadence and posts decision cards: a tour whose price rose after it was added to a plan, a host cancellation that opened a gap in a day, and a listing whose utilization for a specific weekend is running well below its recent average. Each card carries a short explanation, a link to the listing, plan or analytics behind it, and accept or dismiss buttons. A runs table records every execution with the agent that ran it, when it started, the trip or brand it examined, how many findings it produced and what it cost in tokens, so the cost and yield of the automation are as visible as its output.

Together these surfaces set the rule the rest of the product follows: agents read widely, propose clearly, and apply nothing by themselves. The footer of the activity view says it outright — agents raise cards, and a person applies the change.