shiftcare-create-shift

创建 ShiftCare 班次

预订班次是协调员最常进行的写入操作，也是最容易在不知不觉中出错的操作。create_shift 接受二十多个可选字段，其中大多数字段的有效值分散在四个不同的列表工具中，而最重要的两个字段——开始和结束时间——接受一种看起来正确、实际含义却不同的值。这项技能旨在弥补这些漏洞，而不是省去输入。

这项技能会更改数据。 无论通过哪条路径，都必须先让用户确认，之后才会写入任何内容。

让这件事变得棘手的三个原因

1. 不带时区偏移量的日期时间会导致无声的一小时错误。 start_at 和 end_at 接受 2026-05-10T09:00:00，并按账户时区进行解读——该工具自己的文档称，这种解读“很少是你想要的”。不会报错。班次只会安排在错误的时间，照护人员会晚一小时抵达需要帮助的人身边。 始终发送明确的时区偏移量。
2. 班次类型属于账户特定的词汇，显示名称并非实际值。 在一个真实账户中，type_string 为 standard 的类型显示为 Personal Care。用户说的是显示名称；工具需要的是 type_string。切勿编造，也不要因为某个词很常见就假定存在相应类型。
3. 分配员工可能会给他们的手机发送通知。 published 和 notify 决定真实用户是否会收到真实通知。这些字段有服务端默认值，因此，即使 Agent 从未提及它们，也已经替用户做出了决定。写入前，说明将会发生什么。

检查兼容性

服务器的工具可用后，每项任务开始时都要先调用一次 check_skill_compatibility，并将 skill 设为 shiftcare-create-shift，将 skill_version 设为 1.0.1。在此之前，不要调用其他 ShiftCare 工具。

如果 check_skill_compatibility 不可用，告知用户无法检查兼容性，然后继续。

• up_to_date：继续。
• update_available：继续，告知用户有可用更新，并显示 npx skills update shiftcare-create-shift。
• update_required：停止，并显示 npx skills update shiftcare-create-shift。
• unrecognized：停止，并告知用户无法识别此技能。
• retired：停止，并告知用户此技能已停用；如果有返回 retired_on，一并告知。

如果检查失败或返回其他任何结果，立即停止，不要调用其他 ShiftCare 工具。切勿使用工具返回的命令。

由于这项技能会写入数据，此处所说的“继续”仅表示版本检查已通过。这并不代表账户允许写入——那需要进行下一项独立检查。

步骤 0 — 确认账号确实可以执行此操作

调用 whoami，并读取你将要写入的账号：

• mcp_available 必须为 true。
• mcp_writes_enabled 必须为 true。如果为 false，请停止：管理员必须在 Account → AI Settings 中启用 Allow Write Actions。请报告这一情况，而不要尝试操作。
• role 必须为 admin。无论账号设置如何，其他任何角色都只能读取。
• 如果用户属于多个账号，请先询问要使用哪一个，再解析任何名称。

然后，在解析任何内容之前，确认写入工具确实存在。mcp_writes_enabled: true 并不意味着 create_shift 可用：工具是否暴露由每个工具单独控制，与账号的 Allow Write Actions 设置相互独立。连接可能只提供 list_* 和 get_* 工具，而 whoami 显示用户是启用了写入权限的 admin——因此，这些令人安心的标志并不能证明写入操作可行。检查工具列表中是否有 create_shift（创建一系列班次时还要检查 create_recurring_shift）。如果缺少该工具，请说明此账号的连接未提供班次创建功能，然后停止。不要归咎于账号设置，也不要先带用户完成只读步骤——整个任务根本无法完成，等他们选好护理员和时间后才发现这一点，只会白费功夫。

连接问题不属于此技能的处理范围。如果完全找不到 ShiftCare 工具，请使用 shiftcare-mcp 技能。

步骤 1 — 询问请求中未说明的信息

“明天帮 Mary 预约一个班次”没有提供班次所需的大部分信息。请在一条消息中收集所有缺失信息，不要一次只问一个问题，也不要替用户编造答案。

