Tool Catalogue

The server knows 106 operations, and by default it advertises 25 of them as tools. The rest are still fully available — you reach them through three discovery tools instead of having all 106 definitions loaded into every conversation. You only ever see or reach operations covered by the scopes you approved at connect time — a read-only connection never shows a tool that writes, and discovery does not change that.

⚠️ marks tools annotated as destructive. Well-behaved clients ask before running these.You do not need to memorise tool names. Ask in plain language and the client picks the tool — the names are here for debugging and for writing your own client.

The discovery model

Advertising every operation cost about 33,000 tokens of tool definitions before the client had read a single word of your question, and near-neighbours (create_schedule_item vs. create_schedule_items) made the choice ambiguous. The default surface is now about 6,500 tokens, and the long tail is fetched on demand.

Tool	What it does
`list_capabilities`	Call it with no arguments for the domains and how many operations each holds; call it with `domain` for that domain’s operation names and one-line summaries. This is how you find an operation that is not in the tool list.
`describe_operations`	Returns the exact typed input for named operations — the same JSON Schema you would have seen had they been advertised. Ask for at most 10, and only the ones you are about to use.
`invoke_operation`	Runs one: `{ operation, input }`. Input is validated against that operation’s real schema, so a wrong shape is rejected with the expected fields rather than half-applied.

So the write flow is: list_capabilities → describe_operations → invoke_operation. invoke_operation cannot call arbitrary URLs or endpoints. operation must name an operation in this catalogue, and one your connection is authorised for; anything else is refused.

Keeping the old tool list

If you built against the pre-reduction surface and your client enumerates tools, append ?tools=all to the MCP URL (or send x-daysync-mcp-tools: all) to get all 106 advertised exactly as before. Nothing was removed either way: every tool name that used to exist is still callable by name, whether or not it appears in tools/list. An integration that hardcodes create_pass_type needs no change.

Where to start

A few tools do most of the work:

Tool	Why it matters
`list_organizations` → `list_tours`	How you find IDs. Nearly every other tool needs a tour UUID.
`get_tour_data`	Loads a whole tour — every day with its date, name, day type, time zone and location, plus its schedule, venues, stays, guest lists and bulletins — in one call. Much better than paging resource by resource, and you no longer need `list_tours` afterwards to work out which day is which.
`list_reference_types`	Returns 24 ID lookups in one call. Needed before most writes.
`list_capabilities`	Finds anything not in the tool list. Cheap; safe to call whenever you are unsure a capability exists.
`whoami`	Confirms which Daysync account you are connected as.

Session tools

Always available on any connection.

Tool	What it does
`whoami`	Shows the account this connection is bound to.
`disconnect`	Revokes this connection; the next request prompts a fresh sign-in.

Files

Four tools cover the whole file lifecycle. They are advertised by default, because they are the only route to file content.

Tool	Scope	What it does
`list_files`	`tours.read`	List the files attached to a tour — across its schedule items, venues, stays and pass types — with ID, name, size, which entity holds it and when it was added. Filter by `entityTypes`, `dayId` or a file-name `search`; page with `limit`/`offset` (max 200).
`get_file`	`tours.read`	Metadata plus a short-lived signed download URL for one file. The URL expires in about five minutes — fetch it or hand it over straight away, and call again for a fresh one rather than storing it.
`upload_file`	`schedule.write`	Stores a file and returns the key to attach. Three sources, see below.
`attach_file`	`schedule.write`	Attaches an already-uploaded file to a schedule item, venue, stay or pass type. Additive — it never touches the entity’s existing attachments — and idempotent, so a retry is safe.

Choosing an upload source

upload_file takes a source:

`source`	Use it when	Notes
`content`	You have the bytes	Base64, max 256 KB. The only source an assistant can drive on its own.
`url`	The file is at a public HTTPS URL	The server fetches it (max 25 MB). Direct links only — redirects are refused. This is the original attachment upload, unchanged.
`ticket`	The file is large and local to your app	Returns a signed `PUT` URL. Send the returned headers exactly as given: `content-length` and `content-type` are part of the signature, so storage rejects anything else. An assistant cannot do this itself.

Uploading does not attach anything — call attach_file next.

Bulletins do not support attachments. Chat files are not in list_files either; use search_chat_files.Prefer attach_file over re-sending an entity’s update body with attachments, which replaces the whole set.

Limits and rejections

