DEV Community: hiruthicSha

Building MCP Server - The Hidden Protocol Behind Smart AI Collaboration

hiruthicSha — Sat, 25 Oct 2025 06:09:16 +0000

Back in the 1960s, when computers were rare and applications even rarer, the term API quietly entered the scene. It wasn't about the web or microservices back then; it was about getting one piece of software to talk to another within the same machine.

Fast forward to the 2000s, when the internet exploded into the hands of everyday developers. New frameworks, operating systems, and applications were popping up faster than anyone could keep track of. It was an incredible time; every week brought something new to try, build, or break.

But that rapid innovation came with a cost: incompatibility. Everyone built their own thing in their own way. There was no single language or standard for systems to communicate. If your shopping site wanted to talk to another vendor, you had to build a custom connector. One partner? One connector. A hundred partners? A hundred connectors. It was chaos.

That’s where APIs changed everything; they gave systems a common protocol to collaborate without needing to know each other’s internal wiring.

And that's exactly what the Model Context Protocol (MCP) aims to do, but for AI systems. Just as APIs allowed applications to exchange data and perform tasks together, MCP defines a unified language that lets AI models, tools, and environments interoperate seamlessly.

If you are new to MCP, please follow these before continuing:

How does an MCP work?
How I Built an MCP Client (and How You Can Too)
If you want to quickly get the idea without diving deep: https://www.instagram.com/p/DIpoV9OzayA/

Building the MCP Server

Project Setup

In my earlier store, where we talked about how to build an MCP Client where we used filesystem-mcp-server. This time, since we are building our own server, we'll call it "Wannabe FS MCP Server".

mkdir wannabe-fs-mcp-server 
cd wannabe-fs-mcp-server
npm init -y
npm install express body-parser cors @modelcontextprotocol/sdk
npm install --save-dev typescript ts-node @types/node @types/express @types/cors
npx tsc --init

Our project structure should look like:

mcp-server/
├─ src/
│  ├─ server.ts
│  └─ fs-service.ts
├─ package.json
├─ tsconfig.json

Core Logic

Let's create the obvious logic, listing files and reading the file fs-service.ts.

import fs from 'fs';
import path from 'path';

const ROOT_DIR = path.resolve('./');

export function listDirectory(relPath: string = ''): string[] {
  const fullPath = path.resolve(ROOT_DIR, relPath);
  if (!fullPath.startsWith(ROOT_DIR)) throw new Error('Access denied');
  return fs.readdirSync(fullPath);
}

export function readFile(relPath: string): string {
  const fullPath = path.resolve(ROOT_DIR, relPath);
  if (!fullPath.startsWith(ROOT_DIR)) throw new Error('Access denied');
  return fs.readFileSync(fullPath, 'utf-8');
}

This service logic is responsible for reading a file or listing a directory under a directory.
Let's build the MCP part.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import fs from "fs";
import path from "path";

Now, let's be a good developer and follow proper security practices, at least one. We'll allow the server access to the current directory.

const ROOT_DIR = path.resolve("./");

function safeResolve(relPath: string) {
  const fullPath = path.resolve(ROOT_DIR, relPath);
  if (!fullPath.startsWith(ROOT_DIR)) throw new Error("Access denied");
  return fullPath;
}

Now, let's create the handlers that the MCP can register as tools.

function listDirectory(relPath: string = ""): string[] {
  const fullPath = safeResolve(relPath);
  return fs.readdirSync(fullPath);
}

function readFile(relPath: string): string {
  const fullPath = safeResolve(relPath);
  return fs.readFileSync(fullPath, "utf-8");
}

Create a new instance of the MCP Server and register the tools.

const server = new McpServer({
  name: "file-server",
  version: "1.0.0",
  capabilities: { tools: {}, resources: {} },
});

server.registerTool("list_dir", {
  description: "List files in a directory"
}, async (args: any) => {
  try {
    const relPath = args?.path || "";
    const files = listDirectory(relPath);
    return { content: [{ type: "text", text: files.join("\n") }] };
  } catch (err: any) {
    return { content: [{ type: "text", text: `Error: ${err.message}` }] };
  }
});

