append_contents_to_channel
ChatGPTAppends one or more content occurrences to the end of a channel playlist, in the supplied order. Use this only for additions without a requested position; it never replaces or reorders the current playlist and accepts no position argument. The change is saved but neither sets the channel published flag nor synchronizes a screen; screen synchronization is a separate action allowed only when the user explicitly asks. Returns the ids of players whose screens are now out of date.
assign_channel_to_player
ChatGPTPlaces a channel into a player's layout zone, appending to the end of the zone's playlist unless a scheduleIndex is given. The change is saved but does not appear on screen: the player keeps showing its current content until the user explicitly asks to publish to the screens. Returns the ids of the players whose screens are now out of date.
clone_layout
ChatGPTCreates a copy of one layout, with its zones, under a new name. The source is one of the layouts list_layouts reports: a layout the tenant owns or a shared one. The source is left untouched, and the copy always belongs to the caller's tenant, so cloning a shared layout produces a layout of this tenant, not another shared one. The copy is a catalog entry and nothing more: it is attached to no player, carries no schedule and is no player's default layout, so it changes nothing on any screen and no synchronization is needed. Assigning it to players with set_player_layouts or set_default_layout_for_players, and scheduling it with schedule_layouts, are separate steps to be taken only if the user asks for them. Every successful call creates one more copy, so if a call's outcome is uncertain, read list_layouts before repeating it rather than assuming nothing was created. Returns the new layout's id and name.
create_channel
ChatGPTCreates a channel (internally called an area) in the caller's tenant. The channel is saved but not assigned to any player, so nothing appears on screen. Leave it that way: do not publish it to the screens unless the user explicitly asks.
create_schedule
ChatGPTCreates a schedule ("programmazione") in the caller's tenant, defining when the channels, contents and layouts assigned to it are on air. Dates/times are the player's local time. A new schedule broadcasts nothing until contents, channels or layouts are assigned to it, so its contents, channels and layouts come back empty. The change is saved but does not appear on screen: the assigned players keep showing their current content until the user explicitly asks to publish to the screens. Returns the created schedule and the ids of the players whose screens are now out of date.
create_tag
ChatGPTCreates one tag in the caller's tenant. Create a tag ONLY when the user has explicitly asked for it or confirmed it, never on your own initiative as a step towards tagging something: a tag is vocabulary shared by the whole tenant. When a label the user mentioned is not in list_tags, report it back to the user and ask, instead of creating it. A label that already exists is not an error: nothing is created and created=false is returned. Creating a tag assigns it to nothing and changes nothing on any screen.
get_content
ChatGPTGets a single content (a media asset schedulable into a channel) by id, with the channels it is assigned to and the schedules that put it on air.
get_content_tags
ChatGPTGets the tags assigned to one content, named by its id. A content that exists but carries no tag returns an empty tag list; an id that names nothing the caller can reach returns nothing at all.
get_current_identity
ChatGPTReturns the WallSign user, tenant and authorization claims bound to the current authenticated MCP token, so the user can confirm which account is connected. Unlike get_server_info, this identifies the authenticated account rather than the running deployment. Requires only authentication.
get_player_channels
ChatGPTGets a player's zones (internally called areas), each listing its assigned channels ordered by their position in the zone's playlist. This tool reports what plays in a player's zones, not when: for the time windows — weekdays, calendar bounds, daily hours — use list_schedules.
get_player_settings
ChatGPTGets a single settings group for a player (e.g. logo, audio, resolution), matching the corresponding REST GET endpoint.
get_player_status
ChatGPTGets the details and current status of a single player by id, including the diagnostics the device last reported: content status, uptime, resolution, CPU, RAM, storage, network and the latest screenshot. It also reports the player's stored location; a non-null googlePlaceId means that location was picked through Google Places in the web app, and set_player_location cannot preserve it. defaultLayoutId and defaultLayoutName name the player's default layout: the one it shows when no scheduled layout of its own is on air. They do not report the layout the player is rendering at this moment, which no tool exposes. Use list_player_layouts for that player's scheduled layouts.
get_players_connection_status
ChatGPTGets the last-get connection status for all accessible players, or a single player when a player id is given. Use this, not search_players, to answer whether one specific player is connected now. If only its name is known, resolve the id with search_players first, then call this tool.
get_schedule
ChatGPTGets a single schedule by id, with the contents, the channels and the layouts it puts on air. A listed layout is the one this schedule is assigned to, and this schedule's window decides when it goes on air; no tool reports which layout a player is rendering at this moment.
get_server_info
ChatGPTReturns the WallSign MCP server name, version and the date its current deployment was published, so a client (or the user, by asking the assistant) can confirm which deployed release it is talking to and tell two deployments of the same version apart. Because the server is remote, the reported values are always those of the current deployment. Requires only authentication.
list_channel_tags
ChatGPTLists the tags assigned to each channel (internally called an area) in the caller's tenant. Channels carrying no tag are omitted.
list_channels
ChatGPTLists the broad channel catalog (internally called areas) defined in the caller's tenant, with each channel's name, color, published state and assigned players. Use search_channels instead whenever the request names a filter or will build a multi-channel mutation target; do not filter this broad enriched list in the model.
list_content_tags
ChatGPTLists every content of the caller's tenant that carries at least one tag, with its tags. Contents with no tag do not appear at all: to check whether one specific content has tags, call get_content_tags with its id instead.
list_contents
ChatGPTLists the broad content catalog of the caller's tenant, optionally filtered by content type, each with the channels it is assigned to and the schedules that put it on air. Use search_contents instead whenever the request names a filter or will build a multi-content mutation target; do not filter this broad enriched list in the model. A content is a media asset that can be scheduled into a channel: an image, a video, a web page, a text, an audio or video stream, or a feed (news, weather, social, YouTube). Each schedule is named only; call get_schedule for its days and hours.
list_cultures
ChatGPTLists the culture names supported for player language settings, such as it-IT. These are the values set_players_language accepts, and it is the tool that writes what this one lists. The list is the same for every tenant and describes no player; the language a given player runs on is read with get_player_status.
list_layout_schedules
ChatGPTLists the layouts that are scheduled, each with the schedules that govern it, named only — call get_schedule for a schedule's days and hours. A layout missing from this list carries no schedule THE CALLER CAN SEE, which is not the same as being unscheduled: the result is narrowed to the schedules the caller can access. Use list_layouts for the whole layout catalog, and schedule_layouts to change these assignments. This tool reports which layouts are scheduled; list_layouts (scheduledPlayers) and list_player_layouts report which players a layout can be switched on. Both edges are needed for a layout to ever reach a screen, and neither of them — nor the two joined — reports what a player is rendering at this moment: no tool exposes that.
list_layouts
ChatGPTLists the caller's tenant layout catalog: every layout the tenant owns plus the shared layouts available to all tenants, including layouts no player uses. Each layout carries two separate player lists. scheduledPlayers are the players a schedule can switch onto that layout: this is the edge layout scheduling runs on, and a layout listed there goes on air only if it also appears in some schedule's layouts list. defaultPlayers are the players whose default layout this is: what each of them shows when no scheduled layout of its own is on air, and nothing more — a player that merely falls back to a layout is never scheduled onto it, no matter how many schedules that layout has. Neither list reports what a player is rendering at this moment: no tool exposes that. Do not conflate the two: to find which layout is scheduled on which player, use scheduledPlayers (or list_player_layouts) joined with list_schedules on the layout id. A player can appear in both lists. A layout nobody uses returns two empty lists. scheduledPlayers reports what is stored, including attachments made before the current eligibility rule, so an EPaper player or one whose licence does not support layouts can still appear there; use set_player_layouts to replace or clear a player's attachments.
list_player_layouts
ChatGPTLists every player in the caller's tenant with its two layout edges. defaultLayout is the layout the player shows when no scheduled layout of its own is on air; it is absent when the player has none. scheduledLayouts are the layouts attached to the player, which its schedules can switch it onto. Neither reports the layout the player is rendering at this moment: no tool exposes that. This is the per-player view; use list_layouts for the tenant's layout catalog, which also includes the shared layouts and the ones no player uses. Joined with list_schedules on the layout id, this tool answers which layout is scheduled on which player and when: a scheduled layout that appears in no schedule's layouts list is never switched to. Use set_player_layouts to replace or clear a player's scheduledLayouts; a new non-empty set is accepted only for a player that is not an EPaper device and whose licence supports layouts, which means WallSign Pro, BrightSign Pro or BrightSign Plus. What this tool reports is what is stored, including attachments made before that rule, so an ineligible player can still appear with scheduled layouts.
list_player_power_schedules
ChatGPTLists the power schedules assigned to each player in the caller's tenant: the player-centric view of who carries what. Call this before set_players_power_schedules to see what a player carries today, since that write replaces the whole set. For the tenant's catalog of power schedules — the ids and time windows to assign — call list_power_schedules instead.
list_player_resolutions
ChatGPTLists the display resolutions the given player's device model supports: these ids are the only ones set_player_resolution accepts. The list is per player and not a tenant catalog, because what is on offer comes from the device model, and only BrightSign players support having a resolution assigned at all. A player whose device does not support resolution assignment, or whose model the CMS does not know, is reported as an error rather than as an empty list, so an unsupported device is never mistaken for a device that supports none. The resolution a player carries today is read with get_player_settings, settings group Resolution.
list_player_tags
ChatGPTLists the tags assigned to each player in the caller's tenant.
list_players
ChatGPTLists the broad digital-signage player catalog the caller can access in their tenant, with the device model, app version, firmware and whether each player has changes saved but not yet published to its screen. Use search_players instead whenever the request names a filter or will build a multi-player mutation target; model-side filtering of this broad list is not proof of a complete server-selected set. Use get_player_status for a single player's live diagnostics.
list_power_schedules
ChatGPTLists the tenant's power schedule catalog: each schedule's id, name, the weekdays it covers and the times it turns the screens on and off. These are the ids set_players_power_schedules takes. A power schedule governs when the screens are on, which is not the same thing as when a player receives updated content. This is a catalog and says nothing about which players carry which schedule: call list_player_power_schedules for that.
list_schedules
ChatGPTLists the broad schedule catalog ("programmazioni") defined in the caller's tenant, each with the contents, the channels and the layouts it puts on air. Use search_schedules instead to locate schedules by id/name or build a multi-schedule mutation target; do not filter this broad enriched list in the model. A schedule is the time window — weekdays, calendar bounds, daily hours — during which what is assigned to it is broadcast. A listed layout is the one this schedule is assigned to, and this schedule's window decides when it goes on air; it does not mean a player is showing that layout now, and no tool reports what a player is rendering at this moment. Joined with list_player_layouts (or a layout's scheduledPlayers) on the layout id, this tool answers which layout is scheduled on which player and when.
list_tags
ChatGPTLists the tags defined in the caller's tenant: the labels available to assign to players, channels and contents. Call it freely whenever a tag is mentioned, to check whether the label already exists and how it is spelled. It reports the catalog, not what carries a tag: for that use list_player_tags, list_channel_tags or list_content_tags.
list_timezones
ChatGPTLists the supported canonical IANA time-zone identifiers, such as Europe/Rome. These are the values to choose from when calling set_player_timezone: pick one from this list rather than inventing an identifier or converting from a Windows time-zone name. The list is the same for every tenant and does not describe any player; get_player_status reports the time zone a given player currently carries.
reboot_player
ChatGPTSends a reboot command to one player device. The device restarts and, once back up, resumes the content it was showing: nothing saved in the CMS changes and no synchronization follows. The screen is interrupted while the device restarts, so reboot only when the user asks for it. The command is sent without waiting for the device: true means the command was dispatched, not that the player has restarted, and a player that is offline may not receive it.
rename_channel
ChatGPTRenames a channel (internally called an area). The name is only a label used to identify the channel in the CMS: what the players show does not change, and no synchronization is needed. Returns the channel's id and its new name.
rename_content
ChatGPTRenames one content in the CMS. The name is only a label used to identify the content: it does not change what any player shows, and no synchronization is needed. Returns the content's id and its new name.
rename_player
ChatGPTRenames a player in the CMS. The name is only a label used to identify the player in the CMS: nothing changes on the screen, and no synchronization is needed. Returns the player's id and its new name.
request_player_screenshot
ChatGPTRequests a fresh screenshot from a player and waits briefly for it to be uploaded. Returns the screenshot URL, its last-update timestamp, and online/refreshed outcome flags; on timeout or when the player is offline, the existing (stale) capture is returned with refreshed=false.
schedule_channel
ChatGPTSets which schedules put a channel on air. The schedules given here REPLACE the ones the channel currently carries, so any schedule not in the list is removed from it, and omitting scheduleIds removes every schedule from the channel. The assignable schedules are the ones list_schedules reports, with the channels each is already assigned to — read it first to see what the channel is scheduled on today, so nothing is dropped by accident; if the user named a schedule that is not there, report it back and ask rather than assuming it should be created. Because the list replaces what the channel carries, one channel is not a small call: run it with dryRun=true first, show the user which schedules would be removed, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date.
schedule_contents
ChatGPTSets which schedules put one or more contents on air. A schedule decides when a content is shown inside the channels it belongs to. The schedules given here REPLACE the ones each content currently carries, so any schedule not in the list is removed from it, and omitting scheduleIds removes every schedule from the named contents. Call list_contents first to see what each content is scheduled on today, so nothing is dropped by accident. The assignable schedules are the ones list_schedules reports, with what each is already assigned to; if the user named a schedule that is not there, report it back and ask rather than assuming it should be created. Run it with dryRun=true first, show the user which schedules would be removed from which contents, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date.
schedule_layouts
ChatGPTSets which schedules govern one or more layouts. A schedule assigned to a layout decides when the players that layout is attached to switch onto it, so this is only half of the edge: a layout with schedules but no player in its scheduledPlayers switches nobody, and this tool does not attach a layout to a player. That other half is set_player_layouts: it decides where a layout may run, this tool decides when it is on air, and a new attachment there is accepted only for a player that is not an EPaper device and whose licence is WallSign Pro, BrightSign Pro or BrightSign Plus. The schedules given here REPLACE the ones each layout currently carries, so any schedule not in the list is removed from it, and omitting scheduleIds removes every schedule from the named layouts. Call list_layout_schedules first to see what each layout is scheduled on today, so nothing is dropped by accident. The assignable schedules are the ones list_schedules reports; if the user named a schedule that is not there, report it back and ask rather than assuming it should be created. Run it with dryRun=true first, show the user which schedules would be removed from which layouts, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date.
search_channels
ChatGPTSearches the caller's channels by name, id or publication state and returns one bounded page plus the total number of matches. Use this, not list_channels, whenever the request names a criterion or will build a target set for a bulk operation. A query or a published state is required. Results carry id, name and published state only — call list_channels for a channel's players and playlist.
search_contents
ChatGPTSearches the caller's contents by name, id or type and returns one bounded page plus the total number of matches. Use this, not list_contents, whenever the request names a criterion or will build a target set for a bulk operation. A query or a type is required; an unknown type is rejected rather than ignored. Results carry id, name and type only — call get_content for a content's channels and schedules.
search_players
ChatGPTSearches the caller's players with server-side filters and returns one bounded page plus the total number of matches. Use this, not list_players, to select players by criteria or build a target set for a bulk operation: the server applies the filters and reports how many players match, so the set can be shown to be complete. The online filter selects an online or offline fleet; to answer whether one specific player is connected now, use get_players_connection_status, using this search only to resolve a supplied name to an id if needed. At least one filter is required. Filters combine with AND. Use has-style filters set to false to find incomplete configuration. Page with offset until hasMore is false, and treat the set as complete only when the number of distinct players collected equals total; note that total describes one query, so a catalog changing between pages can still shift rows.
search_schedules
ChatGPTSearches the caller's schedules by name or id and returns one bounded page plus the total number of matches. Use this, not list_schedules, to locate a named schedule or to build a target set for a bulk operation. The query is required. Results carry id and name only — call get_schedule for a schedule's days, hours and window.
set_channel_contents
ChatGPTTenant administrators only. Replaces a channel's complete playlist: every occurrence to keep must be supplied, omitted occurrences are removed, repeated content ids are allowed, and an empty list clears the channel. Input positions must be distinct non-negative values and define order; the server stores the result contiguously from 0. One channel does not make this a small call — what the supplied playlist omits is deleted — so run it with dryRun=true first, show the user which contents would be dropped, and only then repeat the same call with dryRun=false. The change is saved but neither sets the channel published flag nor synchronizes a screen; screen synchronization is a separate action allowed only when the user explicitly asks. Returns what changed, or would change, and the ids of players whose screens are now out of date.
set_channel_published
ChatGPTPublishes or unpublishes a channel. Publishing marks the channel as available to the players it is assigned to; it does not push anything to a screen. The affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns the ids of the players whose screens are now out of date.
set_default_layout_for_players
ChatGPTSets one layout as the default layout of one or more players, REPLACING the default each of them carries today. The default layout is what a player shows when no scheduled layout of its own is on air, so this is not the scheduling edge: it neither attaches the layout to the players' schedules nor removes any scheduled layout they already carry — set_player_layouts is the tool for that, and it works on one player's scheduled layouts only. Call list_layouts for the assignable catalog, which is the tenant's own layouts plus the shared ones, and list_player_layouts to see each player's current default before replacing it. The whole call is refused, with nothing written, unless every named player accepts the layout: the layout's orientation must match the player's, an EPaper player accepts only its own orientation's default layout, and a player on a Standard WallSign or BrightSign licence accepts only a layout with exactly one zone that is neither audio nor a widget. Report a refusal back with its reason rather than retrying player by player. Run it with dryRun=true first, show the user the report — which names every player that refuses the layout, not just the first — and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a player already on this default can still be in it.
set_player_layouts
ChatGPTSets which layouts one player can be switched onto by its schedules. The layouts given here REPLACE the ones the player currently carries, so any layout not in the list is detached from it, and an empty list detaches them all. Call list_player_layouts first to see what the player carries today, so nothing is dropped by accident; the attachable layouts are the ones list_layouts reports. This is where a scheduled layout may run; schedule_layouts decides when it is on air, and both edges are needed before a schedule switches the player onto a layout. A non-empty list is accepted only for a player that is not an EPaper device and whose licence supports layouts, which means WallSign Pro, BrightSign Pro or BrightSign Plus; an empty list is always accepted, so it is also how a player that is no longer eligible gets its old attachments cleared. Because the list replaces what the player carries, one player is not a small call: run it with dryRun=true first, show the user which layouts would be detached, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the player keeps showing its current content until the user explicitly asks to publish to the screens.
set_player_location
ChatGPTRecords where a player physically is. This writes the player's WHOLE location: every field you do not pass is cleared, including a Google place id set from the web app, which no argument here can carry. A call that would clear values the player already has is refused unless confirmReplace=true, so call get_player_status first when you only mean to change part of the location, and pass back the values you want to keep. Pass latitude and longitude only when the user gave them to you: never derive coordinates from a place name or address, and note that a location made of placeName and placeAddress alone is complete and valid. The two coordinates go together or not at all. The server checks only that the coordinates are within valid ranges, never that they match the address, so repeat user-supplied coordinates back to the user for confirmation before writing and report the stored values afterwards. This is CMS metadata: nothing changes on the screen and no synchronization is needed.
set_player_resolution
ChatGPTSets the display resolution of one player. Call list_player_resolutions first and pass one of the ids it returns: a resolution the player's device model does not support is refused, and since the offer differs from player to player this tool takes one player rather than a list. The change is saved but does not appear on screen: the player keeps its current output until the user explicitly asks to publish to the screens. Returns the assigned resolution and the id of the player whose screen is now out of date.
set_player_timezone
ChatGPTSets the time zone a player runs on, which is what its schedules and its clock follow. Call list_timezones for the supported identifiers and pass one of them: an identifier that is not supported is refused. Pass null to clear the player's time zone, and note that an empty or blank string clears it too, so never pass a placeholder when you mean to leave it alone. get_player_status reports the time zone the player carries today. The change is saved but does not reach the screen: the player keeps running on its current time zone until the user explicitly asks to publish or synchronize. Returns the player, its stored time zone and the id of the player whose screen is now out of date.
set_players_brightness
ChatGPTSets the same screen brightness, from 0 to 100, on one or more players. When the call names more than one player, run it with dryRun=true first, show the user the report, and only then repeat the same call with dryRun=false. The value is stored for every player named, including one whose device model or version the CMS cannot confirm supports eco brightness — the report says so per player, and the write proceeds either way. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a player reported as unchanged can still be in it.
set_players_language
ChatGPTSets the same interface language, as a culture name such as it-IT, on one or more players. Call list_cultures for the values this accepts: a culture outside that list is refused, and so is a blank one, which is never a way to clear a player's language. When the call names more than one player, run it with dryRun=true first, show the user the report, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a player reported as unchanged can still be in it.
set_players_power_schedules
ChatGPTSets which power schedules one or more players run on, which is when their screens turn on and off. The schedules given here REPLACE the ones each named player currently carries, so any schedule not in the list is unassigned from them, and an empty list clears them all. Call list_power_schedules for the ids to pass, and list_player_power_schedules to see what the players carry today. Because the list replaces what each player carries, always run it with dryRun=true first, show the user which schedules would be unassigned, and only then repeat the same call with dryRun=false. The assignment is stored for every player named, including one whose device model or version the CMS cannot confirm supports eco power schedules, and schedules with overlapping windows are reported rather than refused. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a player reported as unchanged can still be in it.
sync_players
ChatGPTPushes assigned content to live screens. Call this ONLY when the user has explicitly asked to synchronize or publish to the screens. NEVER call it on your own initiative, and never as a follow-up step after a mutation: saved changes are meant to remain unpublished until the user decides to publish them. Returns the dispatch schedule, including each chunk's player ids and when they will be updated.
tag_channels
ChatGPTAssigns tags to one or more channels (internally called areas). The labels must already exist in the tenant: call list_tags to see them, and if the user named a label that is not there, report it back and ask rather than assuming it should be created. When the call names more than one channel, run it with dryRun=true first, show the user the report, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a channel reported as unchanged can still put its players in it.
tag_contents
ChatGPTAssigns tags to one or more contents. The labels must already exist in the tenant: call list_tags to see them, and if the user named a label that is not there, report it back and ask rather than assuming it should be created. When the call names more than one content, run it with dryRun=true first, show the user the report, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a content reported as unchanged can still put its players in it.
tag_players
ChatGPTAssigns tags to one or more players. The labels must already exist in the tenant: call list_tags to see them, and if the user named a label that is not there, report it back and ask rather than assuming it should be created. When the call names more than one player, run it with dryRun=true first, show the user the report, and only then repeat the same call with dryRun=false. The change is saved but does not appear on screen: the affected players keep showing their current content until the user explicitly asks to publish to the screens. Returns what changed, or would change, and the ids of the players whose screens are now out of date; that sync list follows the write, so a player reported as unchanged can still be in it.
update_schedule
ChatGPTPatches an existing schedule: only the supplied fields change, every omitted field keeps its current value. Dates/times are the player's local time. Returns the updated schedule, including the contents, channels and layouts it puts on air, together with the ids of the players whose screens are now out of date. The change is saved but does not appear on screen: the assigned players keep showing their current content until the user explicitly asks to publish to the screens.
append_contents_to_channel
Claudeassign_channel_to_player
Claudeclone_layout
Claudecreate_channel
Claudecreate_schedule
Claudecreate_tag
Claudeget_content
Claudeget_content_tags
Claudeget_current_identity
Claudeget_player_channels
Claudeget_player_settings
Claudeget_player_status
Claudeget_players_connection_status
Claudeget_schedule
Claudeget_server_info
Claudelist_channel_tags
Claudelist_channels
Claudelist_content_tags
Claudelist_contents
Claudelist_cultures
Claudelist_layout_schedules
Claudelist_layouts
Claudelist_player_layouts
Claudelist_player_power_schedules
Claudelist_player_resolutions
Claudelist_player_tags
Claudelist_players
Claudelist_power_schedules
Claudelist_schedules
Claudelist_tags
Claudelist_timezones
Claudereboot_player
Clauderename_channel
Clauderename_content
Clauderename_player
Clauderequest_player_screenshot
Claudeschedule_channel
Claudeschedule_contents
Claudeschedule_layouts
Claudesearch_channels
Claudesearch_contents
Claudesearch_players
Claudesearch_schedules
Claudeset_channel_contents
Claudeset_channel_published
Claudeset_default_layout_for_players
Claudeset_player_layouts
Claudeset_player_location
Claudeset_player_resolution
Claudeset_player_timezone
Claudeset_players_brightness
Claudeset_players_language
Claudeset_players_power_schedules
Claudesync_players
Claudetag_channels
Claudetag_contents
Claudetag_players
Claudeupdate_schedule
Claude
