DEV Community: nithish rodrigo

How I Connected GitHub Copilot in VS Code to GitHub Using MCP

nithish rodrigo — Fri, 21 Aug 2026 12:18:32 +0000

Understanding MCP Through a Practical Example

Recently, I’ve been learning about Model Context Protocol (MCP) and wanted to understand it beyond the theory.

Instead of just reading about MCP, I decided to try a practical integration:

Connect GitHub Copilot in VS Code to GitHub using the GitHub MCP Server.

This helped me understand how AI agents can interact with external systems and why MCP is becoming an important part of the AI ecosystem.

What is MCP?

MCP (Model Context Protocol) is a standardized protocol that allows AI applications and agents to communicate with external tools, services, and data sources.

For example, an AI agent may need to interact with:

GitHub
Jira
AWS
Databases
Internal documentation
Monitoring systems
APIs

Without a standard integration mechanism, each AI application would potentially need its own custom integration for every service.

MCP provides a standardized approach.

A simplified architecture looks like this:

AI Application / Agent
(Claude, Copilot, ChatGPT)
          │
          │ MCP Protocol
          ▼
      MCP Server
          │
          │ API / SDK / Service Integration
          ▼
External System
(GitHub, AWS, Jira, Database)

How is MCP Similar to REST APIs?

When I first tried to understand MCP, I compared it with a traditional REST API architecture.

Traditional API communication

Client
(Postman / Application)
        │
        │ HTTP
        ▼
API Server
        │
        ▼
Application / Service

For example, when using the GitHub REST API, a developer might manually call an endpoint like:

GET /repos/{owner}/{repo}/issues

The client needs to know:

Which API endpoint to call
Which HTTP method to use
Which parameters are required
How authentication works
How to process the response

With MCP, the interaction can be more agent-oriented.

AI Agent
   │
   │ MCP
   ▼
MCP Server
   │
   ▼
External Service

Instead of manually calling an API endpoint, you can tell the AI:

"Show me all open issues in this repository."

The AI agent can then determine which available tool is appropriate and use it through the MCP server.

My Practical Example: GitHub Copilot + GitHub MCP Server

For this experiment, I used:

Visual Studio Code
GitHub Copilot
GitHub MCP Server
GitHub authentication

The architecture looks like this:

Developer
    │
    ▼
VS Code
    │
    ▼
GitHub Copilot
    │
    │ MCP
    ▼
GitHub MCP Server
    │
    │ GitHub APIs / Services
    ▼
GitHub

GitHub Copilot acts as the AI-powered client that can use tools exposed through the MCP server.

Step 1: Configure the GitHub MCP Server

In VS Code, MCP servers can be configured using an mcp.json configuration.

For the remote GitHub MCP server, the configuration looks similar to:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Once configured, VS Code can connect to the MCP server.
for more on configuration check here

Step 2: Authenticate with GitHub

Since the MCP server needs permission to access GitHub resources, an authentication flow is required.

The flow is approximately:

VS Code
   │
   ▼
GitHub Copilot
   │
   ▼
GitHub MCP Server
   │
   │ Authentication Required
   ▼
GitHub OAuth
   │
   ▼
User Approves Access
   │
   ▼
MCP Server Can Access Authorized Resources

MCP defines how the AI application and MCP server communicate.

Authentication and authorization determine:

Who are you, and what are you allowed to access?

Step 3: Let Copilot Use GitHub as a Tool

After connecting the MCP server, I can ask GitHub Copilot questions such as:

"Show me my open GitHub issues."

Or:

"Get information about this repository and explain its architecture."

Or even:

"Create a GitHub issue titled 'Add Terraform deployment documentation'."

Behind the scenes, the interaction looks something like this:

1. User
      │
      │ "Show me open issues"
      ▼

2. GitHub Copilot / AI Agent
      │
      │ Determines GitHub data is required
      ▼

3. MCP Client
      │
      │ MCP Request
      ▼

4. GitHub MCP Server
      │
      │ Interacts with GitHub
      ▼

5. GitHub
      │
      │ Returns Data
      ▼

6. GitHub MCP Server
      │
      │ MCP Response
      ▼

7. Copilot
      │
      ▼

8. User receives the result

Tools, Resources, and Context

One of the things that made MCP clearer for me was understanding that MCP servers can expose capabilities to AI agents.

For example, an MCP server may provide tools such as:

get_repository()
list_issues()
create_issue()
get_pull_request()

It may also provide access to resources, such as:

Repository information
Source code
Documentation
Issues
Pull requests
Infrastructure information
Logs

