ChatGPT Plugin

Daysync: Tour Manager

Run your tour from chat

Brand: Unknown

Category: Pending
Primary Subcategory: Pending

Integration details

Description

Daysync is tour management software for artists, tour managers and production crews. Connect your Daysync account to read and update your tours in plain language. Ask for a day's schedule, venue details, hotel and room lists, guest-list counts, bulletins and files, or load a whole tour at once. With write access you can add and update schedule items, venues, stays, guests and bulletins, and export a PDF day sheet. Daysync only ever sees what your own Daysync account can see, bounded by the permissions you approve when you connect. Tour chat is read-only, and 1:1 direct messages are never accessible. Review the requested action and permissions before approving a change. Requires a Daysync account.

Integration type: Plugin
Verification status: Not applicable
Platform: ChatGPT
Category: Pending
Primary Subcategory: Pending
Secondary Subcategories: None listed
Brand: Unknown
Access: Account required
First tracked: 2026-10-22
Tool count: 120
Geography: US

Agent DiscoverabilityChatGPT Plugin Discovery Score

ChatGPT organic discovery is live

Your score is coming

ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.

ChatGPT recommends Airtable when a user asks it to update a CRM. — ChatGPT surfaces Airtable because it matches the user's request.

Primary Subcategory

Competitive lineup

No Primary Subcategory assigned yetOnce Daysync: Tour Manager has a Primary Subcategory, the Plugins and Connectors it competes with will appear here with their scores.

Tools

120 tools agents can invoke

