jujugrowth-mcp 1.0.9 → 1.2.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jujugrowth-mcp",
-  "version": "1.0.9",
-  "description": "MCP server connecting your AI coding assistant (Claude, Cursor, Codex) to jujugrowth — pull recommendations and apply them in your repo.",
+  "version": "1.2.0",
+  "description": "MCP server connecting your AI coding assistant (Claude, Cursor, Codex) to jujugrowth — pull your living marketing plan's dev tasks + recommendations and apply them in your repo.",
   "type": "module",
   "bin": {
     "jujugrowth-mcp": "server.mjs"

package/server.mjs

@@ -71,6 +71,44 @@ const TOOLS = [
         `/recommendations${a.tenantId ? `?tenantId=${encodeURIComponent(a.tenantId)}` : ""}`,
       ),
   },
+  {
+    name: "list_plan_tasks",
+    description:
+      "List the dev-AI tasks from this site's LIVING MARKETING PLAN — the roadmap steps the plan assigned to the developer AI (changes to the business's own site/app/code; jujugrowth executes the 'autonomous' marketing steps itself). Each task has a ready-to-run `prompt`, plus why it matters, its priority, and the plan's north-star + strategy for context. This is your growth to-do list for the business: pull it, implement the highest-priority tasks in the repo (verify current state first; show a diff/PR), and the next plan regeneration reflects what you shipped via its evidence-grounded status. Pass `tenantId` to target a site; if more than one is connected and you omit it you get {needsSite:true,...} — ASK the user which site, then call again. Never pick a site for them.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        tenantId: {
+          type: "string",
+          description: "the site (optional; required when more than one site is connected)",
+        },
+      },
+      additionalProperties: false,
+    },
+    run: async (a) =>
+      call("GET", `/plan-tasks${a.tenantId ? `?tenantId=${encodeURIComponent(a.tenantId)}` : ""}`),
+  },
+  {
+    name: "mark_plan_task_handled",
+    description:
+      "Report a marketing-plan dev-AI task DONE after you've shipped it in the repo. Pass the task's `action` (exactly as returned by list_plan_tasks) and a short `note` of what you changed. jujugrowth records it and the next plan regeneration marks that step done (and stops listing it). ALWAYS call this once a plan task is implemented — it's how the plan knows the work happened. Pass `tenantId` if your token spans more than one site.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        tenantId: { type: "string", description: "the site (required only for multi-site tokens)" },
+        action: { type: "string", description: "the task's action text, exactly as listed" },
+        note: { type: "string", description: "1-3 sentences: what you implemented" },
+      },
+      required: ["action"],
+      additionalProperties: false,
+    },
+    run: async (a) =>
+      call("POST", "/plan-tasks/handled", {
+        action: a.action,
+        ...(a.tenantId ? { tenantId: a.tenantId } : {}),
+        ...(a.note ? { note: a.note } : {}),
+      }),
+  },
   {
     name: "get_recommendation",
     description:
@@ -146,13 +184,16 @@ async function handle(msg) {
         // Workflow the AI should follow unprompted (so the human never has to
         // say "now mark it handled"). Surfaced to the model by MCP clients.
         instructions:
-          `This server provides growth recommendations for ${SITE_LABEL ? `the site "${SITE_LABEL}"` : "the user's site(s)"} and connects them to your code work. Standard loop:\n` +
-          "1) list_recommendations.\n" +
-          "2) get_recommendation for one you'll act on.\n" +
-          "3) Before changing anything, VERIFY the brief's current-state claims against the actual code — they can be stale; skip what's already done.\n" +
-          "4) Implement in the user's repo, scoped to wording/structure/SEO. Never change checkout, auth, or analytics events. Show a diff / open a PR for the user to review.\n" +
-          "5) ALWAYS call mark_recommendation_handled with a short note of what you changed once it's shipped — don't wait to be told.\n" +
-          "Skip GA4-console toggles and business-judgment items — flag those for the user instead of editing code. Campaigns and ad budgets are NOT here — those are owner decisions in the jujugrowth web UI. This server is bound to ONE site; never act on another.",
+          `This server connects ${SITE_LABEL ? `the site "${SITE_LABEL}"` : "the user's site(s)"} growth work to your coding. Two task sources:\n` +
+          "• list_plan_tasks — the dev-AI steps of the business's LIVING MARKETING PLAN (the strategic roadmap). Start here: these are the prioritized site/app/code changes the growth plan needs (each has a ready-to-run prompt + the north-star for context).\n" +
+          "• list_recommendations — individual one-off growth recommendations.\n" +
+          "Standard loop:\n" +
+          "1) list_plan_tasks (and/or list_recommendations).\n" +
+          "2) get_recommendation for any rec you'll act on.\n" +
+          "3) Before changing anything, VERIFY current-state claims against the actual code — they can be stale; skip what's already done.\n" +
+          "4) Implement in the user's repo, scoped to wording/structure/SEO/tracking the plan asks for. Show a diff / open a PR for the user to review.\n" +
+          "5) ALWAYS report completion once shipped, don't wait to be told: mark_recommendation_handled for a recommendation, or mark_plan_task_handled (with the task's action + a note) for a plan task — that's how the plan learns the work happened and marks the step done.\n" +
+          "Campaigns and ad budgets are NOT here — those are owner decisions the jujugrowth system runs itself. This server is bound to ONE site; never act on another.",
       },
     });
   }