The AI agent can discover the capabilities available from the MCP server and use the appropriate one based on the user's request.

Why I Think MCP is Interesting

As someone working in Cloud and TechOps, I find MCP particularly interesting because I can imagine many practical use cases.

For example:

GitHub Copilot / AI Agent
           │
           ├── GitHub MCP Server
           │
           ├── AWS MCP Server
           │
           ├── Jira MCP Server
           │
           ├── Monitoring MCP Server
           │
           └── Internal Documentation MCP Server

Imagine asking an AI agent:

"A production deployment failed. Check the GitHub pull request, investigate the AWS environment, review the monitoring alerts, and create a Jira incident with your findings."

The AI agent could potentially interact with multiple systems through MCP servers.

Of course, proper authentication, authorization, approval mechanisms, and security controls would be essential, especially when the agent can perform actions in production environments.

My Biggest Takeaway

The easiest way I currently understand MCP is:

MCP is a standardized integration layer that allows AI agents to discover and interact with external tools and data sources.

A simplified comparison would be:

Traditional Development:

Developer
   │
   ▼
Application Code
   │
   ▼
REST API
   │
   ▼
External Service

Whereas an MCP-enabled workflow can look like:

User
   │
   ▼
AI Agent
   │
   ▼
MCP Client
   │
   ▼
MCP Server
   │
   ▼
Tools / APIs / Data / External Services

Instead of building a completely custom integration for every AI application and external service, MCP provides a common protocol for connecting them.

🐳 Why Docker, Why Kubernetes and Why Did It Change DevOps Forever?

nithish rodrigo — Mon, 03 Aug 2026 10:39:29 +0000

nithish rodrigo

Aug 1

🐳 Why Docker, Why Kubernetes and Why Did It Change DevOps Forever?

#docker #kubernetes #devops #cicd

3 min read

🐳 Why Docker, Why Kubernetes and Why Did It Change DevOps Forever?

nithish rodrigo — Sat, 01 Aug 2026 17:03:27 +0000

🐳 What is Docker, and Why Did It Change DevOps Forever?

If you've worked in software development, you've probably heard this sentence at least once:

"But it works on my machine!"

This is one of the most common problems in software development and was a major pain point before Docker became mainstream.

Let's explore how Docker solved this problem and why it became a game changer for DevOps.

The Problem: "It Works on My Machine"

Imagine this scenario:

👨‍💻 A developer builds a new feature and tests it locally.

Everything works perfectly.

The code is then handed over to the QA team.

❌ Suddenly, the application crashes.

The developer insists:

"It works perfectly on my machine."

So what went wrong?

Usually, the issue isn't the code itself. It's the environment.

Some common differences include:

Different operating systems
Different library versions
Missing dependencies
Different runtime versions (Java, Python, Node.js, etc.)
Different environment variables
Different system configurations

Even a tiny version mismatch can cause an application to fail.

Enter Docker

Docker was created to solve exactly this problem.

Instead of deploying only the application code, Docker packages everything the application needs into a single unit called a Docker Image.

A Docker image contains:

Application code
Runtime
Required libraries
Dependencies
Configuration
System tools

When someone runs that image, Docker creates a container.

Since every container is created from the same image, every environment behaves consistently.

This means:

✅ Developer machine

⬇️

✅ QA environment

⬇️

✅ Staging

⬇️

✅ Production

Everyone runs the exact same application in the exact same environment.

Why Docker Became So Popular

Docker introduced several benefits that transformed software delivery.

Consistent Environments

Applications behave the same across Development, QA, UAT, and Production.

Faster Deployments

Instead of configuring servers manually, you simply run a Docker image.

docker run my-app:latest

Deployment becomes predictable and repeatable.

Lightweight Virtualization

Unlike Virtual Machines, containers share the host operating system kernel.

This makes them:

Faster to start
More resource-efficient
Smaller in size
Easier to scale

Simplified Dependency Management

No more installing dozens of packages manually.

Everything travels together inside the image.

Better CI/CD Pipelines

Docker integrates seamlessly with tools such as:

Jenkins
GitHub Actions
GitLab CI
Azure DevOps
AWS CodePipeline

Build once.

Deploy anywhere.

But Docker Isn't Perfect

Although Docker solved many problems, it also introduced new challenges.

Containers are ephemeral, meaning they are designed to be temporary.

If a container crashes, it disappears unless something recreates it.

Managing a handful of containers is easy.

Managing hundreds or even thousands is a different story.

Docker alone does not provide enterprise-grade capabilities such as:

Service discovery
Self-healing
Automatic scaling
High availability
Load balancing
Rolling updates
Secret management
Multi-node scheduling

These features become essential as applications grow.

This Is Where Kubernetes Comes In

Kubernetes wasn't created to replace Docker.

It was created to orchestrate containers.

Think of it this way:

Docker creates and runs containers.

Kubernetes manages them at scale.

Kubernetes automatically:

Restarts failed containers
Distributes traffic between containers
Scales applications up or down
Schedules containers across multiple servers
Performs rolling updates with minimal downtime
Maintains the desired state of your applications

Instead of manually managing containers, you simply describe the desired state, and Kubernetes continuously works to maintain it.

Docker + Kubernetes = Modern DevOps

Today, Docker and Kubernetes are foundational technologies in cloud-native architectures.

Together they enable teams to:

Deliver software faster
Reduce deployment failures
Improve infrastructure consistency
Scale applications with ease
Increase system reliability
Automate operations

These technologies have fundamentally changed how modern software is built, deployed, and managed.

Final Thoughts

Docker solved one of the most frustrating problems in software development: environment inconsistency.

It gave developers confidence that applications would run the same way across different environments.

As organizations adopted microservices and containerized applications at scale, Kubernetes emerged to solve the operational challenges of managing large numbers of containers.

Together, Docker and Kubernetes have become the backbone of modern DevOps and cloud-native engineering.

Have you ever encountered the classic "It works on my machine" problem?

Share your experience in the comments. I'd love to hear how you solved it! 🚀

devops #docker #kubernetes #cloud #aws #containers #cicd #softwareengineering

What Really Happens When You Type a URL in Your Browser? (Explained Step-by-Step)

nithish rodrigo — Sat, 02 May 2026 11:48:57 +0000

When you type a URL like www.google.com into your browser, a lot more happens behind the scenes than you might think.

Let’s break it down step by step.
🌐 Step 1: DNS Resolution

Your browser doesn’t understand domain names—it needs an IP address.

So it checks:

Browser cache
OS cache
Router cache
ISP DNS
Public DNS like Google Public DNS

Once resolved, you get the IP address of the server.

🔗 Step 2: Establishing a TCP Connection

Now your browser connects to the server using TCP.

This happens via the 3-way handshake:

SYN → Request to connect
SYN-ACK → Acknowledgement from server
ACK → Final confirmation

This ensures reliable communication.

🔐 Step 3: Secure the Connection (TLS/SSL)

Before sending data:

Server sends SSL certificate
Browser verifies it
Encryption is established

This is why you see 🔒 in your browser.

📡 Step 4: Sending HTTP Request

Now the browser sends:

HTTP GET request (to fetch page)
or POST request (to send data)

This happens at the Application Layer (OSI Layer 7).

🌍 Step 5: Network Journey

Your request travels through:

Local router
ISP
Global internet backbone
Undersea cables
Data centers
⚖️ Step 6: Load Balancer

Before reaching the server:

A load balancer distributes traffic
Prevents overload
Improves performance and availability
🖥️ Step 7: Server Processing

The backend server:

Processes your request
Fetches data
Generates response
🎨 Step 8: Browser Rendering

Finally, your browser:

Parses HTML
Applies CSS
Executes JavaScript

And boom 💥 — the page loads!

🧠 Final Thoughts

What looks like a simple action actually involves:

DNS resolution
Networking
Security
Distributed systems
Application processing

Understanding this flow is crucial for SREs, DevOps Engineers, and Backend Developers.

Automated Jira Ticket Creation for AWS EC2 Scheduled Events

nithish rodrigo — Mon, 05 Jan 2026 06:12:07 +0000

This post describes the architecture and configuration required to automatically generate Jira Service Management (JSM) tickets in response to AWS Health notifications about scheduled EC2 instance events (e.g., reboots, instance retirements).

The aim is to eliminate the manual process of reviewing and forwarding AWS notification emails to a service desk email address. With this automation, you can proactively track and resolve AWS‑initiated maintenance activities and also we can do this maintenace under our control.

Architecture Overview

AWS Health Events → EventBridge → SQS → Jira Service Management Connector

At a high level:

AWS Health generates events for EC2 scheduled maintenance.
Amazon EventBridge captures and filters those events.
An Amazon SQS queue receives the events.
The Jira Service Management Connector consumes messages from SQS and creates issues in a JSM project.

AWS Health Setup

Using AWS Organizations, you can centralize scheduled AWS Health maintenance notifications for all EC2 instances across all member accounts into a single “central operations” account. From this account, events are visible in the AWS Health Dashboard and can be routed to other AWS services.

