Joy

Guide the host through designing their wedding or event website — theme, colors, fonts, layout, and the welcome-page header photo — and, for a broad or whole-look redesign, coherence-check the proposal before it’s applied. Call this FIRST when they want to design, restyle, or choose the look of their site (especially if they’re unsure where to start): it reads their current design and gives expert, Joy-specific guidance. For a WHOLE-LOOK redesign, pass `proposal` (the changes accumulated in the conversation, same fields as apply_website_design) to get a coherence check — contrast, harmony, completeness, buildability — then commit it with apply_website_design; a DIRECTED or SINGLE-AXIS change skips the proposal and applies directly with apply_website_design. Pass `reference` (e.g. "affordances") to pull exact option details only when you need them. Reads only; changes nothing.

design_guide

List the weddings — and any other special occasions (birthdays, anniversaries, etc.) — the signed-in Joy account can manage (as owner or admin), each with its type, date, venue, and website link. Call this when you don't yet know — or don't want to ask the user to type — which one they mean: the website link it returns is what the other tools take to identify it. Also confirms who is signed in (its first line), so it doubles as the way to check a sign-in worked. Pass `query` to filter by host or event name. 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. 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

View and organise the event website's photo library — the shared pool of uploaded photos and the albums built from them. Use it to see what photos and albums exist, upload a new photo from a PUBLIC image URL into the pool, permanently remove a photo from the pool, and manage albums: create one, add or remove photos, make it visible to guests or hide it, set how it displays (grid or slideshow), and rename it. Photos upload once into the pool and can be reused across albums and pages. Refer to a pool photo by its number and an album by its number or name (from a list). 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. This does NOT upload from a device — ask for a public link, not a file. The "list" action returns the library as TEXT (photo numbers + album names) — use it to find a number or answer a question. To SHOW the couple their photos as a visual gallery, use the separate view_media_library tool instead.

manage_media

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, same fields as apply_website_settings) to get a coherence check — buildability, the password/guard and RSVP-page preconditions, and the publish flow — then commit it with apply_website_settings. Pass `reference` (e.g. "affordances") to pull exact option details only when you need them. Reads only; changes nothing.

settings_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 apply_website_content 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 guest from the guest list. Deleting a guest 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 who would be removed. Only after the host has approved, call again with confirm: true to actually remove them. Identify the guest by name or email, with an optional distinguisher (city, household, label) when several match — the server resolves and removes just that guest. ONE EXCEPTION: if the resolved guest is the head of a household with other members, removing them removes the WHOLE household (Joy won't remove a head while its household has members) — the preview lists every member that would go, so the host can approve the full set.

remove_guest

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

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, organise albums, set privacy) — or to look up a photo number as text — use manage_media 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

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, same fields as apply_website_content) to get a coherence check — buildability, page references, and the apply flow — then commit it with apply_website_content. Pass `reference` (e.g. "affordances") to pull exact option details only when you need them. Reads only; changes nothing.

content_guide