// Read file tool
server.registerTool("read_file", {
  description: "Read the contents of a file"
}, async (args: any) => {
  try {
    if (!args?.path) {
      return { content: [{ type: "text", text: "Error: path parameter is required" }] };
    }
    const content = readFile(args.path);
    return { content: [{ type: "text", text: content }] };
  } catch (err: any) {
    return { content: [{ type: "text", text: `Error: ${err.message}` }] };
  }
});

The above process is just telling the server instance to expose certain tools, which are bound to our handlers. This way, an MCP Client can discover these tools when the server is connected and provide context to the LLM. A little bit of driver like below and that's it.

const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Wannabe File System MCP Server running on stdio");

And that’s it, our humble, wannabe filesystem MCP server, "ready" to tackle production-level chaos (just kidding, don’t actually deploy it💀).

You can build the project, grab the path to the transpiled script.js, and paste it into the MCP Client from the previous post to give it a spin.

This is a very simple introduction to building an MCP Server, and there are a lot of other things like:

Different transport types
Authentication and access control
Error handling and retries
Logging and observability
Scaling and concurrency management
Message schema versioning and backward compatibility
Security and input validation

Each of these aspects adds robustness and makes the server truly ready for real-world workloads.

If you are interested, I have created such a simple MCP server that runs multiple LLMs at the same time and can also summarize by querying multiple LLMs. Read more: MMMCP — An MCP Server for Multi-Model Prompts.

Stay Curious. Adios 👋

Cover image generated with Canva AI

AI Weekend Projects That Slash Repetitive Work

hiruthicSha — Tue, 12 Aug 2025 06:04:24 +0000

Lets build some project that is not just a entry in your resume like, YouTube clone or Reddit clone.

If you’ve been following my articles, you know I spend a few weekends each month on what I call “Personal Hackathons”.
These are my sprint sessions to build something that either:

Becomes a product I can monetize, or
Eliminates friction from my daily workflows.

Here are some projects I’ve already built for myself, and a few more I’m planning for the coming weeks.

Environment Status updates in Messaging Channels

Build a tool that periodically monitors a service and takes action when certain conditions are met, for example:

If the response code isn’t 200, notify the DevOps team and possibly a potential fix aswell using an LLM.
If latency exceeds 250ms, alert the development team and automatically create a ticket in your project management tool. -If the issue is simple, trigger a background coding agent to work on the task and raise a PR.

This isn’t just for your organization, you can use it for your own hosted services as well.

What to learn

A bit of scripting (Bash/Python/Node.js)
REST APIs for your deployment environment.
Power automate/n8n if your organization have the subscription.
Prompt engineering.

How to approach

Set up a bot or webhook for the messaging medium that your organization uses.
Create a small service that fetches environment status from your infra (K8s cluster, VM health checks, API uptime).
Post updates on-demand or at intervals to a dedicated Teams channel.
Use the issue and code repository context, ask a coding agent to work on the task.

Potential

Saves “Hey, is staging up?” Slack/Teams chatter.
Can be extended to trigger alerts on failures.
Please make sure your team’s in the loop and that you’re within organizational policy, before the IT team catches you and makes that face.

CI/CD Pipeline Highlighter/Alert

This is similar to the previous tool. Build a tool that can detect pipeline completions or failure and trigger an alert to the respective person.

I have built this exact thing but only for highlighting, but you can extend it to alert. Below I have mentioned each of the learning path with “[Alerting]” or “[Highlighting]”

What to learn

[Alerting] Your DevOps provider API (Azure, GitHub or others)
[Highlighting] Browser extension development.
[Highlighting] Basic HTML/CSS for visual cues.

How to approach

[Alerting] Fetch pipeline run data via Azure DevOps API.
[Highlighting] Highlight failed tasks, bottlenecks, or flaky tests visually.
[Highlighting] Build as a browser extension.
[Highlighting] String parsing through HTML to find the relevent emails.

Potential

Immediate clarity on where a build went wrong.
A massive time-saver during release crunch.
Shows skill in automation + front-end + Browser extension development.

