comfyui-mcp 0.52.87 → 0.52.89

package/dist/orchestrator/panel-tools.js

@@ -1001,6 +1001,7 @@ const RETRY_SAFE_CMDS = new Set([
     "graph_query",
     "get_todo",
     "workflow_list",
+    "nodes_search",
     "nodes_list",
     "nodes_queue_status",
     "node_queue_status",
@@ -4949,6 +4950,7 @@ const QUERY_GRAPH_MAX_CHARS_DEFAULT = 12000;
 const QUERY_GRAPH_MAX_CHARS_CEILING = 60000;
 const DETAIL_WIDGET_MAX_CHARS_DEFAULT = 2048;
 const DETAIL_WIDGET_MAX_CHARS_CEILING = 32768;
+const QUERY_GRAPH_WIDGET_MAX_CHARS_NOTE = "widget_max_chars_note";
 /** The panel's own clamp for graph_query's budget, mirrored so the figure this module
  *  reports and enforces is the one the panel was actually working to. */
 function clampQueryGraphMaxChars(v) {
@@ -4957,6 +4959,49 @@ function clampQueryGraphMaxChars(v) {
         return QUERY_GRAPH_MAX_CHARS_DEFAULT;
     return Math.min(Math.max(Math.floor(n), QUERY_GRAPH_MAX_CHARS_FLOOR), QUERY_GRAPH_MAX_CHARS_CEILING);
 }
+/**
+ * `widget_max_chars` is deliberately a pinpoint-only escape hatch. Keep the
+ * precondition at the MCP seam as well as in the Panel serializer: older Panel
+ * builds silently ignored the argument, and broad reads must never accidentally
+ * trade away the query's token bound for one large widget.
+ */
+function widgetMaxCharsRequest(args) {
+    const requested = args.widget_max_chars;
+    if (typeof requested !== "number")
+        return {};
+    if (args.fields !== "detail") {
+        return {
+            note: `widget_max_chars=${requested} was not applied: it is accepted only with ` +
+                `fields:"detail" and exactly one explicit ids entry; this query used ` +
+                `${args.fields === undefined ? "an omitted fields projection" : `fields:"${String(args.fields)}"`}. ` +
+                `The default ${DETAIL_WIDGET_MAX_CHARS_DEFAULT}-char per-widget cap remains in force.`,
+        };
+    }
+    if (!Array.isArray(args.ids) || args.ids.length !== 1) {
+        return {
+            note: `widget_max_chars=${requested} was not applied: it is accepted only with ` +
+                `fields:"detail" and exactly one explicit ids entry; this query supplied ` +
+                `${Array.isArray(args.ids) ? `${args.ids.length} ids` : "no explicit ids"}. ` +
+                `The default ${DETAIL_WIDGET_MAX_CHARS_DEFAULT}-char per-widget cap remains in force.`,
+        };
+    }
+    return { value: requested };
+}
+/** A legacy Panel can accept the command but still serialize at its old cap. */
+function legacyWidgetMaxCharsNote(res, requested) {
+    if (typeof requested !== "number" || requested <= DETAIL_WIDGET_MAX_CHARS_DEFAULT)
+        return undefined;
+    const text = res.content
+        .filter((block) => block.type === "text")
+        .map((block) => (block.type === "text" ? block.text : ""))
+        .join("\n");
+    if (!/2048-char per-widget cap/.test(text))
+        return undefined;
+    return (`widget_max_chars=${requested} was not applied: the connected Panel returned its ` +
+        `default ${DETAIL_WIDGET_MAX_CHARS_DEFAULT}-char per-widget cap. Update the Panel ` +
+        `to a build that supports graph_query.widget_max_chars, then retry this exact ` +
+        `detail read; the query result below is otherwise unchanged.`);
+}
 /** The reply fields that are CONTEXT rather than answer. `viewing` is deliberately not
  *  one of them: it identifies which graph the answer describes, it is a couple of small
  *  fields, and a reply that cannot say what it is about is worse than a bigger one. */
@@ -4971,6 +5016,7 @@ const QUERY_GRAPH_RIDER_KEYS = [
  *  (independent gate P0). `max_chars` is re-set unconditionally just below. */
 const QUERY_GRAPH_OWNED_KEYS = new Set([
     "max_chars",
+    QUERY_GRAPH_WIDGET_MAX_CHARS_NOTE,
     "groups_membership_omitted",
     "groups_omitted",
     "rails_omitted",
@@ -5017,7 +5063,7 @@ function groupIndexEntry(g) {
  * than silently ignored — `max_chars` bounds characters, and calling image bytes
  * characters would be its own false figure.
  */
-function fitQueryGraphReply(res, requested) {
+function fitQueryGraphReply(res, requested, widgetMaxCharsNote) {
     const payload = parseToolResultJson(res);
     if (!payload)
         return res;
@@ -5064,6 +5110,8 @@ function fitQueryGraphReply(res, requested) {
     // trustworthy, and a caller who learns to distrust it will ignore the real ones. This
     // accounting is the sole author of these fields, so it is also their sole source.
     answer.max_chars = budget;
+    if (widgetMaxCharsNote)
+        answer[QUERY_GRAPH_WIDGET_MAX_CHARS_NOTE] = widgetMaxCharsNote;
     const groups = Array.isArray(riders.groups) ? riders.groups : null;
     const hasGroups = !!groups && groups.length > 0;
     const hasRails = riders.rails !== undefined;
@@ -11979,7 +12027,7 @@ export function buildPanelToolDefs() {
     // Local helper so each def reads like the original `tool(...)` call.
     const def = (name, description, schema, handler) => ({ name, description, schema, handler });
     const defs = [
-        def("panel_query_graph", "FILTER or TRAVERSE a SUBSET of the live canvas, for when you ALREADY KNOW what you're looking for. NOT for 'show me the canvas' or any whole-graph overview — call panel_graph_outline FIRST for that. NOT get_workflow's query action (that queries a saved file or JSON you provide, not the live canvas). Filters, traverses, projects and aggregates over the workflow the user is CURRENTLY VIEWING without dumping the whole graph (replaces the old panel_get_graph full-JSON dump; output is TOKEN-BOUNDED with an explicit truncation marker, so a big graph can never flood your context). Combine: `types` (node type contains any), `title` (contains), `where` widget predicates ANDed ('cfg>7', 'steps<=20', 'sampler_name=euler', 'text~sunset' — ops = != >= <= > < ~contains), `ids` (exact nodes — THE way to read ONE node's exact slot/widget detail: {ids:[42], fields:'detail'}), `upstream_of`/`downstream_of` + `depth` (dependency traversal: upstream = what FEEDS that node, downstream = what CONSUMES it; seed at depth 0), `fields` ('compact' one line per node [default], 'ids', 'detail' = the full node summary with slots + connections + mode), `group_by:'type'` (counts only), `limit` (default 40). detail rows include each node's MODE — a 'bypass' node is skipped and a 'mute' node kills everything downstream, so check modes on the path you care about before running (fix with panel_set_node_mode). Every result also carries `groups` (id, title, member node_ids — groups are geometric, trust this list) and, when viewing a SUBGRAPH (after panel_enter_subgraph), `rails` (boundary rail ids/slots). `max_chars` bounds the WHOLE result, those riders included, and the rows you asked for are spent first: on a big graph the riders lose their member ids, then drop out entirely, rather than starving your query — and each says in-band when it did, with the true counts. `widget_max_chars` raises the per-widget cap only for `fields:'detail'`; use it only with exactly one explicit `ids` entry (for example `{ids:[42], fields:'detail', widget_max_chars:8192}`), with a default of 2048 and a maximum of 32768. It does not change compact, ids, or broad reads. Typical flow: panel_graph_outline to orient → panel_query_graph to pinpoint/inspect → edit. Read-only.", {
+        def("panel_query_graph", "FILTER or TRAVERSE a SUBSET of the live canvas, for when you ALREADY KNOW what you're looking for. NOT for 'show me the canvas' or any whole-graph overview — call panel_graph_outline FIRST for that. NOT get_workflow's query action (that queries a saved file or JSON you provide, not the live canvas). Filters, traverses, projects and aggregates over the workflow the user is CURRENTLY VIEWING without dumping the whole graph (replaces the old panel_get_graph full-JSON dump; output is TOKEN-BOUNDED with an explicit truncation marker, so a big graph can never flood your context). Combine: `types` (node type contains any), `title` (contains), `where` widget predicates ANDed ('cfg>7', 'steps<=20', 'sampler_name=euler', 'text~sunset' — ops = != >= <= > < ~contains), `ids` (exact nodes — THE way to read ONE node's exact slot/widget detail: {ids:[42], fields:'detail'}), `upstream_of`/`downstream_of` + `depth` (dependency traversal: upstream = what FEEDS that node, downstream = what CONSUMES it; seed at depth 0), `fields` ('compact' one line per node [default], 'ids', 'detail' = the full node summary with slots + connections + mode), `group_by:'type'` (counts only), `limit` (default 40). detail rows include each node's MODE — a 'bypass' node is skipped and a 'mute' node kills everything downstream, so check modes on the path you care about before running (fix with panel_set_node_mode). Every result also carries `groups` (id, title, member node_ids — groups are geometric, trust this list) and, when viewing a SUBGRAPH (after panel_enter_subgraph), `rails` (boundary rail ids/slots). `max_chars` bounds the WHOLE result, those riders included, and the rows you asked for are spent first: on a big graph the riders lose their member ids, then drop out entirely, rather than starving your query — and each says in-band when it did, with the true counts. `widget_max_chars` raises the per-widget cap only for `fields:'detail'`; use it only with exactly one explicit `ids` entry (for example `{ids:[42], fields:'detail', widget_max_chars:8192}`), with a default of 2048 and a maximum of 32768. If supplied without those preconditions, it is not sent and the result says why; a legacy Panel that still returns the default cap is named in the result. It does not change compact, ids, or broad reads. Typical flow: panel_graph_outline to orient → panel_query_graph to pinpoint/inspect → edit. Read-only.", {
             types: z.array(z.string()).optional().describe("Node type contains ANY of these (case-insensitive)."),
             title: z.string().optional().describe("Node title contains this."),
             where: z
@@ -12030,21 +12078,27 @@ export function buildPanelToolDefs() {
         // The panel bounds `text`; the `groups`/`rails` riders were never in that
         // accounting, so on a large graph the reply could be many times the budget it
         // announced. Nothing is shed while the whole reply fits.
-        async (args, ctx) => fitQueryGraphReply(await ctx.call({
-            cmd: "graph_query",
-            types: args.types,
-            title: args.title,
-            where: args.where,
-            ids: args.ids,
-            upstream_of: args.upstream_of,
-            downstream_of: args.downstream_of,
-            depth: args.depth,
-            fields: args.fields,
-            group_by: args.group_by,
-            limit: args.limit,
-            max_chars: args.max_chars,
-            widget_max_chars: args.widget_max_chars,
-        }), args.max_chars)),
+        async (args, ctx) => {
+            const widgetMaxChars = widgetMaxCharsRequest(args);
+            const panelReply = await ctx.call({
+                cmd: "graph_query",
+                types: args.types,
+                title: args.title,
+                where: args.where,
+                ids: args.ids,
+                upstream_of: args.upstream_of,
+                downstream_of: args.downstream_of,
+                depth: args.depth,
+                fields: args.fields,
+                group_by: args.group_by,
+                limit: args.limit,
+                max_chars: args.max_chars,
+                ...(widgetMaxChars.value === undefined
+                    ? {}
+                    : { widget_max_chars: widgetMaxChars.value }),
+            });
+            return fitQueryGraphReply(panelReply, args.max_chars, widgetMaxChars.note ?? legacyWidgetMaxCharsNote(panelReply, widgetMaxChars.value));
+        }),
         def("panel_graph_outline", "READ THE LIVE CANVAS the user is looking at, as text. 'Show me what's on the canvas' / 'what's on the graph right now' / 'read the current workflow' / 'describe the open graph' -> THIS TOOL, with no arguments. NOT visualize_workflow (it DRAWS A DIAGRAM of a workflow you PASS IN — a saved file or JSON — and never sees the live canvas). NOT panel_query_graph (that FILTERS a SUBSET, for when you already know what you're looking for). Returns one `outline` string covering the WHOLE open graph, topologically sorted (sources first, sinks last): each node as `id Type \"title\" [bypass/mute] [OUTPUT] · group:X  widget=value …` with `← inputs` (source_node.output_name) and `→ outputs` (target_node.input_name), after a GROUPS index (title → member node ids). It gives you the WIRING you would otherwise reconstruct by hand — read it FIRST to get oriented, then panel_query_graph to inspect one node ({ids:[42], fields:'detail'}) or panel_find_nodes for free-text search. Over `max_chars` it never cuts the graph short: it sheds per-node detail, or refuses with a reason — never a partial outline. Read-only.", {
             max_chars: z
                 .number()