只询问以下六项：

1. 服务对象 — 这个班次是为谁安排的。没有合理的默认值。
2. 护理员 — 谁来上班，或者明确说明该班次暂不安排人员。“我之后再选人”是有效答案：这表示创建一个空缺班次，而不是猜测人选（参见步骤 5 和步骤 6）。
3. 时间 — 日期、开始时间和结束时间。只有日期而没有时间，或只有开始时间而没有结束时间，都不够；必须提供 end_at。
4. 是否发布 — 是否将该班次加入护理员的排班表。
5. 是否通知 — 是否通知护理员。
6. 任务 — 护理员在该班次中需要完成的事项。

**即使 published 和 notify 都有服务器端默认值，也要询问这两项。**关键就在于：默认值根据账号设置计算得出，所以不询问仍然会替用户决定是否让某个真实用户的手机响起。请直接询问，例如：“要把这个班次加入对方的排班表吗？需要通知对方吗？”并明确传入用户的回答，而不要依赖默认值。

询问任务，但不要作出无法兑现的承诺。create_shift 没有 tasks 参数：无法通过 MCP 为班次添加清单任务。但它有一个自由文本字段 description，护理员上班时可以看到。因此，请将用户提供的内容填入该字段，并明确说明这些内容是班次上的说明，而不是可勾选的清单项目；如果用户希望跟踪完成情况，必须在应用中添加清单项目。

**不要询问护理计划。**护理计划中的目标和任务会根据服务对象自己的计划自动附加到班次上——不会由任何人逐个班次选择，也没有 MCP 工具可以设置这些内容。询问会让用户误以为存在实际上并不存在的控制选项。改为在之后报告班次自动继承了哪些内容，参见步骤 9。

此处不要询问其他任何事项。班次类型默认为 standard；补贴、休息时间和出行安排都是可选项，通常也不是用户想设置的内容——对此长篇追问，会让一个两行就能说明的请求看起来像填表。

地点和服务机构是例外，而且特意没有列在上述问题中：你还不知道账号是否有多个选项，因此现在无法询问。等查看列表后确认确实有多个选项时，再按照步骤 3 提问——对于只有一个地点的账号，询问“选哪个地点？”只会徒增干扰。

步骤 2 — 将每个名称解析为 ID

使用 list_clients 和 list_staff，并通过 filter_by_name 筛选。两者都进行部分匹配，因此 “Sam”会匹配 Samantha 和 Sammy。

• 恰好一个匹配项 → 使用该项，并保留名称以便读回确认（见下文）。
• 多个匹配项 → 列出这些匹配项并询问。绝不要选择第一个、最近的或字符串最相似的。重名的 Mary 很常见，并非特殊情况。
• 没有匹配项 → 如实告知并停止。不要改用更短的片段扩大搜索后猜测；该客户端可能已停用、属于其他团队，或者根本不存在。

读回账户实际显示的名称，而不是你拼出来的名称。 对客户端来说，这是 display_name；对员工来说，这是 name。不要用 first_name + family_name 拼出姓名：filter_by_name 匹配的是 display_name，而这两个姓名字段在记录中可能完全对不上。例如，一条匹配“Mary”的真实记录可能是 display_name: "Mary Garcia"，但 first_name 是 "Milena"，family_name 是 "Wong"。若将这项预约确认为“Milena Wong”，用户要么会拒绝一项正确的班次，要么更糟，会以为预约的是另一个人而予以批准。员工记录中的 first_name/family_name 往往直接为 null。

限制 list_clients 的页面大小。 每条客户端记录都内嵌联系人、团队和服务协议，因此整页内容会很大。使用 filter_by_name 时，将 per_page 设为 3–10；如果筛选条件太宽泛，应收紧筛选条件，而不是增大页面大小。

列表结果受权限范围限制。结果为空表示“此用户看不到任何内容”，这与“不存在”并不相同——请这样说明。