WebUI for Ollama

Ollama is a local LLM model runner which works in command line interfaces. These models will output text in md format when it needs to structure the output but the command line doesn’t render the markdown content.

BTW, there is already a tool that does this https://github.com/open-webui/open-webui. But what’s the fun in that.

What to learn

Working with Ollama API
React/Next.js or any front-end framework you like or want to learn. Prompt engineering fundamentals

How to approach

Spin up a small web app that interacts with your local Ollama server.
Add features like conversation history, model switching, and file uploads.
Keep it lightweight and internal for personal productivity.

Potential

A custom AI playground tailored to your needs.
Gateway to experimenting with AI tools without leaving the browser.

Retrain an LLM to Talk Like You

This one’s pretty self-explanatory. I’ve wanted to build it since my first year of university, after reading a post about a Chinese guy who created a tool to reply to his girlfriend, and she didn’t realize for an entire year.

I’m still not sure how he pulled that off without the advancements we have in LLMs today (and I don’t recall seeing the word LLM in that post either), but still… it’s a pretty cool project to try.

What to learn

Fine-tuning LLMs
Dataset creation & cleaning
Messaging API integrations (WhatsApp via Twilio, Telegram bots, Signal API) to read and respond to the texts.

How to approach

Collect your writing/chat history (with consent where required).
Fine-tune a small open-source model to mimic your tone and style.
Deploy the model on a server and connect it to WhatsApp or other messaging platforms.

Potential

Your own AI assistant that sounds like you.
Can help with drafting messages, reminders, or automating repetitive responses.
An advanced AI + automation project that’s a great portfolio talking point.

Some of the projects mentioned here involve data you may or may not have permission to access. Always communicate with the right stakeholders and make sure you’re following applicable policies and laws.

Stay Curious. Adios 👋

Cover image generated with ChatGPT using DALL.E

Why Vibe Coding Isn't the AI Utopia You Think It Is

hiruthicSha — Sat, 09 Aug 2025 06:56:56 +0000

The internet loves good vibe coding post like "AI wrote my app in 5 minutes".

I mean, attention is gold in content creation and I totally get it but it doesn't show the other side of the process. Especially about the part where people say its replacing developers.

It does raise the bar as now anyone can build a product with LLMs and vibe coding is fast. It feels smart. But it's not replacing developers. It's reminding us why they still matter.

What Is Vibe Coding?

Vibe coding is what happens when developers offload code generation to AI. You give a high-level instruction like: "Write a function to parse a config and return only the active keys." and let the AI do the rest.

The appeal is real. You get speed, fewer keystrokes, and less context-switching. The code often looks right, but that's not the same as being right.

My Experience

I've been using LLMs for code since GitHub Copilot first dropped in early 2022 so without realizing it, I've been vibe coding for quite a while.
Looking back, the evolution is undeniable. The current models are incredibly powerful. But even with all that progress, I never really felt like I was co-programming with an AI.

At best, it helped me move faster, especially through the boring parts. It felt like a supercharged autocomplete, and honestly, that was great. But today's coding models are marketed as pair programmers, and that's where the illusion begins.

Yes, the latest models are surprisingly capable. They've helped me generate things I didn't expect them to pull off. But here's the catch: it's still a coin toss. You might get exactly what you want, or something that totally misses the point. And even if it looks right, accuracy is never guaranteed.

Sure, you could write a 1000 word prompt to steer it correctly, but come on, WTF? At that point, you might as well just code it yourself. 🤷‍♂️
And honestly, that's to be expected. These models don't think, they run on probability, predicting the next best token. The real issue is how people treat them like some kind of god-tier dev replacement.

A Recent Issue I Faced #1

Here's what happened:

I asked the LLM to write a helper function. Simple stuff. It needed to read from a dictionary, extract some values, and return results. Instead of using dict.get(), the AI used dict.pop(). Of-course I had to give a big ass prompt, but this is the idea anyway.

At first glance, it worked.

