Joy

Edit the website’s written content in one call: a PAGE’s paragraphs (via `text` ops — add a paragraph, replace an existing block by number, or remove one), and/or the site-level WELCOME GREETING and RSVP BUTTON label. Read read_website_content first for page names and block numbers. Replacing or removing a paragraph (by block number) previews first (call without confirm, then with confirm: true); adding a paragraph and setting the greeting or RSVP button label apply immediately (they’re short, reversible). Identify the event by its event-website link.

edit_page_text

Lists every wedding — and any other special occasion (birthday, anniversary, etc.) — the signed-in Joy account can manage (as owner or admin), each with its hosts, title, date, location, and website link. When the user refers to one of their events, do NOT immediately pick the closest match and act on it — an exact-looking name match is NOT permission to proceed. First scan the WHOLE list for EVERY plausible candidate — by host/couple names, title, or website handle — and treat close name variants or spellings ("George" vs "Giorgio", "Katie" vs "Kate") and partial-name overlaps as plausible, even when one event matches the words exactly. Confidently acting on the WRONG event is much worse than surfacing ambiguity and letting the user choose: a wrong-event action is costly and hard to undo, while asking "which one?" is cheap. If more than one event is a plausible candidate, list them and let the user choose before you act — do not decide for them. Only when exactly ONE event is plausible may you proceed on your own, and even then name it back to the user (e.g. "George & Giorgia") so they can catch a wrong pick. Once the event is settled, use its website link to identify it for the other tools. The first line also confirms who is signed in, so it doubles as the way to check a sign-in worked. Takes no destructive action and changes nothing. When you talk to the user about which one, call it their wedding (or event) website or its link — never a parameter or field name.

find_event

Fetch the guest list, identified by its website link — guest names, households, email, labels, phone, and mailing address. Guests belong to households: when you present the list, GROUP guests by household (using each guest’s household) rather than as one flat run. An unnamed placeholder guest is shown as "{head}’s guest" (e.g. "Marcel Bichon’s guest") — a household can hold several — and you can give one a name with apply_guest_list. Unlike the public schedule, this is private data: the server reads it with the owner's Joy sign-in and can only return the guest list of one they own.

get_guest_list

Fetch the couple’s schedule — the ceremony, reception, and surrounding events with their times, locations, dress code, and WHO CAN SEE each one. Identify it by its website link (or the handle at the end of it). This is the admin view: read with the owner’s Joy sign-in, so it returns a site they own or co-host, and it shows every item — including ones hidden from some or all guests — with each item’s audience. To change an item (including who can see it) use update_schedule_item.

get_event_schedule

Look up the website DESIGN by its link — the current theme, font, layout, and colors (plus the page list). This is the couple's current design (what they see and what design edits change), read with the owner’s Joy sign-in, so it only returns one they own. For page CONTENT (text, Q&A, photos, who can see a page) use read_website_content; for site SETTINGS — publishing, the web address or domain, the guest password — use read_website_settings. Call this first to see the current design before editing it. Returns a TEXT summary — it does NOT display the website; to SHOW the host a rendered picture of the site, use preview_website. A bare "show me" request is ambiguous across these three tools — if unclear whether the host wants the rendered look (preview_website), the page/site content (read_website_content), or the current design settings (read_website_design), ask which before calling; if clear, just proceed.

read_website_design

Look up the website’s SETTINGS by its link — whether it’s published or hidden from guests, the web address (handle) and any custom domain, whether a guest password is set and what it protects (the value itself lives in the host’s Joy settings, not here), the guest website language, and each page’s visibility (public / password-protected / guest-list only / hidden). Use this for anything about publishing, privacy, passwords, the web address or domain, the guest language, or showing/hiding pages. For the LOOK — theme, fonts, colors, layout — use read_website_design instead. Owner-only, so it only returns a site they own. Returns a TEXT summary — it does NOT display the website.

read_website_settings

Add, edit, remove, or reorder Q&A items (FAQ / story tidbits) on a page — pass `ops`, one or more changes applied together IN ORDER. Edits/removes/reorders use the item NUMBER from read_website_content (read it first); numbers refer to that listing and stay stable across the ops in this one call (the ops are applied edits→removes→reorders→adds against the read). A batch that removes or edits previews first (call without confirm, then with confirm: true); one that only adds/reorders applies immediately. Identify the event by its event-website link.

manage_faq

Place or remove images on a page in one call — pass `ops` (applied in order): add a single library PHOTO (by number from the picker — view_media_library with purpose:"select"), add a whole ALBUM as a gallery (by album number or name), or REMOVE an image from the page by its number (from read_website_content). Adds are additive — what’s already on the page stays. A batch that removes previews first (call without confirm, then with confirm: true); one that only adds applies immediately. Removing takes the image off the PAGE only — it stays in the library. Identify the event by its event-website link.

