{
  "model": "gemini-3.8-flash",
  "same_connection": {
    "server": {
      "name": "shipctl_docs",
      "instructions": "Ask shipctl questions in plain English.",
      "capabilities": [
        "prompts",
        "resources",
        "tools"
      ]
    },
    "tools": [
      {
        "name": "shipctl_docs",
        "description": "Answer a question about shipctl, the team's deploy CLI, from its manual. Pass the full question; follow-up questions on the same connection keep the context.",
        "inputSchema": {
          "properties": {
            "request": {
              "title": "Request",
              "type": "string"
            }
          },
          "required": [
            "request"
          ],
          "title": "call_agentArguments",
          "type": "object"
        }
      }
    ],
    "calls": [
      {
        "request": "I'm on shipctl 1.x. How do I roll back production to r41?",
        "is_error": false,
        "text": "In shipctl 1.x, use:\n\n```bash\nshipctl release revert r41\n```\n\nThis reverts traffic to release `r41`. Note that in shipctl 2.x, this was replaced by `shipctl rollback --env production --to r41`.",
        "seconds": 6.0
      },
      {
        "request": "And how do I list the releases of production?",
        "is_error": false,
        "text": "In shipctl 1.x, use:\n\n```bash\nshipctl release list\n```\n\n(In shipctl 2.x, this was replaced by `shipctl releases --env production`.)",
        "seconds": 5.9
      }
    ]
  },
  "new_connection": {
    "server": {
      "name": "shipctl_docs",
      "instructions": "Ask shipctl questions in plain English.",
      "capabilities": [
        "prompts",
        "resources",
        "tools"
      ]
    },
    "tools": [
      {
        "name": "shipctl_docs",
        "description": "Answer a question about shipctl, the team's deploy CLI, from its manual. Pass the full question; follow-up questions on the same connection keep the context.",
        "inputSchema": {
          "properties": {
            "request": {
              "title": "Request",
              "type": "string"
            }
          },
          "required": [
            "request"
          ],
          "title": "call_agentArguments",
          "type": "object"
        }
      }
    ],
    "calls": [
      {
        "request": "And how do I list the releases of production?",
        "is_error": false,
        "text": "To list releases in production, run:\n\n```bash\nshipctl releases --env production\n```\n\nThis lists the releases that the environment has run, newest first, along with their status (`live`, `previous`, `degraded`, `failed`, or `pending`).",
        "seconds": 3.8
      }
    ]
  },
  "failures": {
    "no_key": {
      "server": {
        "name": "shipctl_docs",
        "instructions": "Ask shipctl questions in plain English.",
        "capabilities": [
          "prompts",
          "resources",
          "tools"
        ]
      },
      "tools": [
        {
          "name": "shipctl_docs",
          "description": "Answer a question about shipctl, the team's deploy CLI, from its manual. Pass the full question; follow-up questions on the same connection keep the context.",
          "inputSchema": {
            "properties": {
              "request": {
                "title": "Request",
                "type": "string"
              }
            },
            "required": [
              "request"
            ],
            "title": "call_agentArguments",
            "type": "object"
          }
        }
      ],
      "calls": [
        {
          "request": "I'm on shipctl 1.x. How do I roll back production to r41?",
          "is_error": true,
          "text": "Error executing tool shipctl_docs: No API key was provided. Please pass a valid API key. Learn how to create an API key at https://ai.google.dev/gemini-api/docs/api-key.",
          "seconds": 0.8
        }
      ]
    },
    "default_timeout": {
      "question": "Staging deploy r42 failed in pre_deploy. Ask the docs whether rolling staging back undoes its migration.",
      "timeout": null,
      "calls": [
        {
          "name": "docs_shipctl_docs",
          "args": {
            "request": "Does rolling staging back undo its migration after a pre_deploy failure?"
          }
        },
        {
          "name": "docs_shipctl_docs",
          "args": {
            "request": "Does rolling back staging undo migrations?"
          }
        }
      ],
      "results": [
        {
          "error": "MCP tool execution failed: Timed out while waiting for response to ClientRequest. Waited 5.0 seconds."
        },
        {
          "content": [
            {
              "type": "text",
              "text": "No. `shipctl rollback` only moves traffic back to an earlier release and does not run any hooks, so database migrations are never undone. \n\nIf a migration must be reversed, write a new migration that reverses the change and deploy it as a new release before rolling back."
            }
          ],
          "isError": false
        }
      ],
      "answer": "No. `shipctl rollback` only reverts traffic to an earlier release and does not run hooks, so migrations are never undone. \n\nTo reverse a migration, you must write a new migration that undoes the changes and deploy it as a new release before rolling back."
    }
  },
  "release_bot": {
    "question": "Staging deploy r42 failed in pre_deploy. Ask the docs whether rolling staging back undoes its migration.",
    "timeout": 60,
    "calls": [
      {
        "name": "docs_shipctl_docs",
        "args": {
          "request": "Does rolling staging back undo its migration?"
        }
      }
    ],
    "results": [
      {
        "content": [
          {
            "type": "text",
            "text": "No. Running `shipctl rollback` (for example, `shipctl rollback --env staging`) moves traffic back to an earlier release, but database migrations are not rolled back. If the release ran a migration, you must write and deploy a new migration that reverses the changes."
          }
        ],
        "isError": false
      }
    ],
    "answer": "No, rolling back staging does not undo its database migration. `shipctl rollback` only reverts traffic to an earlier release. To undo the database changes, you must write and deploy a new migration that reverses them."
  }
}