To delegate AWS Health Dashboard organization view to a central account, run the following command from your AWS Organizations management (root) account:
aws organizations register-delegated-administrator \ --account-id <CENTRAL_OPERATIONS_ACCOUNT_ID> \ --service-principal health.amazonaws.com

Replace <CENTRAL_OPERATIONS_ACCOUNT_ID> with the ID of the account where you want to centralize AWS Health events.

AWS EventBridge

EventBridge is used to capture EC2‑related AWS Health events and route them to an SQS queue.

Setup Steps
In your central operations account, create an EventBridge rule, for example: aws_schedule_maintenance_event.
Set the target of this EventBridge rule to an Amazon SQS queue that will buffer health events for downstream processing.

Delivering Events to Jira Service Management via SQS
The SQS queue receives the AWS Health event payloads from EventBridge. These messages are then delivered into a Jira Service Management project using the AWS Service Management Connector for Jira Service Management (often referred to as the “AWS JSM Connector”).

You can install the connector from the Atlassian Marketplace and configure it to read from the SQS queue and create issues in a chosen JSM project (for example, an infrastructure or operations service desk).

High‑Level Configuration in Jira
Once the AWS JSM Connector is installed:

Navigate to the AWS Service Management Connector configuration in Jira.
Configure an AWS account connection that has permissions to read from the SQS queue and interact with the necessary AWS services.
On the connector settings page, ensure the AWS Health integration is enabled.
Enable the desired Jira Service Management project and configure:

For details on accessing Forge‑based Jira app logs for troubleshooting, see Atlassian’s documentation: Access app logs

Outcome
With the above workflow implemented correctly (and with appropriate AWS and Jira configuration), AWS Health events for EC2 maintenance automatically generate Jira tickets in your chosen JSM project.

This gives operations teams:

Proactive visibility into upcoming instance retirements and maintenance.
A consistent ticketing trail for AWS‑initiated changes.
The ability to track remediation work through normal incident or request workflows.

Troubleshooting
Occasionally, the connection between the SQS queue and the JSM connector can fall out of sync (for example, due to transient network or authentication issues). When that happens, EC2 Health events may accumulate in the SQS queue without being turned into Jira tickets.

A typical temporary fix looks like this:

Check the SQS queue
Reset / re‑sync the connector in Jira

After the connection is re‑established and the sync completes, the SQS messages should start being processed, and Jira tickets should appear for any pending EC2 instance retirement or maintenance events.

Future Improvements

To make the automation more effective and user‑friendly, you can enrich the Jira tickets with additional context:

Include instance names in the ticket summary or description, not just the instance ID.
Add environment tags (e.g., prod, staging) and application identifiers to help teams quickly understand impact.
Use a Lambda function or similar service to:

Enriching tickets in this way makes automated notifications more actionable and reduces the time needed for responders to identify and remediate affected resources.

Further this project is complete open source, we can create jira tickets for AWS scheduled maintenance for any AWS services using AWS health.

A Guide to AWS CloudFront Invalidations

nithish rodrigo — Sat, 03 Jan 2026 11:48:19 +0000

Static frontend website requires consistent update to the webpages as the website grows, so a classic cloud native static web content is served ususally by files uploaded to an Amazon S3 bucket which is accessed via cloudfront. A typical issue with static content is some might notice that the old version of webpage still appears when you visit your website though when there is new content is updated. This happens because of caching.

To fix this, you need to perform a CloudFront Invalidation. This guide will walk you through the process step-by-step, ensuring your audience always sees the most recent version of your content.

What is S3 Object Invalidation?
Before we dive into the "how," let's look at the "why."

When you use Amazon S3 to store files and Amazon CloudFront to deliver them, CloudFront stores copies of your files in "Edge Locations" around the world. This makes your website fast because the data is physically closer to your users.

However, CloudFront will keep that copy until it expires (often 24 hours or more). If you upload a new version of webpage to S3, CloudFront won't know it changed. So therefore Invalidation tells CloudFront to delete its cached copies and fetch the brand-new version from S3 immediately.

Step-by-Step: How to Invalidate a File
Follow these steps to refresh your content across the web.

Access the CloudFront Console Sign in to your AWS Management Console.

In the search bar at the top, type CloudFront and select it from the services list.

Select Your Distribution You will see a list of "Distributions" (these are the bridges between your S3 bucket and the web).

Locate and click on the Distribution ID associated with your website

Create the Invalidation Click on the Invalidations tab in the top menu.

Click the orange Create invalidation button.

Define the Object Path In the "Object paths" box, you need to tell AWS exactly which file to clear.

