A traveler forwards a cancellation email to their personal assistant and asks, “Can you help me claim this?” The assistant needs to discover what TourClaim does, preserve the booking details, understand its permissions, and know exactly when to bring the traveler back.
We built TourClaim’s assistant pages and connector around that handoff. Muse is one integration under review; the same developer interfaces are available for other personal assistants to evaluate. This work is not an announcement of Meta approval or a listed Muse partnership.
The “Are you an assistant?” entry point
Near the top of the booking intake page, a section headed “Helping a traveler as their assistant?” gives the assistant a clear next step. Its “View assistant instructions” link opens the instructions for personal assistants.
The heading, instructions, and regular link are in the page’s initial HTML and main content. A reader extracting the main text can see the preparation route and its limits together. The section tells assistants to prepare an intake first and leave medical answers, email sign-in, consent, signatures, and payment details to the traveler.
The instructions are readable without executing JavaScript. Preparing and saving an intake does require JavaScript and cookies; the page explains that distinction and gives a regular intake link for the traveler to use when preparation is unavailable.
Keep the booking context through the handoff
An operator’s TourClaim link may already identify the operator and booking. The assistant route carries that context forward. When a traveler switches from the regular form after entering answers, the page attempts to save those answers for the preparation flow and reports a failure if that save does not work.
The assistant can fill in known booking information, leave unknown answers blank, attach selected non-medical evidence, and prepare a review link. Saving a preparation files nothing. On this operator-linked path, only the traveler can finish the intake and submit it after verifying their email and reviewing the details.
The medical questions, medical-note upload, signature, consents, and any payment step remain the traveler’s. This gives the assistant a useful stopping point: a prepared intake the traveler can inspect, rather than a claim supposedly filed on their behalf without that review.
Three paths, with explicit purposes
- An assistant helping with an operator booking: follow the booking link to assistant preparation, preserving its context, then hand the traveler the review link.
- A traveler with a real claim and no operator referral: use the direct online claim form. No Muse account or agent integration is needed.
- A developer testing an assistant integration: start at the developer guide. The REST API, CLI, SDK, and local MCP adapter use fictional claims in synthetic review mode. Production access requires approval.
The browser preparation and connector are different interfaces. The connector can submit an authorized draft with the traveler’s go-ahead, but its current review-mode submissions stay synthetic. It cannot borrow the live behavior of the direct online form.
Open the pages and examples
These public resources let an assistant or its developer inspect the workflow before sharing any traveler data:
- Assistant instructions: the actual page linked from booking intake, including what opening it does and does not do.
- Agent discovery JSON: available interfaces, current operating mode, and how to request integration help.
- OpenAPI schema: the connector’s actions and request and response shapes.
- Worked reviewer walkthrough and fictional flight, hotel, email, and medical examples: concrete test material, not customer records or evidence for a real claim.
- Python SDK examples, agent instructions in the public repository, and local MCP setup: ways to connect the workflow to an agent’s existing tools.
Some shared reference URLs retain /muse in their path. Reading them or using the general developer interfaces does not require a Muse account.
A conversation can resume without inventing progress
The connector returns missing fields, next questions, a review URL, and draft state. An assistant can ask for the missing information and return later to the same record. It should check the current state instead of assuming that the traveler signed or that an upload completed.
A traveler signs the specific draft in their own browser. Changing its answers or evidence invalidates that approval. Retry controls help clients recover from interrupted calls without creating a second claim. Those are useful integration details because a personal assistant may stop, resume, or retry during an ordinary conversation.
Discovery should explain the service before asking for access
Our public service index links to the docs, source, and integration status. These articles expose their full text and links in HTML. A reader can follow the same path from a search result to the instructions, to an example, to an access request.
The reason to connect is the service behind that path: benefits review, medical-provider coordination when needed, claim preparation, and follow-up. Read where medical claims exceed an assistant’s capabilities for the problem this handoff is designed to solve.
Build a travel-claim handoff into your agent
Follow the production-access request process and tell us your product, website, use case, expected volume, and intended launch date. Copernican reviews requests and replies by email. A request or a self-service test key does not activate live access; each traveler must still authorize their own connection.
Start with the public source repository, developer guide, and current interface status. Self-service integration testing uses fictional data in synthetic review mode; nothing is filed, billed, or sent to a clinician.