Add a guest-list entry to a tour day. passes[].passId values come from list_pass_types. Returns { id }. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create the template's items on a tour day. The day must belong to the template's own tour. MERGE (default) adds them alongside whatever is there; REPLACE soft-deletes the day's existing items you can see first — reversible with undo_applied_schedule_template. Returns { ids } of the created items. Private-account boundary: it copies the template's items, with their reminders and attachment links, onto a day of that tour in the connected user's own Daysync account — nothing is booked and no booking or other outside service is called on your behalf. Notifications: applying sends none; copied reminders later notify the people who can see each item (in app, plus push/email per their settings). Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Attach a file you have already uploaded to a schedule item, venue, stay or pass type. `key` is the value upload_file returned. This is ADDITIVE — it never touches the entity's existing attachments. It is also idempotent: attaching the same key to the same entity twice returns the first attachment and reports alreadyAttached, so a retry is safe. Only to an entity you can access, on that tour. It checks the uploaded object in Daysync's own storage and refuses it if it is missing (an expired or unfinished upload), empty, larger than 25 MB, or of a type that is not allowed; it downloads nothing from the internet and sends no notification. Bulletins do not support attachments. Supported entityType values: schedule_item, venue, accommodation, pass_type.
Attach a searched flight to a tour day, creating the item or re-connecting an existing one. Pass ONLY the `key` of a search_flights option — no route, time or duration is accepted, so nothing you supply becomes trusted scheduled data. Omit itemId to create; pass it to replace an item's connection and every auto-filled value in one commit. The OWNING DAY NEVER MOVES: a day-before or day-after departure leaves the item where it is, and on a re-attach dayId is ignored in favour of the item's own day. A created item is Unconfirmed and visible to everyone on the tour. A key that no longer resolves, or departs outside the three-day window, is refused and writes NOTHING. The TITLE is rewritten only when the item is not already wearing one a human gave it, so read the returned `name`; `data.replaceManualValues: true` is the only way past that rule. It also fills the Flight Information fields `Airline` and `Flight number` under that same rule. Returns the item id, the code and that title; the legs it wrote are in the text content, and get_flight_legs reads them back. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Calculate a drive's arrival time, duration and distance for a given vehicle and set of avoided road types. Persists nothing and is safe to repeat. THREE outcomes to distinguish: (1) a normal result; (2) noRouteFound=true, a DEFINITE answer that no road route exists for this vehicle — do not retry, change the vehicle or the avoids; (3) a non-empty constraintViolations, meaning the route is usable but the provider could NOT honour something you asked for — never present this as a clean success.
Remove the link AND every value the flight filled in — route, times, timezones, airline, duration, all legs and any layovers — leaving an empty flight ready to search again. The title reverts to the placeholder ONLY if it is still the one the lookup wrote; a typed title is kept, so read the returned `name`. DESTRUCTIVE and not reversible; use disconnect_flight to keep the values. The `Airline` and `Flight number` rows go too, unless a human edited them, and the item is left with no legs at all. Notes, tags, reminders and attachments are NOT touched. Safe to repeat.
Mark every schedule item on a day as confirmed. Returns the ids that were previously unconfirmed or had no status, so the change can be undone.
Create an accommodation stay. CAMELCASE ids (tourId/dayId); check-in/out are epoch-millisecond numbers; formatted_address needs geometry.location + geometry.viewport. Visible to EVERYONE on the tour by default — set isAdminsOnly, or list users in visibilityList, to restrict. Returns { id, name }. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a bulletin on a tour day (dayId only — the tour is resolved from the day). Content field is "body". Returns { bulletin_id }. Notifications: without scheduledFor it is posted at once, it appears on the tour straight away, and this call sends no notification for it — hasNotification takes effect only with scheduledFor. With a future scheduledFor it stays hidden until then, and if hasNotification is true Daysync then notifies everyone on the tour and the organization's admins (in app, plus push/email per their settings), not you. A past scheduledFor is accepted and the bulletin is visible immediately; with hasNotification true, delivery depends on whether the timestamp still falls within the scheduled-notification polling window, so older timestamps do not notify. Use a future scheduledFor when notification delivery is intended. Private-account boundary: the connected user's own Daysync tour; no outside service is called on your behalf. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Add a person to the organization's key-contact book, then link them to a venue or stay with set_venue_key_contacts / set_stay_key_contacts. Returns { id, ... }. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a guest-list pass type on a tour. day_ids are the days it applies to. Visible to EVERYONE on the tour by default — set isAdminOnly (note the singular), or list users in visibilityList, to restrict. Requires tour-admin. Returns { id }. Private-account boundary: a pass type is a guest-list category (such as AAA or Guest) on a tour in the connected user's own Daysync account — no ticket is issued, sold or printed, no ticketing or other outside service is called on your behalf, and no notification is sent. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Add a room to a stay. roomType comes from list_reference_types (hotelRoomTypes); dates and times are epoch milliseconds. generalNotes and confirmationNumber are required by the API — pass "" if empty. Returns { id, name }. Private-account boundary: it writes a room record on a stay in the connected user's own Daysync account — no hotel booking or reservation is made and no booking or other outside service is called on your behalf. Notifications: unless `hasNotification` is false, Daysync sends a room-assignment notification (in app, plus push/email per their settings) to the room's occupants and, on a public stay, the tour's admins and the organization's admins (on a private stay, its owner and the people it is shared with) — but not to you; an unchanged retry within the idempotency window does not send it again. Send hasNotification: false to suppress it. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a schedule item on a tour day. Times are HH:mm time-of-day strings (NOT ISO — the date comes from day_id); travel items (type 2–6) require origin. Visible to EVERYONE on the tour by default — set isAdminsOnly, or list users in visibilityList, to restrict (leaving visibility unset would otherwise make it creator-only). Returns { id, route_stale, route_computed_at } — plus `reminders` with their server-generated ids when the request sent a `reminder` list. Private-account boundary: it writes a schedule entry on a tour in the connected user's own Daysync account. A flight, hotel or transfer item is a record only — nothing is booked, bought or reserved, no booking or other outside service is called on your behalf, and attachment links are stored, not downloaded. Notifications: the create itself sends none; each `reminder` later notifies the people who can see the item (in app, plus push/email per their settings). Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create MANY schedule items in one call — use this instead of looping create_schedule_item when adding a set of items. Same body shape per item. Returns { ids } in request order. All or nothing: up to 1,000 items (within the 512 KB request limit) are written in one transaction, so if any item is refused none is created. Private-account boundary: the connected user's own Daysync tour; nothing is booked and no booking or other outside service is called on your behalf. Notifications: the create sends none; `reminder` entries notify later, as on create_schedule_item. Safe to retry unchanged within ~10 minutes (returns the original ids). Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a tag on a tour. colorId is an AvatarColor id — get one from list_reference_types (group "avatarColors"). Returns the new tag. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a tour with its days (at least one). Needs org_id from list_organizations and day_type_id values from list_day_types. Only org_admin users can create tours. Returns { id } — the new tour's UUID; call list_tours afterwards to get the created day ids. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Save a vehicle on a tour so drives can be routed for its size, weight and speed. Units are METRIC. lengthM and trailerLengthM are stored but do NOT affect routing — the provider constrains on height, width and weight only. A trailer's height and width DO: the route is constrained by max(vehicle, trailer) for each. maxSpeedKph and avgSpeedKph DO affect the result, applied to the provider's durations afterwards rather than sent to it. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Create a venue on a tour day. venueCategoryId is required in practice (1=commercial, 2=private). Visible to EVERYONE on the tour by default — set isAdminsOnly, or list users in visibility_list, to restrict. Returns { id }. Safe to retry: repeating this call with the same details within ~10 minutes returns the ORIGINAL record instead of creating a second one — if you get back an id you have already seen, that is what happened. To create a genuine duplicate, pass a new `idempotency_key`.
Delete an accommodation.
Soft-delete a bulletin.
Delete a guest-list entry.
Soft-delete a pass type. WITHOUT force it is a SAFE CHECK: if any guest still holds this pass, nothing is deleted and the blocking entries come back in data.guestLists. With force:true those allocations are deleted too, and any guest left holding no pass at all is soft-deleted with them. Reversible with restore_pass_type.
Soft-delete a room. Reversible with restore_room.
Delete a schedule item.
Soft-delete a template. Reversible with restore_schedule_template. Schedule items previously created FROM the template are not affected.
Permanently delete a tag. This is a HARD delete — the tag is removed from every schedule item that carries it and cannot be restored. Check get_tag_usage first.
Soft-delete a tour.
Retire a vehicle. Every drive using it switches to Car (default) and is marked for recalculation; the drives themselves are not deleted. Check get_vehicle_usage first to see how many are affected.
Delete a venue.
Get the exact typed input for named operations — the same JSON Schema each one carries in the tool list. On this connection (tools=all) all 120 operations it is authorised for are already advertised as their own tools with these schemas, so you only need this to re-read one. Returns each operation's full description, inputSchema, outputSchema and read/destructive/idempotent flags. Ask for at most 10 at a time.
Disconnect this MCP session from its Daysync account. Use this when `whoami` shows the wrong account: it revokes the current session so your NEXT request prompts you to sign in again — reconnect with the correct account. Does not delete any Daysync data.
Remove the LINK between a flight item and the lookup, KEEPING every value it filled in so a human can edit them. Reversible and safe to repeat. NOT clear_flight: use it when the figures are right but should stop tracking the lookup. The legs survive unchanged — read them with get_flight_legs. The title is not touched at all.
Render one tour day as a PDF day sheet and get a short-lived download URL back. Answers { url, expiresAt, fileName, pageCount, bytes, ignoredIdCount, cached } — the URL expires, so fetch it promptly rather than storing it. Read-only: it creates nothing on the tour and changes no record (the rendered PDF is cached, nothing else is stored), so it is safe to repeat. Start with a preset (FULL, SCHEDULE or MINIMAL) and narrow it with `options` if needed; ids you pass that you cannot see are dropped and reported in ignoredIdCount.
Get one stay in full — including its custom fields, emails/phones/urls and visibility. list_accommodation returns a leaner projection.
Total guests across a day's APPROVED guest-list entries — the number a day's cap is checked against. It is a SUM of party sizes, not a row count, and it is not derivable from a paged get_guest_list.
Get one channel or group chat: name, description, whether it is public/archived, and its member count.
Read one tour day as a print-ready day sheet MODEL: header, running order, venues, stays, consolidated key contacts, guest-list totals, bulletins and the upcoming-days strip, filtered to what you can see. Use it to decide what to include before calling export_day_sheet; the ids it returns are the ids that tool accepts. For the raw records instead, use get_tour_data.
Get a download URL and the authoritative size/content-type for ONE file from list_files. The URL is signed and EXPIRES in about five minutes — fetch or hand it to the user straight away, and never store it or paste it into a document as a permanent link; call this again for a fresh one. Returns 404 both when the file does not exist and when the connected user is not allowed to see it, so it cannot be used to probe for files on other tours.
The persisted legs of a flight item, in order, plus the code it is auto-filled from — stops, terminals, coordinates, each airport's street address and per-leg times, all UTC. flightLookupCode null means the item is manual or was disconnected. A null `originFormattedAddress` is usually FINAL, not pending: an airport we asked about and could not place is cached as a permanent negative and is never re-asked, so do not poll for it and never synthesise one from the name. An airport `name` can EQUAL its `municipality` (ZQN is 'Queenstown' at every provider endpoint): compare them rather than reading it as missing, and never append 'Airport'. A null `airlineIcao` means fall back to IATA, never derive one.
Get the guest list for a specific tour day. Each guest includes its current pass allocation under `passes` ([{ passType, count }]) — read these before update_guest, which hard-replaces the whole pass set. Pass limit/offset to page large days.
Get a schedule item's custom fields (its "extra info" rows).
List the reactions on a message, grouped by emoji with who reacted.
Read a conversation's messages, NEWEST FIRST. Paging is cursor-based on message id, not offset: pass the returned nextCursor back as `cursor` to fetch the next (older) page. Max 100 per call. To jump to a specific message pass aroundMessageId with before/after instead. Thread replies are not in this feed — use get_thread_replies.
Get the schedule items for a specific tour day. The server returns at most 1000 items per call — for larger days pass limit/offset to page.
Read the items a template holds — times, notes, locations, attachments, reminders, travel details and visibility. Use it to see what apply_schedule_template would create.
Get a stay's own emails, phone numbers and urls.
Get a stay's custom fields.
Get the people from the org contact book linked to a stay.
Count how many schedule items currently carry a tag — use before delete_tag to see what would be affected.
Read the replies on a threaded message, oldest first. Cursor is a message id and returns replies NEWER than it (the opposite direction to get_messages).

FAQs