Rule	Result
Content type not on the allow-list (images, PDF, Office documents, text/CSV, ZIP, audio, video)	`415` naming the allowed types. SVG, HTML and executables are not allowed.
Inline upload over 256 KB	`413` naming the two larger-file alternatives.
File over 25 MB	`413`.
A key that this API did not mint	`400`. Arbitrary or traversing storage paths are not accepted.
A key that was never uploaded, or whose ticket expired	`404`.
An entity that is not on the named tour, or that you cannot see	`404` / `403`.

File reads are bounded by the same organization, tour, role and per-item visibility rules as everything else: a file on a private item you are not on is not listed, and files on another tour are not reachable.

By scope

Organization · Read

organization.read — 3 tools

Tool	What it does
`list_org_key_contacts`	List the organization’s key-contact book — the people who can be linked to venues and stays.
`list_organization_members`	List the members of an organization.
`list_organizations`	List the organizations the authenticated Daysync user belongs to.

Users · Read

users.read — 3 tools

Tool	What it does
`disconnect`	Disconnect this MCP session from its Daysync account.
`list_tour_members`	List the members of a tour.
`whoami`	Show which Daysync account this MCP session is connected as.

Tours · Read

tours.read — 8 tools

Tool	What it does
`export_day_sheet`	Render one tour day as a PDF day sheet and return a short-lived download URL. Non-destructive — it creates nothing and changes no record.
`get_day_sheet_data`	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. Use it to decide what to include before `export_day_sheet`.
`get_file`	Metadata and a short-lived signed download URL for one file.
`get_tour_data`	Load a whole tour in ONE call: every day with its schedule items, venues, stays, guest lists, bulletins and pass types.
`list_day_types`	List the available day types.
`list_files`	List the files attached to a tour.
`list_reference_types`	Look up the ID values the create/update tools require.
`list_tours`	List tours in an organization as memberships.

get_tour_data, get_day_sheet_data, export_day_sheet, list_files and get_file each span several resources, so they need the read scope for all of them — see Scopes. They appear with tours.read but fail without the rest.

The day sheet is a read, despite export_day_sheet being a POST. It rides tours.read, creates nothing on the tour, and changes no record — the POST is only because the render takes a body. Start from a preset (FULL, SCHEDULE, MINIMAL) and narrow it with options; ids you pass that you cannot see are dropped and counted in ignoredIdCount. See Day sheet.

Tours · Write

tours.write — 3 tools

Tool	What it does
`create_tour`	Create a tour with its days (at least one).
`delete_tour` ⚠️	Soft-delete a tour.
`update_tour` ⚠️	Update a tour. Days you do not mention are preserved; deletions must be explicit.

Schedule · Read

schedule.read — 6 tools

Tool	What it does
`get_item_custom_fields`	Get a schedule item’s custom fields.
`get_schedule`	Get the schedule items for a specific tour day.
`get_schedule_template_items`	Read the items a schedule template holds.
`get_tag_usage`	Count how many schedule items carry a tag — use before `delete_tag`.
`list_schedule_templates`	List your saved schedule templates for a tour.
`list_tags`	List the tags defined on a tour, with their colours.

Schedule · Write

schedule.write — 20 tools

Tool	What it does
`apply_schedule_template` ⚠️	Create a template’s items on a tour day. `REPLACE` mode soft-deletes the day’s existing visible items first.
`attach_file`	Attach an uploaded file to a schedule item, venue, stay or pass type. Additive and idempotent.
`confirm_all_schedule_items`	Mark every schedule item on a day as confirmed.
`create_schedule_item`	Create a schedule item on a tour day.
`create_schedule_items`	Create many schedule items in one call.
`create_tag`	Create a tag on a tour.
`delete_schedule_item` ⚠️	Delete a schedule item.
`delete_schedule_template` ⚠️	Soft-delete a schedule template. Items created from it are unaffected.
`delete_tag` ⚠️	Permanently delete a tag — a hard delete, removed from every item.
`rename_schedule_template`	Rename a template. The only edit possible — its items are fixed at save time.
`restore_schedule_item`	Restore a soft-deleted schedule item.
`restore_schedule_template`	Restore a soft-deleted schedule template, with its items.
`save_schedule_template`	Save a set of existing schedule items as a reusable template.
`set_item_custom_fields`	Add, update or remove a schedule item’s custom fields.
`set_item_tags`	Set the tags on a schedule item (replaces the whole set).
`undo_applied_schedule_template` ⚠️	Soft-delete the items a template created on a day.
`update_schedule_item`	Update a schedule item.
`update_tag`	Rename a tag or change its colour.
`upload_attachment`	Upload a file by URL. Superseded by `upload_file` (`source: "url"` does the same thing); kept for compatibility.
`upload_file`	Store a file — from bytes, a public URL, or a signed upload ticket — and return the key to attach.