But I realized later that this mutated the original dictionary. And that same dict was used later in the codebase. Suddenly, things were breaking.
Why? Because pop() removes the key. The AI broke a cardinal rule of clean code: never modify inputs unless that's the point. This wasn't just a bad choice, it was a sign that the LLM didn't understand intent.

It Had All the Context

The code wasn't deeply nested. It was a short function, called directly from a file.

This wasn't a case of lacking information. The LLM had everything it needed. It just didn't reason about it. It didn't realize that mutating the dict would have downstream effects.

Because it can't reason. It only predicts.

To my surprise, even the reasoning model failed this task multiple time and I had make the changes myself.

There are a lot of times I had these issues along the years but it never bothered me as I wasn't expecting them to code for me instead to assist me. But the AI bros on the internet have a different idea.
Don't get me wrong, there were days when I pushed the agents to their limits, relying on them to write nearly 80% of the code. That's exactly how this project came to life: I Vibe‑Coded My Way Into a Broken Android with ChatGPT & Python.

A Recent Issue I Faced #2

I've been trying to migrate some data-fetch logic from one data source to another data source. In theory, the job is easy: read the existing code, follow the call chain, note what each method actually returns, and rewrite the bits that need changing. In practice?

Copilot and other VS Code extensions kept telling me, "They call this method; I assume it returns X."

Gee, thanks, Copilot. I, too, can assume.🤷‍♂️

The whole reason I summoned an AI sidekick was so I wouldn't have to spelunk through twenty-three files at 2 AM.

Could I stuff every source file into the prompt? Sure. But by the time I've hand fed the model half my repo, I already understand the code, and I'm paying $10/month for the privilege of explaining it to a chatbot.

Weirdly, this guessing game only happens with Copilot, Gemini, and most VS Code extensions. Cursor? That thing actually reads the code. It hops through references, figures out real return types, and gives answers that don't begin with "I assume." It's not perfect (the previous issue with python code was done in cursor), but at least it behaves like it's seen my codebase before.

The Tech Is New, And That's the Point

This is bleeding-edge stuff. Tools like prompt.md, instructions.md, and AI-assisted flows are emerging to guide LLMs more effectively. We're learning how to wrangle them.

But even with those tools, this tech is not yet a silver bullet. It's powerful, but still unreliable in critical workflows. It's evolving fast, but not fast enough to replace developers.

What vibe coding is doing is shifting the developer's role:

From author to editor.
From builder to reviewer.
From executor to architect.

It still needs your defensive programming habits. Your understanding of why some choices are bad even if they "work." You still hold the ownership of the things you build with it.

I did try this with multiple models GPT4 & 4.1, o3-mini, Sonnet 3.7 and few Gemini models and they all seem to have the same output except when used in Cursor.

You're Still the Engineer

AI is an incredible assistant, not a replacement.

It can vibe. It can guess. But it can't own code.
It can't architect. It doesn't live with the consequences of its predictions.

So sure, vibe code away. Just remember who's really accountable.
Stay Curious. Adios 👋

Cover image generated with DALL.E using ChatGPT

I Vibe‑Coded My Way Into a Broken Android with ChatGPT & Python

hiruthicSha — Mon, 16 Jun 2025 07:47:44 +0000

It started with a crack, literally…

My friend dropped her phone on asphalt, and after six long years of brutal survival, the screen finally decided it had had enough.

We're talking six years of tech abuse. No screen protector, no hard case, multiple drops on every imaginable surface. We used to joke that this phone was the true successor to the legendary Nokia brick. This device had more scars than the guy fighting the final boss.

But this time it was different, guess it's just Wrong asphalt, wrong time.

The display still lit up, but the touchscreen? Possessed. Ghost taps everywhere, especially on the bottom edge, where it developed a deep obsession with hammering the Android "Back" button, like it was desperately trying to erase its own existence.

To make matters worse, she lives life on maximum risk mode, no cloud backup, no SD card, no local copy. Just raw, unprotected digital chaos.

Replacing the screen? Not happening. The model was so old, it should've come with museum tags.

That's when the idea struck: What if we never touch the screen again?

Armed with ChatGPT, Python, ADB, and a whole lot of vibe coding, I hacked together a way to remotely control the phone using ADB. I ended up writing a tool that let me tap, swipe, and type on the phone, all by clicking on screenshots. And it actually worked.

