MCP ツール

エンドツーエンドの流れ

実際のデプロイは、一連の MCP ツール呼び出しとして表現されます。

MCP ツールリファレンスには、すべてのツールを個別に掲載しています。このページでは、実際のデプロイとして一連の呼び出しをつなぎ、エージェントセッション全体の流れを示します。

このフローでは次のことを前提としています。

  • 少なくとも 1 つのサイトを含む Showly ワークスペース
  • スコープ project:read、site:read、site:write、preview:create、checks:run、publish:request、publish:confirm、logs:read のMCP トークン
  • https://mcp.showly.ai/mcp に接続された Claude Code または Codex クライアント — 例:

claude mcp add --scope user --transport http showly https://mcp.showly.ai/mcp、 次に、最初のツール呼び出し時にブラウザで認証します。を参照してください。 他のホストごとに接続ガイド。

以下の入出力は短縮した JSON です。完全なスキーマはツールリファレンスを参照してください。

1. list_projects — プロジェクトを選択します

エージェントが作業するプロジェクトを見つけます。

// Input
{}
// Output
{
  "ok": true,
  "data": [
    {
      "id": "22222222-2222-4222-8222-222222222222",
      "name": "Acme",
      "slug": "acme",
      "createdAt": "2026-05-01T10:00:00.000Z"
    }
  ]
}

エージェントは関連する projectId を選択し、セッションの残りの間それを記憶します。

2. list_sites — サイトを見つける

プロジェクトには複数のサイトを含めることができるため、エージェントは選択した projectId の下にサイトをリストし、操作対象の具体的な siteId を取得します。

// Input
{ "projectId": "22222222-2222-4222-8222-222222222222" }
// Output
{
  "ok": true,
  "data": [
    {
      "id": "33333333-3333-4333-8333-333333333301",
      "name": "Marketing site",
      "slug": "marketing-site",
      "projectId": "22222222-2222-4222-8222-222222222222"
    }
  ]
}

エージェントは一致する siteId を選択し、残りのセッションでそれを使用します。

3. get_site_context — 現在の状態を読み取る

ユーザーが変更したいサイトのマニフェストと最近のアクティビティを取得します。

// Input
{ "siteId": "33333333-3333-4333-8333-333333333301" }
// Output
{
  "ok": true,
  "data": {
    "site": {
      "id": "33333333-3333-4333-8333-333333333301",
      "name": "Marketing site"
    },
    "framework": "next",
    "routes": ["/", "/pricing", "/about"],
    "envReferences": ["NEXT_PUBLIC_ANALYTICS_ID"],
    "latestPreviewUrl": "https://acme-pr-12.showly.site",
    "lastProductionDeploymentId": "99999999-9999-4999-8999-999999999902"
  }
}

4. create_change_plan — 意図を宣言する

何を変更したいのかを説明します。この呼び出しはファイルを変更しません**。

// Input
{
  "siteId": "33333333-3333-4333-8333-333333333301",
  "request": "Change the hero headline to 'Ship without ceremony'"
}
// Output
{
  "ok": true,
  "data": {
    "siteId": "33333333-3333-4333-8333-333333333301",
    "request": "Change the hero headline to 'Ship without ceremony'",
    "plan": [
      {
        "path": "app/page.tsx",
        "action": "edit",
        "summary": "Replace H1 text"
      }
    ],
    "nextStep": "apply_site_patch"
  }
}

通常、エージェントは続行する前に確認のためにユーザーに計画を示します。

5. apply_site_patch — 変更を書き込む

実際のファイル編集をステージングします。

// Input
{
  "siteId": "33333333-3333-4333-8333-333333333301",
  "files": [
    {
      "path": "app/page.tsx",
      "content": "export default function Page() {\n  return <h1>Ship without ceremony</h1>;\n}\n"
    }
  ],
  "message": "Update hero headline"
}
// Output
{
  "ok": true,
  "data": {
    "changesetId": "cs_01HZ8K2QRR3KKTYR4MA8YPNZRC",
    "siteId": "33333333-3333-4333-8333-333333333301",
    "fileCount": 1,
    "ttlSeconds": 3600,
    "nextStep": "create_preview"
  }
}