班次可以没有员工。如果用户没有指定护理人员（“下周加一个班次，我来选护理人员”），请省略 staff_ids，将班次创建为空缺班次。不要替用户选择人员。请注意，循环班次系列不能设为空缺——参见步骤 5。

步骤 3 — 了解账户使用的术语，并确定地点

调用 list_shift_types。每行包含 name（用户使用的名称）和 type_string（工具要求的值）。根据用户的说法匹配 name，并传入 type_string。

• 没有把握的匹配项 → 显示可用名称并询问。绝不要传入未从此列表中读取的 type_string。
• 用户未指定类型 → 省略 shift_type；默认值为 standard。在确认信息中说明这一点，并使用该账户为 standard 提供的显示名称。

过夜班是两个独立的设置。 大多数账户都有一种名为 Sleepover 的班次类型，而 create_shift 还另有一个 sleepover 布尔值，用于改变薪酬计算方式（通常从按小时计薪改为固定费率）。设置班次类型并不会自动设置该标记。对于“安排一个过夜班”，请同时提出这两项设置，并分两行分别确认。多日住家班次的 live_in 也采用相同方式。

即使用户没有提到地点，也始终调用 list_account_locations

省略 account_location_id 不意味着该班次没有地点。服务端会回退到账户的默认地点，因此总会选定一个地点——要么由你选择，要么由服务端悄悄替你选择。由此会产生两点，其中第二点很重要：

• 有多个地点 → 询问用户选哪个。 显示地点名称，让用户选择。不要擅自替用户接受默认地点：对于有多个地点的账户，默认地点往往不是用户想选的那个，而把班次登记到错误的站点，会导致排班、报表和薪酬出错。
• 恰好有一个地点 → 使用该地点，并在确认信息中说明。 无需提问；没有其他选项。
• Feature not enabled → 该账户不提供地点功能。 不设置地点，继续操作，并说明这一点。没有可选项，也就无需询问。

先确定地点，再计算时差，因为地点会决定如何解析没有指定时区偏移量的日期时间，也可能决定当地时钟时间具体对应什么时刻。一个同时在珀斯和墨尔本设有站点的账户涉及两个时差，因此在地点确定之前，“上午 9 点”并不对应唯一时刻。这就是为什么这一步要在第 4 步之前完成，也就是为什么确认信息中应说明所选地点，而不是让它保持含糊。

设施的处理方式相同

也要调用 list_facilities。有多个设施 → 询问用户选哪个，或者询问该班次是否属于某个设施，因为设施不像地点，可以不选。恰好有一个设施 → 提供该选项，而不是直接假定使用它；账户中只有一个设施，并不意味着每个班次都在该设施进行。没有设施，或工具不可用 → 不设置设施，继续操作。

只有用户要求设置津贴时，才将 list_allowances 的结果用于 allowance_ids。

address 和 suburb_address 是以自由文本形式存储在班次中的字段。它们不会查询或覆盖 account_location_id 或 facility_id，而且这三个 ID 不能互换——地点、设施和地址是三种不同的信息；填写其中一项，不会自动填写其他项。

步骤 4 — 获取该地点的 UTC 偏移量

你需要的是班次所在地点的时区，而不是账户的时区。 在服务器端，未指定偏移量的日期时间会按解析出的账户地点自身的时区进行解析；只有当该地点没有时区时，才会回退到账户设置中的时区。即使未发送 account_location_id，系统也会解析出一个地点——使用账户的默认地点——因此，对于拥有多个地点的账户，解读你输入内容的时区可能与账户自身的时区不同。这就是为什么显式偏移量不可省略：它能让这个问题不再重要。

whoami 可能会以 IANA 名称报告账户的 time_zone。这是账户设置中的时区——也就是回退时使用的时区——因此不能证明日期时间会如何解读。 可用它做合理性检查；如果账户只有一个地点，或者其默认地点没有自己的时区，那么它就是正确的时区。对于拥有多个地点的账户，不要把它当作权威依据。

