DEV Community: Mani Movassagh

MCP Explained: How AI Plus MCP Controls a Real Browser

Mani Movassagh — Thu, 26 Mar 2026 08:35:51 +0000

The Problem

AI models like Claude are powerful — but they live inside a text box.

By default, I can read your message, think, and reply. That's it. I cannot open a browser, click a button, fill a form, or take a screenshot. My "hands" stop at the conversation window.

Developers worked around this by building custom integrations — glue code that connected AI to specific tools. Every team reinvented the wheel. There was no standard.

Without MCP:
  Claude ── custom glue ──► Playwright
  Claude ── custom glue ──► Supabase
  Claude ── custom glue ──► Gmail

Every integration was one-off, fragile, and hard to maintain.

What MCP Is

MCP stands for Model Context Protocol. It is an open standard created by Anthropic that defines one consistent way for any AI to communicate with any external tool or service.

Think of it like USB. Before USB, every device had its own connector. After USB, one standard plug worked with everything. MCP does the same for AI tools.

With MCP:
  Claude ── MCP ──► Playwright MCP Server ──► Browser
  Claude ── MCP ──► Supabase MCP Server   ──► Database
  Claude ── MCP ──► Gmail MCP Server      ──► Email

Same protocol. Different servers. Infinite tools.

The Language: JSON

MCP communicates using JSON messages — structured text passed back and forth between Claude and an MCP server.

When I want to navigate to a URL, I send this:

{
  "method": "browser_navigate",
  "params": {
    "url": "https://google.com"
  }
}

The server executes the action and sends back a result:

{
  "status": "navigated",
  "url": "https://google.com"
}

That's it. No magic. Just JSON flying between two programs.

The MCP Server: The Translator

Raw Playwright has no idea what to do with my JSON. It doesn't speak MCP natively.

That's where the Playwright MCP Server comes in. It is a small program that:

Listens for JSON messages from Claude
Translates them into real Playwright API calls
Controls the browser
Sends results back to Claude

Claude ──JSON──► Playwright MCP Server ──► Playwright ──► Browser

The MCP Server is the middleman. It bridges the gap between my structured messages and the actual browser automation library.

Where It Runs: Your Machine, Not the Cloud

This is a common misconception. The Playwright MCP Server does not run on AWS, Anthropic's servers, or anywhere on the internet.

It runs as a local process on your machine, right alongside Claude Code:

Your Machine
├── Claude Code
├── Playwright MCP Server  ← a Node.js process, running locally
└── Chrome / Firefox

Claude Code connects to it through a local socket or pipe. Your browser never leaves your machine unless you navigate to an external URL.

How Claude Discovers Tools: The Handshake

When Claude Code starts, it reads a config file (.mcp.json or settings.json) that lists available MCP servers:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp"]
    }
  }
}

Claude Code starts the process, then immediately asks:

"What tools do you offer?"

The Playwright MCP Server replies with a full list of available tools and their parameters:

{
  "tools": [
    {
      "name": "browser_navigate",
      "description": "Navigate to a URL",
      "parameters": {
        "url": { "type": "string", "required": true }
      }
    },
    {
      "name": "browser_click",
      "description": "Click an element on the page",
      "parameters": {
        "selector": { "type": "string", "required": true }
      }
    },
    {
      "name": "browser_take_screenshot",
      "description": "Take a screenshot of the current page",
      "parameters": {}
    }
  ]
}

Claude reads this list and now knows exactly what it can ask Playwright to do.

A Full Real Example: End to End

Let's trace one complete action. You ask Claude:

"Take a screenshot of google.com"

Here is every step that happens:

1. You ─────────────────────► Claude
        "screenshot google.com"

2. Claude ──────────────────► Playwright MCP Server
        {
          "method": "browser_navigate",
          "params": { "url": "https://google.com" }
        }

3. MCP Server ──────────────► Browser
        playwright.goto("https://google.com")

4. MCP Server ──────────────► Claude
        { "status": "navigated" }

5. Claude ──────────────────► Playwright MCP Server
        {
          "method": "browser_take_screenshot"
        }

6. MCP Server ──────────────► Claude
        { "image": "<base64 encoded image data>" }

7. Claude ──────────────────► You
        [displays the screenshot]

Two JSON calls. One visible result. Claude is orchestrating each step, deciding what to call next based on the previous response.

How Claude Finds Elements: Visual Reasoning

Simple selectors work fine when the HTML is clean:

{ "method": "browser_click", "params": { "selector": "#submit-btn" } }