manage_page_photos

Guide the host through their wedding or event website SETTINGS — publishing the site or going live, hiding it while building, the withjoy.com web address or a custom domain, what the guest password protects (requiring it to see the date or venue), and whether RSVP shows on the site — and coherence-check the result before it’s applied. Call this FIRST when they want to publish/go live or change these interdependent settings: it reads their current settings and gives expert, Joy-specific guidance, including a go-live readiness check before publishing. Pass `proposal` (the changes accumulated in the conversation, the same settings fields) to get a coherence check — buildability, the password/guard and RSVP-page preconditions, and the publish flow — then apply each change with its matching settings tool (publish_website, set_website_address, update_website_settings). Pass `reference` (e.g. "affordances") to pull exact option details only when you need them. Reads only; changes nothing.

settings_guide

Add, edit, or remove things-to-do items on a page — pass `ops`, one or more changes applied together IN ORDER. Edits/removes use the item NUMBER from read_website_content (read it first); numbers refer to that listing and stay stable across the ops in this one call. A batch that removes previews first (call without confirm, then with confirm: true); one that only adds/edits applies immediately. Identify the event by its event-website link.

manage_things_to_do

Add, edit, remove, or reorder travel tips — pass `ops`, one or more changes applied together IN ORDER. Edits/removes/reorders use the item NUMBER from read_website_content (read it first); numbers refer to that listing and stay stable across the ops in this one call (removing a tip and reordering others in the same call compose correctly). reorder positions EXISTING tips; to place a tip you’re ADDING, add it here then reorder it in a follow-up call (a just-added tip has no number yet). A batch that removes previews first (call without confirm, then with confirm: true); one that only adds/edits/reorders applies immediately. Identify the event by its event-website link.

manage_travel

Add, edit, or remove wedding-party members — pass `ops`, one or more changes applied together IN ORDER. Edits/removes use the member NUMBER from read_website_content (read it first); numbers refer to that listing and stay stable across the ops in this one call. A batch that removes previews first (call without confirm, then with confirm: true); one that only adds/edits applies immediately. Identify the event by its event-website link.

manage_wedding_party

Manage the where-to-stay page: set its hotels/neighborhoods NOTES and/or add, edit, or remove recommended PLACES. Pass `notes` and/or `places` (each a list of changes). Edits/removes use the place NUMBER from read_website_content (read it first). Removing a place previews first (call without confirm, then with confirm: true); notes, adds, and edits apply immediately. Identify the event by its event-website link.

manage_accommodations