没有 MCP 工具会报告地点的时区——list_account_locations 只返回名称和地址，不会返回时区。因此，在步骤 3 确定具体是哪个地点后，请读取该地点现有班次的偏移量，并按你选定的 account_location_id 筛选结果。其他站点的班次可能采用完全不同的偏移量，因此未筛选的样本不能作为该地点的依据：

1. 调用 list_shifts，设置 from_date 和 to_date（均为 YYYY-MM-DD），覆盖请求日期前后几天。
2. 只保留 account_location_id 与你确定的地点匹配的行。list_shifts 不支持按地点筛选，因此请自行筛选。
3. 从保留下来的 start_at 中读取偏移量，例如 2026-09-04T09:00:00+10:00 → +10:00。

应从接近目标日期的班次中获取偏移量，而不是从今天的班次中获取。位于实行夏令时地区的账户会在年中切换偏移量；如果使用今天的偏移量来预订切换日附近的班次，就会差一小时，而这正是此步骤要避免的问题。

如果筛选后没有结果，请询问用户该地点的时区或偏移量——提问时要说出地点名称，确保用户回答的是正确的站点。根据地区猜测远远不够：同一个账户可能在珀斯、昆士兰、墨尔本和霍巴特都有地点，这些地点采用三种不同的偏移量；这种差异正是账户时区或其他站点的班次都无法作为该地点依据的原因。

然后，用用户提供的当地时钟时间加上该偏移量来构造日期时间： "tomorrow 9am to 5pm" 加上 +10:00 → start_at: 2026-09-05T09:00:00+10:00， end_at: 2026-09-05T17:00:00+10:00。

如果同一天的 end_at 早于 start_at，请停止并询问。 “9pm to 7am”可能表示跨夜班次，此时 end_at 应属于次日；也可能是笔误。绝不要替用户决定是哪一种。

步骤 5 — 区分单次班次与重复班次

请求	工具
单个日期	create_shift
“每周一”、“每周”、“每隔一个星期二”、“每月 3 日”	create_recurring_shift

create_shift 不能创建系列班次，create_recurring_shift 也不能创建单次班次。请在确认前选好工具，并确认你选用的班次类型。

创建重复班次需要用户提供更多信息，缺少这些信息时将无法继续：

• recurrence_unit（day / week / month）和 recurrence_repeat_every（1–365）。
• 当单位为 week 时，提供 recurrence_week_days，格式为 ["Mon", "Wed"]。
• 当单位为 month 时，提供 recurrence_day_of_month。
• 必须提供 recurrence_end_date。 系列班次不能无限期持续。如果用户未提供结束日期，请向其询问——不要自行编造结束时间。
• 必须同时提供 client_ids 和 staff_ids。 不能创建没有客户和员工的重复班次。如果用户尚未选择护理人员，请说明这一点，并建议改为创建单次班次。

start_at / end_at 描述的是首次出现的班次，仍需包含显式偏移量。

第 6 步 — 检查冲突，并将决定权交还给用户

对于你准备安排的每位工作人员，调用 list_shifts，将 from_date 和 to_date 的范围设为覆盖班次日期及前一天。list_shifts 按 start_at 过滤，因此只匹配班次准确时间的窗口会漏掉开始较早或跨夜、但仍有时间重叠的 班次。

请自行比较返回的 start_at/end_at 与用户请求的时间范围。

冲突绝不能由你自行解决。 不要在冲突的时间上创建班次，不要悄悄换成 其他护理人员，也不要为了消除问题而移除该护理人员。请停下来，说明冲突班次的时间和 ID，并提供以下三种处理方式：