The Problem

We figured this was finally the moment to retire the old warrior and get a new phone, repairing it would've been expensive, given its age, and even then, it was living on borrowed time which makes the use even more risky.

We had one mission: get the data out.

But that was easier said than done. Every time we tried to open an app or navigate the UI, the ghost taps would kick in, slamming the back button, opening random apps, or just spamming nonsense. It was like trying to defuse a bomb while someone kept pressing "Cancel".

Since a screen replacement which was our easy way out, wasn't an option, we thought about buying a USB-C to USB-A (female) adapter to plug in a mouse and control the phone that way. But that meant waiting for the adapter. Since I had an idea in mind, I challenged myself: "Let me try fixing this before you finish that venti iced coffee."

Idea

I've seen people doing things with ADB to control things like tapping the screen and opening apps or installing. Since I still had the android development setup in my laptop, I quickly found the platform-tools location in my android SDK directory and tried connecting the device.

Thankfully, the phone already had Developer Options and USB debugging enabled, from back when I used it to test a few apps. And since it was running an older version of Android, the Developer Options hadn't hidden themselves again, like newer versions love to do.

That meant ADB was almost ready to roll, the only hurdle left was tapping "Allow" on the "Trust this computer?" prompt that appears the first time you connect ADB from a new machine. After the painful yet fun 5 minutes of a pleasant Tuesday evening, we were able to click the allow button before the ghost tapping started!

Attempt #1: Screenshots, Coordinates, and Pain

With USB debugging enabled, I knew I could control the phone using ADB, this means I could simulate taps and swipes without physically touching the screen.

I started by blindly guessing the coordinates, because hey, what could go wrong? Turns out: everything.

I ran commands like:

adb shell input tap 500 1000

…and hoped it landed on the right button.

Sometimes I'd get lucky and open the correct app. Most of the time, though, I was just poking empty pixels.

So I leveled up, just a little.

I began taking screenshots with ADB:

adb shell screencap -p /sdcard/screen.png
adb pull /sdcard/screen.png

Then I'd open the image in MS Paint, hover over the UI element I wanted to tap, grab the x and y coordinates, and fire off an ADB tap with surgical precision.

It was progress… but every single tap felt like a full-blown side quest: screenshot, open Paint, find coordinates, run command, observe results, repeat.

The whole process felt like trying to control a wild animal using chopsticks.

There had to be a better way. I decided it was time to automate the chaos. And me being me, if something has more than zero steps, I'm automating it. You'd know that if you've been following along and reading these stories:

Attempt #2: Vibe coding a tool

The goal is to be able to click on the phone screen from my machine using ADB. So, my requirements are:

Render the phone screen on my machine by taking a screenshot.
Get the coordinates when I click on the screen and generate an ADB command, and send it.
Need a way to type, for input fields like phone numbers or login forms.
Need a way to swipe to unlock by pattern.

So I spent maybe like 5 mins creating the prompt for my requirements and asked ChatGPT. After reviewing the code, and asking it to cover a few cases and few adjustments later, I had a tool that could mirror my phone. Now, after finding the sweet spot between the code crashing and having a steady stream of screen updates, I had around 20–25 FPS.

And that's it. From there, I shared my script with her, gave her instructions on how to use it, and in under 30 minutes, the WhatsApp backup was under control, and other backups were also started.

Lessons Learned at a Coffee Time

In the end, we didn't need a new screen, a USB adapter, or even a working touchscreen.

All we needed was a bit of Python, some OpenCV magic, and a spark of vibe coding spirit.

With a little help from ChatGPT, I turned a random idea into a working tool that saved data from a decade-old phone powered purely by commitment and sheer f***ing will.

And yes, for the record, I did finish before she finished her coffee.

Never thought I'd say this, but coding does make life a little better.
That is… as long as you use it wisely, and actually understand what your LLM is spitting out.

So, always enable USB debugging.

That's a joke, please don't. Backup regularly and keep your data safe.
Here is the script: https://gist.github.com/hiruthicShaSS/e2ce710032199729b16160eb040e5c8d