Guide the host through building or organising their wedding or event website PHOTO LIBRARY — uploading photos and arranging them into albums (create an album, add or remove photos, show or hide it, grid vs slideshow, rename). Call this when they want to prepare or tidy their photo library or albums — especially a standalone "get my photos ready" session — or when you need the library workflow (how the shared photo pool and albums work, uploading from a URL vs the device picker, and how deletion's confirm step works). It gives expert, Joy-specific guidance and points to the specific library tools. For PLACING a photo on a page, the welcome header, or a page gallery, use the design/content guides instead; to just SHOW the library, use view_media_library. Reads only; changes nothing itself.

media_guide

Guide the host through planning their whole wedding or event — orientation, not a single task. Call this when they want help across the board ("help me plan", "where do I start?", "what’s left to do?") or are new and unsure: it reads where their event stands across every surface (date, venue, guests, website design, content, publish/RSVP, schedule) and tells them the most useful next step, handing off to the specialist guide for it (design, content, settings, venue research) or the guest-list / RSVP / schedule tools. Reads only; changes nothing itself — the specialists do the work. Go straight to a specialist when the host already knows what they want.

planning_guide

Render the couple’s current website and show it to them so they can SEE their design edits. After a WHOLE-LOOK design change — or whenever the host asks to see it — call this to show the result (a directed or single-axis edit does not need a preview unless they ask); at most ONCE per response (never twice in the same turn). Optionally target a section with 'page'. Shows the current design whether or not the site is public yet — so this is how to show an UNPUBLISHED site: the public withjoy.com/<handle> URL returns 404 until the site is published, so never share that link for an unpublished site — show it here instead. Read-only. A bare "show me" request is ambiguous across these three tools — if unclear whether the host wants the rendered look (preview_website), the page/site content (read_website_content), or the current design settings (read_website_design), ask which before calling; if clear, just proceed.

preview_website

Read the event website's content. Omit `page` for the SITE MAP — every page with its kind (standard/custom) and who can currently see it (hidden pages included) — the place to start, and what you need before changing page visibility. Give a `page` to read ALL of it: text blocks (numbered), Q&A, images (numbered), the greeting/RSVP-button/layout/display-formats, its visibility, AND the collection it owns — wedding-party members, travel tips, where-to-stay places, or things-to-do (all numbered). Read-only; call before editing with the content write tools so you have the current numbers. A bare "show me" request is ambiguous across these three tools — if unclear whether the host wants the rendered look (preview_website), the page/site content (read_website_content), or the current design settings (read_website_design), ask which before calling; if clear, just proceed.

read_website_content

Record a guest's RSVP — attending or not attending. This writes the RSVP the host sees on their dashboard, as if the guest replied, so use it when a guest tells the host directly. Identify the guest by name or email; if more than one guest shares that name, use their email instead. Note: the RSVP is yes/no — there is no "maybe", and a reply cannot be cleared once set.

set_guest_rsvp

Record one guest's answer to a specific RSVP question — a meal choice, a hotel/transport question, a free-text note, etc. Get the exact question wording and its choices from get_rsvp_summary. Identify the guest by name or email; if more than one guest shares that name, use their email instead. Writes the answer the host sees on their RSVP dashboard, as if the guest replied. For attendance (attending / not attending) use set_guest_rsvp instead. An answer overwrites any previous one and cannot be cleared.

answer_rsvp_question

Remove a question from the RSVP form, by name. Removing a question is destructive — it also drops the answers guests already gave it. This is a TWO-STEP tool: by default (confirm omitted) it does NOT remove anything — it returns a preview of the exact question that would go. Only after the host has approved that specific question, call again with confirm: true. Joy's built-in questions can't be deleted — this turns them off instead. The attendance question can't be removed.

remove_rsvp_question

Remove an event from the schedule, identified by name. Deleting a schedule item is destructive and not reversible in one step. This is a TWO-STEP tool: by default (confirm omitted) it does NOT delete — it returns a preview of exactly which item would be removed. Only after the host has approved that specific item, call again with confirm: true to actually delete it.

remove_schedule_item

Permanently delete one or more photos from the event website's photo library (the pool), by their NUMBERS. This can't be undone — you'd have to re-upload. TWO-STEP for safety: call first WITHOUT confirm to PREVIEW exactly what would be deleted; then, only after the host approves, call again with confirm:true AND the removeToken from the preview (it pins the deletion to those exact photos, so nothing shifts if the library changed in between). A deleted photo also leaves any album it was in; but a copy placed directly on a page may still show there — remove that separately. Identify the event by its event-website link.

remove_website_photos

Joy has distilled its experience helping couples choose a wedding venue into a structured, guided research flow. Use it when someone planning a wedding or other event has settled on a city or destination and is ready to evaluate and compare actual, named venues — a structured path through what matters for the decision, rather than a long ad-hoc back-and-forth that leans on the user's own know-how and prompting. Give it 1–5 venue names plus the city/region; it returns a sourced, event-oriented read of each — whether it is real and currently operating, walkable nearby places with distances, rating and reviews, and on-site photos. A deeper tier unlocks with a Joy account (see the `deepResearch` field): a capacity-fit check for the guest count, a weather-readiness read of the venue’s outdoor spaces and backup for the date, a track record of real events held there, a curated on-site photo gallery, synthesized review themes, and grounded pricing. Reads only; no sign-in for the base tier. Once a venue is chosen, set it on the event with create_or_modify_event, not this tool; never surface internal ids or field names.

research_venues

Joy’s guided flow for choosing a wedding or event venue, built from its experience helping couples make this decision. Use it when the user has settled on a city or destination and is ready to evaluate and compare actual, named venues: it guides gathering what is needed, runs research_venues, works through what matters for the decision, notes when the deeper tier unlocks with a Joy account, and moves toward setting the chosen venue on the event with create_or_modify_event. Pass `reference` (e.g. "research-tiers") for the exact inputs and tiers. Reads only; changes nothing; no sign-in needed.

venue_guide

FIND candidate themes or fonts for a described vibe — a model-facing search over Joy's large theme/font catalogs (hundreds each), returning candidate NAMES as text. Nothing is shown to the couple. This is step 1 of showing a theme/font gallery: search here for the couple's vibe, pick the 3–6 that fit, then call browse_website_design with `shortlist` set to those names to show them. Matches on style tags and categories, not just names. Read-only.

search_design_catalog

Show the RSVP questionnaire — every question (including ones turned off), its type, its options, and whether it is required or asked of plus-ones. Use this to see the form before adding or changing questions (so you turn on a built-in question rather than adding a duplicate). Reads only.

read_rsvp_form

Summarize the RSVPs. By default returns AGGREGATE only — how many guests are attending, declined, or haven't replied, who still needs a nudge, and the answer breakdown for each RSVP question (meal choices, hotel, etc.). Individual guests’ answers (with their email, the follow-up identity key) are returned ONLY when you scope the request: pass `question` (optionally with `answer`) for who answered a given question a given way — e.g. who chose the fish, or who hasn't replied to it — pass `guest` for one guest's answers, or `offset`/`limit` to page through guest-level answers. Private data, read with the owner's Joy sign-in; identify it by its website link. Reads only, changes nothing.

get_rsvp_summary

Send the user's feedback to the Joy team — a bug report, a feature request, or a question. Use this only when the user explicitly asks to send feedback, report a problem, or contact the team; do not file feedback on your own initiative (for example, when a request is unsupported) unless the user asks you to. Two-step: call it first without `confirm` to draft what would be sent and show the user that draft; only after they approve it, call again with `confirm: true` to send. Include only what the user has said or approved. This does not change the user's wedding or website.

submit_feedback

Set the main photo on a page of the event's website — the welcome/home page by default, or another page such as story, schedule, or travel. Uses a photo already in the event's library: give its NUMBER (`photo`). Every page ships a sample photo, so the couple is choosing whether to KEEP it or replace it — don't ask them to recall a number. Instead open the picker in the same turn: view_media_library with purpose:"select", showCurrentPagePhoto:"<page>", and maxPhotos:1 — it shows the current page photo (keep in one tap) alongside the library, and posts the picked number back to you to set here. To use a brand-new image, first add it with manage_media (action: "upload", the image's public URL) — it becomes photo #1 — then set it here. Changes appear on the site; if it is still a private draft, publish from Joy to make them public. Identify the event by its event-website link.

