Review an MCP configuration change

Work through a synthetic package upgrade that also changes a local path, adds an environment key and introduces a remote endpoint.

Configuration review starts with a narrower question than “is this server safe?” Ask which launch or connection instructions changed, and whether the existing approval still covers them. This example is synthetic. Its package name and endpoints are not recommendations.

The existing configuration

{
  "mcpServers": {
    "notes": {
      "command": "npx",
      "args": [
        "--yes",
        "@example/notes-mcp@1.2.0",
        "/project/notes"
      ],
      "env": {
        "NOTES_TOKEN": "synthetic-old-value"
      }
    }
  }
}

The notes entry uses a package runner, an explicit version string and a project subdirectory argument. The configuration alone does not show what that directory argument means to the package, whether it is enforced, or what the process inherits.

The proposed configuration

{
  "mcpServers": {
    "notes": {
      "command": "npx",
      "args": [
        "--yes",
        "@example/notes-mcp@1.3.0",
        "/project"
      ],
      "env": {
        "NOTES_TOKEN": "synthetic-new-value",
        "WRITE_ENABLED": "true"
      }
    },
    "archive": {
      "url": "http://archive.example.test/mcp?token=synthetic-token"
    }
  }
}

Use Load worked example with Client config selected to reproduce the comparison. The output suppresses these values. Keep this synthetic source visible here to understand what each changed path represents.

Four review questions

1. What changed in the package? The argument at /mcpServers/notes/args/1 changes from version 1.2.0 to 1.3.0. Review provenance, release notes and the resolved artifact privately. The PACKAGE-RUNNER rule asks about versioning; it does not resolve or audit a dependency.
2. Does the broader path expand access? The next argument changes from /project/notes to /project. This is launch-input evidence. Confirm the package's interpretation and the operating system boundary before calling it a permission increase.
3. What does the new environment variable enable? WRITE_ENABLED is added and NOTES_TOKEN changes. The report retains the key names and change status without their values. Confirm scope, write behavior and credential ownership separately.
4. Who operates the new endpoint? The archive server is added with a non-loopback HTTP URL. The report shows its origin and prompts about plaintext transport. Its path and query token are hidden. It has not been contacted.

Why existing settings still produce prompts

LOCAL-EXECUTION and PACKAGE-RUNNER describe the proposed snapshot even when the command is unchanged. They are context for an approval, not newly discovered vulnerabilities. A page with zero changed fields can still contain these prompts.

The MCP local-server guidance discusses execution consent and restricted access. This workbench never launches a server, and its redacted display is not a substitute for reviewing the full command in your trusted client before execution.

A useful handoff for this example

Evidence: synthetic before/after mcpServers JSON
Owner: assign a real maintainer
Observed: package argument and path changed; environment key added;
          token value changed; new HTTP endpoint configured
Unresolved: package provenance, path enforcement, token scope,
            endpoint ownership and transport requirements
Decision: pending private inspection and scoped approval

Avoid “two high risks” or “safe after upgrade.” The available evidence supports neither a calibrated severity score nor a security verdict. Continue with the approval handoff checklist.