MCP 工具

MCP工具参考

每个 Showly MCP 工具 — 范围、参数、返回形状、审计行为。

本页列出 Showly MCP 服务器公开的全部工具。每个条目包含所需作用域、 简化输入 schema、响应结构，以及写入审计日志的内容。

所有工具都需要经过身份验证的 MCP 客户端。令牌从工作区设置 → MCP 客户端发出。

调用被阻断时

Showly 返回的失败都用同一种结构：工具自己判定的失败，以及 MCP 层在工具执行前判定的失败（令牌缺少的范围、过大的参数或结果），格式一致。ok 为 false，error 是可用于分支判断的 string 代码，不会是对象。MCP 层的拒绝同时置上 MCP 的 isError 标志，因此按该标志分支的客户端仍然看到调用失败，标志旁的文本就是同一份 JSON。

有三类失败不走这套结构，因为 MCP SDK 在任何 Showly 代码执行前就已应答。三者都返回 isError: true 加一段纯文本：

  • 缺少参数或参数类型错误 — MCP error -32602: Input validation error: Invalid arguments for tool <name>: …。这是集成方最常产生的失败，解析时必须做防御。
  • 调用了本服务器未公开的工具名 — MCP error -32602: Tool <name> not found。
  • 意外崩溃 — 传输故障或缺陷。

工具未声明的参数不在此列，也根本不算失败：SDK 会在调用前丢弃未知键，工具只看到自己声明过的参数。

因为响应体无法保证可解析，所以遇到解析不了的响应体应按未知错误处理，不要猜测代码。

{
  ok: false,
  error: "insufficient_credits",
  message: "A production deployment costs 5 credits and this workspace has 2 left.",
  status?: 402,

  resolvedBy: "agent" | "human",
  actionUrl?: "https://showly.ai/app/billing#upgrade",
  humanAction?: "Open Plan & Billing and add credits, then tell the agent to retry.",
  agentNext: {
    kind: "retry" | "retry_with" | "call_tool" | "poll" | "wait_for_human" | "stop",
    tool?: "publish_site",
    afterSeconds?: 10,
    note: "After the balance changes, start the publish over from step 1."
  }
}

先读 resolvedBy。"agent" 表示用现有工具即可自行解决：换一个 previewSlug、取回缺失的 id，或调用 agentNext.tool 指定的工具。"human" 表示再多的工具调用也无济于事，应把 humanAction 和 actionUrl 转达给用户，然后按 agentNext 处理。

actionUrl 是绝对 URL，指向 Showly Web 应用中的页面，不会指向仅管理员可进入的区域。actionUrl 存在时以链接形式转达，humanAction 则必须每次都转达：这句话决定链接落到谁手上才有用。关键场景是套餐与账单页面：该页面仅限工作区所有者、管理员和账单角色，结账还额外需要 billing:write，普通成员点开只会被退回仪表盘。Showly 无法判断读到这条消息的是哪一方，因为页面依据的是本人的 Web 会话，而 MCP 令牌描述的是代理，所以链接一律照发，由 humanAction 说明限制：所有者可直接操作，其他人转交。套餐或额度类失败上的旧字段 webUpgradeUrl 取值与限制同上。

唯一需要人介入的成功响应也带同样的四个字段：request_publish 在顶层返回 resolvedBy、actionUrl、humanAction 和 agentNext，位置与失败响应完全一致，因此 if (result.actionUrl) 对两者都成立。这四个字段同时在 data 内与旧的 webApprovalUrl 并列重复一份，读取 data.actionUrl 的既有集成不受影响。

因为要保证既有集成继续可用，所以两个旧字段仍与 actionUrl 并存且取值相同：email_verification_required 的 webVerificationUrl，以及 request_publish 成功时的 webApprovalUrl。

list_projects

范围： project:read

列出令牌可以看到的项目（工作空间）。

Input:  {}
Output: { ok, data: Array<{ id, name, slug, createdAt }> }
Audit:  mcp.list_projects

list_sites

范围： site:read

列出当前工作区中的站点。通过 projectId 来确定列表范围；项目范围的 MCP 令牌会强制执行此过滤器，而不管参数如何。

Input:  { projectId?: string }
Output: { ok, data: Array<Site>, view: ListSitesView }
Audit:  mcp.list_sites

