@vibetocloud/mcp 1.0.0

package/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "@vibetocloud/mcp",
+  "version": "1.0.0",
+  "description": "Claude Code MCP server and skills for deploying applications on vibetocloud",
+  "bin": {
+    "vibetocloud-mcp": "./dist/index.js"
+  },
+  "files": [
+    "dist/",
+    "skills/"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "devDependencies": {
+    "@modelcontextprotocol/sdk": "^1.0.0",
+    "esbuild": "^0.28.0",
+    "express": "^4.21.2",
+    "@vibetocloud/shared": "1.0.0"
+  },
+  "scripts": {
+    "dev": "pnpm -w exec tsx apps/mcp-server/src/index.ts",
+    "dev:http": "pnpm -w exec tsx apps/mcp-server/src/index.ts http",
+    "build": "pnpm -w exec nest build mcp-server && node scripts/generate-mcp-json.mjs",
+    "build:npm": "node apps/mcp-server/scripts/bundle.mjs",
+    "lint": "pnpm -w exec eslint apps/mcp-server libs/shared"
+  }
+}

package/skills/.claude-plugin/marketplace.json

@@ -0,0 +1,15 @@
+{
+  "name": "vibetocloud",
+  "description": "vibetocloud platform skills for Claude Code",
+  "owner": {
+    "name": "vibetocloud"
+  },
+  "plugins": [
+    {
+      "name": "vibetocloud",
+      "description": "Deploy and debug applications on the vibetocloud platform from Claude Code.",
+      "version": "1.0.0",
+      "source": "./"
+    }
+  ]
+}

package/skills/.claude-plugin/plugin.json

@@ -0,0 +1,11 @@
+{
+  "name": "vibetocloud",
+  "description": "Deploy and debug applications on the vibetocloud platform from Claude Code.",
+  "version": "1.0.0",
+  "mcpServers": {
+    "vibetocloud": {
+      "command": "npx",
+      "args": ["-y", "@vibetocloud/mcp"]
+    }
+  }
+}

package/skills/README.md

@@ -0,0 +1,47 @@
+# Vibetocloud Claude Code Plugin
+
+Claude Code skills for deploying and debugging applications on the vibetocloud platform.
+
+## Skills
+
+| Command | Purpose |
+|---|---|
+| `/vibetocloud-onboard` | Authenticate, set up git remote, scaffold docker-compose.yml, configure secrets, and push code |
+| `/vibetocloud-deploy` | Push latest code, trigger a deployment, and poll until done |
+| `/vibetocloud-debug` | Inspect running services and tail logs |
+| `/vibetocloud-platform-logs` | Open an SSH tunnel to the platform host and view Grafana logs |
+
+## Installation
+
+Run this once to install the plugin (MCP server + skills):
+
+```bash
+npx @vibetocloud/mcp setup
+```
+
+Then restart Claude Code. The slash commands and vibetocloud tools will be available in any project.
+
+The plugin manifest declares the MCP server, so a single `claude plugin install` registers everything. To remove it all again:
+
+```bash
+claude plugin uninstall vibetocloud
+```
+
+## Typical workflow
+
+```
+# First time: onboard your project
+/vibetocloud-onboard
+
+# Every time you want to deploy
+/vibetocloud-deploy
+
+# When something breaks
+/vibetocloud-debug
+```
+
+## State
+
+Skills share state via `.vibetocloud/config.json` in your project root. This file is added to `.gitignore` automatically by the onboard skill — it contains your session token and should never be committed.
+
+To re-authenticate or switch environments, run `/vibetocloud-onboard` again.

