docs: follow bounded MCP lists and strict tenant arguments

skills/ns-advanced-memory-leak-hunter/SKILL.md

@@ -8,7 +8,7 @@ This skill reads N|Solid data through the N|Solid MCP server (`nsolid`) and bund
 
 ### Phase 0: Reuse Evidence and Resolve Target
 1. If the user already supplied both baseline and peak evidence (asset IDs or local files), skip straight to Phase 4.
-2. The N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names. Pass it to every call, and set `NSOLID_TENANT` for the scripts.
+2. Most N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names. Pass the same tenant to every tenant-scoped call, and set `NSOLID_TENANT` for the scripts.
 3. If no `agentId` is supplied, call `fleet_snapshot` with `where: 'app == "<appName>"'` and `sort: "used_heap_size"` to find the process; keep the exact `appName` for downloads. Stop if no matching process is connected.
 4. A leak can sit in a worker thread while the main thread looks fine: `list_threads` with the `agentId` shows each thread's heap. Capture the thread that grows (`threadId`).
 

skills/ns-analyze-asset/SKILL.md

@@ -11,7 +11,7 @@ This skill reads assets through the N|Solid MCP server (`nsolid`) and bundled sc
 When the user asks to restore a deleted profile or snapshot, pick the tenant (step 1), then go straight to [Restoring a Deleted Asset](#restoring-a-deleted-asset) instead of steps 2–10. Every other request follows the steps below.
 
 ### 1. Pick the Tenant
-- The N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names. Pass the same tenant to every call, and set `NSOLID_TENANT` for the scripts.
+- Most N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names. Pass the same tenant to every tenant-scoped call, and set `NSOLID_TENANT` for the scripts.
 
 ### 2. Identify the Asset
 - The user should provide an asset ID or an app name with asset type.

skills/ns-analyze-behaviors/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Investigates what N|Solid's behavioral watch found: npm packages that newly run programs, compile code, use the network, start threads or touch the file system in production, packages that start running at all, release regressions and dependency drift. Use when the user asks about supply-chain attacks at run time, a compromised or suspicious dependency, what a package started doing, a behavior alert, or dependencies that changed without a release.
 ---
 
-This skill works through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names.
+This skill works through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names.
 
 The watch learns what each app's packages do from its CPU profiles, and reports a package doing something it never did before in that app, once the app has a history without it.
 

skills/ns-analyze-event/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Investigates an existing N|Solid event or N|Solid alert and correlates the relevant evidence from N|Solid. Use when the user provides or references an event or alert such as a blocked event loop, a process exit or crash, an uncaught exception, a new vulnerability, a new package behavior, a stack trace, or span data. Also use when the user asks why an agent dropped, disconnected or reconnected, even without a specific event or alert. Routes follow-up to CPU, memory, vulnerability, or tracing workflows when needed.
 ---
 
-This skill reads N|Solid data through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the event or user names.
+This skill reads N|Solid data through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the event or user names.
 
 **No event, just a drop or reconnect.** When the user asks why an app or process dropped, disconnected or reconnected without giving an event or alert, skip parsing: resolve the app or process they name with `find_agents` to get its actual `agentId` (ask only for the missing app or process when they named neither), then go straight to **Lifecycle** in step 2. Use the time window they gave for `list_events`, or say which recent window you used (such as `-1h`) when they gave none; `agent_sessions` takes no `from`/`to`.
 

skills/ns-analyze-logs/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Searches and analyzes the logs N|Solid keeps from Node.js apps (nsolid.logger and OpenTelemetry logs): errors and warnings by app, process, text or severity, a request's logs (by its trace, for OpenTelemetry logs), and how they line up with exits, blocked loops and slow traces. Use when the user asks what an app logged, to find errors in production logs, what happened around an incident, or for the logs of a specific request or trace.
 ---
 
-This skill reads logs through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names.
+This skill reads logs through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names.
 
 N|Solid keeps logs for 14 days by default. Apps send them through the N|Solid logger (`nsolid.logger`) or an OpenTelemetry SDK. Only OpenTelemetry logs carry trace and span ids: `nsolid.logger` lines have none yet, so they are found by process and time rather than by trace.
 
@@ -14,7 +14,7 @@ N|Solid keeps logs for 14 days by default. Apps send them through the N|Solid lo
   - `severity`: the least severe to include (e.g. `warn`);
   - `agentId`: one process (`find_agents` finds them by app or host);
   - `traceId`: one request's logs (OpenTelemetry logs only);
-  - `where`: an expression, e.g. `level >= "error" && service == "checkout"`, `body.contains("ECONNREFUSED")`, `attr["http.route"] == "/orders"` (`expression_help` with context `log` lists the fields).
+  - `where`: an expression, e.g. `level >= "error" && service == "checkout"`, `body.contains("ECONNREFUSED")`, `attr["http.route"] == "/orders"` (`expression_help` with context `log` lists the fields; it takes no `tenant`).
 - Start narrow (an app, errors, the incident's window) and widen only as needed.
 
 ### 2. Correlate

skills/ns-analyze-release/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Explains what a release of a Node.js app changed in production, from N|Solid's CPU profiles and package inventories: CPU by package and function against the release before (with confidence), calls between packages that are new or gone, packages added, removed or upgraded, regressions and dependency drift. Use when the user asks whether a deploy made things slower, what changed in version X, why the app behaves differently since a release, or wants releases marked or sourcemaps uploaded from CI.
 ---
 
-This skill works through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names (production and staging are usually separate tenants).
+This skill works through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names (production and staging are usually separate tenants).
 
 A release is a version of the app as its processes report it (`package.json`'s `version`). N|Solid records a release when its processes first report it, and CI can mark a deploy with its commit and a link.
 

skills/ns-analyze-tracing/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Analyzes N|Solid/OpenTelemetry tracing evidence from N|Solid for request latency, HTTP errors, and service dependencies. Use when the user asks about slow endpoints, API timeouts, distributed traces/spans, N+1 queries, await chains, microservice latency, cascading failures, or trace IDs. Query N|Solid only when no trace data was provided.
 ---
 
-This skill reads traces through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names.
+This skill reads traces through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names.
 
 ### 1. Use Provided Trace Data First
 - Treat the prompt as primary evidence. Parse any provided trace ID, span list, app name, endpoint name, status code, duration, or error stack before calling tools.
@@ -13,7 +13,7 @@ This skill reads traces through the N|Solid MCP server (`nsolid`). The N|Solid t
 
 ### 2. Discover Services Only When Needed
 - **Skip this step if sufficient host-provided trace data is present**, or when the user names the service or app.
-- Call `list_apps` for the app names. A span's `service` is its app's name.
+- Call `list_apps` for the app names. A span's `service` is its app's name. An app missing from an omitted or truncated answer is not proven absent: if the user gave its exact name, pass it straight to the tools that take it; otherwise ask for the exact name rather than guess.
 - The N|Solid server doesn't collect AWS Lambda functions; if the user asks about a serverless function, say so.
 
 ### 3. Find Slow Requests Only If No Trace Was Supplied

skills/ns-analyze-vulnerabilities/SKILL.md

@@ -4,13 +4,14 @@ description: >-
   Analyzes live runtime vulnerabilities in the packages connected N|Solid Node.js processes run, from N|Solid. Use when the user wants to know which CVEs are actually present in running apps, active exploitable/live vulnerabilities, malicious packages, zero-day exposure, supply-chain risk in production, Node.js runtime advisories, or production package risk. For static npm-audit-style project dependency scans, use ns-audit-dependencies instead.
 ---
 
-This skill reads vulnerability findings through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names (production and staging are usually separate tenants).
+This skill reads vulnerability findings through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names (production and staging are usually separate tenants).
 
 ### 1. High-Level Overview
 - Call `list_vulnerabilities`: open findings, most severe first. Each names its advisory (GHSA, a malicious-package report MAL, or a Node.js core advisory NODE-CORE), the app, severity, the vulnerable packages with the version that fixes them, the app's own dependencies that bring each in (`via`), and the runtime evidence: `installed`, `loaded` (required by the app) or `running` (seen in CPU profiles). A finding whose CVE CISA lists as exploited in the wild carries `knownExploited`: the CVE, when CISA listed it, its remediation due date, and whether ransomware campaigns use it.
-- Narrow large fleets with `app`, `severity` (at least), or `where`, e.g. `severity >= "high" && evidence >= "loaded"`, or `knownExploited` (`expression_help` with context `finding` lists the fields).
+- Narrow large fleets with `app`, `severity` (at least), or `where`, e.g. `severity >= "high" && evidence >= "loaded"`, or `knownExploited` (`expression_help` with context `finding` lists the fields; it takes no `tenant`).
+- A result that fills its `limit` or carries a cut notice is partial: the findings it shows stand, but more may exist, so it cannot support an app all-clear or a complete ranking.
 - Summarize which app has the most critical issues. Lead with malicious packages (MAL-…) when there are any, then known exploited findings in loaded or running code: attackers use those now, whatever their severity.
-- Before saying an app has nothing to fix, `vulnerability_data` shows whether the advisory data is current: when the OSV mirror and CISA's catalog were last checked, and any sync error. Say so when it is stale.
+- Before saying an app has nothing to fix, `vulnerability_data` (it takes no `tenant`) shows whether the advisory data is current: when the OSV mirror and CISA's catalog were last checked, and any sync error. Say so when it is stale.
 - For the Node.js runtime itself, `list_runtimes` gives each Node.js version in use: its core advisories, the release that fixes them, and whether its line is at or near end of life.
 
 ### 2. Detail Per App

skills/ns-configure-agents/SKILL.md

@@ -4,18 +4,20 @@ description: >-
   Changes how N|Solid agents run, safely: tracing on or off, continuous CPU profiling, the metrics interval, the blocked-loop threshold, trace sampling, snapshot redaction, tags. Use when the user wants tracing turned on for an app, continuous profiling for a while, a different metrics interval, asks why a process has a setting, or asks for a named config's history: who changed it and what it held before. Previews every change, prefers changes that expire, and explains where each running value came from.
 ---
 
-This skill works through the N|Solid MCP server (`nsolid`). The N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names. Changing configuration needs the `nsolid:dynamic-configuration` permission; without it the change tools are missing, and the skill can still explain and preview.
+This skill works through the N|Solid MCP server (`nsolid`). Most N|Solid tools take a `tenant`: when the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names. Changing configuration needs the `nsolid:dynamic-configuration` permission; without it the change tools are missing, and the skill can still explain and preview.
 
 N|Solid keeps agents at **desired configs**: each targets processes by an expression (or an app, tags or one agent), has a priority, and can expire. Processes started later get them too, and N|Solid confirms each change from the agent's own report. That beats changing one process once, which a restart forgets.
 
 ### 1. Understand What Runs Now
-- `list_desired_configs`: the configs the tenant keeps, with their targets, settings and priority; ones with `expiresAt` are temporary overrides.
+- `list_desired_configs`: the configs the tenant keeps, with their targets, settings (as `config`) and priority; ones with `expiresAt` are temporary overrides.
 - `agent_config` with an `agentId`: what that process reports, what it should have and which config set each key, what is still to apply, and whether it has converged. Use it to answer "why does this process have that setting?"
 - `desired_config_history` with a config's `name`: its 50 newest saves and deletes, each with the settings, target, priority, expiry, who made it and when. Deleted configs keep their history. Read it before changing or deleting a named config, to see who set it and what it held before. No tool restores an earlier version: to go back to one, make it a new change and preview and apply it as below.
 
 ### 2. Shape the Change
+- `preview_desired_config` and `set_desired_config` accept exactly one of `settings` or its alias `config`, never both.
 - Settings: `tracingEnabled`, `traceSampleRate` (0 to 1), `contCpuProfile` (continuous CPU profiling), `interval` (metrics, ms), `blockedLoopThreshold` (ms), `pauseMetrics`, `promiseTracking`, `redactSnapshots`, `assetsEnabled`, `tags`. Turning `contCpuProfile` on needs the tenant's continuous-profiling feature: where N|Solid has it off, the save is refused, and processes stay off whatever a config says.
-- Target: `app`, `tags`, one `agentId`, or `where`, an expression over what a process is (`app == "checkout" && hostname.endsWith(".prod")`, `nodeVersion >= "22"`; `expression_help` with context `selector` lists the fields). Every process of the tenant needs `allAgents: true` and the user's explicit agreement.
+- Target: `app`, `tags`, one `agentId`, or `where`, an expression over what a process is (`app == "checkout" && hostname.endsWith(".prod")`, `nodeVersion >= "22"`; `expression_help` with context `selector` lists the fields; it takes no `tenant`). Every process of the tenant needs `allAgents: true` and the user's explicit agreement.
+- A `where` expression is limited to 4,000 characters, 256 nodes, 32 levels of depth, 500 characters per string literal and 200 values per `in` list.
 - **Prefer an expiring override** for anything diagnostic: `expiresInMinutes` makes it stop applying, and the processes go back to what they had. Tracing or continuous profiling "for the next hour" is an override of 60 minutes.
 - `priority`: higher wins where configs disagree.
 - Names use letters, digits, `.`, `_` and `-`: `checkout-tracing-1h`.

skills/ns-cpu-spike-analysis/SKILL.md

@@ -18,7 +18,7 @@ when the token can use several tenants).
 - If the user explicitly says read-only, offline, or "analyze this data", never capture a new profile unless they later approve it.
 
 ### 2. Pick the Tenant
-- The N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user or alert names (production and staging are usually separate tenants). Pass the same tenant to every call, and set `NSOLID_TENANT` for the scripts.
+- Most N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user or alert names (production and staging are usually separate tenants). Pass the same tenant to every tenant-scoped call, and set `NSOLID_TENANT` for the scripts.
 
 ### 3. Discover Connected Agents Only When Needed
 - Call `fleet_snapshot` with `sort: "cpu_percent"` to list connected processes, hottest first, with their live metrics. When the user named an app, add `where: 'app == "<appName>"'`.

skills/ns-download-asset/SKILL.md

@@ -10,7 +10,7 @@ This skill downloads N|Solid assets with a bundled script, finding them through
 
 ### 1. Pick the Tenant
 
-- The N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` once and use the tenant the user names. Set `NSOLID_TENANT` for the script.
+- Most N|Solid tools take a `tenant`. When the token can use one tenant it is the default; otherwise call `list_tenants` (it takes no `tenant`) once and use the tenant the user names. Set `NSOLID_TENANT` for the script.
 
 ### 2. Identify the Asset