只有这个工具返回两个文本块。第一个是服务端写好的摘要，包含站点名称、哪些已公开，以及一条推荐的后续操作，因此每次调用的排版一致。第二个是上面的 JSON 信封，内容不变：请从 content[content.length - 1] 读取，不要从 content[0] 读取。同一个信封也会作为 structuredContent 返回，view 则是摘要与下述交互式渲染共用的投影。

如果客户端在 initialize 能力中声明了 MCP Apps 扩展 io.modelcontextprotocol/ui，本工具还会附带 _meta.ui.resourceUri，指向一个 ui:// HTML 资源，由宿主在沙箱 iframe 中渲染。未声明该扩展的客户端不会看到这项元数据，结果的其余部分也不受影响。

get_site_context

范围： site:read

返回站点、检测到的框架、路由、引用的环境变量名称、最新预览 URL，以及给定 siteId 的最新生产部署 ID。Site 的字段结构见[常用类型](#common-types)。

Input:  { siteId }
Output: { ok, data: { site, framework, routes, envReferences, latestPreviewUrl, lastProductionDeploymentId } }
Audit:  mcp.get_site_context  (records siteId)

create_change_plan

范围： site:read

产生变更计划提案。 _不_修改任何文件。代理通常会读取返回的计划，要求用户确认，然后调用apply_site_patch。

Input:  { siteId, request: string }
Output: { ok, data: { siteId, request, plan, nextStep } }
Audit:  mcp.create_change_plan

apply_site_patch

范围： site:write

暂存站点的文件编辑。分阶段的变更集是临时的，必须在 create_preview 之前实现。

Input:  { siteId, files: Array<{ path, content }>, message: string }
Output: { ok, data: { changesetId, siteId, fileCount, ttlSeconds, nextStep } }
Audit:  mcp.apply_site_patch  (records siteId + changesetId + file count)

create_preview

范围： preview:create

构建修补后的工作区并生成预览 URL。用户拥有 私有访问决策：省略 access 以获得服务器生成的简短 XXX-XXX 密码，传递自定义的 6-128 个字符的密码，或选择 organization (Pro+) 或 organization_or_password。生成的明文返回一次并且 以后无法检索。预览不能公开；发布时实时发布 应该对每个人都可见。previewSlug 可为已有站点选择一个独立的单层 <previewSlug>.showly.site 地址。

Input:  { changesetId?, siteId?, files?, previewSlug?, access?: { mode, password? } }
Output: { deploymentId, previewUrl, framework?, fileCount?, access: { mode, passwordConfigured, password? } }
Audit:  mcp.create_preview

create_github_preview

范围： preview:create

根据站点连接的 GitHub 上的最新提交构建私有预览 分支。安装凭据保留在Showly内。省略 access 即可得到 服务器生成的短 XXX-XXX 密码返回一次，传递自定义 6–128 字符密码，或在Pro+上选择组织成员访问。这个工具 从不发布Live。投票get_preview_status返回 deploymentId。

如果站点没有活动的 GitHub 应用程序存储库，请先在 Showly Web 中连接它。 存储库自动构建目前支持静态部署目标；动态的 容器目标在任何内容之前返回 repository_build_target_unsupported 正在排队。 未经验证的 Showly 电子邮件会返回 email_verification_required 以及 Web URL 来完成验证。

set_preview_access

范围： preview:create

更改现有 Preview 或已发布 Live 部署的访问策略，而不改变 URL。若要给正式站点 加密码，请先通过 list_deployments 取得状态为 ready 的 production 部署 ID； 这个工具为了兼容已有客户端而保留历史名称。保存密码模式会轮换密码；传递 6–128 个字符值或省略 password 在服务器端生成一个简短的XXX-XXX共享代码。回应 在 previewUrl 旁边显示一次新的明文密码。每项政策 更改会使之前发布的预览访问 cookie 失效。

组织模式验证访客的活跃Showly组织成员资格， 这样队友就可以登录而不是共享密码。 organization_or_password 保持内部流程，同时允许外部审阅者使用密码。

Input:  { deploymentId, access: { mode: "password" | "organization" | "organization_or_password", password? } }
Output: { deploymentId, target, previewUrl, access: { mode, passwordConfigured, password? }, policyVersion, advancedDeploymentControls }
Audit:  mcp.set_preview_access

自定义密码轮换示例：

{
  "deploymentId": "00000000-0000-4000-8000-000000000000",
  "access": { "mode": "password", "password": "ABC-123" }
}

retry_deployment

范围： preview:create

重新构建状态为失败或已取消的预览部署。调用方必须再次提交与 create_preview 相同的 files，因为服务器不会保留源文件。该操作会 把 files 视为必填字段，并创建一个状态为 status: "building" 的 新 deploymentId 返回供 轮询，原失败记录仍保留在历史中。每次重试都是新的构建，因此会计入 每月部署额度。如果部署仍在构建或已经就绪，返回 409 not_retryable；令牌无权查看时返回 404；超出额度时返回 402。

Input:  { deploymentId, files: [{ path, content }] }
Output: { ok, data: { deploymentId, status: "building", pollUrl, retriedFrom } }
Audit:  mcp.retry_deployment

run_checks

范围： checks:run

根据预览运行工作区的检查矩阵（lint、类型、自定义 CI 挂钩）。 checks 是 { id, status } 行的列表 (lint / typecheck / build / audit-gate)； summary 是单行字符串，例如 "3 passed / 1 pending"。

Input:  { deploymentId }
Output: { ok, data: { deploymentId, checks: [{ id, status }], summary } }
Audit:  mcp.run_checks

request_publish

范围： publish:request

打开准备预览部署的批准请求。响应包括 webApprovalUrl 深层链接；显示该链接，以便用户可以查看确切的内容 预览并完成任何计划所需的第二人批准。出版确实 不需要 OTP/MFA 注册。绑定MCP令牌的用户必须拥有 已验证 Showly 帐户电子邮件。如果工具返回 email_verification_required，将用户发送到webVerificationUrl重新发送 并在重试之前完成验证。

Input:  { deploymentId, message: string }
Output: { approvalId, deploymentId, state: "pending", expiresAt, reused, webApprovalUrl }
Audit:  mcp.request_publish

publish_site

范围： publish:confirm

直接从对话中发布准备好预览部署到生产 - 适用于无需批准工作流程的单独工作区和计划。绑定MCP令牌的用户必须拥有经过验证的Showly帐户电子邮件。如果工具返回email_verification_required，则将用户发送到webVerificationUrl，等待他们完成验证，然后重新启动两步流程；该网站尚未上线。 两步人工确认：用siteId + deploymentId（无confirmationToken）调用以获得摘要+短暂的confirmationToken；向用户展示即将上线的内容，然后使用令牌再次调用。步骤 2 返回 202 publishing。在启用了审批工作流程的计划中，请使用 request_publish 来代替 - 此工具会将您引导至那里。

Step 1: { siteId, deploymentId }                        → { confirmationToken, summary }
Step 2: { siteId, deploymentId, confirmationToken }      → { siteId, deploymentId, status: "publishing" }
Audit:  mcp.publish_site

支持 MCP Apps 的宿主可以省掉第一步的往返：Preview 就绪的卡片上带一个 Publish live 按钮，点击会把用户的确认作为一条消息送进对话。把那条消息当作确认——预检和带令牌的发布连着跑完，只回一次结果。其余不变：同样两次调用、同样由服务端签发的令牌、同样的阻断条件，以及和任何一次生产部署相同的积分开销。

get_preview_status

范围： preview:read

返回预览部署的当前状态。可选的长轮询（默认 30 秒，最长 60 秒），直到状态从已知值转变——在 request_publish 之后等待审阅者时有用。当status为failed或canceled时，结果还带有errorCode，errorMessage，stage，以及一个简短的logTail，解释为什么构建失败；与retry_deployment配对进行重建。

Input:  { deploymentId, waitForChange?: boolean, currentStatus?: string, timeoutMs?: number }
Output: { ok, data: Deployment & { productionUrl?, errorCode?, errorMessage?, stage?, logTail? }, changed?, timedOut? }
Audit:  mcp.get_preview_status

get_deployment_logs

范围： logs:read

返回部署的构建日志尾部（捕获的构建输出的最后 lineCount 行，默认 200）。 source 区分 db（真实日志行）、pending（部署存在，但尚未捕获日志 - 仍在构建或没有尾部）或 not-found（此令牌没有此类部署）。

Input:  { deploymentId, lineCount?: number }
Output: { ok, data: { deploymentId, lineCount, source, lines } }
Audit:  mcp.get_deployment_logs

diagnose_deployment

范围： logs:read

自我诊断您自己的部署之一。返回单个结构化的 AI 消耗性 诊断包，以便代理可以推理 为什么 构建在一次调用中失败 - 然后修复源和 retry_deployment - 而不是将单独的 get_preview_status / get_deployment_logs 读取缝合在一起。该捆绑包聚合：构建 失败（stage、errorCode、errorMessage、a logTail）、来自 Sentry 的相关运行时错误（通过提交 SHA + 环境 + 部署周围的窗口、失败软关联）、部署的 ops-job 状态、组织的 quota 状态、任何代理推送的 clientLogs（已编辑） +上限）和确定性hypotheses——有信心的可能根本原因（例如quota_exceeded/build_install_failed），通过规则（而非人工智能）作为高质量起点导出。

租户隔离：只能诊断当前组织中的部署。对令牌不可见的部署 ID 返回 404，与不存在的 ID 无法区分，从而避免泄露跨组织资源是否存在。 该工具与员工诊断中心使用同一个后端聚合器，对应端点为 GET /deployments/:deploymentId/diagnostics。

Input:  { deploymentId }
Output: { ok, data: { deployment, failure, jobRun, quota, sentry, clientLogs, hypotheses } }
Audit:  mcp.diagnose_deployment

list_templates

范围： template:read

列出当前令牌可用的 Showly 站点模板。与 create_site_from_template 配对即可在没有 Git 存储库的情况下登录新站点。

Input:  { framework?: string }
Output: { ok, data: Array<{ slug, displayName, description, framework, screenshots }> }
Audit:  mcp.list_templates

create_site_from_template

范围： template:create、site:write

从模板实现一个新的 Showly 托管站点并构建其第一个 私人预览。省略 access 生成返回的服务器拥有的密码 与 initialPreviewUrl 恰好一次；组织模式需要Pro。siteSlug 是首个预览和后续 Live 共用的稳定 <siteSlug>.showly.site 地址。

Input:  { projectId, templateSlug, name, siteSlug, variables?: Record<string, unknown>, access?: { mode, password? } }
Output: { ok, data: { siteId, projectId, initialVersionId, initialPreviewDeploymentId, initialPreviewUrl, access, templateSlug, createdAt } }
Audit:  mcp.create_site_from_template

create_site_from_html

范围： site:write、preview:create

直接从纯 HTML/CSS/JS 文件创建一个新的 Showly 托管站点 — 没有模板、没有框架、没有 Git 存储库。传递 或者 内联文件（index.html 必需；encoding: "base64" 对于二进制资产），或 sourceBundleId 对于您通过 request_upload_url 上传到带外的大型源（正是 files / sourceBundleId 之一）。一次调用即可创建网站并构建其第一个预览；使用 get_preview_status 轮询返回的 deploymentId。siteSlug 会成为预览/Live 共用的 <siteSlug>.showly.site 地址。生产保持在发布流程中。

Input:  { projectId, name, siteSlug, files?: Array<{ path, content, encoding?: "utf8" | "base64" }>, sourceBundleId?, framework?, access?: { mode, password? } }
Output: { ok, data: { siteId, deploymentId, status | previewUrl, access, ... } }
Audit:  mcp.create_site_from_html

request_upload_url

范围： site:write、preview:create

为不适合通过模型传递的大型站点源创建一个短时有效、仅可使用一次的上传 URL。使用 Content-Type: application/x-tar 将 tar 归档 PUT 到返回的 uploadUrl，然后调用 create_site_from_html，传入返回的 sourceBundleId 而不是 files。

Input:  {}
Output: { ok, data: { uploadUrl, sourceBundleId, contentType, expiresInSeconds } }
Audit:  mcp.request_upload_url

request_download_url

范围： site:read

与 request_upload_url 对应的读取工具。传入有权查看的 deploymentId，即可获得其保留源归档的短时、一次性 downloadUrl。在本地下载并编辑归档，然后用 request_upload_url 上传新版本，并把得到的 sourceBundleId 传给 create_preview。如果没有可用的源归档，会返回 source_not_retained (422)；小型站点可使用 get_site_files。

Input:  { deploymentId }
Output: { ok, data: { downloadUrl, expiresInSeconds } }
Audit:  mcp.request_download_url

claim_trial_site

范围： site:write

将通过 Showly 公开试用流程创建的站点归入当前已认证账户，使其不再过期并成为永久站点。传入服务器提供的 trialId + guestToken。如果试用已过期，或工作区设置了明确的活跃站点限制，则会失败；请删除不再使用的站点或联系 Showly 支持后重试。Free 和 Pro 默认都不限预览站点和正式站点数量，升级套餐不会增加站点名额。

Input:  { trialId: string, guestToken: string }
Output: { ok, data: { trialId, siteId, claimed: true } }
Audit:  mcp.claim_trial_site

delete_preview

范围： preview:create

按 ID 软删除预览部署。返回deletedAt。 幂等 — 删除已删除的预览将返回 404 preview_not_found。这里只能删除预览；生产不受影响。

Input:  { deploymentId }
Output: { ok, data: { deploymentId, deletedAt } }
Audit:  mcp.delete_preview

delete_site

范围： site:delete

软删除站点并级联其部署、版本和自定义域。 两步人工确认：使用 siteId（无 confirmationToken）调用以获取摘要（slug + 级联部署数量）以及短暂的 confirmationToken；向用户显示，然后使用要删除的令牌再次调用。只能从备份中恢复。

Step 1: { siteId }                          → { confirmationToken, summary: { siteSlug, cascade: { deployments } } }
Step 2: { siteId, confirmationToken }        → { siteId, deletedAt }
Audit:  mcp.delete_site

list_site_domains

范围： site:read

列出附加到站点的自定义域，包括当前引导步骤、DNS 记录、证书状态、恢复 CTA、管理页面和线上地址。结果默认返回 50 条，最多可请求 100 条。当 pagination.nextCursor 不为 null 时，将它原样作为 cursor 传回；游标是不透明的，并且只绑定到一个站点。

结果非空时，请遵循每个目标行中的 domains[].journey；此时不存在顶层 journey。只有列表为空时才会返回顶层 journey，用于引导首次连接域名。仅当目标域名的阶段为 setting_up_https 时进行轮询；进入 needs_attention 后停止轮询。

Input:  { siteId, limit?, cursor? }
Output: { ok,
          journeyGuide: { steps, whatShowlyGivesYou },
          domains: [{ id, hostname, status, isLive, certStatus, liveUrl,
                      manageUrl, dnsRecords, proxyNote, apexNote?,
                      journey: { phase, currentStep, stepStatuses,
                                 whereYouAre, userAction, agentAction,
                                 actionUrl }, recovery? }],
          pagination: { count, total, nextCursor },
          journey? }
Audit:  mcp.list_site_domains

add_custom_domain

范围： site:write · 所有套餐均可使用

将客户自己的域附加到站点并返回 DNS 记录 用户 必须在其域提供商处发布。

智能体不能替客户完成这一步。 添加域名只会创建待验证记录，不会 路由流量；客户必须在域名注册商或 DNS 服务商处添加返回的记录。请把 记录明确交给客户，并说明完成配置前域名不会生效。根域名响应会包含 apexNote，必须向客户展示，因为区域顶点不能使用普通 CNAME。每条响应还会带上 proxyNote，必须转达给客户：CNAME 必须以纯 DNS 记录发布（在 Cloudflare 上是灰色云图标，新建记录默认是橙色），否则证书永远签发不出来；而 TXT 记录无论是否代理都能验证通过，本流程其他任何环节都发现不了。

保留返回的verificationToken； verify_custom_domain需要它，并且只显示一次。

Input:  { siteId, hostname }
Output: { ok, domain: { id, hostname, status, dnsRecords, proxyNote, apexNote?, verificationToken }, nextStep }
Audit:  mcp.add_custom_domain

verify_custom_domain

范围： site:write · 所有套餐均可使用

重新检查 DNS 是否有待处理的域。在用户说他们已添加记录后调用它。仅当记录实际发布和传播时它才会成功 - 失败通常意味着“尚未”，而不是“损坏”，因此请等待几分钟并重试，而不是报告错误。

成功后，将自动请求 TLS 证书，并且域名将在一小时内上线。投票 list_site_domains 投票给 isLive。

Input:  { siteId, domainId, token }
Output: { ok, domain: { id, hostname, status, isLive, ... } }
Audit:  mcp.verify_custom_domain

故意不让代理删除域名。 归档活动域名会使客户的网站在他们公布的地址立即脱机，无需任何外部Showly同意 - 因此它会在仪表板中保留一个人的操作。参见 ADR 0015。

list_site_versions

范围： site:read

列出站点的版本历史记录（最新的在前）：id、source、changeSummary、作者、createdAt。与 get_site_files 配对（传递 versionId​​）来读取该版本的内容。

版本列表使用键集分页。limit 每页最多为 100；如需读取更早的版本，请把上一响应的 pagination.nextCursor 作为下一请求的 cursor。当 nextCursor 为 null 时，表示已经到达历史记录末尾。游标是不透明值并且绑定到一个站点；它会固定首次请求时的目录快照，因此翻页期间新建的版本不会把条目挤入已经读过的页面。

hasMore 已弃用，镜像 pagination.nextCursor !== null；更喜欢pagination。

Input:  { siteId, limit?, cursor? }
Output: { ok, data: {
          versions: [{ id, source, changeSummary, authorUserId, createdAt }],
          hasMore,
          pagination: { limit, nextCursor: string | null }
        } }
Audit:  mcp.list_site_versions

list_deployments

范围： site:read

列出站点的部署（最新的在前）：id、target (preview / staging / production)、status、url、createdAt。这就是 deploymentId 的来源 — 将返回的 id 与 retry_deployment、delete_preview、request_publish 或 publish_site 一起使用。

Input:  { siteId }
Output: { ok, data: [{ id, siteId, target, status, url, createdAt }] }
Audit:  mcp.list_deployments

get_site_files

范围： site:read

读取站点版本的文件树 (path → content)，以便您可以在编辑之前查看当前内容。通过siteId + versionId（从list_site_versions）。大型/清单支持的版本返回 files: null 加上 note。

Input:  { siteId, versionId }
Output: { ok, data: { versionId, source, changeSummary, files: Record<string,string> | null, note? } }
Audit:  mcp.get_site_files

diff_site_versions

范围： site:read

比较两个版本并准确返回更改的内容：每个文件状态 (added / removed / changed) 加上行级别 add / remove / context。通过 siteId + versionA（较旧的“之前”）+ versionB（较新的“之后”），均来自 list_site_versions。回答诸如“昨天和今天之间发生了什么变化”之类的问题。大型/清单支持的版本无法进行比较并返回错误。

Input:  { siteId, versionA, versionB }
Output: { ok, data: {
          versionA: { id, source, changeSummary, createdAt },
          versionB: { id, source, changeSummary, createdAt },
          summary: { filesChanged, filesAdded, filesRemoved, linesChanged },
          files: Array<{ path, status, lines: Array<{ type, text }> }>
        } }
Audit:  mcp.diff_site_versions

rollback_to_version

范围： rollback:confirm

将生产回滚到旧版本并发布它没有预览 - 这里最重要的工具。 两步人工确认：用siteId + versionId（无confirmationToken）调用，得到warning + 摘要 + confirmationToken；向用户显示警告，然后使用令牌再次调用。步骤 2 返回 202 building — Showly 构建该版本的预览并自动将其升级到生产环境。可通过前滚到更新版本来恢复。

Step 1: { siteId, versionId }                       → { confirmationToken, warning, summary: { changeSummary, versionCreatedAt, previewed: false } }
Step 2: { siteId, versionId, confirmationToken }     → { siteId, versionId, deploymentId, status: "building" }
Audit:  mcp.rollback_to_version

生产工具（不MCP-暴露）

不公开MCP — 需要 Web/API 批准流程。

旧版 rollback_deployment 操作不通过 MCP 提供。它不会出现在 tools/list，也不能使用 MCP 令牌调用；请使用 Showly Web 中对应的 审批界面。

生产发布是 MCP-可调用的：publish_site（上面的两步确认）直接发布，而rollback_to_version回滚生产——这两种kind: "confirm-publish"风格的工具都不会在第一次调用时起作用。

常见类型

该参考使用了上面的一些命名形状。具体的字段集如端到端流程所示，它使用真实的JSON走完整个会话。快速总结：

类型关键字段
Siteid、name、slug、projectId、framework（自动检测）、repositoryUrl
Deploymentid、siteId、target（preview / staging / production）、status、previewUrl?、createdAt
plancreate_change_plan提案：预期文件编辑的列表以及人类可读的摘要；直到apply_site_patch才适用
checks工作区检查矩阵的每次检查结果（lint、类型、自定义 CI 挂钩）
summary由 run_checks 返回的 checks（通过/失败的计数）的汇总

status是queued、building、ready、failed、canceled之一。 ready 是预览和生产部署的最终成功状态。 framework 在构建时自动检测，并且是 astro、vite、next-export、static-html、custom 或 unknown 之一 - 它不是您在清单上设置的内容。

版本控制

工具模式通过 MCP version 字段遵循 semver。重大更改带来了新的工具名称 (apply_site_patch_v2)；旧名称在至少一个发布周期内继续有效，并在 notes 中附有弃用说明。