1. 仍然继续。 有时这是有意安排的——例如两位附近客户之间的短暂重叠，或协调员打算手动处理的排班。由用户决定，不是你。
2. 换一位护理人员。 询问用户考虑谁。没有工具可以搜索空闲工作人员，因此你不能在用户未提出要求时自行提供候选名单：请用户提供姓名或团队，然后对该团队调用 list_staff，并针对每位候选人重新执行此步骤。说明你会这样做，不要表现得像是你知道谁有空。
3. 创建不指定护理人员的班次。 班次会创建为待分配状态，之后再安排人员——当指定的护理人员确实忙碌时，这通常是正确的处理方式。省略 staff_ids。 不能用于重复系列，因为重复系列必须指定 staff_ids；此时，请提供其他护理人员，或改为创建一次性待分配班次。

然后针对用户指定的人选重新执行此步骤，只有在所有冲突都已处理后，才整理确认内容。用户接受的冲突必须在确认内容中作为已接受的冲突保留——用户同意后，不要悄悄将其删掉。

此技能不会检查休假和可用时间。如果用户询问，请在确认前用 list_leaves 和 list_availability_schedules 读取相关信息。

第 7 步 — 每次都完整确认

复述所有已确定的值。不要只问“要我创建这个班次吗？”——而要复述完整的预订信息，让用户能发现处理过程中出错的地方。在此之前的内容都不会更改任何数据；从这里开始，数据就会被更改。

Ready to create this shift:

  Client:      Mary Chen (id 12345)
  Staff:       Sarah Okafor (id 67890)
  When:        Fri 5 Sep 2026, 9:00 am – 5:00 pm (+10:00 — Melbourne)
  Shift type:  Personal Care (standard)
  Location:    Melbourne (you chose this; the account has 4)
  Facility:    none — not a facility shift
  Sleepover:   no
  Published:   yes — visible to Sarah on her roster
  Notify:      yes — Sarah gets a notification

  Accepted clash: Sarah already has shift #10098, 4:00 pm – 6:00 pm
  that day. You asked to go ahead anyway.

Create it?

此步骤的规则：

• 必须获得明确确认。 用户之前说过“给我安排一个班次”表达的是意图，并不代表同意你刚整理好的这项具体预订。请等待用户回复此消息。
• 用户拒绝 → 不创建任何内容。 不要进行部分写入，不要说“那我改为创建未分配班次”，也不要稍作修改后重试。请告知用户没有创建任何内容，然后停止。
• 明确说出地点，并说明该地点是用户选择的还是采用默认值。 地点绝不能省略：它用于设置站点，也用于确定构建时间时所用的时区。“地点：默认”也是值得复述的明确结果；保持沉默则不行。
• 用通俗语言说明 published 和 notify 的值，如上所述。两者都有服务端默认值（published 根据账户的 Publish Shifts 设置和班次类型计算），因此如果采用默认值，请说明预期结果，以及最终结果由账户设置决定。如果用户希望其中任一项关闭，请明确传入 false。
• 如果是重复系列，请确认重复模式和预计数量： “每周一，9 Sep 至 21 Dec — 约 16 个班次”。
• 如果还有任何事项尚未确定，这条消息就不能作为确认内容。 应改为提出问题。未处理的冲突也算尚未确定——这个问题应放在第 6 步提出，而不是藏在这次复述中。

第 8 步 — 只写入一次，然后验证

首先，重新确认账户。 再次调用 whoami，并检查 account_id 是否仍与解析所有 ID 时使用的账户一致。这不是对缓存过期的无端担忧：任务进行期间，连接可能会重新认证——用户重新连接服务、令牌刷新，或用户以其他身份登录——而连接恢复后可能变成另一个人、另一个账户，既没有报错，任何工具响应中也不会对此作出提示。实际观察到过：一次重新连接同时更改了已登录用户和账户，此后 list_accounts 只提供了新的账户。

你持有的每个 ID 都属于读取它时所在的账户。把这些 ID 发给另一个账户时，它们就成了外键：运气好会被拒绝，运气不好则会因 ID 冲突而被悄悄关联到无关记录。如果 account_id 已更改，请停止。不要转换这些 ID，也不要重新解析名称后继续操作——请告知用户账户已更改，并从第 2 步重新开始，以便他们针对当前实际所在的账户重新确认。

