An environment‑aware upgrade context MCP server with an Upgrade Agent that supercharges your AI coding assistant to open precise, review‑ready IaC pull requests—safely, transparently, and in minutes.

Today we’re announcing Cursor × Chkk Upgrade Context Server + Upgrade Agent in Public Preview. Initial support focuses on Helm IaC across 260+ open‑source projects. Upgrade Context MCP Server and Upgrade Agent support a wide range of OSS projects, including Networking (Istio, Cilium, ..), Databases (PostgreSQL, Redis, ..), Data Jobs (Argo Workflows, Jenkins, ..), Data Streams (Kafka, RabbitMQ, ..), Observability (Datadog, Grafana, ..), Security (cert-manager, Kyverno, ..), Autoscaling (Karpenter, KEDA, ..), and Developer Tooling (ArgoCD, Bitbucket, ..).

Minimal Relevant Context, At the Right Time

Upgrade Context is an MCP‑compatible server that connects Chkk’s understanding of your running environment with your IDE. It identifies the components requiring upgrades based on EOL, compatibility and other criteria, recommends a compatible, stable target version (not just the newest) for the required upgrades, explains why the upgrade is warranted, and vends an environment‑specific PR creation workflow, equipped with source-grounded, task-specific agents for IaC pattern detection, Helm/CRD/RBAC diffs, accurate ordering, and safety guardrails Your Coding Assistant holds the pen and opens the PR.

Why It Matters

The hard part of upgrade work isn’t syntax—it’s choosing a version that will hold in production and surfacing the implications where reviewers can act on them. Chkk Upgrade Context Server + Upgrade Agent focus on those two problems.

• Version recommendations are computed against your constraints and policies so targets are compatible and stable, not simply recent.
• Diffs are scoped to what you actually run, with ordering and selectors that make changes deterministic and auditable.
• Breaking changes, critical fixes, and upgrade considerations appear next to the change, so reviews move quickly and confidently.

The effect is cumulative: planning takes minutes, PRs arrive review‑ready, and execution windows stop slipping.

How the Upgrade Workflow Flows in Cursor

Connect your environment to Chkk and generate an Upgrade Plan. From the Cursor IDE, ask the Chkk Upgrade MCPAgent to fetch Upgrade Context from that plan for the OSS project you’re about to change—say cert‑manager or External Secrets Operator. The agent retrieves the recommended target version and rationale, detects your IaC pattern, identifies which files need to be updated, creates an environment‑specific diff, and attaches the notes reviewers want (deprecations, critical fixes, notable features). Your IDE applies the diff and opens the PR, with optional preflight and postflight checks to keep code and running state aligned.

The entire flow happens in your Cursor editor chat, end-to-end. Below is exactly what you’ll see, phase by phase, using a live example that upgrades cert-manager from v1.14.4 → v1.17.2 with a forked Helm chart.

Step 1: Kickoff & ID Handshake

What you do: You connect Chkk Upgrade Context MCP server to Cursor. In Cursor Chat, you invoke the PR creation workflow (e.g., “Use the Chkk upgrade agent to apply the IaC changes. Start by asking for the upgrade ID.”).
What you see: The agent asks you for the upgrade_id—a single natural key that ties your request to a Chkk Upgrade Plan (precomputed for your environment).

Why it matters: The upgrade_id is how the agent fetches the precise context– including resources, subagents and diffs–for your cluster constraints, not “generic upstream.”

Step 2: Environment Snapshot & State Setup

What you do: Provide the upgrade_id.
What you see: The agent resolves plan metadata immediately (package name and from/to versions) and prepares a safe workspace:

• Confirms the package (e.g., cert-manager) and version span (1.14.4 → 1.17.2).
• Creates a project-local scratchpad (e.g., .chkk/scratchpad/) which enables workflow tracing and checkpointing.

Why it matters: This isolates automation artifacts from your source tree while keeping a local, inspectable record of every change.

Step 3: Context Retrieval (MCP Tool Call)

What you do: Nothing; the agent drives.
What you see: A short progress line—“Now fetching the context”. The Context contains:

• The authoritative Upgrade Plan for cert-manager.
• Exact file artifacts to add and unified diff files to apply.

Step 4: Plan Load & Sanity Summary

What you do: Nothing; the agent reads the plan.
What you see: Compact, human-readable instructions from the plan:

• Upgrade Details: cert-manager v1.14.4 → v1.17.2
• Reasons: e.g., “1.14.4 is EOL/Unsupported” and “1.14.4 incompatible with Kubernetes 1.32.”
• Inventory: Added: 2 files, Modified: 23 files, Deleted: 0 (your counts will vary by package).