Stay Curious. Adios 👋
Cover image generated with ChatGPT.

You're Still Using Just One Type of Breakpoint?

hiruthicSha — Sun, 08 Jun 2025 06:09:26 +0000

Most developers smash F5, F9 and F10 or click the buttons that are far left that you need to swipe your mouse twice to reach.
But what if I told you you're only scratching the surface of what morden debuggers can do?
There's a whole toolbox (or 3 which I going to cover) of smarter breakpoints that can save your time if you learn how to use them.
Let's break them down. (Pun intended.)

The Basic Breakpoint

Let's get this out of the way.
You set it up on a line, the execution stops, you inspect stuff.
It works, until your app loops 999 times or you're tracing something that happens sometimes under some condition. That's when the basic Breakpoint becomes… basic.

Conditional Breakpoint

Break only when a condition is met.
Perfect when you're debugging a loop but only care when i == 998.
So, no more pushing debug lines to the PR like this anymore:

if (i == 998) Console.WriteLine(x);

Instead, right click on your breakpoint or the breakpoint pane -> "Condition"-> i == 998. And boom. It'll pause only when it matters.

Tracepoint / Logpoint

Print without pausing.
Sometimes you want to see what's happening, but stopping the program ruins the flow. That's where tracepoints come in.
Log values, hit counts, or custom messages straight from the debugger, no debug code is required.
Let's say, you're debugging a race condition or async code. A normal breakpoint ruins it. A tracepoint observes silently.

Temporary Breakpoint

Trigger once, then disappear.
Ideal when you're checking a one-time setup or a rare code path.
Why spam breakpoints or logs and keep cleaning up later? This one is deleted once the breakpoint is hit.
Just right click and mark it temporary.

Dependent Breakpoint

Break only after another one fires.
Let's say, you have a multi-step validation process where you only care about your breakpoint when a particular breakpoint is also hit.
Instead of manually tracking that, you cane make a breakpoint dependent on another breakpoint.

Data Breakpoint / Watchpoint

Triggers on field/property write or read operations. Useful when the output is wrong but you suspect that something else is also changing the property or field.

This type may not be available on all.

Debugger didn't stop there, but it's a start and knowing these exists can help you do your job a lot let less harder.
Stay Curious. Adios 👋

You're Not Debugging. You're Just Wasting Time

hiruthicSha — Sun, 01 Jun 2025 05:41:04 +0000

If I had a penny for every time a developer copy-pasted an error into Google or Stack Overflow without reading it, I'd be running a global datacenter by now. And don't get me started with this new LLM race, blindly following what the LLM asks you to do.

An error pops up… and instead of reading it, your fingers are already firing up Chrome. Paste. Search. Click random Stack Overflow answers. Try. Fail. Try again. Maybe drop it into ChatGPT, hoping magic happens.

And somehow, this feels like debugging.
Let's be clear, this is not debugging.

It's reaction. It's panic. It's a habit. And it's wasting your time, your growth, and your ability to actually solve problems.

Trial-and-Error Culture

We've all been there. Stuck. Frustrated. The deadline is creeping up, tasks are getting reprioritized and all you want is for the damn thing to work. So what do you do?

Paste the error into Google.
Click the first few links. Hope that someone have faced the same error as you.
Try the top-voted fix.
Didn't work? Try the next.
Still doesn't? Ask ChatGPT. Copy. Paste. Pray.

Most of the times it works. But you didn't learn why. You don't know what caused it. You don't know what actually fixed it. You just know that something made the red squiggly go away.

This is the trial-and-error trap, a culture of coding that looks like progress but isn't.

In a world flooded with AI tools, blogs (written by AI), answer farms (made by AI), and auto-complete (AI again), we've unknowingly trained ourselves to skip the one thing that truly matters:

Thinking

The irony? Most errors already tell you what's wrong. Stack traces, logs, line number, they're practically handing you the answer. But we've built this twitchy, compulsive loop around skipping them.

Don't get me wrong, there's nothing wrong with searching for help. If you're digging into the why, exploring different angles, and making informed, calculated decisions, you're doing it right.

