AI DevOps Sidekick with MCP Servers
Deploy apps to Kubernetes using 5 MCP servers and natural language prompts.
Introduction
30 Second Summary
Deploying an application used to mean days of learning Kubernetes, writing YAML by hand, and debugging cryptic error messages. What if your AI assistant could handle all of that for you, as long as it had the right context?
In this project, you will wire up 5 MCP servers into Cursor and use them together to deploy an application to a local Kubernetes cluster using nothing but natural language prompts.
What You'll Build
Imagine typing "deploy my web app" and watching your AI generate the correct Kubernetes manifests, write them to disk, and apply them to a live cluster in seconds.
By the end of this project, you'll have:
- A working multi-MCP-server DevOps co-pilot in Cursor that gives your AI simultaneous access to code, documentation, infrastructure data, a live Kubernetes cluster, and your filesystem.
- A containerized application deployed to Kubernetes entirely by AI with real infrastructure context, without writing any YAML yourself.
- Quantified benchmark data proving the MCP approach saves 99%+ tokens and reduces deployment time from hours to minutes compared to the traditional manual approach.
- Secret Mission: Deploy a multi-container pod with resource limits and health checks, using jDataMunch to enforce team deployment standards.
Are there any prerequisites?
You need Docker Desktop installed and running on Windows before starting this project. Everything else (Python, Node.js, Kind) is installed in Step 1.
Before We Start
Before we dive in, let's lock in what you're about to build and why it matters.
Install the Foundation
Your AI co-pilot needs three foundational tools before it can talk to a Kubernetes cluster. Python runs the jMunch MCP servers. Node.js runs the Kubernetes and Filesystem MCP servers. Kind creates a real Kubernetes cluster inside Docker so the AI has live infrastructure to manage.
In this step, you will install Python, Node.js, Kind, and kubectl, then spin up a local cluster. Once the cluster is running, your foundation is ready for the MCP servers in the next step.
In this step, get ready to:
- Install Python 3.12 and Node.js 22 LTS.
- Install Kind and kubectl.
- Create a local Kubernetes cluster named devops-copilot.
Install Python 3.12
Python 3.12 is the runtime for the jMunch MCP servers (jCodeMunch, jDocMunch, jDataMunch). Without it, those servers cannot start.
- Open your browser and go to python.org/downloads.
- Download the Python 3.12 installer for Windows.
- Run the installer.
- Check the box that says Add Python to PATH before clicking Install Now.
Why Add Python to PATH matters
Adding Python to PATH lets you run python from any terminal window. Without it, Windows will not recognize the command and the MCP servers will fail to start later.
- Once the installer finishes, open a new terminal by pressing the Windows key, typing PowerShell, and pressing Enter.
- Verify Python is installed by running:
python --version
✔️ I see Python 3.12 or higher
Python is ready to go. Move on to the next install below.
ⓧ I see a version lower than 3.12
Your system has an older Python that will not work with the jMunch packages. You need to install 3.12 alongside it.
- Go back to python.org/downloads and download the 3.12 installer specifically.
- Run it and ensure Add Python to PATH is checked.
- Close your current terminal and open a new one so the updated PATH takes effect.
- Run python --version again to confirm it shows 3.12 or higher.
ⓧ Command not found
Windows does not see the Python binary on your PATH.
- Re-run the installer from python.org/downloads.
- This time make sure you check Add Python to PATH at the very bottom of the first screen.
- Close your terminal completely and open a fresh PowerShell window.
- Run python --version again.
Install Node.js 22 LTS
Node.js powers the Kubernetes MCP server and the Filesystem MCP server. Both run via npx, which ships with Node.
- Open your browser and go to nodejs.org.
- Download the 22 LTS installer for Windows.
- Run the installer and accept the default settings.
- Close your current PowerShell terminal and open a new one so the PATH updates.
- Verify Node is installed by running:
node --version
✔️ I see version 22 or higher
Node.js is ready. Move on to installing Kind below.
ⓧ I see a version lower than 22
You have an older Node.js that may not support the MCP servers correctly.
- Go back to nodejs.org and download the 22 LTS installer.
- Run the installer. It will upgrade your existing Node.js in place.
- Close and reopen your terminal.
- Run node --version again to confirm it shows 22 or higher.
ⓧ Command not found
The Node.js binary is not on your PATH.
- Re-run the installer from nodejs.org. Accept all defaults (the installer adds Node to PATH automatically).
- Close your terminal completely and open a fresh PowerShell window.
- Run node --version again.
Install Kind and kubectl
Kind creates a Kubernetes cluster using Docker containers as nodes. kubectl is the command-line tool for talking to that cluster.
- Install Kind by running this command:
winget install Kubernetes.kind
What is Kind?
Kind stands for "Kubernetes IN Docker." It runs a full Kubernetes cluster inside a Docker container on your machine. Because you already have Docker Desktop, Kind can create a cluster in seconds with no extra virtualization.
- Verify Kind installed by running:
kind --version
Command not found after installing Kind?
Close your terminal and open a fresh PowerShell window. Winget installs may require a new terminal session for PATH changes to take effect.
Help me fix my PATH for Kind
- Install kubectl by running this command:
winget install Kubernetes.kubectl
- Close your terminal and open a new PowerShell window so both tools are on your PATH.
- Verify kubectl installed by running:
kubectl version --client
kubectl not recognized?
Make sure you opened a fresh terminal after the winget install. If it still fails, restart your computer to force Windows to reload PATH variables.
Help me troubleshoot kubectl on Windows
Create a local Kubernetes cluster
With Kind and kubectl ready, you can now spin up a real Kubernetes cluster that lives inside Docker. This is the cluster your AI co-pilot will deploy applications to.
- Make sure Docker Desktop is running (check the system tray for the Docker whale icon).
- Create your cluster by running this command:
kind create cluster --name devops-copilot
What does this command do?
Kind pulls a pre-built Docker image that contains everything Kubernetes needs. It spins up a single Docker container acting as your Kubernetes node and bootstraps a cluster named devops-copilot.
It also automatically configures kubectl to talk to this new cluster by updating your kubeconfig file.
The command takes 30-60 seconds. You will see output as Kind pulls the node image and sets up the cluster.
Before you run the next command, what do you expect to see when you ask kubectl about the nodes in your cluster?
- Verify the cluster is running by checking its nodes:
kubectl get nodes
You should see one node with a status of Ready. This confirms your local Kubernetes cluster is running inside Docker and kubectl can communicate with it.
Node shows NotReady or command fails?
If the node status says NotReady, wait 30 seconds and run kubectl get nodes again. The cluster needs a moment to finish starting.
If the command fails entirely, confirm Docker Desktop is running and that you see the Docker whale icon in your system tray. Kind cannot create clusters without Docker.
Help me fix my Kind cluster
Your foundation is solid. You have Python for the jMunch servers, Node.js for the Kubernetes and Filesystem servers, and a live Kubernetes cluster waiting for deployments. Next up, you will wire all five MCP servers into Cursor so your AI can actually see and interact with this cluster.
Wire Up the MCP Server Stack in Cursor
Your Kubernetes cluster is running and ready for workloads. Now you need to give your AI assistant the ability to actually interact with it.
Right now, the AI inside Cursor is completely blind. It cannot see your cluster, it cannot read documentation efficiently, and it cannot understand your code structure. In this step, you wire up 5 MCP servers that give it eyes and hands across code, docs, data, infrastructure, and your filesystem.
In this step, get ready to:
- Install the jMunch MCP server packages and the tool runner they depend on.
- Create the MCP configuration file that tells Cursor how to launch each server.
- Verify all 5 servers connect successfully in Cursor's settings.
Install the jMunch MCP servers
The jMunch suite is a family of three MCP servers that give AI token-efficient access to different types of information. You also need uv, a fast Python package runner that provides the uvx command Cursor uses to launch these servers.
- Install uv (which provides the uvx command) by running:
pip install uv
- Install all three jMunch MCP servers by running:
pip install jcodemunch-mcp jdocmunch-mcp "jdatamunch-mcp[all]"
- Confirm the installs succeeded by running:
uvx --version
You should see a version number printed, confirming uvx is available on your PATH.
What are these three servers?
- jCodeMunch indexes source code by symbol (functions, classes, imports) so the AI retrieves exact implementations instead of loading entire files.
- jDocMunch indexes documentation by section heading so the AI fetches only the relevant paragraph instead of an entire docs page.
- jDataMunch indexes tabular data (CSV, Excel, Parquet) so the AI queries specific rows and columns instead of loading the full dataset.
🙋♀️ Seeing 'pip is not recognized'?
- Make sure Python is on your PATH. Open a new terminal window and try again.
- If you installed Python 3.12 without checking "Add to PATH", re-run the installer and enable that option.
- Ask for help: Why is pip not recognized in my terminal after installing Python?
Create the Cursor MCP configuration
Cursor reads a JSON file at .cursor/mcp.json in your project root to know which MCP servers to launch. You need a project folder first.
- Move to your Desktop by running this command:
cd ~/Desktop
- Create your project folder and move into it by running these commands:
mkdir devops-copilot
cd devops-copilot
- Create the .cursor directory inside your project by running:
mkdir .cursor
- Confirm the folder structure by running:
ls
You should see .cursor listed in the output.
Now open the project in Cursor so you can create the configuration file.
- Press the Windows key to open your search bar.
- Type Cursor and press Enter to open it.
- In Cursor, click File in the top menu bar.
- Click Open Folder.
- Navigate to your Desktop and select the devops-copilot folder, then click Select Folder.
- In the Explorer sidebar on the left, right-click the .cursor folder.
- Click New File.
- Name the file mcp.json and press Enter.
- Paste the following configuration into mcp.json:
{
"mcpServers": {
"jcodemunch": {
"command": "uvx",
"args": ["jcodemunch-mcp"]
},
"jdocmunch": {
"command": "uvx",
"args": ["jdocmunch-mcp"]
},
"jdatamunch": {
"command": "uvx",
"args": ["jdatamunch-mcp"]
},
"kubernetes": {
"command": "npx",
"args": ["-y", "kubernetes-mcp-server@latest"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
}
}
}
What does this configuration do?
Each entry tells Cursor how to start one MCP server. The command field is the executable to run, and args are the arguments passed to it.
- The three jMunch servers use uvx to launch. This resolves packages on demand without PATH issues inside Cursor's restricted environment.
- The kubernetes server uses npx to run a native Go binary that talks directly to your cluster's API. It reads your kubeconfig automatically.
- The filesystem server uses npx to run the official reference implementation for secure file operations. The "." argument restricts access to your project directory.
- Save mcp.json with Ctrl+S.
Why uvx instead of running pip-installed packages directly?
Cursor runs with a restricted PATH that often cannot find pip-installed executables. The uvx command resolves and launches Python packages on demand, bypassing PATH issues entirely. This is why the config uses uvx for the Python-based servers and npx (the Node.js equivalent) for the JavaScript-based ones.
✔️ Awesome, I've got everything!
Great. Double check you have saved .cursor/mcp.json before moving on.
ⓧ I'd like to double check the full code
Your .cursor/mcp.json should contain exactly this:
{
"mcpServers": {
"jcodemunch": {
"command": "uvx",
"args": ["jcodemunch-mcp"]
},
"jdocmunch": {
"command": "uvx",
"args": ["jdocmunch-mcp"]
},
"jdatamunch": {
"command": "uvx",
"args": ["jdatamunch-mcp"]
},
"kubernetes": {
"command": "npx",
"args": ["-y", "kubernetes-mcp-server@latest"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
}
}
}
Restart Cursor and verify all servers connect
Cursor only reads the MCP configuration at startup. You need to fully restart it for the servers to launch.
- Close Cursor completely (not just the tab).
- Reopen Cursor using the Windows key search bar. Type Cursor and press Enter.
- Cursor should reopen with the devops-copilot folder still loaded. If not, open it again via File > Open Folder.
Before you check the settings, how many servers do you expect to see listed? What colour indicator means a server started successfully?
- Click File in the top menu bar.
- Click Preferences, then Cursor Settings.
- Select MCP from the left sidebar.
You should see all 5 servers listed: jcodemunch, jdocmunch, jdatamunch, kubernetes, and filesystem. Each one should have a green dot indicating it connected successfully.
Seeing a red dot on one or more servers?
- If a jMunch server (jcodemunch, jdocmunch, or jdatamunch) shows red, open a terminal and run uvx --version to confirm uvx is on your PATH. If it is not found, close Cursor, run pip install uv in a new terminal, then reopen Cursor.
- If the kubernetes server shows red, confirm Docker Desktop is running. Kind needs Docker to keep your cluster alive.
- If the filesystem server shows red, confirm Node.js is on your PATH by running node --version in a terminal. The npx command ships with Node.
- Ask for help: Why are my MCP servers showing a red status in Cursor after I configured mcp.json?
Your AI assistant now has eyes on your code, documentation, data, live cluster, and filesystem. Next up, you will load real knowledge into these servers so the AI can answer with precision instead of guessing.
Give Your AI Eyes - Index Docs and Query the Cluster
Your MCP servers are wired up and showing green in Cursor. The connections are live, but the AI has no actual knowledge loaded yet.
Right now, if you asked your AI about Kubernetes, it would fall back on generic training data. In this step, you'll feed it real content: official Kubernetes documentation, live cluster state, and your project's source code. By the end, your AI answers with precision and citations instead of guessing.
In this step, get ready to:
- Index Kubernetes documentation for searchable AI reference.
- Query your live cluster to prove infrastructure visibility.
- Create and index your application source code.
Index Kubernetes documentation with jDocMunch
jDocMunch indexes documentation by section and heading, so the AI retrieves just the relevant snippet instead of dumping an entire docs page into the context window.
- Switch to Cursor's AI chat panel (the chat sidebar).
- Type the following prompt and press Enter:
Use jdocmunch to index the Kubernetes documentation from the GitHub repo at https://github.com/kubernetes/website. Focus on the content/en/docs/concepts directory.
The AI calls the index_repo tool on jDocMunch. You'll see it working through the GitHub API to fetch and parse docs by heading.
What does this do?
jDocMunch's index_repo tool fetches documentation files from the specified GitHub repository via the GitHub API. It parses each file into individual sections by heading, stores them locally, and makes them searchable by title and content.
After indexing, the AI can call search_sections to find relevant doc snippets and get_section to retrieve the full content of a specific section. This means it pulls in only the 200-token paragraph it needs, not the entire 50,000-token docs page.
Wait for the AI to confirm indexing is complete. You should see a success message mentioning the number of documents and sections indexed.
Seeing a rate limit or timeout error?
The GitHub API limits unauthenticated requests to 60 per hour. If the indexing fails mid-way, set a GITHUB_TOKEN environment variable with a personal access token (no special scopes needed for public repos) and try again.
If Cursor's AI doesn't seem to use the jdocmunch tool at all, check that the server shows green in Settings > MCP.
Help me troubleshoot why jDocMunch indexing failed in Cursor.
Query your live cluster with Kubernetes MCP
Your AI can now read docs, but can it see your actual infrastructure? Let's prove it.
- In the same Cursor AI chat, type this prompt and press Enter:
Use the kubernetes MCP to list all namespaces and pods in my cluster.
The AI calls the Kubernetes MCP server, which talks directly to your Kind cluster's API. You should see a list of default namespaces and system pods.
What should I see?
The response lists your cluster's namespaces (default, kube-system, kube-public, kube-node-lease) and several system pods running in kube-system (like coredns, etcd, and kube-apiserver). These are the control plane components that make Kubernetes work.
No application pods appear yet because you haven't deployed anything. That changes in the next step.
🙋♀️ AI says it can't connect to the cluster?
The Kubernetes MCP server reads your kubeconfig from the default location. On Windows, this is %USERPROFILE%\.kube\config. Kind auto-creates this file when you ran kind create cluster in the previous step.
If the file is missing, run kind get kubeconfig --name devops-copilot in your terminal to regenerate it.
Help me fix the Kubernetes MCP connection to my Kind cluster.
Create application files and index with jCodeMunch
Now you need source code for the AI to understand. You'll create a simple Nginx application that the AI will deploy to your cluster in the next step.
- Create the app directory inside your project folder by running this command in your terminal:
mkdir app
- In Cursor's Explorer sidebar, right-click the new app folder and select New File.
- Name it Dockerfile and paste the following content:
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/
- Right-click the app folder again and create another new file named index.html:
<!DOCTYPE html>
<html>
<head><title>DevOps Co-Pilot</title></head>
<body>
<h1>Deployed by AI Co-Pilot</h1>
<p>This application was generated and deployed using 5 MCP servers working together.</p>
</body>
</html>
What do these files do?
The Dockerfile tells Docker to build an image based on Nginx (a lightweight web server) and copy your HTML page into it. The index.html is the page visitors see when the app is running.
Together, they form a complete deployable application. jCodeMunch will index these files so the AI understands your project structure when generating Kubernetes manifests.
- Save both files.
- Confirm the files exist by running:
ls app
You should see Dockerfile and index.html listed in the output.
- Now tell the AI to index your project. In Cursor's AI chat, type:
Use jcodemunch to index the current project directory.
The AI calls jCodeMunch's index_folder tool, which uses tree-sitter to parse your source files and extract structured symbols. It now knows exactly what's in your project without needing to read entire files each time.
jCodeMunch reports 0 files indexed?
This can happen if all files matched a built-in skip pattern. Make sure the app folder is inside the project root that Cursor has open. If you opened a different folder, close it and reopen the correct project folder.
Help me fix jCodeMunch indexing showing 0 files.
✔️ Awesome, I've got everything!
Great. Make sure both app/Dockerfile and app/index.html are saved.
ⓧ I'd like to double check the full code
Here's the complete content for each file:
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/
<!DOCTYPE html>
<html>
<head><title>DevOps Co-Pilot</title></head>
<body>
<h1>Deployed by AI Co-Pilot</h1>
<p>This application was generated and deployed using 5 MCP servers working together.</p>
</body>
</html>
Time to test the full loop. Before you run this next prompt, think about how the AI will respond differently now that jDocMunch is loaded with Kubernetes documentation.
- In Cursor's AI chat, ask:
What is a Kubernetes Deployment?
The AI responds with an exact documentation section from jDocMunch, including a section ID reference. This is not a generic training-data answer. It's a precise retrieval from the indexed Kubernetes docs.
Why does this matter?
Without jDocMunch, the AI would paraphrase from its training data, which could be outdated or imprecise. With jDocMunch loaded, it pulls the current official documentation and cites exactly which section it came from. You can verify the answer against the real docs.
This is the difference between an AI that guesses and an AI that knows.
Your AI co-pilot now has eyes across three domains: official Kubernetes documentation, live cluster state, and your project's source code. Next up, you'll put all of that context to work by asking the AI to actually deploy your application.
Deploy with AI - Hit the Wall
Your MCP servers are loaded with real context. The AI can read your Dockerfile, search Kubernetes documentation by section, and interact with your live cluster. It is time to put this system to the test with a real deployment request.
You will ask the AI to deploy your Nginx application end-to-end, from generating the manifest to applying it to your cluster. Along the way, you will run into a real limitation that every Kubernetes beginner hits.
In this step, get ready to:
- Ask your AI co-pilot to deploy the Nginx app using all available MCP context.
- Verify pods are running and test app accessibility.
- Discover the gap that catches every Kubernetes beginner.
Ask the AI to deploy your app
Your AI co-pilot now has access to everything it needs: your Dockerfile via jCodeMunch, Kubernetes deployment syntax via jDocMunch, the ability to write files via Filesystem MCP, and the ability to apply manifests via Kubernetes MCP. Time to give it a single deployment request and watch it coordinate.
- In Cursor's AI chat, enter the following prompt:
Deploy my Nginx app to the Kubernetes cluster. Write the manifest file and apply it. Use the Dockerfile in the app/ folder as context.
What should the AI do?
The AI coordinates across multiple MCP servers to fulfil this single request. It uses jCodeMunch to read your Dockerfile and understand the image. It uses jDocMunch to look up Deployment manifest syntax from the indexed Kubernetes docs. It writes a deployment.yaml file to your project using Filesystem MCP. Finally, it applies the manifest to your cluster using Kubernetes MCP.
Watch the AI's tool calls in the chat. You should see it invoke tools from at least 3 different MCP servers in sequence.
The AI writes a deployment.yaml file to your project root and applies it to your cluster. You should see confirmation messages in the chat indicating the Deployment was created.
AI not calling MCP tools?
If the AI generates a generic Kubernetes manifest without calling any MCP tools, it may not be routing to the correct servers. Try being more explicit in your prompt: mention jCodeMunch, jDocMunch, and Kubernetes MCP by name.
If MCP servers show as disconnected in Settings > MCP, restart Cursor and check that Python and Node are on your PATH.
Why isn't my AI using the MCP servers I configured?
Verify pods are running and access the app
The AI reported success, but you need to verify independently. Before you check, what do you think kubectl get pods will show?
- Ask the AI to check your deployment status by entering this prompt:
Check the status of my deployment using the kubernetes MCP.
The AI queries the Kubernetes MCP server and reports back. You should see your nginx-app pods with status Running.
- Confirm this yourself by running the following command in your terminal:
kubectl get pods
You should see a pod with a name starting with nginx-app and status Running. The AI and reality match.
- Now access the running app by port-forwarding from your local machine to the pod:
kubectl port-forward deployment/nginx-app 8080:80
What does this command do?
This creates a tunnel from port 8080 on your machine directly to port 80 on the pod managed by the nginx-app Deployment. It bypasses normal Kubernetes networking entirely. Think of it as reaching into the cluster and grabbing the pod directly.
The command will keep running in your terminal. You will need to leave it open while you test the app.
- Open your browser and go to http://localhost:8080.
You should see your page with the heading "Deployed by AI Co-Pilot". The app is alive and the AI deployed it correctly.
Page not loading at localhost:8080?
Make sure the kubectl port-forward command is still running in your terminal. If you see "connection refused", the command may have exited.
If the pod is not in Running state, the Deployment may have failed to pull the image. The AI-generated manifest should reference nginx:alpine directly (it does not build your local Dockerfile into a cluster image).
Why can't I access my app through port-forward?
Understand the gap
- Stop the port-forward command by pressing Ctrl+C in the terminal.
- Back in Cursor's AI chat, enter this prompt:
How would other services in my cluster reach this app?
The AI queries jDocMunch for Kubernetes Service documentation and explains what you are missing. Without a Service, nothing inside the cluster can discover your app by name. Port-forward is a developer shortcut that tunnels directly to a pod. It is not how real applications communicate inside Kubernetes.
What is a Kubernetes Service?
A Service is a Kubernetes resource that gives your pods a stable network identity. Other pods can reach your app using the Service name (like nginx-app) instead of tracking individual pod IP addresses that change every time a pod restarts.
Without a Service, your app is invisible to everything else in the cluster. In a real team with multiple microservices, this means nothing can talk to your app.
This is the wall. You deployed pods successfully, but you have no Service. The AI gave you a working Deployment because that is what basic Kubernetes docs teach first. It lacked knowledge of your team's deployment requirements, which would have told it to include a Service from the start.
You have proven the AI can deploy code to Kubernetes using MCP context. But it produced an incomplete result because it lacked one crucial piece: your team's standards data. In the next step, you will give the AI that missing context and watch it generate production-ready infrastructure on the first try.
Add Context, Fix, and Measure
Your AI successfully deployed pods to the cluster, but you discovered a real gap. Other services inside the cluster cannot find your app because no Kubernetes Service exists.
The AI was missing structured data about your team's deployment requirements. In this step, you will feed those standards into jDataMunch so the AI generates complete, production-ready manifests. Then you will measure the quantified value of this approach.
In this step, get ready to:
- Create a deployment standards CSV and index it with jDataMunch.
- Regenerate the manifest with full context so it includes a Service.
- Measure token savings and deployment time to benchmark the MCP approach.
Create and index deployment standards
Your AI needs to know what a complete deployment looks like on your team. A simple CSV file can encode these rules: which apps need a Service, what ports to expose, whether resource limits are required, and what health check path to use.
- In Cursor's Explorer sidebar, right-click the project root folder and select New Folder.
- Name the folder standards.
- Right-click the new standards folder and select New File.
- Name the file deployment-standards.csv.
- Paste the following content into the file:
app_name,needs_service,service_type,port,health_check_path,requires_resource_limits,max_memory,max_cpu
nginx-app,yes,ClusterIP,80,/,yes,128Mi,100m
api-service,yes,ClusterIP,3000,/health,yes,256Mi,200m
worker,no,,,,yes,512Mi,500m
What does this CSV define?
Each row is a deployment rule for an application on your team. The columns specify whether a Service is required, the service type, which port to expose, the health check path, and resource limits.
Your nginx-app row says: yes it needs a ClusterIP Service on port 80, yes it needs resource limits (128Mi memory, 100m CPU), and the health check hits /.
- Save deployment-standards.csv.
- Confirm the file exists by running this in your terminal:
ls standards/
You should see deployment-standards.csv listed in the output.
Don't see the file?
Make sure you created the standards folder at the project root, not inside the app/ folder. The file should be at standards/deployment-standards.csv relative to your project root.
help me find where my deployment-standards.csv file was created
Now tell your AI to index this file. In Cursor's AI chat, send the following prompt:
Use jdatamunch to index the file at standards/deployment-standards.csv with the name team-standards.
The AI calls index_local on jDataMunch behind the scenes. You should see a confirmation that the dataset was indexed with 3 rows and 8 columns.
What just happened?
jDataMunch loaded your CSV into a local SQLite database, profiled every column, and made the data queryable via MCP tool calls. The AI can now look up deployment requirements for any app by name without loading the entire file into its context window.
🙋♀️ Indexing failed?
Ensure the jdatamunch MCP server shows as connected (green dot) in Cursor Settings > MCP. If it disconnected, close and reopen Cursor to restart the servers.
help me troubleshoot why jdatamunch cannot index my CSV file
✔️ Awesome, I've got everything!
Great. Double check you saved standards/deployment-standards.csv and confirmed the indexing succeeded.
ⓧ I'd like to double check the full code
app_name,needs_service,service_type,port,health_check_path,requires_resource_limits,max_memory,max_cpu
nginx-app,yes,ClusterIP,80,/,yes,128Mi,100m
api-service,yes,ClusterIP,3000,/health,yes,256Mi,200m
worker,no,,,,yes,512Mi,500m
Regenerate the manifest with full context
The AI now has your team's standards indexed. This time when you ask it to deploy, it can look up the nginx-app row and see that a ClusterIP Service on port 80 is required.
- In Cursor's AI chat, send this prompt:
Check our team-standards dataset for nginx-app requirements, then generate a complete Kubernetes manifest that includes both the Deployment and Service. Write it to k8s/complete-deployment.yaml and apply it.
Watch the AI's response. It should coordinate across multiple MCP servers: querying jDataMunch for the standards row, using jDocMunch for Service syntax, writing the file via Filesystem MCP, and applying it via Kubernetes MCP.
What is the AI doing behind the scenes?
- Queries jDataMunch get_rows to find the nginx-app row from team-standards.
- Reads the standards: needs a ClusterIP Service on port 80, resource limits of 128Mi memory and 100m CPU, health check at /.
- Uses jDocMunch to look up the correct YAML syntax for a Kubernetes Service.
- Writes k8s/complete-deployment.yaml via the Filesystem MCP server.
- Applies the manifest to your cluster via the Kubernetes MCP server.
- Verify the Service was created by running:
kubectl get svc
You should see a nginx-app Service listed with type ClusterIP on port 80. This is the piece that was missing in the previous step.
Before you run the next command, predict: will accessing the app through the Service work now that you have both a Deployment and a Service?
- Port-forward through the Service by running:
kubectl port-forward svc/nginx-app 8080:80
- Open your browser and go to http://localhost:8080.
You should see your page with the heading "Deployed by AI Co-Pilot". The app is now accessible through a proper Kubernetes Service.
- Press Ctrl+C in your terminal to stop the port-forward.
Service not showing up?
If kubectl get svc does not show nginx-app, the AI may not have applied the manifest. Ask the AI: "Apply the manifest at k8s/complete-deployment.yaml to my cluster using the kubernetes MCP."
If the file does not exist, re-run the generation prompt from above.
help me figure out why my nginx-app Service does not exist
Measure the benchmark
You have a working deployment through a proper Service. Now quantify how much value the MCP approach delivered compared to the traditional manual path.
- In Cursor's AI chat, send this prompt:
Call get_session_stats on jdocmunch and jdatamunch. Report: total tokens saved, estimated dollar savings, and how many doc sections/data rows were retrieved vs what would have been loaded raw.
The AI will call get_session_stats on both servers and report back with cumulative token savings and cost avoided for this session.
What do these numbers mean?
Each jMunch server tracks how many tokens it saved by returning only the relevant slice of data instead of dumping entire files into the AI's context. For jDocMunch, this means retrieving specific doc sections instead of the entire Kubernetes documentation. For jDataMunch, this means returning individual rows instead of the full CSV.
The jDataMunch benchmark on large datasets shows token reductions of 25,000x or more. Your 3-row CSV is small, but the pattern scales to production data with thousands of rows.
Now document your personal benchmark. Note these metrics from your session:
- Time from first prompt to working deployment (minutes).
- Traditional beginner time researching Kubernetes docs, writing YAML, and debugging: 2-4 hours (industry average).
- Context switches: 1 (Cursor only) vs 5+ (browser, terminal, editor, docs, Stack Overflow).
- First-try accuracy: did the final manifest deploy without manual YAML edits?
Why do these metrics matter?
Token savings prove the MCP servers are working as designed. Retrieving a specific doc section costs a few hundred tokens instead of loading the entire Kubernetes documentation (millions of tokens).
Time-to-deploy and context switches prove the operational value: a complete beginner just deployed to Kubernetes in minutes using only natural language.
Before you wrap up, predict: based on what you saw the AI retrieve from jDocMunch and jDataMunch, do you think token savings exceeded 99%?
- Check the stats the AI reported. You should see 99%+ token savings from both jDocMunch (retrieving targeted sections vs the full K8s docs) and jDataMunch (retrieving specific rows vs the entire dataset).
Stats showing zero savings?
If the AI reports zero tokens saved, it may not have used jDocMunch or jDataMunch tools during the session. Try asking: "Search for 'Service' in the Kubernetes docs using jdocmunch, then call get_session_stats." This forces a retrieval call that generates savings data.
help me understand why my jMunch session stats show zero token savings
Secret mission
Production-Grade Multi-Container Deployment
You deployed a single-container app. But production workloads often need sidecars for logging, monitoring, or proxying. Can your AI co-pilot handle a multi-container pod with resource limits, health checks, and shared volumes, all driven by team standards?
Clean Up Your Resources
Clean Up Your Resources
Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally using Docker resources, so there are no ongoing cloud costs.
Resources you used:
- A local Kind Kubernetes cluster (devops-copilot) running inside Docker.
- pip packages: jcodemunch-mcp, jdocmunch-mcp, and jdatamunch-mcp.
- Local index files at ~/.doc-index/ (jDocMunch) and .jcode/ (jCodeMunch) plus SQLite files (jDataMunch).
- Project files: app/, k8s/, standards/, and .cursor/ directories.
- Global npm package: @kubernetes-cli/kind.
- kubectl installed via winget.
Keep everything running
No action needed. Choose this if you plan to continue experimenting with your MCP-powered DevOps co-pilot or want to build on it for a future project.
- Your Kind cluster uses minimal Docker resources while idle.
- The MCP server configuration in .cursor/mcp.json stays active whenever Cursor is open.
- Local index files remain cached for fast retrieval on your next session.
Pause - I'll come back to this later
Stop Docker Desktop to free up memory. Your Kind cluster state is preserved and restarts automatically when Docker restarts.
- Right-click the Docker Desktop icon in your system tray and select Quit Docker Desktop.
- When you are ready to resume, reopen Docker Desktop. Your devops-copilot cluster and all deployments restart automatically.
- Your project files, index caches, and MCP configuration all remain on disk.
Delete - I don't want to use this again
Remove all project resources and start fresh. Follow each step below to fully clean up.
- Delete the Kind cluster by running:
kind delete cluster --name devops-copilot
- Uninstall the jMunch pip packages by running:
pip uninstall jcodemunch-mcp jdocmunch-mcp jdatamunch-mcp
- Uninstall the Kind CLI by running:
npm uninstall -g @kubernetes-cli/kind
- Uninstall kubectl by running:
winget uninstall Kubernetes.kubectl
- Remove the jDocMunch index cache by running:
macOS
rm -rf ~/.doc-index/
Windows
Remove-Item -Recurse -Force ~\.doc-index
- Delete your project folder from the Desktop by running:
macOS
cd ~/Desktop
rm -rf devops-copilot
Windows
cd ~\Desktop
Remove-Item -Recurse -Force devops-copilot
- Confirm the cluster is gone by running:
kind get clusters
You should see no clusters listed. Your system is fully cleaned up.
That's a Wrap!
That's a Wrap!
Nice work! You just built a fully operational DevOps co-pilot that deploys applications to Kubernetes using nothing but natural language prompts.
You've learned how to:
- Configure 5 MCP servers (jCodeMunch, jDocMunch, jDataMunch, Kubernetes MCP, Filesystem MCP) into a unified DevOps co-pilot in Cursor that gives AI simultaneous access to code, docs, data, cluster state, and your filesystem.
- Deploy a containerized application to Kubernetes without any prior Kubernetes knowledge, guided entirely by AI with real infrastructure context.
- Measure quantified benchmark data proving the MCP approach delivers 99%+ token savings, single-digit minutes vs hours of manual work, and first-try deployment accuracy.
- Secret Mission: Deploy a production-grade multi-container pod with sidecars, probes, and resource limits, demonstrating that even complex Kubernetes patterns are accessible through the AI co-pilot.
Ready to quiz yourself?