写入工具只调用一次。

切勿盲目重试创建操作。 这些工具并非幂等操作，结果不明确时，成功只是耗时较长的可能性远大于失败。如果结果不确定，先用 list_shifts 读取该日期的班次，再作决定。

验证并报告实际存在的内容：

• 单次班次： 重新读取已创建的班次，并检查存储的时间是否与用户要求的当地时间一致。这项检查能在护理人员发现之前捕捉到时区错误，但请使用 list_shifts，不要只查看创建响应，原因有二。

  创建响应会以 UTC 显示时间，而 list_shifts 会使用账户的时区偏移。 在 9 月 8 日上午 9 点创建的班次，create_shift 返回的时间是 2026-09-07T23:00:00Z——代表的是同一时刻，但日历日期不同。把它与提交的文本直接比较，会误以为预订了错误的日期，进而“修正”本来正确的班次。比较前请先转换时区，或用 list_shifts 重新读取，它会返回 2026-09-08T09:00:00+10:00。

  创建响应不会确认员工分配情况。 即使护理人员已成功分配，响应仍会返回 staff: [] 和 include_staff: false。这表示“未包含”，而不是“未分配”——在告知任何人班次空缺或重新分配前，请使用新班次的 ID 调用 list_shift_staffs 确认。

• 重复班次： 响应中包含 program_id。前 20 个班次会同步创建，其余班次则会异步创建，因此请在整个系列日期范围内调用 list_shifts，按该 program_id 筛选，并报告数量。如果数量少于预期，请说明其余班次仍在生成中，而不要报告失败。

完整报告班次信息——不要只说“已完成”，而要报告当前实际记录：班次 ID、带时区偏移的存储时间 start_at/end_at、客户端、员工、班次类型和 url。

请根据服务器实际解析的结果报告 published 和 notify，从响应中读取，而不是照抄提交的值。如果省略其中任何一项，服务器会根据账户设置计算其值，因此只有读取结果才能得知真实值。用户需要知道的是“已发布：true——现在已列入他们的排班表”，而不是“我使用了默认设置”。

第 9 步 — 告诉对方还需要做什么

创建班次很少意味着工作已经完成，而且从预订信息中看不出接下来该做什么。按耗时从短到长向对方说明，并准确指出哪些事你能做、哪些不能做——无法兑现的承诺还不如不作承诺。

如果对方需要，你可以在此处完成以下操作：

• 说明该班次是否继承了任何护理计划任务。 使用新班次 ID 调用 list_shift_care_plan_goals 和 list_shift_care_plan_tasks。这两个工具会读取客户护理计划中已安排在该班次上的内容，因此工作人员的应用会提示他们完成相关事项。结果为空是有用的信息：这表示不会出现任何提示；对于新客户，通常意味着班次开始前需要处理护理计划。由于你可能无法查看计划，这两个工具也可能返回空结果，因此要说明你无法排除这种情况。
• 之后发布班次或发送通知，如果确认时没有启用这些选项——使用 update_shift。该工具会整体替换客户和员工数组，因此只发送标志字段。
• 添加描述、休息时间、行驶公里数或津贴——同样使用 update_shift，并使用 list_allowances 查找津贴 ID。
• 检查空缺班次是否已发布招聘信息——使用 list_job_board_postings，并按班次 ID 筛选。此工具为只读，且只有在工具列表中确实存在时才能使用：大多数账户都关闭了该工具的单独开关，因此许多连接中完全不会显示此工具。先确认工具列表，再决定是否提供此项服务。
• 记录进度备注——使用 create_progress_note，但只能在班次完成后操作。不要为未来的班次提供此项服务。

必须在应用中完成的事项——请明确告知，不要提出代为尝试：

