> ## Documentation Index
> Fetch the complete documentation index at: https://docs.daysync.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tool Catalogue
> Every tool the Daysync MCP server exposes, and the scope that reveals it.
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](/mcp/authentication) — 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](/scopes#endpoints-that-need-more-than-one-scope). 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](/endpoints/tours#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](/endpoints/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](/endpoints/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
1. **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.
2. **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.
3. **The application does not hold that scope.** Nothing you can do client-side — the partner credential needs it.
4. **Your session predates the tool.** Tool lists are cached from session start; start a new chat.
See [Troubleshooting](/mcp/troubleshooting).
***
## When something new becomes a tool
So the surface does not creep back up, new capabilities follow a fixed rule:
1. If an existing tool covers it with one more field, that tool is extended.
2. Otherwise it becomes an **operation** — reachable via `list_capabilities` / `describe_operations` / `invoke_operation` from day one, with no client change and no re-consent.
3. 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.
4. 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](/scopes) for the mapping.