But real pages are rarely that clean:

<div class="x7k2p" data-v="3">Submit</div>

No useful selector. So Claude takes a different approach:

Calls browser_take_screenshot — receives a base64 image
Visually inspects the image — Claude is multimodal, it can see
Locates the button by its appearance and position
Clicks using pixel coordinates

{
  "method": "browser_click",
  "params": { "coordinate": [842, 560] }
}

No CSS selector needed. Claude reasons the same way a human would — it sees a blue "Submit" button in the bottom right and clicks there.

This is the loop that makes MCP powerful:

Claude ──► screenshot ──► [sees, thinks] ──► click ──► [sees, thinks] ──► next step

Snapshot vs Screenshot: Choosing the Right Tool

Taking a screenshot on every step is expensive — images are large and slow to process.

Playwright MCP offers a smarter alternative: browser_snapshot. Instead of an image, it returns the accessibility tree of the page as text:

button "Submit" [id=submit-btn] at (842, 560)
input "Email" [id=email] at (400, 300)
link "Forgot password?" at (400, 400)

This gives Claude exact element references, names, and positions — without processing a full image.

Situation	Use
Need to see visual layout or styling	`browser_take_screenshot`
Need to find and interact with elements	`browser_snapshot`
Debugging a visual bug	`browser_take_screenshot`
Fast, efficient automation	`browser_snapshot`

MCP vs Writing Your Own Playwright Script

Both can automate a browser. So when do you use each?

Situation	Use
One-off task: "grab this data for me"	MCP — no code needed
Repeatable test in CI/CD	Playwright script — version controlled
Debugging a flaky test interactively	MCP — Claude reasons step by step
Production test suite	Playwright script — no AI dependency

The core difference:

MCP              = Claude drives the browser live, reasoning at each step
Playwright script = code drives the browser, no AI at runtime

But here is the most powerful pattern — use both together:

Use MCP to explore the page, figure out the right selectors and flow, then ask Claude to write the Playwright script based on what it just learned.

You get the best of both worlds: AI-assisted discovery, production-grade output.

Setting It Up Yourself

Getting Playwright MCP running takes three steps.

1. Install the MCP server

npm install -g @playwright/mcp

2. Add it to your Claude Code config

Create or edit .mcp.json in your project root:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp"]
    }
  }
}

3. Restart Claude Code

Claude Code will automatically start the server, perform the handshake, and add all Playwright tools to its capabilities.

Now try it:

"Go to github.com and take a screenshot"

Claude will navigate, capture, and show you the result — no code written, no script run.

What You Now Know

MCP is a standard protocol — the USB of AI tools
It uses simple JSON messages over a local connection
The MCP Server is a translator between Claude and the real tool
Everything runs locally on your machine
Claude discovers tools automatically via a handshake at startup
Claude reasons visually between steps — it sees, thinks, then acts
MCP is for interactive exploration; scripts are for production automation
The killer combo: use MCP to discover, then generate a script

🧰 Springman – A Fast Go CLI to Boost Your Spring Boot Development 🚀

Mani Movassagh — Mon, 09 Jun 2025 18:14:56 +0000

If you're a Java developer who builds Spring Boot applications regularly, chances are you're tired of clicking through start.spring.io or managing repetitive tasks manually.

That's where Springman comes in — a lightweight CLI tool written in Go that lets you:

✅ Generate Spring Boot projects

✅ Run them instantly with Maven or Gradle

✅ Add or remove dependencies from pom.xml

✅ Build once and use from anywhere

🌱 Why Springman?

As a full-stack developer, I often found myself switching between front-end and backend work, and I wanted something blazing fast, offline-capable, and super clean for bootstrapping Java projects.

So I built springman, and I open-sourced it here:

👉 GitHub – manimovassagh/Springman

🔧 Features

springman new myapp --build maven → create a Spring Boot project
springman run myapp → run it with Maven or Gradle (auto-detected)
springman add myapp group:artifact[:version] → add dependency to pom.xml
springman remove myapp group:artifact → remove it from pom.xml

All XML operations are safely parsed and formatted. You’ll never break your pom.xml again 😎

💻 Quick Installation

git clone https://github.com/manimovassagh/Springman.git
cd Springman
go build -o springman
sudo mv springman /usr/local/bin/
springman --help

💚 Built With
• Go 1.21+
• Cobra CLI
• Standard XML library
• Lots of ☕ and love

⸻

🙌 Contribute or Fork It

Feel free to:
• Fork the project
• Suggest features (Gradle DSL support? Native Image runner?)
• Drop a ⭐ if you like it