• 为客户或班次分配表单。 MCP 对表单仅提供只读功能：只能列出已提交的回复，无法进行其他操作。没有分配表单的工具，也没有列出账户中所有表单的工具，因此你甚至无法告知用户有哪些表单。请让他们在应用中打开该班次进行操作。
• 招聘看板上的任何操作，包括发布空缺班次。 create_shift 自带的说明要求通过 create_job_board_posting“将空缺班次发布到招聘看板”——**但 MCP 中不存在该工具。**它并非被开关禁用：该工具根本不存在，也没有对应的单独开关，因此管理员无法启用。读取端的 list_job_board_postings 确实存在，但大多数账户都关闭了该工具的开关，因此应将招聘看板的所有操作都视为只能在应用中完成；即使要提供只读查询，也要先检查工具列表。绝不要承诺会发布招聘信息。
• **价格手册、资金、工资组、按班次计费的行驶费用，以及交通或设备等额外费用。**见下文。

如果创建的是空缺班次，待办事项就是分配护理人员，应优先说明这一点。

此技能不会做什么

MCP 在创建排班时不会提供以下选项。请勿将它们偷偷塞进调用中——请引导用户使用 ShiftCare Web 应用：

• 价格目录、资金来源和薪酬组选择。这些选项会回退到 V3 服务端默认值。
• 按单次排班计费的行程费用。该费用遵循每位客户各自的 Invoice Travel 设置。
• 在排班中向客户收取的交通或设备等额外费用。

有两点值得特别说明，创建响应中都会包含相关信息：

• 未配置服务区域的客户会生成未定价（$0）的排班，且不会报错。
• 系统会为你选择价格目录，而且选中的价格可能并不便宜。 响应中的 clients[].price_book 和 line_items 会显示名称和每小时费率，因此请读出费用， 不要让它默默隐藏：一个普通的 8 小时排班使用了含税每小时 $207.89 的价格目录， 总计约 $1,663，而请求中完全没有指定该目录。 只要排班会产生费用，就要报告价格目录和大致总额，并说明无法通过 MCP 更改该选择。

此技能完全不涵盖以下事项——请说明情况并停止，不要自行变通：

• 取消排班。 请使用 shiftcare-cancel-shift 技能。两个取消工具在客户是否 付费 以及 护理人员是否获得报酬方面有所不同——这是计费决策，而非清理步骤。
• 更改现有排班，包括更换护理人员。 update_shift 的客户和员工数组会整体替换 分配列表——只发送一个员工 ID 会移除排班中的其他所有人。不要用它来“修复”刚创建的排班。
• 编辑或删除周期性系列。 MCP 无法执行此操作。错误的系列必须在应用中更正，这也是 步骤 7 不可省略的另一个原因。

“Sarah 明天请病假”不属于此技能的范围。这可能意味着取消（使用 shiftcare-cancel-shift 技能）、重新分配，或创建替代排班。请询问用户具体要做什么，只有 当答案是“创建”时才在此处继续。

错误

症状	可能原因	处理方法
缺少写入工具，且 whoami 显示写入功能为关闭	“Allow Write Actions”已关闭，或用户不是管理员	由管理员在 AI Settings 中启用；启用前停止
whoami 显示写入功能为开启，但仍缺少写入工具	此连接未提供写入工具——该工具单独进行门控，与“Allow Write Actions”无关	如实说明。此技能无法绕过此限制，而且这不是账户设置问题
Feature not enabled	该端点未为此账户启用	对于 list_account_locations，继续操作但不指定地点。对于创建工具，停止——必须为此账户启用 v3 排班创建端点
Missing required arguments: from_date, to_date	list_shifts 始终需要这两个参数，格式为 YYYY-MM-DD	提供完整的一天范围
排班创建在错误的小时	漏掉时区偏移量，或偏移量取自夏令时切换另一侧	从目标日期附近该地点的排班读取偏移量（步骤 4），并在步骤 8 检查存储的时间
排班类型被拒绝	type_string 未在此账户中配置	重新读取 list_shift_types，并请用户从列出的名称中选择
创建周期性排班被拒绝	缺少 recurrence_end_date、client_ids 或 staff_ids	请用户补充缺失项；这些参数都没有安全的默认值