package/skills/skills/vibetocloud-debug/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: vibetocloud-debug
+description: Inspect running services and tail logs to diagnose issues on vibetocloud.
+---
+
+# Vibetocloud Debug
+
+Announce at start: "I'm using vibetocloud-debug to inspect your application."
+
+---
+
+## Step 1 — Load config
+
+Read `.vibetocloud/config.json` using the Read tool.
+
+If the file does not exist or any of `token`, `appId`, `orgId` are empty, stop and tell the user:
+"Run `/vibetocloud-onboard` first to set up your project."
+
+Verify the token is still valid by calling `org_authenticate` with:
+```json
+{ "token": "<token>" }
+```
+If it fails, tell the user: "Your session has expired. Run `/vibetocloud-onboard` to sign in again."
+
+---
+
+## Step 2 — Service overview
+
+Call `app_services_list` with:
+```json
+{
+  "token": "<token>",
+  "applicationId": "<appId>",
+  "environment": "<environment>"
+}
+```
+
+Display the result as a table:
+
+```
+Service       Status    CPU      Memory    Uptime
+──────────────────────────────────────────────────
+api           running   2.1%     128 MB    2h 14m
+worker        stopped   —        —         —
+```
+
+If no services are returned, tell the user: "No services are running in this environment. Try deploying first with `/vibetocloud-deploy`."
+
+---
+
+## Step 3 — Select service
+
+If there is only one service, proceed with it automatically.
+
+If there are multiple services, ask: "Which service would you like to debug? (<list service names>)"
+
+---
+
+## Step 4 — Tail logs
+
+Call `app_service_tail_logs` with:
+```json
+{
+  "token": "<token>",
+  "applicationId": "<appId>",
+  "environment": "<environment>",
+  "service": "<selected service name>"
+}
+```
+
+The response contains `{ lines: string[], nextSince: number }`. Display all lines. Note the `nextSince` value.
+
+Ask the user: "Continue tailing new lines? (yes / no)"
+
+If **yes**: call `app_service_tail_logs` again with the same parameters plus `"since": <nextSince>`. Display any new lines. Update `nextSince`. Repeat until the user says no.
+
+If **no**: proceed to Step 5.
+
+---
+
+## Step 5 — Service actions
+
+Offer the following options:
+
+1. **Restart this service** — call `app_service_restart` with:
+   ```json
+   {
+     "token": "<token>",
+     "applicationId": "<appId>",
+     "environment": "<environment>",
+     "service": "<selected service name>"
+   }
+   ```
+   After restarting, return to Step 2 to show updated service status.
+
+2. **Debug a different service** — return to Step 3.
+
+3. **Exit** — done.

