Zero Conflicts, Wrong Price: Validate MongoDB Agent Catalog Changes

A MongoDB merge plan can have zero conflicts and still contain the wrong price. Conflict detection asks whether changes collide. Your application must also decide whether the proposed document satisfies its business rules.

We tested that distinction with a synthetic catalog, Argon's public MCP server and real MongoDB writes. A correct discount was merged. Four invalid proposals were rejected before applying their plans, and the parent collection stayed unchanged. The validator is Python application code; it is not a built-in Argon policy or approval service.

Why catalog enrichment needs a separate check

MongoDB's October 13 catalog enrichment article describes richer product context and consistency across product feeds, APIs and product pages. That is useful engineering background for an agent that proposes catalog updates. It does not establish that generated values are correct, or that this example improves search traffic.

Our earlier MCP sandbox tutorial demonstrates the create, preview, apply and discard sequence. Here we add a narrow acceptance contract and deliberately bad proposals. The new question is: what must a reviewer check even when the merge engine reports no conflict?

A contract small enough to inspect

The parent starts with one product: shoe, priced at 4,900 integer cents in USD. The task may add a discount and its derived sale price. It may not change the original price or currency, add another product, delete the product or introduce another field.

{ "_id": "shoe", "price_cents": 4900, "currency": "USD" }

A discount of 1,000 basis points means ten percent. This fixture uses an explicit rounding-down policy:

sale_price_cents = price_cents * (10000 - discount_bps) // 10000
# 4900 * 9000 // 10000 = 4410

Real catalogs need their own currency, tax and rounding rules. This calculation is only the declared policy for the synthetic example.

Inspect the saved plan, not just its summary

The script creates its own project and sandbox, writes through PyMongo, and requests argon_merge_preview. The MCP response provides a plan ID and counts. It then reads that same saved plan with the public argon merge list CLI to inspect the before and proposed documents. It does not generate a second preview and accidentally review a different plan.

1. Require a pending plan without conflicts and exactly one change.
2. Require an update of products/shoe, with the expected before document and no deletion.
3. Require exactly the five allowed fields and unchanged original values and types.
4. Require an integer discount between 0 and 10,000 basis points, and an integer sale price matching the declared formula.
5. Apply only when the rejection list is empty. Otherwise discard the sandbox.

Missing keys and unexpected types fail closed. In particular, Python booleans are not accepted as integer prices or discounts. The checks use explicit conditionals rather than assert, so Python's -O mode cannot remove the acceptance rules.

The script also reads the entire parent product collection before the decision and after cleanup. Checking only the intended product could miss an unwanted extra document.

Run the five cases locally

Use Python 3.12 or later, the Argon 2.1.4 CLI, and a disposable local MongoDB replica set. Follow the installation guide and the MCP tutorial's local replica-set setup. The script refuses remote hosts and credentials. Do not point it at production.

Download catalog_review.py. It is self-contained, needs no model or API key, and writes protocol messages, the reviewed plan and a summary into a new directory for every run.

python3 -m venv .venv
. .venv/bin/activate
python -m pip install "pymongo>=4.6,<5"
argon --version # expected: argon version 2.1.4

export ARGON_TEST_MONGODB_URI="mongodb://localhost:27017/?replicaSet=rs0"
for scenario in valid invalid-value unexpected-field extra-document delete-document; do
  python -O catalog_review.py --scenario "$scenario" --expected-version 2.1.4 --output-dir "catalog-$scenario" || break
done

The valid scenario automatically applies its plan to its own synthetic parent. Each invalid scenario must be rejected for the run to pass. A rejected proposal is an expected test outcome, not a script failure. A mismatch, protocol failure or cleanup failure exits unsuccessfully. Use fresh output paths for another run.

Observed results

These five cases were executed on November 3, 2026 with public Argon 2.1.4, MongoDB 7.0.43, Python 3.12.14 and PyMongo 4.19.0 on macOS arm64, including Python optimization mode. These are scripted fixture results, not a model evaluation or a performance benchmark.

Only the valid run sent argon_merge_apply. All five runs discarded their sandbox and removed their owned fixture databases. Removing a sandbox after a successful merge does not reverse the parent change; the script verifies that separately before removing its synthetic parent during final cleanup.

What this does not prove

The validator is intentionally specific to one task. It does not judge whether a product description is truthful, whether a proposed discount is commercially sensible, or whether an agent is authorized to make it. Anyone who can bypass this application and call the underlying write or merge tools can bypass its rules. Keep production credentials and apply permissions under an appropriate access-control design.

The experiment also has no concurrent writers. Reading a plan and checking a parent is not an atomic authorization boundary, and this test makes no guarantee about changes arriving between validation and apply. Evaluate those races separately for your deployment. For competing edits, start with the two-agent conflict walkthrough; for operational limits, read Argon's capability boundaries.

The useful separation is concrete: use branching to isolate the proposal, inspect the persisted plan to see its scope, and use explicit application rules to decide whether its data is acceptable. Zero conflicts answers only one of those questions.