@smartytalent/mcp-tools 0.9.35 → 0.9.37

package/dist/tools.json

@@ -166,20 +166,24 @@
                   "type": "object",
                   "properties": {
                     "ad": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. Ads and their images are built for every recruitment process; `enabled` never gated anything, `generateImages` is always on (the env kill switch AD_IMAGE_GENERATION remains), `platforms` were never read (the platform lists are fixed in code). Removed in a later, breaking release together with settings.feedback; declared until then because the generated model whitelists keys."
                     },
                     "brand": {
                       "type": "object",
                       "description": "Brand rules the ad and careers generators read. Split by who can\nact on what: exact colours are applied by CODE (an image model\nonly ever approximates a hex), while the look-and-feel strings\nare fed to the image prompt. Keys: primaryColor / secondaryColor\n(^#[0-9a-fA-F]{6}$), photography, avoid, tone. Freeform for now;\na dedicated brand service is the endgame once logo variants,\ntypefaces and versioning arrive."
                     },
                     "conversation": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. The AI interview is part of the recruitment process (settings.automation on the job); `jobInterview.enabled` never had a reader. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "report": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. Reports run for EVERY active tenant (daily, weekly, monthly) and are downloaded in the report app (showReport meta.pdf); e-mail delivery is gone (a per-user preference is a later phase), so `emails` and `period` gate nothing. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "email": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. `domains` (trusted e-mail domains) never had a reader - inbound trust comes from the user registry and SPF/DKIM alignment. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "operation": {
                       "type": "object",
@@ -188,7 +192,7 @@
                     "feedback": {
                       "title": "TenantAttributesSettingsFeedbackSchema",
                       "type": "object",
-                      "description": "Organisation-wide switch for outbound candidate feedback. Absent = enabled. enabled=false makes feedback:resolve return enabled=false with reason disabled:tenant BEFORE any policy lookup; default and per-job feedback rows stay stored and come back to life when re-enabled. Explicitly validated: enabled must be a JSON boolean (a string is a 400). NOTE: the generated model whitelists keys, so this property MUST be declared for the SDK to carry it. Since the automation switches (2026-09-24) this is the legacy kill switch; the three-state default is settings.automation.feedback.",
+                      "description": "DEPRECATED (2026-09-24, S.K.: settings.automation.feedback is the ONE control of feedback; this field will be removed in a later, breaking release). Organisation-wide legacy switch for outbound candidate feedback: absent = enabled; enabled=false makes feedback:resolve return enabled=false with reason disabled:tenant ONLY while settings.automation.feedback is absent on both the job and the tenant - once the new key is set at either level this field is ignored; default and per-job feedback rows stay stored. Explicitly validated: enabled must be a JSON boolean (a string is a 400). NOTE: the generated model whitelists keys, so this property MUST stay declared until the removal release.",
                       "properties": {
                         "enabled": {
                           "type": "boolean"
@@ -738,20 +742,24 @@
                   "type": "object",
                   "properties": {
                     "ad": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. Ads and their images are built for every recruitment process; `enabled` never gated anything, `generateImages` is always on (the env kill switch AD_IMAGE_GENERATION remains), `platforms` were never read (the platform lists are fixed in code). Removed in a later, breaking release together with settings.feedback; declared until then because the generated model whitelists keys."
                     },
                     "brand": {
                       "type": "object",
                       "description": "Brand rules the ad and careers generators read. Split by who can\nact on what: exact colours are applied by CODE (an image model\nonly ever approximates a hex), while the look-and-feel strings\nare fed to the image prompt. Keys: primaryColor / secondaryColor\n(^#[0-9a-fA-F]{6}$), photography, avoid, tone. Freeform for now;\na dedicated brand service is the endgame once logo variants,\ntypefaces and versioning arrive."
                     },
                     "conversation": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. The AI interview is part of the recruitment process (settings.automation on the job); `jobInterview.enabled` never had a reader. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "report": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. Reports run for EVERY active tenant (daily, weekly, monthly) and are downloaded in the report app (showReport meta.pdf); e-mail delivery is gone (a per-user preference is a later phase), so `emails` and `period` gate nothing. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "email": {
-                      "type": "object"
+                      "type": "object",
+                      "description": "DEPRECATED (2026-09-24, S.K., PLAN_TENANT_SETTINGS_CLEANUP): ignored by the backend and stripped on write. `domains` (trusted e-mail domains) never had a reader - inbound trust comes from the user registry and SPF/DKIM alignment. Removed in a later, breaking release; declared until then because the generated model whitelists keys."
                     },
                     "operation": {
                       "type": "object",
@@ -760,7 +768,7 @@
                     "feedback": {
                       "title": "TenantAttributesSettingsFeedbackSchema",
                       "type": "object",
-                      "description": "Organisation-wide switch for outbound candidate feedback. Absent = enabled. enabled=false makes feedback:resolve return enabled=false with reason disabled:tenant BEFORE any policy lookup; default and per-job feedback rows stay stored and come back to life when re-enabled. Explicitly validated: enabled must be a JSON boolean (a string is a 400). NOTE: the generated model whitelists keys, so this property MUST be declared for the SDK to carry it. Since the automation switches (2026-09-24) this is the legacy kill switch; the three-state default is settings.automation.feedback.",
+                      "description": "DEPRECATED (2026-09-24, S.K.: settings.automation.feedback is the ONE control of feedback; this field will be removed in a later, breaking release). Organisation-wide legacy switch for outbound candidate feedback: absent = enabled; enabled=false makes feedback:resolve return enabled=false with reason disabled:tenant ONLY while settings.automation.feedback is absent on both the job and the tenant - once the new key is set at either level this field is ignored; default and per-job feedback rows stay stored. Explicitly validated: enabled must be a JSON boolean (a string is a 400). NOTE: the generated model whitelists keys, so this property MUST stay declared until the removal release.",
                       "properties": {
                         "enabled": {
                           "type": "boolean"
@@ -5397,7 +5405,7 @@
                     "feedback": {
                       "title": "JobAttributesSettingsFeedbackSchema",
                       "type": "object",
-                      "description": "Per-job switch for outbound candidate feedback. Absent = enabled. enabled=false makes feedback:resolve return enabled=false with reason disabled:job for candidates of this job, before the job override / tenant default lookup. The tenant-level switch (tenant.settings.feedback.enabled) wins over this one. Explicitly validated: enabled must be a JSON boolean. Since the automation switches (2026-09-24) this is the legacy kill switch; the three-state control is settings.automation.feedback.",
+                      "description": "DEPRECATED (2026-09-24, S.K.: settings.automation.feedback is the ONE control of feedback; this field will be removed in a later, breaking release). Per-job legacy switch for outbound candidate feedback: absent = enabled; enabled=false makes feedback:resolve return enabled=false with reason disabled:job ONLY while settings.automation.feedback is absent on both the job and the tenant - once the new key is set at either level this field is ignored. Between the two legacy switches the tenant's wins. Explicitly validated: enabled must be a JSON boolean.",
                       "properties": {
                         "enabled": {
                           "type": "boolean"
@@ -5407,7 +5415,7 @@
                     "automation": {
                       "title": "JobAttributesSettingsAutomationSchema",
                       "type": "object",
-                      "description": "Per-job automation switches (PLAN_PROCESS_AUTOMATION, 2026-09-24): who runs each stage of THIS recruitment process. Values per key: auto = Boe runs the stage, manual = a human runs it (Boe leaves a task on the RecOps board and waits), off = the stage is not part of this process (the candidate moves on). Every key is optional: absent = the organisation's default (tenant.settings.automation), else the platform default (sourcing manual, everything else auto); the job overrides the tenant in BOTH directions. Read by the automation:resolve action at the head of the candidate-facing workflows and by feedback:resolve (feedback). PATCH merges this block PER KEY (send one switch at a time; a key sent as null clears the override). Writable only by sysowner / owner / admin / recops - any other role gets 403 on a payload that carries it, on POST and PATCH. Validated in code: interview and offer accept auto|manual, surveys accepts auto|off, the rest auto|manual|off; an unknown key or value is a 400 naming it. The legacy settings.feedback.enabled=false (job or tenant) still disables feedback with kill-switch precedence. The job build (Create Job From Brief) never generates this block: it keeps the row's values and seeds `off` for the stages the manager declared out of the process in the intake (brief.intakeContext.process).",
+                      "description": "Per-job automation switches (PLAN_PROCESS_AUTOMATION, 2026-09-24): who runs each stage of THIS recruitment process. Values per key: auto = Boe runs the stage, manual = a human runs it (Boe leaves a task on the RecOps board and waits), off = the stage is not part of this process (the candidate moves on). Every key is optional: absent = the organisation's default (tenant.settings.automation), else the platform default (sourcing manual, everything else auto); the job overrides the tenant in BOTH directions. Read by the automation:resolve action at the head of the candidate-facing workflows and by feedback:resolve (feedback). PATCH merges this block PER KEY (send one switch at a time; a key sent as null clears the override). Writable only by sysowner / owner / admin / recops - any other role gets 403 on a payload that carries it, on POST and PATCH. Validated in code: interview and offer accept auto|manual, surveys accepts auto|off, the rest auto|manual|off; an unknown key or value is a 400 naming it. `feedback` here is the ONE control of feedback e-mails (S.K. 2026-09-24): the deprecated settings.feedback.enabled counts only while this key is absent on both the job and the tenant. The job build (Create Job From Brief) never generates this block: it keeps the row's values and seeds `off` for the stages the manager declared out of the process in the intake (brief.intakeContext.process).",
                       "properties": {
                         "sourcing": {
                           "type": "string",
@@ -6297,7 +6305,7 @@
                     "feedback": {
                       "title": "JobAttributesSettingsFeedbackSchema",
                       "type": "object",
-                      "description": "Per-job switch for outbound candidate feedback. Absent = enabled. enabled=false makes feedback:resolve return enabled=false with reason disabled:job for candidates of this job, before the job override / tenant default lookup. The tenant-level switch (tenant.settings.feedback.enabled) wins over this one. Explicitly validated: enabled must be a JSON boolean. Since the automation switches (2026-09-24) this is the legacy kill switch; the three-state control is settings.automation.feedback.",
+                      "description": "DEPRECATED (2026-09-24, S.K.: settings.automation.feedback is the ONE control of feedback; this field will be removed in a later, breaking release). Per-job legacy switch for outbound candidate feedback: absent = enabled; enabled=false makes feedback:resolve return enabled=false with reason disabled:job ONLY while settings.automation.feedback is absent on both the job and the tenant - once the new key is set at either level this field is ignored. Between the two legacy switches the tenant's wins. Explicitly validated: enabled must be a JSON boolean.",
                       "properties": {
                         "enabled": {
                           "type": "boolean"
@@ -6307,7 +6315,7 @@
                     "automation": {
                       "title": "JobAttributesSettingsAutomationSchema",
                       "type": "object",
-                      "description": "Per-job automation switches (PLAN_PROCESS_AUTOMATION, 2026-09-24): who runs each stage of THIS recruitment process. Values per key: auto = Boe runs the stage, manual = a human runs it (Boe leaves a task on the RecOps board and waits), off = the stage is not part of this process (the candidate moves on). Every key is optional: absent = the organisation's default (tenant.settings.automation), else the platform default (sourcing manual, everything else auto); the job overrides the tenant in BOTH directions. Read by the automation:resolve action at the head of the candidate-facing workflows and by feedback:resolve (feedback). PATCH merges this block PER KEY (send one switch at a time; a key sent as null clears the override). Writable only by sysowner / owner / admin / recops - any other role gets 403 on a payload that carries it, on POST and PATCH. Validated in code: interview and offer accept auto|manual, surveys accepts auto|off, the rest auto|manual|off; an unknown key or value is a 400 naming it. The legacy settings.feedback.enabled=false (job or tenant) still disables feedback with kill-switch precedence. The job build (Create Job From Brief) never generates this block: it keeps the row's values and seeds `off` for the stages the manager declared out of the process in the intake (brief.intakeContext.process).",
+                      "description": "Per-job automation switches (PLAN_PROCESS_AUTOMATION, 2026-09-24): who runs each stage of THIS recruitment process. Values per key: auto = Boe runs the stage, manual = a human runs it (Boe leaves a task on the RecOps board and waits), off = the stage is not part of this process (the candidate moves on). Every key is optional: absent = the organisation's default (tenant.settings.automation), else the platform default (sourcing manual, everything else auto); the job overrides the tenant in BOTH directions. Read by the automation:resolve action at the head of the candidate-facing workflows and by feedback:resolve (feedback). PATCH merges this block PER KEY (send one switch at a time; a key sent as null clears the override). Writable only by sysowner / owner / admin / recops - any other role gets 403 on a payload that carries it, on POST and PATCH. Validated in code: interview and offer accept auto|manual, surveys accepts auto|off, the rest auto|manual|off; an unknown key or value is a 400 naming it. `feedback` here is the ONE control of feedback e-mails (S.K. 2026-09-24): the deprecated settings.feedback.enabled counts only while this key is absent on both the job and the tenant. The job build (Create Job From Brief) never generates this block: it keeps the row's values and seeds `off` for the stages the manager declared out of the process in the intake (brief.intakeContext.process).",
                       "properties": {
                         "sourcing": {
                           "type": "string",
@@ -22466,12 +22474,23 @@
       "properties": {
         "filterStatus": {
           "type": "string",
-          "description": "Returns reports with the current status (active, archived). If not provided, the default value will be set to 'active'.",
+          "description": "Returns reports with the given status. Pass it explicitly - the backend applies NO default, so without it pending and failed rows come back too. The report app's history query is `filterStatus=active&sort=-created&pageNumber=1` (newest first): the sort is honoured next to filterStatus ONLY with page-number pagination (`pageNumber`); the cursor pagination (`pageAfter` / `pageBefore`, the default without pageNumber) keeps the index order and ignores `sort` (measured on dev03 2026-09-24). One filter at a time: the backend serves a single index per request.",
           "enum": [
             "active",
-            "archived"
+            "inactive",
+            "pending",
+            "archived",
+            "failed"
           ]
         },
+        "filterResourceId": {
+          "type": "string",
+          "description": "Returns the reports of ONE resource (a job id, or the tenant id for the scheduled tenant reports). Served from the ResourceIndex in index order: `sort` is IGNORED next to it, and it cannot be combined with filterStatus or the created/modified window (one filter at a time). For the tenant history use `filterStatus=active&sort=-created` instead and read `resourceType` / `period` off the rows."
+        },
+        "sort": {
+          "type": "string",
+          "description": "`created` / `-created` / `modified` / `-modified`. Honoured alone (any pagination) and next to filterStatus with page-number pagination only (`pageNumber`; the cursor pagination ignores it there); ignored next to filterResourceId (index order); the date windows keep their own index order."
+        },
         "filterCreatedFrom": {
           "type": "string",
           "description": "Filters results to include only those created from the specified date and time. The value must be in ISO 8601 format."
@@ -22546,7 +22565,7 @@
               "properties": {
                 "resourceId": {
                   "type": "string",
-                  "description": "Identifier of the resource this report is associated with (job ID or tenant ID)"
+                  "description": "Identifier of the resource this report is associated with: the tenant id for the scheduled tenant reports (resourceType tenants), a job id for a job report. On the wire since 2026-09-24 (it was stored but not returned)."
                 },
                 "resourceType": {
                   "type": "string",
@@ -22568,12 +22587,14 @@
                   ]
                 },
                 "reportContent": {
-                  "type": "string",
-                  "description": "Merged analytics and AI analysis content"
+                  "type": "object",
+                  "additionalProperties": true,
+                  "description": "Merged analytics and AI analysis content, an OBJECT (declared as a string until 2026-09-24): keyed by locale for a non-English tenant (`en-US` + the tenant language, each holding the sections kpis / alerts / notes / insights / dailyData / topJobs / ...), the sections directly at the top level for an en-US tenant; `{}` while the row is pending."
                 },
                 "settings": {
-                  "type": "string",
-                  "description": "Report configuration including email recipients and period preferences"
+                  "type": "object",
+                  "additionalProperties": true,
+                  "description": "The analysis window the broker stamps at creation, an OBJECT (declared as a string until 2026-09-24): startDate, endDate (naive calendar stamps `YYYY-MM-DD HH:MM:SS`), reportPeriod, displayName and the period's own fields (day / month / year, isoWeek / isoYear / dateRange, monthName / daysCount). Since 2026-09-24 (PLAN_TENANT_SETTINGS_CLEANUP) no `emails`: reports are downloaded in the report app, not mailed."
                 },
                 "shortCode": {
                   "type": "string",
@@ -22595,8 +22616,9 @@
                   ]
                 },
                 "ttl": {
-                  "type": "string",
-                  "description": "Time-to-live value for automatic report expiration"
+                  "type": "integer",
+                  "format": "int64",
+                  "description": "Epoch seconds at which DynamoDB expires the row (an INTEGER, declared as a string until 2026-09-24): created + 400 days on every scheduled report since 2026-09-24; null on rows born before that."
                 },
                 "timestamps": {
                   "title": "ResourceTimestampsSchema",
@@ -22713,7 +22735,7 @@
               "properties": {
                 "resourceId": {
                   "type": "string",
-                  "description": "Identifier of the resource this report is associated with (job ID or tenant ID)"
+                  "description": "Identifier of the resource this report is associated with: the tenant id for the scheduled tenant reports (resourceType tenants), a job id for a job report. On the wire since 2026-09-24 (it was stored but not returned)."
                 },
                 "resourceType": {
                   "type": "string",
@@ -22735,12 +22757,14 @@
                   ]
                 },
                 "reportContent": {
-                  "type": "string",
-                  "description": "Merged analytics and AI analysis content"
+                  "type": "object",
+                  "additionalProperties": true,
+                  "description": "Merged analytics and AI analysis content, an OBJECT (declared as a string until 2026-09-24): keyed by locale for a non-English tenant (`en-US` + the tenant language, each holding the sections kpis / alerts / notes / insights / dailyData / topJobs / ...), the sections directly at the top level for an en-US tenant; `{}` while the row is pending."
                 },
                 "settings": {
-                  "type": "string",
-                  "description": "Report configuration including email recipients and period preferences"
+                  "type": "object",
+                  "additionalProperties": true,
+                  "description": "The analysis window the broker stamps at creation, an OBJECT (declared as a string until 2026-09-24): startDate, endDate (naive calendar stamps `YYYY-MM-DD HH:MM:SS`), reportPeriod, displayName and the period's own fields (day / month / year, isoWeek / isoYear / dateRange, monthName / daysCount). Since 2026-09-24 (PLAN_TENANT_SETTINGS_CLEANUP) no `emails`: reports are downloaded in the report app, not mailed."
                 },
                 "shortCode": {
                   "type": "string",
@@ -22762,8 +22786,9 @@
                   ]
                 },
                 "ttl": {
-                  "type": "string",
-                  "description": "Time-to-live value for automatic report expiration"
+                  "type": "integer",
+                  "format": "int64",
+                  "description": "Epoch seconds at which DynamoDB expires the row (an INTEGER, declared as a string until 2026-09-24): created + 400 days on every scheduled report since 2026-09-24; null on rows born before that."
                 },
                 "timestamps": {
                   "title": "ResourceTimestampsSchema",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@smartytalent/mcp-tools",
-  "version": "0.9.35",
+  "version": "0.9.37",
   "description": "MCP tool definitions for SmartyTalent API",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",