package/skills/skills/vibetocloud-deploy/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: vibetocloud-deploy
+description: Push latest code to vibetocloud, trigger a deployment, and poll until success or failure.
+---
+
+# Vibetocloud Deploy
+
+Announce at start: "I'm using vibetocloud-deploy to deploy your application."
+
+---
+
+## Step 1 — Load config
+
+Read `.vibetocloud/config.json` using the Read tool.
+
+If the file does not exist or any of `token`, `appId`, `orgId` are empty, stop and tell the user:
+"Run `/vibetocloud-onboard` first to set up your project."
+
+**Token freshness check:**
+
+Decode the JWT payload to check expiry: split the token by `.`, take the second segment, base64-decode it (pad with `=` to make the length a multiple of 4 if needed), and parse as JSON. Read the `exp` field (Unix timestamp in seconds).
+
+If `exp - (Date.now() / 1000) < 3600` (less than 1 hour remaining):
+1. Call `org_refresh_token` with `{ "token": "<current token>" }`.
+2. If successful: update `token` in `.vibetocloud/config.json` with the new token and use it for all subsequent calls.
+3. If it fails: warn the user — "Could not refresh your session token. If API calls fail with an auth error, run `/vibetocloud-onboard` to sign in again."
+
+If more than 1 hour remains, or if the token cannot be decoded, proceed without refreshing.
+
+Do **not** call `org_authenticate` here. The token will be validated by the first real API call; if it is expired the call will return an error, at which point tell the user: "Your session has expired. Run `/vibetocloud-onboard` to sign in again."
+
+---
+
+## Step 2 — Confirm environment
+
+Use the AskUserQuestion tool with options `["dev", "staging", "production"]` to ask:
+"Which environment would you like to deploy to?" (pre-select the value from config).
+
+If the selected environment differs from config, update `environment` in `.vibetocloud/config.json`.
+
+---
+
+## Step 3 — Push latest code
+
+Get the current branch:
+```bash
+git rev-parse --abbrev-ref HEAD
+```
+
+Push to the platform remote (use `remote` from config, defaulting to `origin` if the field is empty):
+```bash
+git push <remote> <current branch>
+```
+
+If the push fails, report the error and stop — do not trigger a deploy with stale code.
+
+---
+
+## Step 4 — Trigger deployment
+
+Call `org_deploy` with:
+```json
+{
+  "token": "<token>",
+  "applicationId": "<appId>",
+  "environment": "<environment>",
+  "branch": "<current branch>"
+}
+```
+
+The response contains `{ id: "<buildId>", ... }`.
+
+Tell the user: "Deployment started (build ID: <buildId>). Polling for status…"
+
+---
+
+## Step 5 — Poll status
+
+Call `org_deploy_status` every 15 seconds with:
+```json
+{ "token": "<token>", "buildId": "<buildId>" }
+```
+
+The response `data.status` is one of: `pending` | `running` | `success` | `failed` | `cancelled`.
+
+Show the `data.message` field from each response so the user sees live step progress.
+
+Continue polling until status is `success`, `failed`, or `cancelled`.
+
+> **Build stall:** if the platform reports "EC2 deploy stalled" in the failure reason, the build produced no output for 10 minutes. This usually means a package install or large Docker layer download is hanging. Check your Dockerfile for slow `RUN` commands and consider layer caching improvements (e.g. copy `package.json` and run `npm install` before copying the rest of the source).
+
+---
+
+## Step 6 — Report outcome
+
+**On `success`:**
+
+Call `app_services_list` with:
+```json
+{
+  "token": "<token>",
+  "applicationId": "<appId>",
+  "environment": "<environment>"
+}
+```
+
+Display a summary of running services (serviceName, status, instanceCount). Tell the user: "✅ Deployment successful. Your application is live."
+
+**On `failed`:**
+
+Find the failed step in `data.steps` (the step where `status === "failed"`). Display:
+
+```
+❌ Deployment failed at step: <step name>
+```
+
+If the failed step has a `failureReason`, display it in full:
+
+```
+Failure reason:
+<failureReason>
+```
+
+The `failureReason` for the "Deploying your application" step contains the `docker compose up --build` output. Read it carefully and help the user understand what went wrong:
+
+- **Image build error** (e.g. `COPY` path not found, `RUN` command failed, package not found): tell the user which line in their `Dockerfile` is causing the failure and suggest a fix.
+- **Container start failure** (e.g. port already in use, missing environment variable, crash on startup): explain the cause and ask if they want to add missing secrets or adjust `docker-compose.yml`.
+- **Image pull failure** (e.g. private registry, image not found): remind the user that vibetocloud builds from source — the `image:` key must reference a public image or use `build: .` with a local Dockerfile.
+- **SSM agent never started** (`failureReason` contains "SSM agent never started"): tell the user "The deployment agent on your instance never started — this is a platform issue, not your code. Try re-deploying; if it persists, contact support."
+- **Build stalled** (`failureReason` contains "EC2 deploy stalled" and "no build output"): tell the user "The build ran but stalled — likely a slow package install or large layer download. Consider: (1) adding `node_modules` to `.dockerignore`; (2) ordering `COPY package.json` + `RUN npm install` before `COPY . .` in your Dockerfile to maximise layer cache hits."
+- **Health check failure** (failed step name contains "health" or "live"): the platform performs `GET /` on your app's public URL and expects HTTP 2xx or 3xx within 2 minutes. A 404 at the root path is treated as an application error — ensure your app serves a response at `/` in production mode. If `NODE_ENV=production` is not set, many frameworks disable their default routes. Suggest running `/vibetocloud-onboard` to check and set `NODE_ENV`.
+
+After explaining the failure, use the AskUserQuestion tool with options `["Yes — help me fix it", "No — I'll investigate myself"]` to ask: "Would you like me to help fix the issue now?"
+
+If yes: read the relevant file (`Dockerfile`, `docker-compose.yml`, or a source file), propose a fix, and tell the user to run `/vibetocloud-deploy` again once the fix is applied.
+
+If no, or the failure does not match the above categories: tell the user: "Run `/vibetocloud-debug` to tail live logs and diagnose further."
+
+**On `cancelled`:**
+
+Tell the user: "Deployment was cancelled."