DEV Community: Integration Ninjas

Every AI Model Hits the Same Wall. MCP Is the Answer

Integration Ninjas — Thu, 18 Jun 2026 16:52:05 +0000

What is MCP? Model Context Protocol Explained. A practical guide for engineers building with AI.

I’ve been building with AI tools for a while now. And for a long time, I kept running into a frustrating pattern.

The model would understand my question perfectly. It would give me a thoughtful, well-reasoned answer.

And then I’d go actually do the work myself.

Not because the AI was wrong. But because it couldn’t reach anything. It couldn’t see my GitHub repos. Couldn’t check my Jira board. Couldn’t tail the logs from production. Couldn’t restart a service or pull up a runbook.

Every AI assistant I used understood the shape of engineering work. None of them could participate in it.

That gap has a name now. And there’s a protocol designed specifically to close it.

The Wall Every AI Model Runs Into

Ask any AI assistant an operational question — something real, something you’d actually ask a teammate — and you’ll see the pattern immediately.

“List all open PRs waiting for review.”

“Check whether the payment service has failing logs.”

“Read the deployment runbook and tell me the next safe step.”

These aren’t exotic requests. They’re the kind of questions developers and platform engineers ask a dozen times a day.

The AI’s answer will usually be something like: “You should check your pull requests” or “Look at your monitoring dashboard.”

That’s advice, not action.

The model understands your workflow. It just can’t touch it.

Before we had a standard way to fix this, teams tried to solve it on their own. And things got messy fast.

The Integration Problem Nobody Wanted to Admit
If you wanted Claude to read your GitHub data, you built a custom GitHub connector.

If you wanted it to pull Jira tickets, you built a different connector.

If you needed AWS access, Confluence, a database, and observability data — that was four separate integration projects, each with its own authentication logic, data format, error handling, and security review.

The same work kept getting rebuilt. Different teams, different AI products, same problem.

And as the number of AI applications grew, the cost of this approach compounded. It wasn’t a technical limitation exactly. It was the absence of a standard.

Every AI application was speaking its own language to every external system. There was no common vocabulary.

The problem wasn’t that AI was too limited. The problem was that every team was solving the same integration puzzle with no shared pieces.

That’s the condition MCP was built to address.

What MCP Actually Is

MCP stands for Model Context Protocol.

It’s an open standard for connecting AI applications to external tools and sources of context.

The operative word is standard.

Instead of every AI product inventing a different way to talk to every system, MCP defines a shared communication layer. An AI application can speak MCP. An external system can expose an MCP server. And the two sides can communicate through a consistent protocol.

No custom one-off bridges. No per-product integration sprawl.

The model gets a common way to discover capabilities, request information, and call approved actions — regardless of what’s on the other side.

The USB-C Analogy That Actually Works

Before USB-C became common, devices used a mess of connectors: USB-A, Micro USB, Mini USB, Lightning, and a few others I’ve already forgotten the names of.

Each one solved a similar problem. In a different shape. With different adapters.

USB-C didn’t make every device identical. It standardized the connection point.

MCP does the same thing for AI integrations.

GitHub, Jira, AWS, your internal database, your documentation system — these are all wildly different tools with different data models and different operational logic. MCP doesn’t pretend they’re the same.

It just gives AI applications a standard port for communicating with them.

So instead of asking “how does this assistant connect to this specific tool?” you can ask a simpler question: does this tool expose an MCP server?

That shift is what makes the ecosystem scalable. Build the server once. Any MCP-compatible client can use it.

How the Architecture Actually Works

Here’s the basic layout.

At the top is a user — you — asking a question or giving an instruction inside an AI application. That could be a desktop assistant, an IDE, a chat interface, or an agent framework.

Inside that application is an MCP client. The client handles the protocol side: discovering what servers are available, understanding what capabilities they expose, and helping the AI make structured requests.

On the other side is an MCP server. The server connects to some external system — a repo, a ticketing platform, a cloud account, a database, an internal service — and exposes what that system can do through the protocol.

The request flows from the AI application through the MCP client to the MCP server. The server performs the operation or retrieves the context. The response comes back through the same path.

The AI application doesn’t need to know the internals of every tool. The tool owner exposes capabilities through a server, and the AI interacts through the protocol. Clean separation. Clear responsibilities.

