node-autotask 0.18.0 → 0.20.0

package/MCP_TOOL_CATALOG.json

@@ -1,7 +1,7 @@
 {
   "generatedBy": "scripts/build-tool-catalog.mjs",
-  "generatedAt": "2026-10-19T05:26:26.501Z",
-  "planHash": "5176d37fc9bae34139c151ae0ea8336dab63a30382f04acbcaed0e24cdd71d5f",
+  "generatedAt": "2026-10-20T01:49:50.366Z",
+  "planHash": "f6a579e0b7a8544f6e477a730d21a9ba031536392d8dbaeb2f73c61ca290ae91",
   "metaTools": [
     {
       "name": "autotask_catalog",
@@ -9891,7 +9891,7 @@
     {
       "operation": "time_entries.dateWorkedWindow",
       "tool": "autotask_timeEntry_date_worked_window",
-      "purpose": "The clearer-named alias for time_entries.postedWithin (issue #66): the dateWorked window read with the posted/unposted split, counted in one pass — same wire, same result (incl. truncated).",
+      "purpose": "The unambiguous-named alias for time_entries.postedWithin (issue #66): the dateWorked window read with the posted/unposted split, counted in one pass — same wire, same result (incl. truncated). The window is ON dateWorked (entries worked within [from, to]); \"postedWithin\" keeps its historical name (its \"posted\" is the posted/unposted split over the returned rows, never a posted-date window).",
       "preferredWhen": null,
       "backingOperation": "time_entries.dateWorkedWindow",
       "effect": "read",
@@ -10170,7 +10170,7 @@
     {
       "operation": "time_entries.postedWithin",
       "tool": "autotask_timeEntry_posted_within",
-      "purpose": "Get time entries worked within an inclusive dateWorked window with the posted/unposted split, counted in one pass (the window is ON the dateWorked field — the posted narrowing is a server-side postedDate exist|notExist predicate; the counts cover the returned rows only, truncated flags the capped window).",
+      "purpose": "Get time entries WORKED within an inclusive dateWorked window with the posted/unposted split, counted in one pass. The window is ON the dateWorked field — the name's \"posted\" is the posted/unposted SPLIT counted over the returned rows (the server-side postedDate exist|notExist predicate), never a posted-date window: no postedDate window op exists (the vendored TimeEntryModel declares no postedDate filter, and ww29-class zones 500 on postedDate filters ONLY WHEN the `posted` narrowing is set — omit `posted` on such zones — W-D3). The counts cover the returned rows only; truncated flags the capped window. time_entries.dateWorkedWindow is the unambiguous name.",
       "preferredWhen": null,
       "backingOperation": "time_entries.postedWithin",
       "effect": "read",
@@ -20634,7 +20634,7 @@
     {
       "operation": "tickets.search",
       "tool": "autotask_ticket_search",
-      "purpose": "Search ticket records by text (contains on the searchable fields).",
+      "purpose": "Search ticket records by text (a vendor contains filter on title only — the vendor exposes no free-text search and no matched-field reporting).",
       "preferredWhen": null,
       "backingOperation": "tickets.search",
       "effect": "read",
@@ -20725,7 +20725,7 @@
     {
       "operation": "operations.aggregate",
       "tool": "autotask_aggregate",
-      "purpose": "Fold any query surface into groups/sums/totals in one bounded call — or count it with the vendor count endpoint when no folding is needed — with blind-surface and truncation honesty; date fields bucket via the closed groupBy suffix <field>@month | @week | @year (ISO labels, UTC-anchored)",
+      "purpose": "Fold any query surface into groups/sums/totals in one bounded call — or count it with the vendor count endpoint when no folding is needed — with blind-surface and truncation honesty (caps documented: the walk scans at most 2500 rows and top keeps at most 100 groups — a truncated aggregate is a PARTIAL answer, never a tenant-wide total); date fields bucket via the closed groupBy suffix <field>@month | @week | @year (ISO labels, UTC-anchored)",
       "preferredWhen": "For existence checks and totals over any queryable table (count mode is one call vs a 50k-char page); group-by/sum folds the vendor has no endpoint for; a targeted read is cheaper when you need the rows",
       "backingOperation": "operations.aggregate",
       "effect": "read",