set_website_page_photo

SHOW the couple a VISUAL GALLERY of the design options you're proposing — themes, fonts, layouts, welcome-page header styles, or color palettes. This is a presentation tool: it renders exactly the set you pass, so the panel matches your advice in chat. For a design request, START with design_guide (it drives this). THEMES and FONTS: pass `shortlist` with the exact names to show (find them first via search_design_catalog — a bare theme/font browse shows nothing). LAYOUTS (3) and HEADER styles are small fixed sets: browse shows them all directly, or pass `shortlist` to narrow. COLOR: pass `palettes` — the 2–4 palettes YOU compose (each the 5 color roles); rendered as mini page previews with a "keep current" card. Read-only.

browse_website_design

Show the couple a VISUAL gallery of the event website's photo library — the pool of uploaded photos as thumbnails, plus their albums (with cover, count, visibility, and display). Use this when they want to SEE their photos or albums. Set `purpose:"select"` to turn it into a PICKER so the couple taps the photos they want (e.g. for a welcome-page header) and posts the numbers back to you — so you never ask them to recall photo numbers. To MAKE changes — upload a photo (upload_website_photo), organise albums (create_photo_album, manage_photo_album), or delete photos (remove_website_photos) — use those tools instead. Read-only. Identify the event by its event-website link.

view_media_library

Change an existing event on the schedule, identified by name. Provide only the fields to change — name, start/end time, location, description, dress code, or WHO CAN SEE it (everyone / nobody / specific guest groups or people); anything you omit stays as it is. Times are the local time.

update_schedule_item

Adjust the website’s standalone settings — pass only the ones you’re changing. Fields: customDomain (a domain the couple owns, like leoandmichelle.com, pointed at their Joy site — they configure DNS separately; EMPTY STRING clears it and falls back to withjoy.com/<handle>); guestLanguage (the locale the whole site renders in for guests — dates, built-in labels, Joy’s sample content — e.g. "it-IT", separate from the chat language, does NOT translate written content); rsvpOnSite (whether RSVP shows on the site and app; needs an existing RSVP page); and passwordProtection (what the guest PASSWORD gates — the event date and/or venue location; turning a guard on needs a guest password to already exist, set in Joy’s own settings). Each applies immediately and overwrites its current value. To change the withjoy.com handle use set_website_address; to publish or hide the site use publish_website. Identify the event by its event-website link.

update_website_settings

Guide the host through writing, reviewing, or improving their wedding or event website CONTENT — page text, our-story and Q&A, travel, accommodations, wedding party, things to do, page photos, adding or renaming pages, who can see a page, and the RSVP form questions — and coherence-check the result before it’s applied. Call this FIRST when they want to compose content across pages or assess existing content for consistency, completeness, correctness, and style: it reads their current content and gives expert, Joy-specific guidance. Pass `proposal` (the changes accumulated in the conversation, the content fields) to get a coherence check — buildability, page references, and the apply flow — then apply each change with its matching content tool. Pass `reference` (e.g. "affordances") to pull exact option details only when you need them. Reads only; changes nothing.

content_guide