Schedule templates are per user. list_schedule_templates shows only the connected account’s own templates, and a template can only be applied to a day of the tour its items came from. See Schedule Templates.

Venues · Read

venues.read — 7 tools

Tool	What it does
`get_venue`	Get one venue in full — custom fields, contacts, age restriction, visibility.
`get_venue_contacts`	Get a venue’s own emails, phone numbers and URLs.
`get_venue_custom_fields`	Get a venue’s custom fields.
`get_venue_key_contacts`	Get the contact-book people linked to a venue.
`list_age_restrictions`	List venue age restrictions.
`list_venue_field_templates`	List the premade venue custom-field templates.
`list_venues`	List the venues for a tour.

Venues · Write

venues.write — 6 tools

Tool	What it does
`create_venue`	Create a venue on a tour day.
`delete_venue` ⚠️	Delete a venue.
`set_venue_contacts`	Add, update or remove a venue’s emails, phone numbers and URLs.
`set_venue_custom_fields`	Add, update or remove a venue’s custom fields.
`set_venue_key_contacts`	Link or unlink contact-book people on a venue.
`update_venue`	Update a venue.

Accommodation · Read

accommodation.read — 7 tools

Tool	What it does
`get_accommodation`	Get one stay in full — custom fields, contacts, visibility.
`get_stay_contacts`	Get a stay’s own emails, phone numbers and URLs.
`get_stay_custom_fields`	Get a stay’s custom fields.
`get_stay_key_contacts`	Get the contact-book people linked to a stay.
`list_accommodation`	List the accommodation for a tour.
`list_rooms`	List a stay’s rooms with their occupants and pending invites.
`list_stay_field_templates`	List the premade stay custom-field templates.

Accommodation · Write

accommodation.write — 12 tools

Tool	What it does
`create_accommodation`	Create an accommodation stay.
`create_key_contact`	Add a person to the organization’s key-contact book.
`create_room`	Add a room to a stay.
`delete_accommodation` ⚠️	Delete an accommodation.
`delete_room` ⚠️	Soft-delete a room.
`restore_room`	Restore a soft-deleted room.
`set_stay_contacts`	Add, update or remove a stay’s emails, phone numbers and URLs.
`set_stay_custom_fields`	Add, update or remove a stay’s custom fields.
`set_stay_key_contacts`	Link or unlink contact-book people on a stay.
`update_accommodation`	Update an accommodation stay.
`update_key_contact`	Update a person in the key-contact book.
`update_room`	Update a room.

Guest list · Read

guestlist.read — 4 tools

Tool	What it does
`get_approved_guest_count`	The approved-guest total for a day — a sum of party sizes, not a row count.
`get_guest_list`	Get the guest list for a specific tour day.
`list_guestlist_requesters`	List the users who can be a guest-list entry’s requester.
`list_pass_types`	List a tour’s pass types (needed to add guests).

Guest list · Write

guestlist.write — 10 tools

Tool	What it does
`add_guest`	Add a guest-list entry to a tour day.
`create_pass_type`	Create a guest-list pass type on a tour. Requires tour-admin.
`delete_guest` ⚠️	Delete a guest-list entry. Reversible with `restore_guest`.
`delete_pass_type` ⚠️	Soft-delete a pass type. Without `force` it is a safe check that deletes nothing and returns the blocking guests.
`restore_guest`	Restore a soft-deleted guest-list entry, with its pass allocations.
`restore_pass_type`	Restore a soft-deleted pass type, with the allocations removed alongside it.
`set_guestlist_config`	Set a day’s guest cap, lock, cut-off and per-pass-type caps. Requires tour-admin.
`update_guest`	Update a guest-list entry — send the full record, not a delta.
`update_guest_statuses`	Approve, deny or waitlist entries in bulk. All-or-nothing across the batch.
`update_pass_type`	Update a pass type — a full record; `day_ids` replaces the day set. Requires tour-admin.

Prefer update_guest_statuses over looping update_guest, which requires the guest’s whole record on every call. And read delete_pass_type’s response rather than only its success: without force it deliberately deletes nothing when a guest still holds the pass.

Bulletins · Read

bulletins.read — 1 tool

Tool	What it does
`list_bulletins`	List the bulletins for a tour.

