server shipctl_docs: Ask shipctl questions in plain English.
tool   shipctl_docs(request): 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.

# connection 1
> I'm on shipctl 1.x. How do I roll back production to r41?
answer In shipctl 1.x, use:

```bash
shipctl release revert r41
```

This reverts traffic to release `r41`. Note that in shipctl 2.x, this was replaced by `shipctl rollback --env production --to r41`.  (6.0s)
> And how do I list the releases of production?
answer In shipctl 1.x, use:

```bash
shipctl release list
```

(In shipctl 2.x, this was replaced by `shipctl releases --env production`.)  (5.9s)

# connection 2
> And how do I list the releases of production?
answer To list releases in production, run:

```bash
shipctl releases --env production
```

This lists the releases that the environment has run, newest first, along with their status (`live`, `previous`, `degraded`, `failed`, or `pending`).  (3.8s)

# no GOOGLE_API_KEY in the server env
> I'm on shipctl 1.x. How do I roll back production to r41?
error  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.  (0.8s)

# release_bot through McpToolset, timeout=60
> Staging deploy r42 failed in pre_deploy. Ask the docs whether rolling staging back undoes its migration.
call   docs_shipctl_docs {"request": "Does rolling staging back undo its migration?"}
result {"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 
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.

# release_bot through McpToolset, default timeout
> Staging deploy r42 failed in pre_deploy. Ask the docs whether rolling staging back undoes its migration.
call   docs_shipctl_docs {"request": "Does rolling staging back undo its migration after a pre_deploy failure?"}
call   docs_shipctl_docs {"request": "Does rolling back staging undo migrations?"}
result {"error": "MCP tool execution failed: Timed out while waiting for response to ClientRequest. Waited 5.0 seconds."}
result {"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 
answer No. `shipctl rollback` only reverts traffic to an earlier release and does not run hooks, so migrations are never undone.   To reverse a migration, you must write a new migration that undoes the changes and deploy it as a new release before rolling back.