Tools vs. Resources: The Core Distinction

MCP has two fundamental building blocks: tools and resources.

They’re different in a way that matters.

Tools Are About Actions

A tool represents something the AI can do.

A GitHub MCP server might expose a tool called list_pull_requests. A Jira server might expose create_ticket. A cloud ops server might expose restart_service or deploy_application.

The AI can see these tools, understand their input schema, and decide when one is relevant to a request.

But tools aren’t free-form commands. They’re structured, named, and controlled. That makes them auditable. You can log every tool call. You can gate approval on sensitive actions. You can test and review them the same way you review any other interface.

That’s the shift that opens the door to real AI agents: not “I can suggest what to do” but “I can perform an approved action for you.”

Resources Are About Information

A resource gives the AI something to read.

That could be a runbook, a knowledge base article, a log stream, a schema, internal documentation, or a configuration file.

The distinction matters more than it might seem.

Not every integration should be an action. Sometimes the most useful and safest thing an AI system can do is read the right context and explain what it means — before doing anything.

Before restarting the service, read the runbook. Before answering the platform question, retrieve the documentation. That’s the difference between a capable AI and a reckless one.

MCP supports both patterns: actions through tools, information through resources.

What This Looks Like in the Real World

Once teams start exposing their existing systems as MCP servers, the operational picture shifts quickly.

A GitHub MCP server gives the AI access to repositories, issues, branches, commits, and pull requests. A Jira server surfaces tickets, priorities, sprint status, and workflow state. An AWS server exposes cloud resources, service health, and approved operational actions. A database server can expose schemas, safe queries, or read-only business data. An observability server connects logs, traces, metrics, alerts, and dashboards.

Each server speaks the same protocol. Each one represents a completely different domain.

MCP doesn’t replace your tools. It creates a standard way for AI systems to interact with the tools your team already depends on. The ecosystem grows without requiring every team to rebuild the same bridges.

Why This Is Bigger Than It Looks

AI is moving through phases.

The first phase was chatbot: ask a question, get an answer. Useful, but limited.

The second phase was assistant: help me write, summarize, and reason. More useful, still detached from real systems.

The phase we’re entering now is different. AI systems that can participate in actual workflows.

An AI engineer that doesn’t just explain code — it inspects a repository.

A platform assistant that doesn’t just describe an incident response process — it reads the runbook, inspects the logs, and prepares the next action.

An AI agent that doesn’t just talk about work — it coordinates with tools.

For that version of AI to exist at scale, and to be safe, integrations need a common foundation. One that’s auditable. One that doesn’t require each team to maintain a pile of custom connectors.

MCP provides that foundation.

It gives AI applications a consistent way to access context and capabilities. It gives tool owners a standard way to expose what they build. It gives platform teams a clean interface to govern, log, and secure what AI can reach.

That’s not a small thing. That’s the infrastructure layer the next generation of AI-native engineering tools is built on top of.

The Short Version

If you want to walk away with one clear mental model:

MCP is a standard protocol for connecting AI applications to external systems.
MCP clients live inside AI applications and handle the protocol.
MCP servers expose capabilities from tools, platforms, and data sources.
Tools are actions the AI can call.
Resources are information the AI can read.
Together, they make AI integrations reusable, understandable, and easier to govern. They turn the many-to-many connector problem into a many-to-one protocol pattern.

That’s why MCP is becoming a foundational part of the AI engineering stack — not as a feature, but as a shared language.

What’s Next

In the next video on the Integrations Ninjas channel, I’m building an MCP server from scratch — connecting it to a real AI application, exposing a tool, exposing a resource, and walking through the full request flow end to end.

If this explanation helped, I’d genuinely like to know: do you think MCP will become table stakes for AI tooling in the next 12 months, or will teams keep building custom connectors out of inertia? Drop your take in the comments.

Deploy Node.js Application to AWS EC2 using GitLab CI

Integration Ninjas — Fri, 14 Feb 2025 10:22:23 +0000

Introduction

Automating deployments with GitLab CI/CD is a powerful way to streamline your development workflow. In this guide, we'll walk through the process of deploying a Node.js application to an AWS EC2 instance using GitLab CI/CD and Docker. This setup ensures that every new commit is automatically built, pushed to a container registry, and deployed to your server.

