pipebrain-mcp 0.21.0 → 0.22.0

package/dist/main.js

@@ -15640,6 +15640,12 @@ var setStatusInputSchema = external_exports.strictObject({
   issue: issueRefSchema,
   status: issueStatusSchema
 });
+var getWorkContextInputSchema = external_exports.strictObject({
+  issue: issueRefSchema.optional(),
+  project: projectRefSchema.optional()
+}).refine((v) => v.issue === void 0 !== (v.project === void 0), {
+  message: "pass exactly one of `issue` or `project` \u2014 an issue names its own project, and passing neither names nothing to read"
+});
 var claimInputSchema = external_exports.strictObject({
   issue: issueRefSchema
 });
@@ -16563,6 +16569,22 @@ var ApiClient = class _ApiClient {
     const query = filter?.mine === true ? { mine: "1" } : void 0;
     return this.requestList("GET", "/api/v1/waiting", { query });
   }
+  // --- the working-context pack ----------------------------------------------
+  /**
+   * Everything a session needs before it starts work, in ONE read (PIPE-86): the
+   * item, the documents that bind it AT THE REVISION IT WAS SPECIFIED AGAINST, the
+   * project's cross-cutting requirements and the release being worked — or, given a
+   * project, the work available to pick up instead.
+   *
+   * ONE method for two routes because they are two forms of one pack, decided by
+   * which of `issue`/`project` is named — exactly one of them, as
+   * `getWorkContextInputSchema` requires. The API assembles the pack and this computes
+   * nothing of its own, so the browser, the command line and the agent read the same
+   * answer.
+   */
+  getWorkContext(input) {
+    return input.issue !== void 0 ? this.request("GET", `/api/v1/issues/${enc(input.issue)}/work-context`) : this.request("GET", `/api/v1/projects/${enc(input.project)}/work-context`);
+  }
   // --- secrets ---------------------------------------------------------------
   // Metadata only: no method here returns a secret VALUE (the reveal plane is a
   // separate surface). Every response type is a `*View` with no `value` field.
@@ -16960,6 +16982,15 @@ Every loose end has one destination, and none of them is prose. Anything you not
     // makes that comparable at a glance.
     run(async () => ({ items: await client2.listWaiting() }))
   ));
+  registerTool("get_work_context", {
+    description: "Everything a session needs before it starts work, in ONE read \u2014 assembled by the API and returned verbatim. Addressed by `issue` OR by `project`, never both and never neither: an issue names its own project, so the pair is refused rather than resolved for you (\xA77). Given an ISSUE: that issue\u2019s full detail \u2014 the same payload `get_issue` returns \u2014 PLUS the BODY TEXT of every requirement it links, AT THE REVISION THE LINK IS PINNED AT. That text is the round trip this removes: `get_issue` names which documents bind the work and at which revision, never what they SAY, so a session that has read the issue still owes one fetch per link \u2014 and the one it skips leaves it building against rules it never read. Comments come CAPPED at the newest `commentLimit`, with `commentCount` \u2014 the issue\u2019s TRUE total \u2014 beside them, so a shortened list reads AS shortened rather than as the whole history; read the issue directly for the rest. Given a PROJECT: `available`, the work a session could START right now. It EXCLUDES finished and abandoned work (`done`, `killed`), work another person has claimed, and anything blocked \u2014 the status guard would refuse to start that, and offering work that cannot be started is offering a refusal. Your OWN claims stay, and so does unscheduled work carrying no milestone. The item form carries no `available`; the project form carries no item. BOTH forms also carry the project half: the release currently being worked (the active milestone) and the project\u2019s cross-cutting requirements WITH their text \u2014 they bind every epic automatically, and each is otherwise a separate call a session can simply forget to make. READ-ONLY \u2014 this claims nothing, moves nothing and writes nothing.",
+    // The WHOLE domain schema rather than its `.shape`: the exactly-one-of rule is a
+    // refinement on the OBJECT, and a raw shape drops it — the SDK validates against
+    // what it is handed, so the shape alone would quietly accept both arguments and
+    // neither. Handing it the schema lets its refusal reach the caller verbatim,
+    // naming the two arguments it refused rather than a reworded stand-in.
+    inputSchema: getWorkContextInputSchema
+  }, (args) => run(() => client2.getWorkContext(args)));
   registerTool("create_milestone", {
     description: "Create a milestone on a project. `token` is the short ref issues point at via their `milestone` field (e.g. `M1`) and is unique per project (a duplicate is rejected); `label` is its display name (e.g. `Feature Verification`). Optional `position` orders it (0-based, defaults to last); optional `active` marks it the current milestone \u2014 AT MOST ONE milestone per project is active, so `active: true` transactionally DEMOTES the previously active one rather than failing. Returns the created milestone (\xA77).",
     inputSchema: {
@@ -17376,7 +17407,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.21.0";
+var VERSION = "0.22.0";
 
 // src/main.ts
 var config2 = loadMcpConfig();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pipebrain-mcp",
-  "version": "0.21.0",
+  "version": "0.22.0",
   "description": "Pipebrain MCP server for Claude Code and Claude Desktop — issues, requirements, content, assets, and metadata-only secrets over the Pipebrain API.",
   "type": "module",
   "license": "MIT",