Important: Do not paste the full website URL. Only paste the path that comes after the domain name.

Example: If your file is at https://example.com/restaurant/dinner.pdf, you should enter:

/restaurant/dinner.pdf

Click Create invalidation at the bottom of the page.

Key Points to Remember
Leading Slash: Always start your path with a forward slash /.

Wildcards: If you want to clear an entire folder, you can use an asterisk, such as /restaurant/*.

Timing: Invalidations usually take 1–3 minutes to process globally. Once the status changes from "In Progress" to "Completed," your new file is live!

Additional Resources
For more technical details on how web caching works and advanced invalidation patterns, refer to the official AWS documentation:

AWS Documentation: Invalidating Files

📅 Understanding Application Log Timeframes: A Guide to Log Time Formats and Timezone Differences

nithish rodrigo — Thu, 24 Apr 2025 08:18:09 +0000

Understanding application log time frame is crucial troubleshooting task where application log time could be different from your local machine clock. In this post I will provide simple examples and terms on understanding the time frames.

P.S> attribution to ChatGPT for helping me write my very first dev.to blog

When you're debugging an issue or investigating an incident, logs are your best friends. But nothing is more frustrating than realizing the timestamp in your application logs doesn't match your local time. You might see a log line saying 2025-04-24T10:00:00Z, but you're pretty sure the event happened at 3 PM your time.

In this post, we’ll break down:

What are the time formats commonly used in application logs
What UTC time is
How to identify the time zone used in your logs
How to convert between log time and your local machine’s time
Simple examples to bring it all together

🕒 1. What Time Format Do Application Logs Use?
Most modern applications use UTC (Coordinated Universal Time) in logs. This is a global time standard not affected by daylight saving time or local time zones. It keeps things consistent when logs are aggregated across servers in different regions.

Here are some common log time formats you might see:

Format	Example	Description
ISO 8601 (UTC)	2025-04-24T10:00:00Z	The `Z` means "Zulu time" (another term for UTC).
UNIX Timestamp	1713952800	Number of seconds since Jan 1, 1970 (UTC).
Local Time Format	Apr 24 03:30:00 PM	Varies depending on the server’s time zone.
Custom Formats	24/Apr/2025:10:00:00 +0000	Often used in web server logs (like Apache/Nginx). The `+0000` means UTC offset.

🌍 2. What Is UTC and Why Is It Used?
UTC (Coordinated Universal Time) is the time standard used across the world. Servers, cloud platforms, and applications prefer UTC to:

Avoid confusion from local daylight saving time changes.

Easily correlate logs across distributed systems.

Think of it as the "common ground" for global systems.

If you're in Sri Lanka, your local time is UTC+5:30. So if an application logs a timestamp of 2025-04-24T10:00:00Z, that event happened at 3:30 PM Sri Lanka time.

🕵️ 3. How to Know What Time Zone a Log Uses?
Look for hints in the log format:

A Z at the end → UTC
A number like +0530 → UTC+5:30
No timezone at all? 😬 Then check your application/server settings. It might be in local time or UTC depending on configuration.

🔄 4. How to Convert Log Time to Your Local Time?
Example 1: ISO 8601 UTC to Local Time (Sri Lanka)
Log Time: 2025-04-24T10:00:00Z
Local Time: UTC+5:30 → Add 5 hours and 30 minutes
Result: 2025-04-24 03:30 PM

Example 2: Apache-style Timestamp
Log Time: 24/Apr/2025:10:00:00 +0000
Still UTC, so same conversion as above → 2025-04-24 03:30 PM

Example 3: UNIX Timestamp
Log Time: 1713952800
This needs to be converted using a tool or script (e.g., Python or an online converter):

# In Linux terminal
date -d @1713952800

🛠️ 5. Tips to Work with Different Timezones in Logs
Always check your local time zone offset (especially during daylight saving time).

Use tools like date, timedatectl, or tzutil (Windows) to confirm your current local time setting.

Many log aggregation tools (like Splunk, Datadog, CloudWatch, etc.) can automatically convert UTC to your local time in the UI.

If you’re writing logs yourself, prefer UTC + ISO 8601 format. It’s clean, unambiguous, and machine-friendly.

Conclusion
When reviewing logs from servers or applications, always ask yourself: "What time zone is this in?" Knowing how to read and convert log times accurately will help you:

Correlate issues faster
Understand when exactly something happened
Avoid confusion when comparing logs from multiple systems

Whether you're troubleshooting an incident or analyzing patterns, this understanding is a small step with big impact.