Chaos: Adding a few MCP endpointSpec and some refactoring & fixes

[priyanshuagarwal-harness]

Description

• Modified & improved existing Chaos MCP endpointSpecs
• Descriptions are enriched for existing endpointSpecs
• Added a few new Chaos related MCP EndpointSpecs like chaos_component_variable, chaos_experiment (create), discovered_network_map, etc.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other

Checklist

• Tests pass
• Typecheck passes

[CLAassistant]

All committers have signed the CLA.

[cursor]

Stale comment

Found 4 issues against the architecture standard.

• High: src/registry/toolsets/chaos.ts now swallows malformed JSON in coerceBody(), which lets bad string bodies reach write actions with defaulted values instead of failing locally.
• High: src/registry/toolsets/chaos.ts exposes chaos_application_map.get without validating the composite {environment_id, infra_id} key, even though the new description says missing either yields a backend 500.
• Medium: src/registry/toolsets/chaos.ts overwrites explicit runtime_inputs when experiment_variables or tasks are also present, silently dropping caller data.
• Medium: src/registry/toolsets/chaos.ts marks chaos_experiment.create.bodySchema.id as required even though the builder auto-generates it, so the agent-facing structured contract is stricter than runtime.

Assumptions:

• None beyond the behavior reproduced from the PR head.

Change summary:

• The Chaos expansion is useful and the branch builds/tests cleanly, but the four items above still miss Sunil’s fail-loud + metadata/runtime-alignment bar.

Verification:

• pnpm build
• pnpm test -- --runInBand tests/registry/chaos-experiment.test.ts (Vitest actually ran the full suite: 57 files / 1354 tests passed)
• pnpm docs:check
• Local repro scripts against origin/pr-218 confirmed the malformed-body, missing-app-map-scope, and runtime_inputs overwrite behaviors.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

coerceBody() currently swallows malformed JSON and keeps going as if the body were an object. I reproduced this on the PR head with registry.dispatchExecute(..., 'chaos_probe', 'enable', { body: '{bad json' }), and it still emitted a real write request with {"isEnabled": true}. For this repo's fail-loud standard, I think this helper needs to throw on parse failure instead of falling through.

[cursor]

The builder below auto-generates id when it is absent, but the structured schema marks it required: true. That means harness_describe / elicitation will tell agents they must provide an ID even though runtime does not need one. Can we make this field optional in bodySchema so the metadata stays aligned with the actual request builder?

[cursor]

This assignment overwrites any caller-supplied runtime_inputs from lines 316-317. I reproduced it on the PR head: passing both runtime_inputs and experiment_variables drops the original runtime_inputs object completely. We should either merge the two representations or reject mixed usage, otherwise the shared-tool contract silently loses data.

[cursor]

The new description says environment_id + infra_id are effectively required here because the backend lookup is keyed on all three values, but there is still no local validation. I verified that registry.dispatch(client, 'chaos_application_map', 'get', { map_id: 'map-1' }) emits a request with neither query param, which pushes callers into the backend 500 path instead of failing locally with a clear missing-parameter error.

[cursor]

Stale comment

Found 3 architecture issues worth fixing before merge:

1. chaos_dr_test.list now parses the wrong response envelope and will silently return empty results.
2. coerceBody() swallows malformed JSON on mutation paths, so bad agent input can turn into defaulted writes instead of a clear validation error.
3. chaos_application_map.get documents environment_id + infra_id as required but never validates them locally, so callers still hit the backend 500 described in the docs.

I also noticed CI already has a red build-and-test (22) shard (docs:check exited 1), but I stopped at the architecture blockers above.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

Changing this parser from { drtests: [...] } to { items, pagination } looks like a regression. The DR-test API docs still return drtests, and main was parsing that shape. With a real response like { drtests: [...] }, this now produces { items: [], total: 0 }, so chaos_dr_test.list silently empties out instead of failing loudly. If the backend contract hasn't changed, this extractor (and the updated descListDRTests pagination prose) should stay on the drtests envelope.

[cursor]

Swallowing JSON.parse failures here violates the fail-loud rule for write paths. A malformed string body now falls through as a plain string, and callers with defaults like chaos_probe.enable / verify still build valid mutation payloads ({ isEnabled: true }, { verify: true }) instead of rejecting bad input locally. Can we throw an actionable error for invalid JSON strings rather than catch {} and continue?

[cursor]

This spec already knows environment_id + infra_id are required for get (descGetApplicationMap says missing either one yields a backend mongo: no documents 500), but nothing here enforces that locally. Registry.dispatch() only checks required listFilterFields on list and required bodySchema fields on the built body, so harness_get(resource_type="chaos_application_map", resource_id=...) without both params still goes straight to that backend 500. I'd add a local guard/preflight so the contract fails loudly.

[cursor]

Found 3 architecture issues worth fixing before merge:

1. High: chaosDRTestListExtract() now expects { items, pagination }, but the published GET /v3/dr-tests contract still returns drtests. On this head, chaosDRTestListExtract({ drtests:[{ identity:"dr1" }], pagination:{ totalItems:1 } }) returns {"items":[],"total":1}, so chaos_dr_test.list silently drops real results.
2. High: the new shared coerceBody() helper swallows JSON parse failures and can turn malformed string bodies into real writes. Repro on this head: dispatchExecute("chaos_probe","verify",{ body:"{" }) emits { verify: true } instead of failing locally.
3. Medium: chaos_application_map.get now documents environment_id + infra_id as required, but the resource still doesn’t validate them before dispatch. Repro on this head issues /applicationmaps/{id} with only org/project params, so callers still hit the backend error path the description warns about.

Assumptions:

• Reviewed against the current PR head ab341469 from the contributor fork and the public Harness API docs for DR tests and application maps.

Change summary:

• The README/docs refresh is now in sync, the POST + page.totalItems application-map list wiring matches the public API docs, and the focused local checks passed.

Verification:

• pnpm build
• pnpm docs:check
• pnpm test tests/registry/chaos-probe.test.ts
• Targeted node --input-type=module repros against the built registry/extractors for the three items above

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

The published GET /v3/dr-tests contract still returns the list under drtests, not items. On this PR head, the built extractor reproduces the regression:

chaosDRTestListExtract({ drtests: [{ identity: "dr1" }], pagination: { totalItems: 1 } })
// => { items: [], total: 1 }

That means chaos_dr_test.list will silently drop real results, which misses the fail-loud / contract-alignment bar. Can we keep reading drtests here (and optionally pagination.totalItems) until the API contract actually changes?

[cursor]

This helper improves the valid double-serialized case, but the empty catch means malformed JSON still falls through as a string. On mutation paths with defaults, that becomes a real write instead of a local validation error. Example on this head:

await reg.dispatchExecute(client, "chaos_probe", "verify", {
  probe_id: "probe-1",
  org_id: "org",
  project_id: "proj",
  body: "{",
});
// request body => { verify: true }

That misses Sunil's fail-loud standard. Could we rethrow when input.body is a string that fails JSON.parse(), rather than silently treating it as an object?

[cursor]

The new description correctly documents environment_id + infra_id as required for chaos_application_map.get, but the resource still doesn't enforce them locally. Repro on this head:

await reg.dispatch(client, "chaos_application_map", "get", {
  map_id: "map-1",
  org_id: "org",
  project_id: "proj",
});
// params => { organizationIdentifier: "org", projectIdentifier: "proj" }

So agents still fall through to the backend error path the description warns about. Can we add a local guard for the composite key before dispatch?