Why it matters: This is the first concrete signal that the plan is environment-aware (incompatible K8s version, distro nuances, etc.) and scoped to what you actually run.

Step 5: Target Locator (Chart Finder)

What you do: Nothing, unless you have multiple candidates.
What you see: The agent identifies your IaC repo pattern and locates the exact Helm chart root for the package/version you’re on (e.g., .../helm/cert-manager/) by scanning for Chart.yaml where name == cert-manager and version == 1.14.4 (exact, case-sensitive).

Edge cases you might see:

• Multiple matches: You’ll get a list of absolute paths and a prompt to choose one—no guessing.
• No match: The agent asks for an explicit absolute path (it won’t “best-effort” a wrong chart).

Step 6: Preflight Checks

What you do: Review pass/fail lines.
What you see: Two precise checks with ✅/❌ outcomes:

1. Chart Name & Version Match — confirms Chart.yaml matches the current package & version.
2. Upgrade Plan Metadata Match — confirms the plan’s from/to are consistent with resolved metadata.

Why it matters: Preflight checks safeguard against pointing the patcher at the wrong subtree or the wrong plan. Any failure stops the run until fixed.

Step 7: Reviewer Context, Upfront

What you do: Skim.
What you see: The agent surfaces the “why”—the exact notes reviewers care about:

• Critical drivers (e.g., EOL, K8s version compatibility).
• Breaking changes (e.g., structured logging, stricter Helm schema validation, API removals).
• Security & bug fixes (e.g., DoS mitigations, renewal logic).
• Notable features (e.g., Gateway API support, metrics exposure).

Why it matters: Your future PR will inherit these callouts so reviewers don’t need to hunt docs to understand risk, scope and impact.

Step 8: Deterministic Apply Pass

What you do: Watch the live counter; no prompts needed.
What you see: A strict, linear, and complete application of the plan:

• Full inventory printout:
  “Processing 25 total files: 2 added, 23 modified, 0 deleted”
  
  
• Adds: Each source file from the context is copied to the correct relative target (e.g., templates/cainjector-service.yaml, templates/extras-objects.yaml) with immediate ✅ Added confirmations.
  
  
• Mods: Every single *.diff is applied one-by-one with a visible sequence:
  “Processing diff 1 of 23: Chart.yaml … ✅ Modified”
  “Processing diff 2 of 23: README.md … ✅ Modified”
  …through to the last template/value file.
  
  
• Deletions: If any exist, they’re backed up to .bak, then removed with ✅ Deleted confirmations.

Step 10: CRD Copy

What you do: Nothing.
What you see: If the context includes CRDs, the agent copies them into the target CRD directory and prints the exact path used.

Why it matters: Reviewers see CRD changes alongside template and values edits.

Step 11: Update Custom Resources

What you do: Nothing.
What you see: If the plan includes Custom Resources, they’re edited based on the changes in the CRD schema.

Why it matters: Custom Resources are validated against their CRDs; migrating specs to the new schema (handling renamed/deprecated fields and default changes) prevents admission failures, reconcile churn, and subtle behavior drift during rollout.

Step 12: Postflight Checks (Hard Gates)

What you do: Review.
What you see: Two final gates:

1. Chart version updated — Chart.yaml version == to_version (e.g., v1.17.2) → ✅/❌
2. All planned changes applied — match exactly and all items carry ✅ → ✅/❌

Any failure here stops the flow and lists the exact mismatches.

Step 13: Human-Readable Summary (PR-Ready)

What you do: Read once; this becomes your PR body.
What you see: A concise, celebratory completion message (never “upgraded,” always “IaC updated”), plus reviewer-focused details:

• Completion: “🎉 cert-manager IaC Successfully Updated — v1.14.4 → v1.17.2.”
• Reasons (EOL, K8s compatibility) and most-critical notes (breaking changes, security fixes).
• Applied changes (counts + important files).
• CRD location (exact path).
• Next step: “Create a Pull Request to review and apply these IaC changes.”

Availability and How to Start

Enable Chkk Upgrade Context MCP in your IDE. Ask your Coding Assistant to fetch Upgrade Context for the component you’re upgrading, and watch it open the PR in minutes.

What’s Coming Next

• More Coding Assistants: We’ll be announcing support for Claude Code, GitHub Copilot, and other MCP‑capable IDEs in the coming days and weeks.
• More IaC formats: We’re expanding beyond Helm with support for Terraform, Kustomize overlays, raw Kubernetes YAML, and others, rolling out over the same period.