@aioproductoscom/mcp 0.9.0 → 0.11.0

package/dist/client.js

@@ -61,6 +61,12 @@ export class PlatformClient {
         const qs = productId ? `?product_id=${encodeURIComponent(productId)}` : "";
         return this.req(`/api/me/brain${qs}`);
     }
+    captureInsight(body) {
+        return this.req("/api/me/insight", { method: "POST", body: JSON.stringify(body) });
+    }
+    customer360(query) {
+        return this.req(`/api/me/customer?q=${encodeURIComponent(query)}`);
+    }
     funnel(opts) {
         const p = new URLSearchParams();
         if (opts.productId)

package/dist/index.js

@@ -3,6 +3,7 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { z } from "zod";
 import { PlatformClient } from "./client.js";
+import { PM_PLAYBOOK, PM_SKILL_VERSION } from "./pm-skill.js";
 const token = process.env.PRODUCTOS_TOKEN;
 const baseUrl = (process.env.PRODUCTOS_URL ?? "https://platform.aioproductos.com").replace(/\/$/, "");
 if (!token) {
@@ -17,15 +18,16 @@ function text(data) {
         ],
     };
 }
-const server = new McpServer({ name: "productos", version: "0.9.0" }, {
-    instructions: "You manage ProductOS PM tickets on behalf of the connected member — the board is the team's " +
-        "source of truth, so work precisely. Resolve names to ids with pm_meta before create_task / " +
-        "update_task; never guess an id. Link a task to the spine (feature_id / insight_id) whenever the " +
-        "context makes the connection real, so the work traces back to the why. Keep titles and " +
-        "descriptions concrete and scoped. Confirm what you changed in plain language, and claim only " +
-        "writes you actually made.",
+const server = new McpServer({ name: "productos", version: "0.11.0" }, {
+    instructions: "You manage product work on ProductOS for the connected member — board, insights, features, and " +
+        "analytics all hang off one spine. Call get_pm_playbook first for how to operate: ground in " +
+        "get_product_brain, keep work tied to the spine (insight→feature→task→outcome), and prioritize on " +
+        "evidence (affected accounts + MRR + reach), never an invented score. Resolve names to ids with " +
+        "pm_meta before create_task / update_task; never guess an id. Confirm what you changed in plain " +
+        "language, and claim only writes you actually made.",
 });
 server.tool("whoami", "Show the connected ProductOS identity (org, member).", {}, async () => text(await client.whoami()));
+server.tool("get_pm_playbook", "How to operate as a product manager on ProductOS — ground in the brain, keep work tied to the spine (insight→feature→task→outcome), and prioritize on evidence (affected accounts + MRR + reach), never an invented score. Read this before planning or prioritizing.", {}, async () => text(`${PM_PLAYBOOK}\n\n— pm playbook v${PM_SKILL_VERSION}`));
 server.tool("pm_meta", "List the org's PM lists, statuses, members, and features — use to resolve names to ids before create/update.", {}, async () => text(await client.meta()));
 server.tool("list_tasks", "List tasks in the org. Optional filters: status_id, list_id.", { status_id: z.string().optional(), list_id: z.string().optional() }, async (a) => text(await client.listTasks(a)));
 server.tool("get_task", "Get one task with its comments and assignees.", { id: z.string() }, async (a) => text(await client.getTask(a.id)));
@@ -51,6 +53,15 @@ server.tool("update_task", "Update a task's fields (status, priority, title, des
 }, async ({ id, ...body }) => text(await client.updateTask(id, body)));
 server.tool("comment_on_task", "Add a comment to a task.", { id: z.string(), body: z.string() }, async (a) => text(await client.comment(a.id, a.body)));
 server.tool("get_product_brain", "Read a grounded, read-only snapshot of the org's product so YOU can reason about it on your own model: revenue + top paying accounts, web + product analytics, features, recent verbatim customer signals, and open work. Optional product_id; omit for the primary product. Returns the brain text plus the list of products you can ask about.", { product_id: z.string().optional() }, async (a) => text(await client.brain(a.product_id)));
+server.tool("get_customer_360", "Everything about ONE customer, resolved by id, email, domain, or company name: profile, subscription + MRR, how many users sit under the account, and their verbatim feedback. The money + people + voice join on one record — use it before answering anything about a specific account.", { query: z.string() }, async (a) => text(await client.customer360(a.query)));
+server.tool("capture_insight", "Write a piece of customer feedback to the spine (the agent's own hand, not just reading). It fires the same insight.created webhook a manual capture does. Tie it to the account it's about (account_id) and the feature it concerns (feature_id) when you know them; kind='opportunity' for a prioritizable ask. Defaults to the primary product.", {
+    body: z.string(),
+    title: z.string().optional(),
+    kind: z.enum(["insight", "opportunity"]).optional(),
+    product_id: z.string().optional(),
+    feature_id: z.string().optional(),
+    account_id: z.string().optional(),
+}, async (a) => text(await client.captureInsight(a)));
 server.tool("analyze_funnel", "Build a conversion funnel from the product's own events and reason over it on your model. Pass `steps` as an ordered list of event names (2+) to compute the funnel: distinct users per step, conversion, and drop-off. Omit `steps` to get the menu of available event names first. Optional product_id (defaults to the primary product) and window_days (default 30).", {
     steps: z.array(z.string()).optional(),
     product_id: z.string().optional(),

package/dist/pm-skill.js

@@ -0,0 +1,40 @@
+// The PM operating playbook — OUR product logic, handed to the customer's PM-side
+// agent via get_pm_playbook() so it works like a great PM grounded in ProductOS,
+// not a generic ticket bot. The server's `instructions` points at it; the agent
+// pulls the full doctrine on demand (keeps it out of every session's context).
+//
+// Bump PM_SKILL_VERSION on any behavioural change so a run traces to a playbook.
+export const PM_SKILL_VERSION = "0.1.0";
+export const PM_PLAYBOOK = `# ProductOS · Product Manager
+
+You operate the product on ProductOS for the connected member. The board, insights, features, and
+analytics all hang off one spine — your job is to keep work tied to the real why and to decide from evidence.
+
+## Ground yourself first
+Call \`get_product_brain\` before you reason about priorities: a live, read-only snapshot of THIS product —
+revenue and top accounts, web + product analytics, features, recent verbatim customer signals, and the open
+work. Decide from it, not from memory. Use \`pm_meta\` to resolve names → ids before any write; never guess an id.
+
+## The spine logic — keep everything connected
+Customer signal (insight) → the bet (feature) → the work (task) → the result (outcome). Don't create orphans:
+- A task that exists because a customer asked → link its \`insight_id\`. Because it serves a bet → link its \`feature_id\`.
+- When you capture feedback, tie it to the account and the feature it's about, in the customer's own words —
+  a specific verbatim beats your paraphrase.
+- Work with no why is the thing to question, not to dutifully schedule.
+
+## Prioritize on evidence — never on a score you invented
+This org has its OWN prioritization framework (RICE, ICE, MoSCoW, WSJF, value/effort, Kano — whatever they set).
+Do NOT assume one, and do NOT compute the score yourself. Attach the EVIDENCE and let their framework do the math:
+- Which accounts are affected, and the MRR behind them (the revenue weight).
+- The reach/usage from analytics (\`analyze_funnel\`, \`get_retention\`, \`analyze_paths\`, the brain).
+- The customer signals that back it.
+Hand work off as an opportunity with that evidence attached — a human (or their configured model) does the ranking.
+You ground the call; you never fake the number.
+
+## Decide from data, not vibes
+Before you assert a priority or a problem, pull the number — funnel drop, retention curve, the path users take,
+the MRR behind a segment — and quote it. "Signups drop 38% on the company-size field" beats "the form feels long".
+
+## Output discipline
+Concise and honest. Confirm only the writes you actually made, in plain language. Resolve ids via \`pm_meta\`.
+Keep titles and descriptions concrete and scoped — a task a teammate can pick up cold.`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aioproductoscom/mcp",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "ProductOS MCP — manage tickets, read your product brain + analytics, and run the support inbox from Claude Code, Cursor, Codex, and any MCP host.",
   "type": "module",
   "license": "MIT",