変更セットは一時的なものです。ttlSeconds 以内に実体化しないと期限切れになります。

6. create_preview — プレビュー URL を構築する

変更セットをプレビュー ビルドとして実体化します。

// Input
{ "changesetId": "cs_01HZ8K2QRR3KKTYR4MA8YPNZRC" }
// Output
{
  "deploymentId": "99999999-9999-4999-8999-99999999990a",
  "previewUrl": "https://acme-pr-13.showly.site",
  "framework": "next",
  "fileCount": 1
}

ビルドは分離されたワークスペースで実行されます。ほとんどのマーケティング サイトは 90 秒以内に終了します。

7. run_checks — 煙 + 糸くず

プレビューに対してワークスペースのチェック マトリックスを実行します。

// Input
{ "deploymentId": "99999999-9999-4999-8999-99999999990a" }
// Output
{
  "ok": true,
  "data": {
    "deploymentId": "99999999-9999-4999-8999-99999999990a",
    "checks": [
      { "id": "lint", "status": "passed" },
      { "id": "typecheck", "status": "passed" },
      { "id": "build", "status": "passed" },
      { "id": "audit-gate", "status": "pending" }
    ],
    "summary": "3 passed / 1 pending"
  }
}

チェックが失敗した場合、エージェントは失敗をユーザーに明らかにし、修正された計画を使用してステップ 4 に戻ります。

8. request_publish — 承認を開く

ワークスペースで承認ワークフローが有効になっている場合、 人間の承認者。この呼び出しによりリクエストが開かれ、レビュー担当者にディープリンクが返されます。 承認または拒否のための訪問。それ以外の場合、エージェントは 2 つのステップを使用します。 publish_site確認。どちらのフローでも OTP/MFA 登録は必要ありません。

// Input
{
  "deploymentId": "99999999-9999-4999-8999-99999999990a",
  "message": "Hero headline update — agent-proposed"
}
// Output
{
  "approvalId": "ap_01HZ8K2QRRA0V01Q3Q7H7R7K2P",
  "deploymentId": "99999999-9999-4999-8999-99999999990a",
  "state": "pending",
  "expiresAt": "2026-05-26T11:00:00.000Z",
  "reused": false,
  "webApprovalUrl": "https://showly.ai/app/deployments/99999999-9999-4999-8999-99999999990a/publish",
  "actionUrl": "https://showly.ai/app/deployments/99999999-9999-4999-8999-99999999990a/publish"
}

エージェントはユーザーに webApprovalUrl と現れます。レビュー担当者はそれをクリックし、差分を確認して承認します。 Showly は、プレビュー アーティファクトを運用環境にプロモートします。

従来の rollback_deployment は MCP ツールではなく、追加の MFA を要求する Web UI にのみ存在します。publish_site と rollback_to_version は、2 段階の確認を経て MCP から呼び出せます。詳しくはツールリファレンスを参照してください。

9. get_deployment_logs — 確認する

承認後、実稼働デプロイには同じ deploymentId が適用されます。ログを取得して、ビルド アーティファクトが正しくプロモートされたことを確認します。

// Input
{
  "deploymentId": "99999999-9999-4999-8999-99999999990a",
  "lineCount": 50
}
// Output
{
  "ok": true,
  "data": {
    "deploymentId": "99999999-9999-4999-8999-99999999990a",
    "lineCount": 50,
    "source": "db",
    "lines": [
      "[build] starting pnpm build",
      "[build] generated 1 page in 14s",
      "[deploy] promoted to production at 2026-05-26T10:05:21Z"
    ]
  }
}

これが完全なループです: 計画 → パッチ → プレビュー → チェック → 承認 → 出荷 → 確認。

次は何ですか