⸻
If you like please give an start to support project ⭐⭐⭐
Made with ❤️ by Mani Movassagh
🔗 GitHub

👉 https://github.com/manimovassagh/Springman

From Java to .NET: A Journey of Curiosity, Confusion, and Compilation

Mani Movassagh — Sun, 08 Jun 2025 16:39:58 +0000

💬 "Java is to C# what Kaffee is to Kaffe... one is just smoother in .NET."

– Every confused Java dev ever

☕ Why I (a Java Dev) Looked at .NET and Thought: "Wait... You Too?"

If you're a seasoned Java developer like me, you’ve probably been living in the world of Spring Boot, JVM tuning, and curly braces for breakfast. Life was good… until one day, a .NET developer casually said:

"We have dependency injection, too."

Hold up. You what?

So began my quest to discover what lies in the realm of Microsoft’s ecosystem. Spoiler alert: It's not just Windows Forms anymore.

🎒 Packing the Java Backpack

Before entering the land of C# and Program.cs, here’s what I brought with me from Java:

✅ OOP experience
✅ Familiarity with Spring Boot (which helps a LOT)
✅ Love for annotations (a.k.a. attributes in .NET)
✅ And that deep, unexplainable bond with IntelliJ IDEA

But I also brought along:

❌ A few biases (thinking C# is just “Java with a Microsoft logo”)
❌ The trauma of NullPointerException
❌ And a tendency to Ctrl+Shift+R like it works in Visual Studio

🚀 Starting with .NET 8 (Yes, Jump to the Latest!)

.NET has matured—like wine or that annoying cousin who’s now a billionaire. .NET 8 is cross-platform, fast, and comes with:

🧱 Minimal APIs (hello, Lambda-lovers)
🔥 Native AOT (yes, your app can be fast and tiny)
🐳 First-class Docker support
🧪 Great testing tools out of the box

If you're used to Maven and Gradle, fear not. dotnet CLI is your new best friend. Think dotnet new, dotnet build, dotnet run, and you're off to the races.

🧠 C# vs Java: Same But Different

Concept	Java	C#
Interfaces	Yep	Yep
Lambdas	Since Java 8	Since forever
Records	Since Java 16	Since C# 9
`var` keyword	Java 10+	C# 3+
Null safety	Optional + pain	Nullable reference types (👍)
Checked Exceptions	Yes (😬)	Nope (😎)

Bonus: C# gives you async/await that actually makes sense.

🏗️ Building a Web API: Spring Boot vs ASP.NET Core

Feature	Spring Boot	ASP.NET Core
Annotation/Attribute	`@RestController`	`[ApiController]`
Route mapping	`@GetMapping("/path")`	`[HttpGet("/path")]`
DI	`@Autowired`	Constructor injection
Build tool	Maven/Gradle	dotnet CLI
Swagger/OpenAPI	SpringDoc	Built-in with 1 line 🧙‍♂️

Here’s how you define an endpoint in .NET 8 Minimal API:

app.MapGet("/hello", () => "Hello, Java friend 👋");

Yes, that’s it. It’s not a trap.

⸻

😱 What Surprised Me
• Visual Studio is powerful… but Rider is still bae
• Entity Framework Core feels like JPA’s cool cousin who skipped XML hell
• C# syntax is cleaner than I expected. Like… really clean
• Native AOT makes .NET blazingly fast

⸻

📚 Best Resources for Java Devs Learning .NET
• 📖 Microsoft Learn: .NET for Java Developers
• 🎥 YouTube series: “Java to .NET in 30 days”
• 🧪 Build a CRUD app with ASP.NET Core + EF Core
• 🛠 Try running a .NET app in Docker just to flex

⸻

🥲 What I Missed from Java
• The ecosystem around Spring (Spring Boot starters are 🤌)
• Maven’s lifecycle (dotnet CLI is simpler but takes getting used to)
• The JVM’s maturity (but .NET has caught up BIG TIME)

⸻

🎉 Conclusion: Should You Switch?

Not necessarily switch — but learn it? Definitely yes.
.NET isn’t just a Microsoft dinosaur anymore. It’s modern, snappy, and very Java-dev-friendly. You’ll feel at home quicker than you think.

And hey, if you can survive Hibernate, you can survive anything 💪

⸻

Made with ❤️ by a coffee-powered dev who crossed over and didn’t look back… much.

⸻

Let me know in the comments if you’re also jumping ships — or just curious how far the C# rabbit hole goes. 🚢🐇

🎬 Building a .NET 8 Web API + GitHub Actions CI/CD — Vibe Coding Ep.1

Mani Movassagh — Sat, 07 Jun 2025 19:13:40 +0000

🔥 Welcome to the first episode of Vibe Coding with Mani!

In this real-world coding session, we:

Build a modern .NET 8 Web API
Use Entity Framework Core to connect to a SQL Server (running in Docker)
Set up a GitHub Actions workflow to automate build & deployment

No boring walkthroughs. No scripts. Just pure development vibes — experimenting, debugging, and building like a real dev.

🎥 Watch the Video

👉 Watch on YouTube

💻 Tech Stack

.NET 8 (Web API)
SQL Server + Docker
GitHub Actions (CI/CD)
Entity Framework Core

🧠 Ideal For

Developers learning backend with .NET
Anyone curious about CI/CD with GitHub Actions
Coders who enjoy watching real development flow and decision-making

📦 Source Code

🔗 GitHub Repo: Dotnet-Vibe

If you're tired of perfect tutorials and want to see how real devs think, break, and build — you're in the right place.

🛎️ Follow me for more Vibe Coding sessions using TypeScript, Java, AI tools, and fullstack tech.

— Mani 💻🎧

📚 10 Timeless Programming Books Every Developer Should Read (Especially If You’ve Been Coding for Years)

Mani Movassagh — Sun, 01 Jun 2025 14:15:36 +0000

📚 10 Timeless Programming Books Every Developer Should Read

(Especially If You’ve Been Coding for Years)

After years of working in software development—across Java, TypeScript, Go, Spring Boot, testing, automation, and even dabbling with Rust and C—I’ve finally decided to dive into programming books seriously.

Not tutorials. Not blogs. Books.

Books that shape how you think, not just what you code.

Here’s my personal list of the top 10 programming books that every developer—especially mid to senior level—should consider reading:

🧠 Top 10 Programming Books for Thoughtful Developers

The Pragmatic Programmer

by Dave Thomas & Andy Hunt

→ Timeless tips and philosophies for becoming a better engineer. You’ll relate to every chapter.
Designing Data-Intensive Applications

by Martin Kleppmann

→ If you’re building modern backends, this book will fundamentally upgrade your thinking on databases, events, and scale.
Computer Systems: A Programmer’s Perspective (CS:APP)

by Randal Bryant & David O’Hallaron

→ From C to assembly, memory, binary, stack, CPU—it’s the behind-the-scenes story of your code.
Clean Architecture

by Robert C. Martin

→ Structure, decouple, and scale your applications the right way.
Refactoring

by Martin Fowler

→ A practical, pattern-driven guide to transforming messy code into clean, testable architecture.
Operating Systems: Three Easy Pieces

by Remzi Arpaci-Dusseau

→ One of the most readable ways to understand how operating systems actually work.
Effective Java

by Joshua Bloch

→ If you write Java, this is gold. If you don’t, still worth reading for sharp language design lessons.
Software Engineering at Google

by Google Engineers

→ How large teams manage code quality, testing, scalability, and developer culture.
Structure and Interpretation of Computer Programs (SICP)

by Harold Abelson & Gerald Jay Sussman

→ A deep, abstract, brain-expanding book. Not practical, but unforgettable.
The Art of Unix Programming

by Eric S. Raymond

→ Principles, philosophy, and the Unix mindset behind tools we all use daily.

🤔 Why Books?

I've realized that books—unlike articles—give you space to think deeply, connect ideas, and reflect.

They don’t just teach you how, they make you ask why.

🔄 Your Turn

Have you read any of these?

Got any others that made you think differently as a dev?

Drop them in the comments 👇 I’d love to expand this list together.

Vibe Coding with Cursor AI

Mani Movassagh — Fri, 30 May 2025 18:46:44 +0000

Vibe Coding with Cursor AI: Building an Express + TypeScript REST API

I just released a new episode on my YouTube channel Tech Talk with Mani that I think you’ll enjoy:
👉 Watch it here

This is part of my Vibe Coding Series, where I explore real-world development tools and AI assistants — all in a relaxed, practical format.

🎯 In this episode, I team up with Cursor AI to build a backend REST API using Express.js + TypeScript.
We cover:
• Project setup with ts-node-dev
• Routing and folder structure
• Creating DTOs and entity layers
• Health checks and testing with Jest
• Letting AI assist in code generation and flow

⸻

🧠 Why you should watch:
• See how AI coding tools like Cursor can speed up real-world backend dev
• Learn clean code patterns using Express and TypeScript
• Follow along in a chill, step-by-step vibe — perfect for fullstack devs

⸻

If you’re into AI, TypeScript, or want to see how devs are building faster with intelligent tools, this one’s for you.

Let me know what you think, or drop your feedback — I’d love to hear it!
Also open to collaborations or coding hangouts 🧑‍💻🎥

Thanks,
Mani
Tech Talk with Mani

Welcome back to Part 3 of the Immo Finder App project! 👷‍♂️

Mani Movassagh — Sun, 18 May 2025 21:05:21 +0000

In this part, I focused on setting up the backend controller for managing apartment listings using:
• 📦 Spring Boot
• 🛠 PostgreSQL
• 🧪 Clean architecture and Flyway migrations
• 📸 Planned photo upload structure (coming next)

We walk through:
• Creating the ApartmentController
• Mapping the database models
• Preparing for property photos and metadata

🎥 Watch the episode here:
https://youtu.be/_4ZbZXC-nrA
Star the repo if you like it
https://github.com/manimovassagh/immo-finder

Building the Immo Finder App (Part 2) – Fullstack with Cursor AI & Vite + Spring Boot

Mani Movassagh — Sun, 18 May 2025 21:02:37 +0000

Hey developers! 👋
In this second part of my Immo Finder App series, we continue building a fullstack real estate platform using:
• 🧠 Cursor AI – to help us write smart code faster
• ⚡️ Vite + React (TypeScript) for the frontend
• ☕️ Spring Boot as the backend
• 🎯 Modern architecture with clean code

👉 In this episode, I set up the frontend and backend structure and connect the pieces using devcontainers + Vite + Tailwind.
📺 Watch it here:
https://youtu.be/JMRj59Hc_BQ
Star if you like the repo or feel free to colaborate
https://github.com/manimovassagh/immo-finder

springboot #postgresql #backend #realestate

From Microservices to Monetization: Building a Real Estate Platform the Right Way

Mani Movassagh — Sat, 17 May 2025 12:22:54 +0000

Intro Section:

After 15 years in software development and test automation, I decided to build something of my own — a real estate (Immobilien) platform tailored for the German market.

The idea was to combine what I know best: robust backend architecture, modern TypeScript frontends, and secure authentication — all designed from the ground up for monetization.

This article walks through the architectural decisions, technical challenges, and hard-earned lessons that shaped the platform.

⸻

🧱 Why Microservices?

I started with one clear goal: keep things clean and scalable. The platform includes:
• 🏘️ Multiple property types (house, apartment, garden…)
• 📦 Listings for rent and purchase
• 📸 File uploads for property photos
• 🧭 Address-to-Geo translation (lat/lng)
• 🔐 Secure login with role-based access

So I split it into microservices:
• property-service: manages property-related data
• auth-service: authentication via Keycloak
• geo-service: converts addresses into coordinates
• upload-service: handles image/file storage in PostgreSQL
• gateway-service: central API routing via Spring Cloud Gateway

⸻

⚙️ Key Technical Choices

UUIDs for IDs:
Avoided collisions and made frontend caching simpler.

Database Design:
Separate tables for property types (Apartment, House, etc.) and for listing types (Rent, Buy) for performance.

File Uploads in PostgreSQL:
No S3 — I stored images using bytea in PostgreSQL. It’s fast and GDPR-friendly for MVP stage.

Keycloak Auth:
It powers:
• Login/Signup
• RBAC (Admin, Agent, User)
• JWT-secured APIs

DevOps with ECS + Terraform:
Everything runs in Docker containers on ECS.
Infrastructure is built using Terraform (VPCs, services, secrets).

⸻

🖼️ Frontend Stack
• Next.js + TypeScript
• Tailwind CSS
• Geoapify for address autocomplete
• Access tokens from Keycloak for secure API use

⸻

💡 Lessons Learned
• Don’t overgeneralize — real estate data is domain-specific
• Start with a Gateway service — saves major refactoring later
• Separate out audit/analytics early
• Keycloak is great but painful to customize

⸻

🚀 What’s Next?
• 💳 Integrate Stripe for paid listings
• 🔔 Notify users of search matches
• 📊 Add analytics microservice
• 🗺️ Improve map-based UX

⸻

✌ Final Thoughts

If you’re considering building your own SaaS — go for it.
Start small, think in services, and build around real use cases.

I’m not just building a side project. I’m building a real app.
You can too.

⸻

Need Help?

Want to chat tech, design, or growth?
Drop a comment — let’s connect!