@pmoses-s1/s1-secops-mcp 1.3.7 → 1.3.8

package/README.md

@@ -73,7 +73,7 @@ Add this to `claude_desktop_config.json` (or `.mcp.json` for Claude Code):
   "mcpServers": {
     "s1-secops-mcp": {
       "command": "npx",
-      "args": ["-y", "@pmoses-s1/s1-secops-mcp@1.3.7"],
+      "args": ["-y", "@pmoses-s1/s1-secops-mcp@1.3.8"],
       "env": {
         "S1_CONSOLE_URL":       "https://usea1-yourorg.sentinelone.net",
         "S1_CONSOLE_API_TOKEN": "eyJ...",

package/deploy/README.md

@@ -57,7 +57,7 @@ Or, equivalently, by package name without the install:
   "mcpServers": {
     "s1-secops-mcp": {
       "command": "npx",
-      "args": ["-y", "@pmoses-s1/s1-secops-mcp@1.3.7"]
+      "args": ["-y", "@pmoses-s1/s1-secops-mcp@1.3.8"]
     }
   }
 }
@@ -376,7 +376,7 @@ Both block the W+X memory mappings V8 needs to JIT JavaScript. Adding them cause
 
 These are supported but not first-class:
 
-- **Docker / docker-compose.** Not shipped in this version. The single-file Node binary doesn't need it. If you want a container, the install is `FROM node:20-alpine` + `RUN npm install -g @pmoses-s1/s1-secops-mcp@1.3.7` + `CMD ["s1-secops-mcp", "--transport", "http", "--host", "0.0.0.0"]`. Mount creds at `/etc/s1-secops-mcp/credentials.json` and tokens at `/etc/s1-secops-mcp/bearer-tokens.json`.
+- **Docker / docker-compose.** Not shipped in this version. The single-file Node binary doesn't need it. If you want a container, the install is `FROM node:20-alpine` + `RUN npm install -g @pmoses-s1/s1-secops-mcp@1.3.8` + `CMD ["s1-secops-mcp", "--transport", "http", "--host", "0.0.0.0"]`. Mount creds at `/etc/s1-secops-mcp/credentials.json` and tokens at `/etc/s1-secops-mcp/bearer-tokens.json`.
 
 - **External bridge (`supergateway`, `mcp-proxy`).** Pre-1.1.0 deployments used these to wrap the stdio-only server. They still work; this server's native HTTP mode is functionally equivalent and removes the extra process. Prefer native unless you have a specific reason.
 

package/lib/s1.js

@@ -643,21 +643,18 @@ export async function uamSetStatus(alertId, status) {
   }
   if (action.failure?.length) {
     const f = action.failure[0];
-    // errorMessage says WHAT failed, not WHY. `Missing UAM manage permissions`
-    // is also what a not-offered action returns: alerts ingested via the UAM
-    // Alert Interface (/v1/alerts) expose only addNote and eventSearch, while
-    // the same token sets status on a native alert successfully (measured).
-    // So ask alertAvailableActions before reporting a cause, and never let the
-    // caller conclude "the token lacks permission" from the string alone.
+    // errorMessage names the failure, not the cause. Ask alertAvailableActions,
+    // which is filtered by the caller's permissions AND the alert type.
     let hint = '';
     try {
       const avail = await uamAvailableActions(alertId);
       const ids = avail.map((a) => a.id);
       if (!ids.includes('S1/alert/statusUpdate')) {
-        hint = ' | alertAvailableActions: statusUpdate is NOT OFFERED for this '
-             + `alert type (available: ${ids.join(', ') || 'none'}). This is a `
-             + 'capability limit of the alert, not a token scope; a new token '
-             + 'will not help.';
+        hint = ' | alertAvailableActions: statusUpdate is NOT OFFERED to this '
+             + `caller for this alert (available: ${ids.join(', ') || 'none'}). `
+             + 'Availability is filtered by the caller\'s permissions and the '
+             + 'alert type: check the service user\'s UAM permissions. A '
+             + 'console user session may still be able to perform it.';
       } else {
         const a = avail.find((x) => x.id === 'S1/alert/statusUpdate');
         hint = a?.isDisabled

package/lib/server-core.js

@@ -94,7 +94,7 @@ const PROMPTS = [
 
 export const SERVER_INFO = {
   name: 's1-secops-mcp-server',
-  version: '1.3.7',
+  version: '1.3.8',
 };
 
 export const PROTOCOL_VERSION = '2024-11-05';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pmoses-s1/s1-secops-mcp",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "MCP server orchestrating SentinelOne skills, APIs, and SOC analyst context. Stdio or Streamable HTTP transport with per-user bearer auth for team deployments.",
   "type": "module",
   "main": "index.js",

package/tools/mgmt-console.js

@@ -346,7 +346,7 @@ export const tools = [
   // ─── uam_available_actions ────────────────────────────────────────────────
   {
     name: 'uam_available_actions',
-    description: `Ask the API which actions can be triggered on a UAM alert, with isDisabled and disabledReason per action. This is the authoritative capability answer and the ONLY correct way to explain a refused write. A refused action returns errorMessage "Missing UAM manage permissions" whether the token lacks a scope OR the action is simply not offered for that alert type, and those need opposite responses. Measured on one tenant with one token: an alert ingested via the UAM Alert Interface (/v1/alerts) offers only S1/alert/addNote and S1/alert/eventSearch, so uam_set_status can never work on it and no token change helps; a native STAR / third-party / correlation alert offers S1/alert/statusUpdate and S1/alert/analystVerdictUpdate and the same token applies them successfully. Call this before concluding anything about permissions, and before a bulk write you cannot undo. Availability is also scope-sensitive: the S1/incident/* actions report INCIDENT_ACTIONS_ONLY_AVAILABLE_FROM_SITE_VIEW under ACCOUNT scope and are enabled under SITE, so pass scopeIds/scopeType when you care about a site-scoped action. Read-only.`,
+    description: `Ask the API which actions can be triggered on a UAM alert, with isDisabled and disabledReason per action. This is the authoritative capability answer and the ONLY correct way to explain a refused write. Availability is filtered by the caller's permissions AND the alert type: one service-user token is offered S1/alert/statusUpdate on a native STAR alert and not on an alert ingested via the UAM Alert Interface (/v1/alerts), where only S1/alert/addNote and S1/alert/eventSearch are listed, while a console user session performs the identical mutation on either. So an action missing here means this identity lacks the permission for this alert type, not that it is impossible: check the service user's UAM permissions. Call this before concluding anything about permissions, and before a bulk write you cannot undo. Availability is also scope-sensitive: the S1/incident/* actions report INCIDENT_ACTIONS_ONLY_AVAILABLE_FROM_SITE_VIEW under ACCOUNT scope and are enabled under SITE, so pass scopeIds/scopeType when you care about a site-scoped action. Read-only.`,
     inputSchema: {
       type: 'object',
       properties: {