@awesomate/hosting-mcp 0.26.0 → 0.27.0

package/dist/index.js

@@ -40969,6 +40969,7 @@ var TITLES = {
   awesomate_app_scaffold: "Get app scaffold guide",
   awesomate_app_deploy_info: "Get app deploy briefing",
   awesomate_app_health: "Check app health",
+  awesomate_app_run_state: "Start or stop an app environment",
   awesomate_app_set_env: "Set app secret",
   awesomate_app_provision_db: "Add database to app",
   awesomate_n8n_workflows: "List n8n workflows",
@@ -41803,6 +41804,27 @@ server.registerTool(
     }
   }
 );
+server.registerTool(
+  "awesomate_app_run_state",
+  {
+    annotations: annotate("awesomate_app_run_state", MUTATING),
+    description: "Start or stop ONE environment of a Node app (its pm2 process). Use `stopped` to turn off a dev or staging environment the user has finished with. This frees process capacity on their hosting account, which is a real constraint: the account has a fixed number of processes it can run at once, and idle environments can starve the account's own websites. Use `running` to bring one back before you build or test on it. Stopping deletes NOTHING: code, database and address all stay, and starting again takes seconds. PRODUCTION CANNOT BE STOPPED (400 `prod_not_stoppable`); it is the address the user's customers reach. A 409 `run_state_failed` on a start means the account has no spare capacity, and the response carries nprocUsed/nprocLimit; tell the user which environment to stop rather than retrying. Static sites have no process (400 `static_app`). Requires apps:write (Support Plus+). Good habit: start dev before a build session, stop it after.",
+    inputSchema: {
+      appId: external_exports.number().int().positive().describe("The app id from awesomate_app_list / _get"),
+      env: external_exports.enum(["dev", "staging", "prod"]).describe("Which environment to act on"),
+      desiredState: external_exports.enum(["running", "stopped"]).describe("'stopped' frees capacity; 'running' starts it again")
+    }
+  },
+  async ({ appId, env, desiredState }) => {
+    try {
+      return textResult(
+        await hubPost(requireConfig(), `/api/my-apps/apps/${appId}/envs/${env}/run-state`, { desiredState })
+      );
+    } catch (err) {
+      return errorResult(err);
+    }
+  }
+);
 server.registerTool(
   "awesomate_n8n_provision_pg",
   {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awesomate/hosting-mcp",
-  "version": "0.26.0",
+  "version": "0.27.0",
   "description": "Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases",
   "license": "UNLICENSED",
   "type": "module",

package/skill/awesomate-app-builder/SKILL.md

@@ -140,6 +140,14 @@ target; never touch prod without an explicit ask.**
    addresses from `awesomate_app_get` rather than constructing them — an
    account without the branded domains falls back to subdomains of its own
    primary domain (`dev-{app}.{domain}`).
+   **If dev is stopped, start it before you deploy to it.** `awesomate_app_get`
+   reports each environment's `desired_state`. A stopped environment is off to
+   free capacity on the account, not broken. `awesomate_app_run_state` with
+   `running` brings it back in seconds, and a health probe against a stopped
+   env fails for that reason and no other. **Offer to stop it again when the
+   session's work is done**: the account can only run a limited number of app
+   processes at once, so an idle dev environment is capacity taken from
+   something the user actually needs. Never stop `prod`; the tool refuses it.
    **Publishing to their WordPress site** (as opposed to an app) has its own
    tools, and `awesomate_run_wp_cli` is the wrong one for content: its
    argument gate rejects spaces outright, so a title or tagline can't go