But that's not what most developers are doing.

The problem starts when you blindly apply every fix you find online, hoping something sticks.

What This Is Doing to You

You're Losing Knowledge

Every time you skip understanding an error, you miss a chance to sharpen your mental model of how things work.

You don't understand why the issue happened.
You can't explain what fixed it, or worse, if it's really fixed.
You become dependent on external tools to solve basic problems.

You're not building experience. You're just building a stack of accidental successes. If you can't explain the root cause, you haven't actually debugged anything.

All this adds up, and before you know it, you are single-handedly destroying the project.

You're Wasting Time

Being on this loop may feel fast, but it's not.

You might find a fix in 5 minutes today. But because you didn't understand it, you'll spend 2 hours on a similar bug next week. And next month. And during production.

Chasing unrelated solutions because you didn't analyze the actual error.
Applying fixes that seem to work but introduce silent bugs.
Wasting time debugging the same class of problems repeatedly.

The trial-and-error habit doesn't just slow you down in the moment, but it quietly chips away at your growth and efficiency over time. This is brainrot for developers.

Think about it. You're in an interview, and the recruiter hits you with the classic:

"Tell me about a challenging task you faced and how you solved it."

Now what do you say?

"Yeah, I bravely copy-pasted 10 random solutions from Stack Overflow until one of them kind of worked… I think."

That's not a story. That's a montage of confusion.

You didn't struggle with the problem — you struggled with the copy-paste buffer. And when they ask you to explain what the actual issue was or why your 'fix' worked?

Crickets. 🦗🦗🦗🦗

The LLM Trap

Look, I love LLMs as much as any developer. It's fast, helpful, and honestly kind of magical. But here's the uncomfortable truth: If you don't know what you're asking, LLMs won't save you.

They'll respond with 500 words of confident-sounding nonsense, sprinkled with just enough keywords to feel legit. But without your context or understanding, it's just noise dressed as code.

LLMs are powerful tools, but they can't read your mind. They don't know your architecture, your business idea, or your weird edge-cases. And if your first move is to dump errors into an LLM hoping for divine intervention, you're just automating the same bad habit.

And no, it doesn't matter if the response sounds smart. LLMs are trained to be fluent, not necessarily correct.

How to Actually Debug

1. Read the Error

Modern tech is built around developer experience. Most of the times the error clearly states what went wrong and languages like Rust even suggest you possible fixes.

You just have to read it, understand the trace and make a calculated decisions.

2. Reproduce it

Can you reliably trigger the error? What changed recently? Does this happen only with specific data or tenant? Does the environment play a role in this behavior?

Asking these questions will itself lead you to figuring out 80% of the problem.

3. Form a Hypothesis

Take an educated guess on what could be wrong and test it

"I think this fails because X happens before Y."

"What if this object is null because of Z?"

Now you have something to test. Something to validate or eliminate.

4. Search with Precision

Now, go to Google, but with clarity. If you want to use an LLM, don't just paste the error. Add context:

What you're trying to do.
What language/framework you're using.
What you've already tried.

You'll get better answers and be more likely to understand them.

5. Reflect Once it's Fixed

The moment you get it working, don't just sprint to the next task.

Stop. Ask:

What actually went wrong?
Why did this fix work?
Could it happen again?
Should I document it or write a test?

This is where real growth happens, not when you fix it, but when you understand it.

Debugging isn't about memorizing solutions. It's about training your brain to think like a system.

And the sooner you get out of the trial-and-error cycle, the sooner you start writing code like someone who actually owns it.

Let's be clear, there's nothing wrong with using Google, Stack Overflow, or LLMs.

In fact, it'd be silly not to. These tools exist to help us move faster, solve problems, and learn from each other.

But the line between help and habit is thin.

The real issue isn't the tool — it's skipping the thinking part.

If you're not taking the time to understand the problem, you're not growing. You're just duct-taping your way through it.

So use the tools. Copy that snippet. Ask that LLM.

But do it after you've read the error, asked questions, formed a theory, and tried thinking it through.

