harness-mcp-v2 3.2.19 → 3.2.21

package/README.md

@@ -2,7 +2,7 @@
 
 [![MCP Toplist](https://mcptoplist.com/badge/glama%2Fharness%2Fmcp-server.svg)](https://mcptoplist.com/server/glama%2Fharness%2Fmcp-server)
 
-An MCP (Model Context Protocol) server that gives AI agents full access to the Harness.io platform through 11 consolidated tools and 223 resource types.
+An MCP (Model Context Protocol) server that gives AI agents full access to the Harness.io platform through 11 consolidated tools and 240 resource types.
 
 ## Why Use This MCP Server
 
@@ -10,10 +10,10 @@ Most MCP servers map one tool per API endpoint. For a platform as broad as Harne
 
 This server is built differently:
 
-- **11 tools, 223 resource types.** A registry-based dispatch system routes `harness_list`, `harness_get`, `harness_create`, etc. to any Harness resource — pipelines, services, environments, orgs, projects, feature flags, cost data, and more. The LLM picks from 11 tools instead of hundreds.
-- **Full platform coverage.** 38 default toolsets spanning CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, Internal Developer Portal, Software Supply Chain, Infrastructure as Code Management, Governance, Service Overrides, Knowledge Graph, and more. Opt-in Ansible coverage is available when you need inventory and playbook data.
+- **11 tools, 240 resource types.** A registry-based dispatch system routes `harness_list`, `harness_get`, `harness_create`, etc. to any Harness resource — pipelines, services, environments, orgs, projects, feature flags, cost data, and more. The LLM picks from 11 tools instead of hundreds.
+- **Full platform coverage.** 39 default toolsets spanning CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, Internal Developer Portal, Software Supply Chain, Infrastructure as Code Management, Release Management, Governance, Service Overrides, Knowledge Graph, and more. Opt-in Ansible coverage is available when you need inventory and playbook data.
 - **Multi-project workflows out of the box.** Agents discover organizations and projects dynamically — no hardcoded env vars needed. Ask "show failed executions across all projects" and the agent can navigate the full account hierarchy.
-- **34 prompt templates.** Pre-built prompts for common workflows: build & deploy apps end-to-end, debug failed pipelines, review DORA metrics, triage vulnerabilities, optimize cloud costs, audit access control, plan feature flag rollouts, review pull requests, approve pending pipelines, and more.
+- **35 prompt templates.** Pre-built prompts for common workflows: build & deploy apps end-to-end, debug failed pipelines, review DORA metrics, triage vulnerabilities, optimize cloud costs, audit access control, plan feature flag rollouts, review pull requests, approve pending pipelines, and more.
 - **Works everywhere.** Stdio transport for local clients (Claude Desktop, Cursor, Devin Desktop), HTTP transport for remote/shared deployments, Docker and Kubernetes ready.
 - **Zero-config start.** Just provide a Harness API key. Account ID is auto-extracted from PAT and SAT tokens, org/project defaults are optional, and toolset filtering lets you expose only what you need.
 - **Extensible by design.** Adding a new Harness resource means adding a declarative data file — no new tool registration, no schema changes, no prompt updates.
@@ -86,7 +86,7 @@ pnpm inspect            # Test with MCP Inspector
 
 ### Anthropic MCP Directory bundle
 
-The MCPB bundle manifest lives in `[mcp-directory/](mcp-directory/)`, and the bundle icon is tracked at `[icon.png](icon.png)` in the repository root. Copy `mcp-directory/manifest.json` to the bundle root after `pnpm build` so the generated archive contains root-level `manifest.json`, `icon.png`, `build/`, `package.json`, and production `node_modules/`.
+The MCPB bundle manifest lives in `[mcp-directory/](mcp-directory/)`, and the 512×512 bundle icon is tracked at `[icon.png](icon.png)` in the repository root. The packaged archive contains root-level `manifest.json`, `icon.png`, `server/`, `package.json`, `npm-shrinkwrap.json`, and production `node_modules/`.
 
 To keep the archive small, build MCPB packages from a staging directory:
 
@@ -94,7 +94,9 @@ To keep the archive small, build MCPB packages from a staging directory:
 pnpm prepare:mcpb
 ```
 
-The staged package is written to `dist/mcpb/` with production dependencies installed using npm's flat layout.
+The staging directory is written to `dist/mcpb/` with production dependencies installed from `npm-shrinkwrap.json` using npm's flat layout. The pinned official MCPB CLI validates it and creates `dist/harness-mcp-server-<version>.mcpb`.
+
+Version tags matching `v*.*.*` publish that bundle to the corresponding GitHub Release automatically. To backfill an existing release without republishing npm, run the `Release` workflow manually with its `release_tag` input (for example, `v3.2.20`). The workflow checks out and builds that exact tag before replacing only its versioned MCPB asset.
 
 ### CLI Usage
 
@@ -537,8 +539,8 @@ The server automatically loads environment variables from a `.env` file in the p
 | `HARNESS_API_KEY`           | Yes*     | --                          | Harness personal access token or service account token. Required in `single-user` mode. Must NOT be set in `multi-user` mode                                                                                                                          |
 | `HARNESS_ACCOUNT_ID`        | No       | *(from PAT/SAT)*            | Harness account identifier. Auto-extracted from PAT/SAT tokens in single-user mode; multi-user sessions can provide their own via `x-harness-account-id` when the API key does not embed one                                                          |
 | `HARNESS_BASE_URL`          | No       | `https://app.harness.io`    | Harness API/UI base URL for local stdio or self-hosted HTTP deployments. Set this to environments such as `https://harness0.harness.io` when running the server yourself. It does not affect the managed `https://mcp.harness.io/mcp` hosted endpoint |
-| `HARNESS_FME_API_KEY`       | No       | --                          | Optional single-user/self-hosted FME/Split Admin credential used for `fme_` resources. This can be a legacy Split admin key or an FME-entitled Harness PAT/SAT. FME calls go directly to `api.split.io`, so hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate these requests. Must not be set in `multi-user` mode; FME must use each session's `x-harness-api-key` credential. If unset, FME falls back to a non-placeholder `HARNESS_API_KEY` for self-hosted sessions |
-| `HARNESS_FME_BASE_URL`      | No       | `https://api.split.io`      | Split/FME Admin API base URL used by `fme_` resources. HTTP URLs require `HARNESS_ALLOW_HTTP=true` for local development                                                                                                                              |
+| `HARNESS_FME_API_KEY`       | No       | --                          | Optional single-user/self-hosted FME/Split Admin credential used for `fme_` resources in **legacy (`workspace_id`) mode only**. This can be a legacy Split admin key or an FME-entitled Harness PAT/SAT. FME calls go directly to `api.split.io`, so hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate these requests. Must not be set in `multi-user` mode; FME must use each session's `x-harness-api-key` credential. If unset, FME falls back to a non-placeholder `HARNESS_API_KEY` for self-hosted sessions. Harness-native (`org_id`+`project_id`) mode ignores this and uses the standard `HARNESS_API_KEY`/`HARNESS_BASE_URL` instead |
+| `HARNESS_FME_BASE_URL`      | No       | `https://api.split.io`      | Split/FME Admin API base URL used by `fme_` resources in **legacy (`workspace_id`) mode only**. HTTP URLs require `HARNESS_ALLOW_HTTP=true` for local development. Harness-native (`org_id`+`project_id`) mode ignores this and uses the standard `HARNESS_API_KEY`/`HARNESS_BASE_URL` instead |
 | `HARNESS_ORG`               | No       | --                          | Organization ID. Used when `org_id` is not specified per tool call. If omitted, `org_id` must be provided explicitly. Agents can also discover orgs dynamically via `harness_list(resource_type="organization")`                                      |
 | `HARNESS_PROJECT`           | No       | --                          | Project ID. Used when `project_id` is not specified per tool call. Agents can also discover projects dynamically via `harness_list(resource_type="project")`                                                                                          |
 | `HARNESS_API_TIMEOUT_MS`    | No       | `30000`                     | HTTP request timeout in milliseconds                                                                                                                                                                                                                  |
@@ -656,24 +658,24 @@ The server exposes 11 MCP tools. Most API tools accept `org_id` and `project_id`
 - `resource_scope: "org"` sends `accountIdentifier` and `orgIdentifier`.
 - `resource_scope: "project"` sends account, org, and project identifiers.
 
-Current multi-scope resources include `connector`, `service`, `environment`, `infrastructure`, `secret`, `file_store`, and `template`. If `resource_scope` is omitted, the registry uses the resource's default scope and configured defaults, except resources marked as optional scope may omit org/project unless explicitly passed. Harness URLs can also set the scope automatically when the path contains account-level or project-level context.
+Current multi-scope resources include `connector`, `service`, `environment`, `infrastructure`, `secret`, `file_store`, `template`, `policy`, and `policy_set`. If `resource_scope` is omitted, the registry uses the resource's default scope and configured defaults, except resources marked as optional scope may omit org/project unless explicitly passed. Harness URLs can also set the scope automatically when the path contains account-level or project-level context.
 
 **Structured output:** Every tool declares an MCP `outputSchema`. `harness_list` normalizes list-like Harness responses into object-shaped structured content so strict clients can validate it: top-level arrays become `{ "items": [...], "total": <count>, "page": <page> }`, and common wrapper keys such as `content`, `data`, `body`, `objects`, or `features` are hoisted to `items` when needed. The text response still contains the compact JSON payload returned to all clients.
 
 
-| Tool               | Description                                                                                                                                                                                                                                                                                                           |
-| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `harness_describe` | Discover available resource types, operations, and fields. No API call — returns local registry metadata.                                                                                                                                                                                                             |
-| `harness_schema`   | Fetch exact YAML/JSON Schema definitions and examples for creating/updating resources. Pipeline/template schemas are bundled; connector, environment, service, secret, and infrastructure schemas are scope-aware entity schemas fetched from bundled snapshots or NG `/yaml-schema`. Supports deep drilling via `path`. |
-| `harness_list`     | List resources of a given type with filtering, search, and pagination.                                                                                                                                                                                                                                                |
-| `harness_get`      | Get a single resource by its identifier.                                                                                                                                                                                                                                                                              |
-| `harness_create`   | Create a new resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via [elicitation](#elicitation).                                                                                                                                                                              |
-| `harness_update`   | Update an existing resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via [elicitation](#elicitation).                                                                                                                                                                        |
-| `harness_delete`   | Delete a resource. Prompts for user confirmation via [elicitation](#elicitation). Destructive.                                                                                                                                                                                                                        |
-| `harness_execute`  | Execute an action on a resource (run/retry pipeline, import pipeline from Git, toggle flag, sync app). Prompts for user confirmation via [elicitation](#elicitation). For pipeline runs, use the runtime-input workflow below (supports `branch`/`tag`/`pr_number`/`commit_sha` shorthand expansion).                 |
+| Tool               | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| --------------------| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `harness_describe` | Discover available resource types, operations, and fields. No API call — returns local registry metadata.                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `harness_schema`   | Fetch exact YAML/JSON Schema definitions and examples for creating/updating resources. Pipeline/template schemas are bundled; connector, environment, service, secret, and infrastructure schemas are scope-aware entity schemas fetched from bundled snapshots or NG `/yaml-schema`; `release_process` and `release_activity` schemas are fetched live from RMG `/api/yamlSchema`. Supports deep drilling via `path`.                                                                                                          |
+| `harness_list`     | List resources of a given type with filtering, search, and pagination.                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| `harness_get`      | Get a single resource by its identifier.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `harness_create`   | Create a new resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via [elicitation](#elicitation).                                                                                                                                                                                                                                                                                                                                                                                        |
+| `harness_update`   | Update an existing resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via [elicitation](#elicitation).                                                                                                                                                                                                                                                                                                                                                                                  |
+| `harness_delete`   | Delete a resource. Prompts for user confirmation via [elicitation](#elicitation). Destructive.                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `harness_execute`  | Execute an action on a resource (run/retry pipeline, import pipeline from Git, toggle flag, sync app). Prompts for user confirmation via [elicitation](#elicitation). For pipeline runs, use the runtime-input workflow below (supports `branch`/`tag`/`pr_number`/`commit_sha` shorthand expansion).                                                                                                                                                                                                                           |
 | `harness_search`   | Search across Harness resource types with a single query. Uses semantic routing (local `all-MiniLM-L6-v2` ONNX embeddings, 384-dim) to predict relevant resource types from a `knowledge` corpus indexed at startup — typically narrowing from ~163 types to 1–8 before scatter-gather. Falls back to full keyword scatter-gather when semantic confidence is low. Response includes `semantic_routed` and `types_skipped` when routing fires. See `docs/search-guidelines.md` for how to make new resource types discoverable. |
-| `harness_diagnose` | Diagnose `pipeline`, `connector`, `delegate`, and `gitops_application` resources (aliases: `execution` -> `pipeline`, `gitops_app` -> `gitops_application`). For pipelines, returns stage/step timing and failure details; for connectors/delegates/GitOps apps, returns targeted health and troubleshooting signals. |
-| `harness_status`   | Get a real-time project health dashboard — recent executions, failure rates, and deep links.                                                                                                                                                                                                                          |
+| `harness_diagnose` | Diagnose `pipeline`, `connector`, `delegate`, and `gitops_application` resources (aliases: `execution` -> `pipeline`, `gitops_app` -> `gitops_application`). For pipelines, returns stage/step timing and failure details; for connectors/delegates/GitOps apps, returns targeted health and troubleshooting signals.                                                                                                                                                                                                           |
+| `harness_status`   | Get a real-time project health dashboard — recent executions, failure rates, and deep links.                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 
 
 ### Schema Lookup Workflow
@@ -682,6 +684,7 @@ Use `harness_schema` before creating or updating YAML-backed resources so agents
 
 - Bundled schemas include `pipeline`, `template`, `trigger`, `pipeline_v1`, `template_v1`, `inputSet_v1`, `overlayInputSet_v1`, and `agent-pipeline`.
 - Entity schemas include `connector`, `environment`, `service`, `secret`, and `infrastructure`. They are scope-aware (`account`, `org`, or `project`) and require `org_id`/`project_id` when the selected scope requires them.
+- Release Management definitions (`release_process`, `release_activity`) fetch live JSON Schema from RMG `/api/yamlSchema` (not bundled). Pass `scope`, `org_id`, and `project_id` when scoping to org or project.
 - Vendored entity snapshots are used first when they match the runtime account; otherwise the tool falls back to the Harness NG `/yaml-schema` API and caches the result.
 - Omit `path` for a field/section summary, then pass a dot-separated `path` to inspect a nested definition.
 
@@ -1202,7 +1205,7 @@ Harness pipelines can be stored in three ways:
 
 ## Resource Types
 
-223 resource types organized across 38 toolsets. Each resource type supports a subset of CRUD operations and optional execute actions.
+240 resource types organized across 39 toolsets. Each resource type supports a subset of CRUD operations and optional execute actions.
 
 ### Platform
 
@@ -1422,24 +1425,39 @@ Template operations use the Harness Template service paths (`/template/api/templ
 
 ### Infrastructure as Code Management (IaCM)
 
-IaCM resources are default-enabled and mostly project-scoped. Start with `iacm_workspace` to find workspace identifiers, then use that `workspace_id` for workspace resources, costs, and activity diffs. The module registry is account-scoped.
+IaCM resources are default-enabled and mostly project-scoped. Start with `iacm_workspace` to find workspace identifiers, then use that `workspace_id` for workspace resources, costs, and activity diffs. Use `iacm_variable_set` for reusable variable sets at account, org, or project scope. The provider registry is account-scoped.
+
+`iacm_module` spans account, org, and project scope. It defaults to the account registry; every operation (list, get, create, update) sends the same `scope_org` / `scope_project` query params, so a module you create is discoverable at the scope you created it. Select the scope with `resource_scope="account" | "org" | "project"` plus `org_id`/`project_id`. Scoping is opt-in: when `resource_scope` is omitted, `org_id`/`project_id` apply only if you pass them explicitly — configured `HARNESS_ORG`/`HARNESS_PROJECT` defaults are not applied, so an ambient project config cannot silently register an account module under a project. A module body's own `org`/`project` fields locate its Git connector and are unrelated to this visibility scope.
+
+`iacm_workspace` create/update return `{ policy_evaluation }` only — follow up with `harness_get` to fetch the workspace. `iacm_variable_set` and `iacm_module` create/update return the resource itself. `iacm_provider` create returns `{ id }` only — follow up with `harness_get`; **update is version-oriented only** (POST/PUT `/providers/{id}/version`) — there is no metadata PUT. Version writes may return an empty body; HarnessClient normalizes that to `{ status: "SUCCESS", message: "No content" }`.
+
+Variable-set **update is HTTP PUT with full-replacement collections** — always `harness_get` first, then PUT the full desired body (`terraform_variables` / `environment_variables` are required on update; omit/empty clears connectors and variable files). Module update is also PUT — prefer get-then-put for optional fields. Writes are `medium_write` and require confirmation (elicitation or `confirm: true`).
+
+Variable-set and provider-registry RBAC (`iac_variableset_*`, `iac_providerregistry_*`) are currently Experimental in Harness — access checks always allow until iac-server activates enforcement. Module registry RBAC (`iac_registry_view` / `iac_registry_edit`) is Active and enforceable. MCP always forwards the caller PAT/SAT unchanged.
 
 | Resource Type                   | List | Get | Create | Update | Delete | Execute Actions |
 | ------------------------------- | ---- | --- | ------ | ------ | ------ | --------------- |
-| `iacm_workspace`                | x    | x   |        |        |        |                 |
+| `iacm_workspace`                | x    | x   | x      | x      |        |                 |
+| `iacm_variable_set`             | x    | x   | x      | x      |        |                 |
 | `iacm_resource`                 | x    |     |        |        |        |                 |
-| `iacm_module`                   | x    | x   |        |        |        |                 |
+| `iacm_module`                   | x    | x   | x      | x      |        |                 |
+| `iacm_provider`                 | x    | x   | x      | x      |        |                 |
 | `iacm_workspace_costs`          | x    |     |        |        |        |                 |
 | `iacm_activity_resource_change` | x    |     |        |        |        |                 |
 
 Typical workflow:
 
 1. `harness_list(resource_type="iacm_workspace", org_id="...", project_id="...")` to find the workspace.
-2. `harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...")` to inspect Terraform resources, outputs, and data sources.
-3. `harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...")` to review per-execution cost entries.
-4. `harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...")` to inspect before/after resource diffs for a plan, apply, or destroy activity.
+2. `harness_create` / `harness_update` on `iacm_workspace` to create from scratch or a template (`associated_template`), or update an existing workspace — response is `{ policy_evaluation }` only.
+3. `harness_get(resource_type="iacm_workspace", workspace_id="...")` to fetch the created/updated workspace.
+4. `harness_list` / `harness_create` / `harness_update` on `iacm_variable_set` (optionally with `resource_scope`) for reusable Terraform/env variable sets — response is the VariableSet resource.
+5. `harness_list` / `harness_create` / `harness_update` on `iacm_module` for the module registry (`name` + `system` required; add `resource_scope` with `org_id`/`project_id` for an org- or project-scoped module) — response is the module resource.
+6. `harness_list` / `harness_create` / `harness_update` on `iacm_provider` for the account provider registry (`body.type` required for create; create returns `{ id }` only — then `harness_get`; update creates/updates **versions** only) — version update may return empty success.
+7. `harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...")` to inspect Terraform resources, outputs, and data sources.
+8. `harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...")` to review per-execution cost entries.
+9. `harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...")` to inspect before/after resource diffs for a plan, apply, or destroy activity.
 
-IaCM list responses expose `page_count` as the count for the current page only. When `has_more` is true, keep requesting the next 1-based page and sum page counts if you need a total.
+IaCM list responses expose `page_count` as the count for the current page only (except `iacm_variable_set`, which is not paginated). When `has_more` is true, keep requesting the next 1-based page and sum page counts if you need a total.
 
 ### Internal Developer Portal (IDP)
 
@@ -1470,15 +1488,45 @@ IaCM list responses expose `page_count` as the count for the current page only.
 Use `harness_execute(resource_type="pull_request", action="close", ...)` for an explicit close operation. `harness_update` also accepts `body.state` (`open` or `closed`) and routes state changes to the dedicated Harness Code PR state endpoint; send title/description edits in a separate update call.
 
 
+### Release Management
+
+Release Management (RMG) resources are default-enabled. Definition resources (`release_process`, `release_activity`) support list/get/create/update/delete with `body.yaml`; call `harness_schema(resource_type="release_process"|"release_activity")` before create/update. Execution resources monitor running releases — most list operations require `release_id` (UUID from `harness_list resource_type=release`, or the UI URL slug such as `identifier-1.0.0-abc`). Paste an RMG release URL into `harness_list` to auto-fill `release_id`.
+
+RMG calls use `${HARNESS_BASE_URL}/gateway/rmg` with account scoping via the `Harness-Account` header. Org/project scope uses header-based scoping when `org_id`/`project_id` are provided. `release_execution_phase` is list-only — use each phase item's `identifier` field as `params.phase_identifier` when calling `harness_get` on phase input/output resources (do not call `harness_get` on `release_execution_phase` itself). Release list `status` filtering is applied client-side on the current page only; keep paging with the same filters when results may span pages.
+
+| Resource Type                         | List | Get | Create | Update | Delete | Execute Actions |
+| ------------------------------------- | ---- | --- | ------ | ------ | ------ | --------------- |
+| `release_process`                     | x    | x   | x      | x      | x      |                 |
+| `release_activity`                    | x    | x   | x      | x      | x      |                 |
+| `release`                             | x    | x   |        |        |        |                 |
+| `release_execution_phase`             | x    |     |        |        |        |                 |
+| `release_execution_task`              | x    |     |        |        |        |                 |
+| `release_execution_activity`          | x    |     |        |        |        |                 |
+| `release_input`                       |      | x   |        |        |        |                 |
+| `release_execution_phase_input`       |      | x   |        |        |        |                 |
+| `release_execution_phase_output`      |      | x   |        |        |        |                 |
+| `release_execution_activity_input`    |      | x   |        |        |        |                 |
+| `release_execution_activity_output`   |      | x   |        |        |        |                 |
+
+Typical workflow:
+
+1. `harness_list(resource_type="release_process", org_id="...", project_id="...")` to discover orchestration process definitions.
+2. `harness_schema(resource_type="release_process")` (or `release_activity`) before create/update; then `harness_create` / `harness_update` with `body.yaml`.
+3. `harness_list(resource_type="release", org_id="...", project_id="...")` to find active or recent releases (default 30-day look-back; optional `filters.status`, `filters.search_term`, `filters.days_back`).
+4. `harness_get(resource_type="release", release_id="...")` for release details.
+5. `harness_list(resource_type="release_execution_phase", filters={ release_id: "..." })` for phase status; same `release_id` for `release_execution_task` and `release_execution_activity`.
+6. `harness_get` on `release_input`, `release_execution_phase_input`, `release_execution_phase_output`, `release_execution_activity_output`, or `release_execution_activity_input` using `release_id` plus `params.phase_identifier` / `params.activity_identifier` / `activity_execution_id` as documented on each resource.
+
+
 ### Feature Flags
 
 
 | Resource Type                       | List | Get | Create | Update | Delete | Execute Actions                           |
 | ----------------------------------- | ---- | --- | ------ | ------ | ------ | ----------------------------------------- |
 | `fme_workspace`                     | x    |     |        |        |        |                                           |
-| `fme_environment`                   | x    |     |        |        |        |                                           |
-| `fme_feature_flag`                  | x    | x   | x      | x      | x      | `kill`, `restore`, `archive`, `unarchive` |
-| `fme_feature_flag_definition`       |      | x   | x      | x      |        |                                           |
+| `fme_environment`                   | x    | x   | x      | x      | x      |                                           |
+| `fme_feature_flag`                  | x    | x   | x      | x      | x      | `kill`, `restore`, `reallocate`, `archive`, `unarchive` |
+| `fme_feature_flag_definition`       | x    | x   | x      | x      | x      | `kill`, `restore`, `reallocate`           |
 | `fme_rollout_status`                | x    |     |        |        |        |                                           |
 | `fme_rule_based_segment`            | x    | x   | x      |        | x      |                                           |
 | `fme_rule_based_segment_definition` | x    |     |        | x      |        | `enable`, `disable`, `change_request`     |
@@ -1486,9 +1534,28 @@ Use `harness_execute(resource_type="pull_request", action="close", ...)` for an
 | `fme_identity`                      |      |     | x      | x      |        |                                           |
 | `fme_standard_segment`              | x    | x   |        |        |        |                                           |
 | `fme_segment_keys`                  | x    |     |        | x      |        |                                           |
+| `fme_segment`                       | x    | x   | x      |        | x      |                                           |
+| `fme_segment_definition`            | x    | x   | x      | x      | x      |                                           |
+
+
+**FME (Split.io) resources** — `fme_`* resources support **dual-mode scoping**: legacy calls pass `workspace_id` and hit the Split.io API (`api.split.io`); newer calls pass `org_id`+`project_id` together and hit Harness-native endpoints (standard `HARNESS_API_KEY`/`HARNESS_BASE_URL`, same auth as every other `harness_*` resource) instead. Passing both `workspace_id` and `org_id`/`project_id` on the same call, or mixing `org_id` with `project_id` alone, is an error — pick one mode per call. Every operation below is available in legacy mode, unchanged. Harness-native mode coverage is currently narrower:
+
+- **`fme_workspace`** — no Harness-native equivalent; legacy-only (used to discover `workspace_id` values).
+- **`fme_environment`** — dual-mode `list` (`workspace_id` or `org_id`+`project_id`). `get`/`create`/`update`/`delete` are Harness-native only (`/fme/api/v4/environments`) — MCP never had a `workspace_id` contract for those ops. Native list uses optional `offset`/`limit` (max 100; `harness_list` `size` maps to `limit`); envelope `{data, limit, offset, totalCount}` is promoted to `items`/`total`. Native create/update use `isProduction` (`production` accepted as an alias). Native update is JSON Merge Patch; `name` and `isProduction` are not clearable. Name max 15 characters.
+- **`fme_feature_flag`** — dual-mode, both branches fully wired. Harness-native (`org_id`+`project_id`): `list`/`get`/`create`/`delete` hit `/fme/api/v4/feature-flags` (body for `create`: `name`, `trafficType`, optional `description`/`tags`/`owners`, per `CreateFeatureFlagRequest`); `update` sends a merge-patch to `/fme/api/v4/feature-flags/{name}`; `archive`/`unarchive` hit `/fme/api/v4/feature-flags/{name}/archive|unarchive` (optional `comment` only — no `title`, per `ArchiveUnarchiveRequest`); `kill`/`restore`/`reallocate` hit `/fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate` with `environment_id` as a query param (optional `comment`/`title`, per `FeatureFlagDefinitionActionRequest`).
+- **`fme_feature_flag_definition`** — `get`/`create`/`update` remain dual-mode (`workspace_id` or `org_id`+`project_id`). `list`/`delete`/`kill`/`restore`/`reallocate` are Harness-native only (`org_id`+`project_id`) — MCP never had a `workspace_id` contract for those ops. Native list requires `feature_flag_name` and uses `offset`/`limit` (default 100, max 100); it does not take `environment_id`. Delete and execute require `environment_id`. Kill/restore/reallocate are the same actions as on `fme_feature_flag`. Get/create/update body matches legacy (`treatments`, `defaultTreatment`, `defaultRule`, optional `rules`/`baselineTreatment`/`trafficAllocation`/`comment`), plus optional `title` in Harness-native mode. Native update is JSON Merge Patch.
+- **`fme_rollout_status`** — dual-mode `list`. Pass `org_id`+`project_id` (preferred) or the deprecated `workspace_id`. Native pagination uses `offset`/`limit` (max 100; `harness_list` `size` maps to `limit`); results are promoted to `items`/`total`. Each item has `id`, `name`, and optional `description`.
 
+- **`fme_rule_based_segment`** — (Deprecated — see `fme_segment`.) Harness-native mode is rejected on every operation (`list`/`get`/`create`/`delete`) — use `fme_segment` instead; this resource supports only the legacy `workspace_id` contract.
+- **`fme_rule_based_segment_definition`** — (Deprecated — see `fme_segment_definition`.) Harness-native mode is rejected on every operation/action (`list`/`update`/`enable`/`disable`/`change_request`) — use `fme_segment_definition` instead (no `enable`/`disable`/`change_request` equivalent there); this resource supports only the legacy `workspace_id`/`environment_id` contract.
+- **`fme_traffic_type`** — dual-mode `list`. Pass `org_id`+`project_id` (preferred) or the deprecated `workspace_id`. Native pagination uses `offset`/`limit` (max 100; `harness_list` `size` maps to `limit`); results are promoted to `items`/`total`. Each item has `id` and `name` (no `displayAttributeId`).
+- **`fme_identity`** — `create`/`update` are not yet implemented if `org_id`+`project_id` are passed together; otherwise proceeds as a normal legacy call.
+- **`fme_standard_segment`** — (Deprecated — see `fme_segment`.) Harness-native mode is rejected on every operation (`list`/`get`) — use `fme_segment` instead; this resource supports only the legacy `workspace_id` contract. There is no `create` operation for this resource in either mode.
+- **`fme_segment_keys`** — `list`/`update` are not yet implemented if `org_id`+`project_id` are passed together; otherwise proceeds as a normal legacy call.
+- **`fme_segment`** — `list`/`get`/`create`/`delete` are wired to the real `/fme/api/v4/segments` endpoint (consolidates `fme_standard_segment`/`fme_rule_based_segment`); `create` body: `name`, `trafficType`, `type` (required — one of `standard`/`rule_based`/`large`), optional `description`/`tags`/`owners`.
+- **`fme_segment_definition`** — Harness-native only (no legacy `workspace_id` support). `list`/`get`/`create`/`update`/`delete` are wired to `/fme/api/v4/segment-definitions`, per `Harness_Split/Main` PR #12644 (open, not yet merged as of this writing — paths may still change). `update` uses JSON Merge Patch on `description`, the only mutable field. There is no `enable`/`disable`/`change_request` action — the backend has no such endpoints for this unified resource.
 
-**FME (Split.io) resources** — `fme_`* resources use the Split.io API (`api.split.io`) and are scoped by workspace ID rather than org/project. In single-user/self-hosted mode, auth uses a Bearer token from `HARNESS_FME_API_KEY`, falling back to a non-placeholder `HARNESS_API_KEY`. `HARNESS_FME_API_KEY` may be a legacy Split admin key or an FME-entitled Harness PAT/SAT, but it is rejected in `multi-user` mode so shared deployments cannot override each session user's credential. Hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate direct Split.io requests. `fme_feature_flag` supports full lifecycle management: create (requires `traffic_type_id`), list, get, update metadata, delete, and kill/restore/archive/unarchive execute actions. Use `fme_traffic_type` to discover traffic type IDs, `fme_identity` to create/update identity attributes, and `fme_standard_segment` / `fme_segment_keys` to inspect standard segments and add member keys. `fme_rule_based_segment` provides CRUD for targeting segments, while `fme_rule_based_segment_definition` manages environment-specific segment rules with enable/disable and change request approval flows.
+In single-user/self-hosted mode, legacy-mode auth uses a Bearer token from `HARNESS_FME_API_KEY`, falling back to a non-placeholder `HARNESS_API_KEY`. `HARNESS_FME_API_KEY` may be a legacy Split admin key or an FME-entitled Harness PAT/SAT, but it is rejected in `multi-user` mode so shared deployments cannot override each session user's credential. Hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate direct Split.io requests. `fme_feature_flag` supports full lifecycle management in legacy mode: create (requires `traffic_type_id`), list, get, update metadata, delete, and kill/restore/reallocate/archive/unarchive execute actions. Use `fme_traffic_type` to discover traffic type IDs, `fme_identity` to create/update identity attributes, and `fme_standard_segment` / `fme_segment_keys` to inspect standard segments and add member keys. `fme_rule_based_segment` provides CRUD for targeting segments, while `fme_rule_based_segment_definition` manages environment-specific segment rules with enable/disable and change request approval flows.
 
 ### GitOps
 
@@ -1512,40 +1579,43 @@ Use `harness_execute(resource_type="pull_request", action="close", ...)` for an
 ### Chaos Engineering
 
 
-| Resource Type                | List | Get | Create | Update | Delete | Execute Actions                                          |
-|------------------------------| ---- | --- | ------ | ------ | ------ |----------------------------------------------------------|
-| `chaos_experiment`           | x    | x   | x      |        | x      | `run`, `stop`                                            |
-| `chaos_experiment_run`       |      | x   |        |        |        |                                                          |
-| `chaos_experiment_variable`  | x    |     |        |        |        |                                                          |
-| `chaos_component_variable`   |      | x   |        |        |        |                                                          |
-| `chaos_input_set`            | x    | x   | x      | x      | x      |                                                          |
-| `chaos_experiment_template`  | x    | x   |        |        | x      | `create_from_template`                                   |
-| `chaos_probe`                | x    | x   | x      |        | x      | `enable`, `verify`                                       |
-| `chaos_probe_in_run`         | x    |     |        |        |        |                                                          |
-| `chaos_probe_template`       | x    | x   |        |        | x      |                                                          |
-| `chaos_infrastructure`       | x    |     |        |        |        |                                                          |
-| `chaos_k8s_infrastructure`   | x    | x   |        |        |        | `check_health`                                           |
-| `chaos_environment`          | x    |     |        |        |        |                                                          |
-| `chaos_hub`                  | x    | x   | x      | x      | x      |                                                          |
-| `chaos_hub_fault`            | x    |     |        |        |        |                                                          |
-| `chaos_fault`                | x    | x   |        |        | x      |                                                          |
-| `chaos_fault_template`       | x    | x   |        |        | x      |                                                          |
-| `chaos_fault_experiment_run` | x    |     |        |        |        |                                                          |
-| `chaos_action`               | x    | x   |        |        | x      |                                                          |
-| `chaos_action_template`      | x    | x   |        |        | x      |                                                          |
-| `chaos_loadtest`             | x    | x   | x      |        | x      | `run`, `stop`                                            |
-| `chaos_application_map`      | x    | x   |        |        |        |                                                          |
-| `discovered_namespace`       | x    |     |        |        |        |                                                          |
-| `discovered_service`         | x    |     |        |        |        |                                                          |
-| `discovered_network_map`     | x    |     |        |        |        |                                                          |
-| `chaos_guard_condition`      | x    | x   |        |        | x      |                                                          |
-| `chaos_guard_rule`           | x    | x   |        |        | x      | `enable`                                                 |
-| `chaos_recommendation`       | x    | x   |        |        |        |                                                          |
-| `chaos_risk`                 | x    | x   |        |        |        |                                                          |
-| `chaos_dr_test`              | x    |     | x      |        |        |                                                          |
-| `scanned_risk`               | x    | x   |        |        |        | `occurrences`, `summary_by_service`                      |
-| `chaos_risk_rule`            | x    | x   |        |        |        |                                                          |
-| `chaos_risk_scan`            | x    | x   | x      | x      | x      | `retry`, `abort`, `report`, `report_download`, `heatmap` |
+| Resource Type                    | List | Get | Create | Update | Delete | Execute Actions                                                              |
+|----------------------------------| ---- | --- | ------ | ------ | ------ |------------------------------------------------------------------------------|
+| `chaos_experiment`               | x    | x   | x      |        | x      | `run`, `stop`                                                                |
+| `chaos_experiment_run`           |      | x   |        |        |        |                                                                              |
+| `chaos_experiment_variable`      | x    |     |        |        |        |                                                                              |
+| `chaos_component_variable`       |      | x   |        |        |        |                                                                              |
+| `chaos_input_set`                | x    | x   | x      | x      | x      |                                                                              |
+| `chaos_experiment_template`      | x    | x   |        |        | x      | `create_from_template`, `list_revisions`, `get_variables`, `get_yaml`, `compare_revisions` |
+| `chaos_probe`                    | x    | x   | x      |        | x      | `enable`, `verify`, `get_manifest`                                           |
+| `chaos_probe_in_run`             | x    |     |        |        |        |                                                                              |
+| `chaos_probe_template`           | x    | x   |        |        | x      | `get_variables`                                                              |
+| `chaos_infrastructure`           | x    |     |        |        |        |                                                                              |
+| `chaos_k8s_infrastructure`       | x    | x   | x      |        |        | `check_health`                                                               |
+| `chaos_enabled_infrastructure`   | x    |     |        |        |        |                                                                              |
+| `chaos_environment`              | x    |     |        |        |        |                                                                              |
+| `chaos_hub`                      | x    | x   | x      | x      | x      |                                                                              |
+| `chaos_hub_fault`                | x    |     |        |        |        |                                                                              |
+| `chaos_fault`                    | x    | x   |        |        | x      | `get_variables`, `get_yaml`                                                  |
+| `chaos_fault_template`           | x    | x   |        |        | x      | `list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`           |
+| `chaos_fault_experiment_run`     | x    |     |        |        |        |                                                                              |
+| `chaos_action`                   | x    | x   | x      |        | x      | `get_manifest`                                                               |
+| `chaos_action_template`          | x    | x   |        |        | x      | `list_revisions`, `get_variables`, `compare_revisions`                       |
+| `chaos_loadtest`                 | x    | x   | x      | x      | x      | `run`, `stop`                                                                |
+| `chaos_service`                  | x    | x   | x      | x      | x      | `list_experiment_runs`, `list_load_tests`                                    |
+| `chaos_application_map`          | x    | x   |        |        |        |                                                                              |
+| `discovered_agent`               | x    |     |        |        |        |                                                                              |
+| `discovered_namespace`           | x    |     |        |        |        |                                                                              |
+| `discovered_service`             | x    |     |        |        |        |                                                                              |
+| `discovered_network_map`         | x    |     |        |        |        |                                                                              |
+| `chaos_guard_condition`          | x    | x   |        |        | x      |                                                                              |
+| `chaos_guard_rule`               | x    | x   |        |        | x      | `enable`                                                                     |
+| `chaos_recommendation`           | x    | x   |        |        |        |                                                                              |
+| `chaos_risk`                     | x    | x   |        |        |        |                                                                              |
+| `chaos_dr_test`                  | x    |     | x      |        |        |                                                                              |
+| `scanned_risk`                   | x    | x   |        |        |        | `occurrences`, `summary_by_service`                                          |
+| `chaos_risk_rule`                | x    | x   |        |        |        |                                                                              |
+| `chaos_risk_scan`                | x    | x   | x      | x      | x      | `retry`, `abort`, `report`, `report_download`, `heatmap`                     |
 
 ### Cloud Cost Management (CCM)
 
@@ -1622,7 +1692,7 @@ Evidence Vault stores in-toto attestations (SDLC evidences). List supports accou
 | `security_issue`          | x    |     |        |        |        |                                |
 | `security_issue_filter`   | x    |     |        |        |        |                                |
 | `security_exemption`      | x    |     | x      |        |        | `approve`, `reject` |
-| `sast_remediation_diff`   | x    |     |        |        |        |                                |
+| `remediation_diff`        | x    |     |        |        |        |                                |
 
 `security_exemption` create is a `high_write` operation. The server derives `requester_id` from the authenticated PAT, sets `exemptFutureOccurrences=true`, and defaults `duration_days` to 30 when not provided. For listing exemptions, pass a small explicit page size (for example `filters: { "status": "Pending", "size": 5 }`) and follow the `_nextPageHint` returned in each response.
 
@@ -1759,7 +1829,7 @@ Security exemption execute workflow:
 
 ## Toolset Filtering
 
-By default, 38 of 39 toolsets are enabled. One toolset is opt-in and excluded from the defaults:
+By default, 39 of 40 toolsets are enabled. One toolset is opt-in and excluded from the defaults:
 
 - **`ansible`** — Harness Ansible (inventories, playbooks, hosts, activity). Opt-in because it is project-scoped and adds concepts many users do not need.
 
@@ -1820,14 +1890,14 @@ Available toolset names:
 | `dashboards`            | dashboard, dashboard_data                                                                                                                                                                                                                                                                       |
 | `idp`                   | idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc                                                                                                                                                                           |
 | `pull-requests`         | pull_request, pr_reviewer, pr_comment, pr_check, pr_activity                                                                                                                                                                                                                                    |
-| `feature-flags`         | fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys                                                           |
+| `feature-flags`         | fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition                       |
 | `gitops`                | gitops_agent, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree                                               |
-| `chaos`                 | chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_application_map, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan |
+| `chaos`                 | chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan |
 | `ccm`                   | cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment                                       |
 | `sei`                   | sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric                                                                                     |
 | `scs`                   | scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom                                                                                                                             |
 | `evidence-vault`        | attestation                                                                                                                                                                                                                                                                                     |
-| `sto`                   | security_issue, security_issue_filter, security_exemption, sast_remediation_diff                                                                                                                                                                                                                |
+| `sto`                   | security_issue, security_issue_filter, security_exemption, remediation_diff                                                                                                                                                                                                                     |
 | `dbops`                 | database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline                                                                                                                                                                                                   |
 | `access_control`        | user, user_group, service_account, role, role_assignment, resource_group, permission                                                                                                                                                                                                            |
 | `governance`            | policy, policy_set, policy_evaluation                                                                                                                                                                                                                                                           |
@@ -1837,8 +1907,9 @@ Available toolset names:
 | `knowledge-graph`       | kg_queryable_type_summary, kg_grammar, hql_query                                                                                                                                                                                                                                                |
 | `semantic-layer`        | kg_type, kg_related_type                                                                                                                                                                                                                                                                        |
 | `ai-evals`              | eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval |
-| `iacm`                  | iacm_workspace, iacm_resource, iacm_module, iacm_workspace_costs, iacm_activity_resource_change                                                                                                                                                                                                 |
+| `iacm`                  | iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_provider, iacm_workspace_costs, iacm_activity_resource_change                                                                                                                                                               |
 | `ansible` *(opt-in)*    | ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity                                                                                                                                                                                                      |
+| `release-management`  | release_process, release_activity, release, release_execution_phase, release_execution_task, release_execution_activity, release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_input, release_execution_activity_output |
 
 
 ## Architecture
@@ -1856,8 +1927,8 @@ Available toolset names:
                           |
                  +--------v---------+
                 |    Registry       |  <-- Declarative resource definitions
-                |  38 Toolsets      |      (data files, not code)
-                |  223 Resource Types|
+                |  39 Toolsets      |      (data files, not code)
+                |  240 Resource Types|
                  +--------+---------+
                           |
                  +--------v---------+

package/build/client/harness-client.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"harness-client.d.ts","sourceRoot":"","sources":["../../src/client/harness-client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,MAAM,EAA6C,MAAM,cAAc,CAAC;AACtF,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,YAAY,CAAC;AA2HjD;;;;GAIG;AACH,MAAM,MAAM,iBAAiB,GAAG,MAAM,MAAM,GAAG,SAAS,CAAC;AAEzD,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAS;IACjC,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAS;IAC/B,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAS;IACnC,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAS;IACjC,OAAO,CAAC,QAAQ,CAAC,UAAU,CAAS;IACpC,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAc;IAC1C,OAAO,CAAC,QAAQ,CAAC,eAAe,CAAU;IAC1C,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAqB;IAC/C,OAAO,CAAC,QAAQ,CAAC,OAAO,CAA6B;IACrD,OAAO,CAAC,iBAAiB,CAAC,CAAoB;IAC9C,OAAO,CAAC,aAAa,CAAC,CAAS;IAC/B,OAAO,CAAC,kBAAkB,CAAC,CAAkB;gBAEjC,MAAM,EAAE,MAAM;IAY1B;;;OAGG;IACH,oBAAoB,CAAC,QAAQ,EAAE,iBAAiB,GAAG,IAAI;IAIvD,6EAA6E;IAC7E,OAAO,CAAC,gBAAgB;IAIxB,IAAI,OAAO,IAAI,MAAM,CAEpB;IAED,IAAI,OAAO,IAAI,MAAM,CAEpB;IAED,OAAO,CAAC,YAAY;IAoBpB,OAAO,CAAC,gBAAgB;IA4CxB;;;;;;;;OAQG;IACG,gBAAgB,IAAI,OAAO,CAAC,MAAM,CAAC;IA2BnC,OAAO,CAAC,CAAC,EAAE,OAAO,EAAE,cAAc,GAAG,OAAO,CAAC,CAAC,CAAC;IA8JrD;;;;OAIG;IACG,aAAa,CAAC,OAAO,EAAE,cAAc,GAAG,OAAO,CAAC,QAAQ,CAAC;IA2F/D,OAAO,CAAC,QAAQ;CA8DjB"}
+{"version":3,"file":"harness-client.d.ts","sourceRoot":"","sources":["../../src/client/harness-client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,MAAM,EAA6C,MAAM,cAAc,CAAC;AACtF,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,YAAY,CAAC;AAuJjD;;;;GAIG;AACH,MAAM,MAAM,iBAAiB,GAAG,MAAM,MAAM,GAAG,SAAS,CAAC;AAEzD,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAS;IACjC,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAS;IAC/B,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAS;IACnC,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAS;IACjC,OAAO,CAAC,QAAQ,CAAC,UAAU,CAAS;IACpC,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAc;IAC1C,OAAO,CAAC,QAAQ,CAAC,eAAe,CAAU;IAC1C,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAqB;IAC/C,OAAO,CAAC,QAAQ,CAAC,OAAO,CAA6B;IACrD,OAAO,CAAC,iBAAiB,CAAC,CAAoB;IAC9C,OAAO,CAAC,aAAa,CAAC,CAAS;IAC/B,OAAO,CAAC,kBAAkB,CAAC,CAAkB;gBAEjC,MAAM,EAAE,MAAM;IAY1B;;;OAGG;IACH,oBAAoB,CAAC,QAAQ,EAAE,iBAAiB,GAAG,IAAI;IAIvD,6EAA6E;IAC7E,OAAO,CAAC,gBAAgB;IAIxB,IAAI,OAAO,IAAI,MAAM,CAEpB;IAED,IAAI,OAAO,IAAI,MAAM,CAEpB;IAED,OAAO,CAAC,YAAY;IAoBpB,OAAO,CAAC,gBAAgB;IA4CxB;;;;;;;;OAQG;IACG,gBAAgB,IAAI,OAAO,CAAC,MAAM,CAAC;IA2BnC,OAAO,CAAC,CAAC,EAAE,OAAO,EAAE,cAAc,GAAG,OAAO,CAAC,CAAC,CAAC;IAwJrD;;;;OAIG;IACG,aAAa,CAAC,OAAO,EAAE,cAAc,GAAG,OAAO,CAAC,QAAQ,CAAC;IA2F/D,OAAO,CAAC,QAAQ;CA8DjB"}

package/build/client/harness-client.js

@@ -99,8 +99,36 @@ const ERROR_FIELD_ENRICHMENTS = [
     { pathPrefix: "/chaos/", field: "description" },
     { pathPrefix: "/loadTest/", field: "description" },
 ];
+const MAX_ERROR_DETAIL_CHARS = 400;
+/** Extra NG fields (`details`, `detailedMessage`, `responseMessages`) not already in `message`. */
+function collectErrorDetail(parsed, message) {
+    const seen = new Set([message.trim()]);
+    const extras = [];
+    const add = (value) => {
+        if (typeof value !== "string")
+            return;
+        const text = value.trim();
+        if (!text || seen.has(text))
+            return;
+        seen.add(text);
+        extras.push(text);
+    };
+    add(parsed.details);
+    add(parsed.detailedMessage);
+    for (const entry of Array.isArray(parsed.responseMessages) ? parsed.responseMessages : []) {
+        if (entry && typeof entry === "object")
+            add(entry.message);
+    }
+    if (extras.length === 0)
+        return undefined;
+    const detail = extras.join("; ");
+    return detail.length > MAX_ERROR_DETAIL_CHARS
+        ? `${detail.slice(0, MAX_ERROR_DETAIL_CHARS)}…`
+        : detail;
+}
 function enrichErrorMessage(rawMessage, parsed, path) {
-    let message = rawMessage;
+    const detail = collectErrorDetail(parsed, rawMessage);
+    let message = detail ? `${rawMessage} — ${detail}` : rawMessage;
     for (const { pathPrefix, field } of ERROR_FIELD_ENRICHMENTS) {
         const value = parsed[field];
         if (path.startsWith(pathPrefix) && typeof value === "string" && value) {
@@ -317,10 +345,6 @@ export class HarnessClient {
                     }
                     throw error;
                 }
-                // 204 No Content — valid success response (e.g. PATCH/DELETE on PM API)
-                if (response.status === 204) {
-                    return { status: "SUCCESS", message: "No content" };
-                }
                 // Binary response mode — return raw ArrayBuffer (used for ZIP downloads)
                 if (options.responseType === "buffer") {
                     const buffer = await response.arrayBuffer();
@@ -328,8 +352,10 @@ export class HarnessClient {
                     return buffer;
                 }
                 const text = await response.text();
+                // Empty body on 2xx is a valid success (204 No Content; also 201 from
+                // IaCM provider-registry create/update version, which returns no JSON).
                 if (!text) {
-                    throw new HarnessApiError(`Empty response body from ${method} ${options.path}`, 502);
+                    return { status: "SUCCESS", message: "No content" };
                 }
                 let data;
                 try {