Prerequisites

Node.js application: Ensure you have a Node.js application ready for deployment.
GitLab repository: Create or use an existing repository to host your application code.(Example Repo)
Docker installed: Install Docker locally(if running self-hosted runner) to build and manage container images. If you're running workflow with GitHub hosted runners then Docker is already installed there.
AWS account: Sign up for a free AWS account if you haven't already.
EC2 instance: Create an EC2 instance in AWS with appropriate specifications for your application. Configure security groups to allow inbound traffic on the port your application uses (e.g., port 3000).
SSH Client: Install an SSH client like PuTTY or Terminal (on macOS/Linux) to connect to your EC2 instance.

AWS EC2 Setup

Use below commands to setup Docker:

sudo apt-get update
sudo apt-get install docker.io -y
sudo systemctl start docker
sudo docker run hello-world
docker ps
sudo chmod 666 /var/run/docker.sock
sudo systemctl enable docker
docker --version

Use below reference to setup self-hosted runner on EC2:

Install GitLab Runner manually on GNU/Linux | GitLab

GitLab product documentation.

docs.gitlab.com

Once you create runner, use this reference to register the GitLab runner on that EC2 machine.

Flow Chart

Now, follow below steps to create required Docker file and .gitlab-ci.yml file to deploy you Node.js code on AWS EC2:

Step 1: Dockerizing the Node.js Application

First, let's create a Dockerfile to containerize our application:
Within your application directory, create a file named Dockerfile with the following content, replacing <IMAGE_NAME> with your desired image name and <PORT> with your application's port:

FROM node:20-alpine3.18
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 5000
CMD ["npm","run","start"]

This Dockerfile:

Uses Node.js 20 on Alpine Linux for a lightweight image
Sets the working directory to /app
Installs dependencies
Copies the application files
Exposes port 5000 (adjust if needed)
Runs the application using npm run start

Build and test your Docker image locally:

docker build -t nodejs-app .
docker run -p 5000:5000 nodejs-app

If everything works, move to the next step!

Step 2: Setting Up GitLab CI/CD Pipeline

To automate deployment, create a .gitlab-ci.yml file in your project root:

default:
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  before_script:
    - docker info

stages:
  - build
  - deploy

build_job:
  stage: build
  script: |
    echo "Building the application.."
    docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
    docker build -t integrationninjas/nodejs-app:$CI_COMMIT_SHA .
    docker push integrationninjas/nodejs-app:$CI_COMMIT_SHA

deploy_job:
  stage: deploy
  script: |
    docker pull integrationninjas/nodejs-app:$CI_COMMIT_SHA
    docker rm -f nodejs-app-container
    docker run -d -p 5000:5000 --name nodejs-app-container integrationninjas/nodejs-app:$CI_COMMIT_SHA
  tags:
    - ec2-runner
  only:
    - deploy-to-ec2

Understanding the Pipeline

Default Section:
- Uses Docker-in-Docker (dind) to enable Docker builds inside the GitLab Runner.
Stages Section:
- Defines two stages – build and deploy.
build_job:
- Logs into Docker Hub.
- Builds the Docker image with the commit SHA as the tag.
- Pushes the image to Docker Hub.
deploy_job:
- Pulls the latest image from Docker Hub.
- Removes the old container (if running).
- Runs the new container on port 5000.
- Uses the GitLab Runner tag ec2-runner to execute on an AWS EC2 instance.
- Triggers only when pushed to the deploy-to-ec2 branch.

Now, when you push changes to the deploy-to-ec2 branch, GitLab CI/CD will automatically build and deploy your app! 🚀

Step 4: Testing the Deployment

Once the pipeline completes, check if your app is running on EC2:

curl http://your-ec2-ip:5000

You should see your application response! 🎉

Conclusion

With this setup, you've successfully automated the deployment of a Node.js application to AWS EC2 using GitLab CI/CD and Docker. Now, every commit to the deploy-to-ec2 branch will trigger an automatic build and deployment process. This approach ensures:

✅ Faster and reliable deployments
✅ Consistency across environments
✅ Less manual effort, thanks to automation.

💬 Questions? Drop them below! 🚀