Stay Curious. Adios 👋

MMMCP - An MCP Server for Multi-Model Prompts

hiruthicSha — Sun, 25 May 2025 05:35:00 +0000

As a software engineer deeply engaged with large language models (LLMs) like ChatGPT, Claude, and Gemini, I often cross-reference their responses to gain diverse perspectives. This practice sparked a question: Can I streamline this process?

I also started seeing a wave of posts claiming how easy it is to build an MCP server. That was enough motivation, even if it didn't work out, I knew I'd learn about building an MCP and gain hands-on experience in the process.

This project was born out of one of my regular weekend hackathons, something I've written about in Code, Coffee, and a Weekend: My Personal Hackathon Ritual. If you've ever felt that itch to just build something for the joy of it, you'll relate.

What is MCP?

I'm sure, at this point you would have bombarded by the new buzz word "MCP Server". So Ill keep it brief.

Problem

Integrating LLMs with external systems is a mess. Every use case required custom scripts, tool-specific APIs, and brittle logic hardcoded into the prompt or application. This is a headache even in small-scale use cases due to:

Tight coupling: Tools and models were glued together in non-standard ways.
Lack of reusability: Every integration had to be rebuilt from scratch.
Security concerns: Exposing sensitive systems via direct API calls was risky.
One-way interactions: Models could only respond, not act or observe.

Solution

Model Context Protocol (MCP) is Anthropic's attempt to fix this mess.
MCP is a standard protocol that allows models to interact with external tools in a structured, secure, and two-way fashion. Here's what it improves:

Two-way communication: Models can request data and act on responses.
Modular design: Tools are plug-and-play, and models can discover and invoke them dynamically.
Security-first: Tool usage is transparent, scoped, and auditable.
Context awareness: Tools can expose metadata, usage instructions, and schemas that the model can understand natively.

This makes LLM integrations predictable, scalable, and safer. Here is a general statement you'll see for an MCP:

Think of MCP as the "USB-C" for AI applications, providing a standardized way to connect AI models to various services and datasets.

Here is a shameless plug: https://www.instagram.com/p/DIpoV9OzayA Please follow!😌

Building MMMCP

I'd been hearing about MCP for a while but didn't pay it much attention at first. However, since I'm someone who loves automating anything that seems possible, I knew I had to give it a shot. If you've been following my other articles, you already know I'm a bit of an automation freak…

Problem

The problem I faced was that I've been using LLMs since before ChatGPT went mainstream, and I often cross-check answers from multiple models to reduce bias and gain richer insights. For example, Claude tends to make fewer coding errors, Gemini (sometimes in the AI Studio) is more expressive, and ChatGPT excels at handling complex context. Comparing their responses helps me think more critically and make better decisions.

What I Built

Motivated by the need for a more efficient comparison between LLMs, I developed MMMCP (Multi-Model MCP Server). This MCP server:

Accepts any prompt.
Fetches responses from OpenAI's GPT-3.5 and Google's Gemini Pro asynchronously.
Returns both responses for quick comparison.
Optionally summarizes the outputs for a consolidated view.

The MMMCP server is built using Python(for now) and sends the prompt to multiple LLMs through API calls.

Future Enhancements

Update the code architecture to provide a better experience in adding new models.
Integrate additional LLMs for broader comparisons.
Enhance summarization capabilities to be able to configure by the user for more personalized outputs.
Building the project in Python introduced one challenge: deploying it to Cloudflare. While Cloudflare offers beta support for Python, I'm hesitant to rely on it just yet. So, I'm planning to migrate the project to JavaScript for better compatibility.

Here is the project: https://github.com/hiruthicShaSS/MMMCP. I built it over a weekend, so it's not perfect, it needs refactoring and better decoupling to make adding new models easier. I'll update it when I have time, but I welcome any feedback or suggestions. Feel free to open a PR if you'd like to contribute! 🙂

BTW, if you want to learn more about MCP, Hugging Face has an extraordinary course on this topic: https://huggingface.co/learn/mcp-course/unit0/introduction

Stay Curious. Adios 👋
Cover image generated with ChatGPT