createCollection/putCollection silently strip event scripts from requests inside folders

[manders42]

Summary

The zod input schemas for createCollection and putCollection declare the event property (pre-request and test scripts) on collection-level events and on top-level items, but not on items nested inside folders. Because zod strips undeclared keys by default, any scripts attached to a request that lives in a folder are removed before the request reaches the Postman API. The tool call succeeds, the collection is created or updated, and nothing in the response indicates that the scripts were dropped.

layout: requests organized into folders.
We hit it while maintaining a QA collection whose requests chain environment variables through test scripts. The collection worked when authored, and every subsequent MCP update silently deleted all of its scripts. We only noticed when a teammate ran the collection and the variable chaining was gone.

Reproduction

Call createCollection with scripts at three placements:

{
  "info": { "name": "script probe", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" },
  "event": [
    { "listen": "prerequest", "script": { "type": "text/javascript", "exec": ["console.log('collection level');"] } }
  ],
  "item": [
    {
      "name": "top-level request",
      "event": [
        { "listen": "test", "script": { "type": "text/javascript", "exec": ["console.log('top level');"] } }
      ],
      "request": { "method": "GET", "url": "https://postman-echo.com/get" }
    },
    {
      "name": "folder",
      "item": [
        {
          "name": "nested request",
          "event": [
            { "listen": "test", "script": { "type": "text/javascript", "exec": ["console.log('nested');"] } }
          ],
          "request": { "method": "GET", "url": "https://postman-echo.com/get" }
        }
      ]
    }
  ]
}

Then read the collection back with getCollection using model: "full".

Observed: the collection-level event and the top-level request's event are present. The nested request has no event key at all. The same happens on putCollection.

Expected: either the nested request keeps its scripts, or the tool rejects or warns about input it cannot preserve. Silent removal is the worst of the options because the caller has no way to know anything was lost.

Where the gap is visible

I understand from CONTRIBUTING.md that src/tools/*.ts are generated from your OpenAPI definitions and that schema problems should be reported as the desired change rather than patched in the generated files, so the file references below are evidence of the gap, not a request to hand-edit them.

In the generated src/tools/putCollection.ts, the event property is declared at the collection level (around line 892) and on the top-level item schema (around line 90). The recursive item schema used for folder contents declares name, request, url, auth, and nested item, but never event. The generated src/tools/createCollection.ts has the same shape (declarations around lines 56 and 803, nothing for nested items). Since the schemas do not use passthrough, zod's default object behavior strips the undeclared event key from every nested item during input validation, before the API call is made.

The nested item schemas also thin out auth (the nested declaration keeps only type and drops the credential parameter arrays), which loses request-level auth overrides the same way.

Desired change

In the source definitions these tools are generated from, folder-nested items should accept the same event property that top-level items accept (and ideally the full auth shape), so scripts on requests inside folders survive createCollection and putCollection. If preserving unknown keys is easier than extending the schema, a passthrough on nested items would also stop the data loss, at the cost of looser validation. Failing either, rejecting input that contains nested event blocks would at least make the limitation visible instead of silent.

Environment

• Server: Postman MCP server (hosted), observed on both the minimal (~42 tool) and full (~124 tool) toolsets
• Client: Claude Code via the claude.ai Postman connector
• OS: macOS (Darwin 25.5.0), though the behavior is input-schema validation on the server side and should be independent of client OS and transport
• Date observed: 2026-07-21, root-caused against the repo source on 2026-07-22

[RounakKumarAgarwal]

I would like to work on this , could you assign this to me? @manders42

[christosgkoros]

Thanks @manders42 — your root-cause analysis was spot on, and a fix is now in review internally. It'll reach this repo through the usual sync once it merges.

We confirmed the API side first: POST /collections with an event on a folder-nested request, and with full auth credentials on that request, is accepted and persisted fine. So nothing was being rejected upstream — the scripts were being stripped by input validation before the call was ever made, exactly as you diagnosed.

The fix is in the source definitions the tools are generated from, not the generated files:

• The nested-item schema now declares event at every folder depth, so scripts on requests inside folders survive createCollection and putCollection.
• Nested item, request, and auth objects now accept unknown keys, so request-level auth keeps its full credential arrays instead of being thinned to just type — and other Collection Format fields on nested items stop being dropped too.

We declared event explicitly rather than relying only on passthrough, so it stays visible to a model reading the tool schema instead of being an undocumented key that happens to work.

Regression tests run against a real collection and cover scripts at collection level, on a top-level request, and on a folder-nested request, for both tools. The putCollection test is your exact scenario: read a collection back and write it out again, then assert the nested scripts are still there.

Sorry about the silent data loss — you're right that it's the worst failure mode. Worth noting that #150 reported a related loss on updateCollectionRequest, where updating one script type deleted the others; different mechanism, same outcome, and both are fixed together.