Bulletins · Write

bulletins.write — 3 tools

Tool	What it does
`create_bulletin`	Create a bulletin on a tour day.
`delete_bulletin` ⚠️	Soft-delete a bulletin.
`update_bulletin`	Update a bulletin.

Chat · Read

chat.read — 10 tools. Read-only, and 1:1 direct messages are never exposed. See Chat.

Tool	What it does
`get_conversation`	Get one channel or group chat.
`get_message_reactions`	List the reactions on a message.
`get_messages`	Read a conversation’s messages, newest first.
`get_thread_replies`	Read the replies on a threaded message.
`is_chat_enabled`	Check whether chat is switched on for a tour.
`list_conversation_members`	List who is in a channel or group chat.
`list_conversations`	List the tour’s channels and group chats.
`list_pinned_messages`	List a conversation’s pinned messages.
`search_chat`	Search a tour’s chat history for a phrase.
`search_chat_files`	Find files and images shared in a conversation.

Retrying a write safely

Every additive write tool — create_tour, create_schedule_item, create_schedule_items, create_venue, create_accommodation, create_room, create_key_contact, create_tag, create_pass_type, create_bulletin, add_guest, save_schedule_template, apply_schedule_template and upload_attachment — accepts an optional idempotency_key.


Reuse the same value	when retrying a call you are not sure completed. The original result comes back instead of a second record.
Use a new value	when you genuinely want another copy.
Omit it	and one is derived from the payload, so an identical retry within about ten minutes is treated as the same action.

That last row is why a duplicated tool call — the failure mode a retrying agent is most prone to — does not silently create two schedule items.

Why a tool might be missing

It is not on the default surface. Most operations are not advertised as tools. Call list_capabilities to find it, then describe_operations and invoke_operation — or append ?tools=all to the MCP URL to advertise everything.
You did not consent to its scope. Reconnect and approve it. invoke_operation distinguishes this case explicitly: it answers INSUFFICIENT_SCOPE and names the scope needed, rather than telling you the operation does not exist.
The application does not hold that scope. Nothing you can do client-side — the partner credential needs it.
Your session predates the tool. Tool lists are cached from session start; start a new chat.

See Troubleshooting.

When something new becomes a tool

So the surface does not creep back up, new capabilities follow a fixed rule:

If an existing tool covers it with one more field, that tool is extended.
Otherwise it becomes an operation — reachable via list_capabilities / describe_operations / invoke_operation from day one, with no client change and no re-consent.
It is promoted to an advertised tool only if an agent needs it to orient itself (a read), or it is the only route to a capability (files); its name is unambiguous against every other advertised tool; and its schema is small — a multi-kilobyte write body belongs behind describe_operations, which delivers it just in time.
Reference and lookup data stays bundled into one read rather than one tool per table.

Every tool maps to a documented REST endpoint — see Scopes & Permissions for the mapping.

Get started

Endpoints

Guides

Reference

The discovery model

Keeping the old tool list

Where to start

Session tools

Files

Choosing an upload source

Limits and rejections

By scope

Organization · Read

Users · Read

Tours · Read

Tours · Write

Schedule · Read

Schedule · Write

Venues · Read

Venues · Write

Accommodation · Read

Accommodation · Write

Guest list · Read

Guest list · Write

Bulletins · Read

Bulletins · Write

Chat · Read

Retrying a write safely

Why a tool might be missing

When something new becomes a tool

​The discovery model

​Keeping the old tool list

​Where to start

​Session tools

​Files

​Choosing an upload source

​Limits and rejections

​By scope

​Organization · Read

​Users · Read

​Tours · Read

​Tours · Write

​Schedule · Read

​Schedule · Write

​Venues · Read

​Venues · Write

​Accommodation · Read

​Accommodation · Write

​Guest list · Read

​Guest list · Write

​Bulletins · Read

​Bulletins · Write

​Chat · Read

​Retrying a write safely

​Why a tool might be missing

​When something new becomes a tool

The discovery model

Keeping the old tool list

Where to start

Session tools

Files

Choosing an upload source

Limits and rejections

By scope

Organization · Read

Users · Read

Tours · Read

Tours · Write

Schedule · Read

Schedule · Write

Venues · Read

Venues · Write

Accommodation · Read

Accommodation · Write

Guest list · Read

Guest list · Write

Bulletins · Read

Bulletins · Write

Chat · Read

Retrying a write safely

Why a tool might be missing

When something new becomes a tool