DEV Community: Kumar Nihal

What If Your AI Agent Had Hands? Building Causly Server with MCP

Kumar Nihal — Tue, 22 Sep 2026 11:47:11 +0000

What If Your AI Agent Had Hands?

AI agents are getting pretty good at writing code. But writing code is only one part of software development.

At some point, the agent needs to do something with that code.

It needs to inspect the repository.
Run a command.
Update a database.
Build a container.
Deploy an application.
Check an error.
Update documentation.
Send a message to the team.

And that's where things start getting messy.

The tools exist. The problem is that they're scattered across different environments.

That's the problem I'm trying to solve with Causly Server.

One MCP server, many capabilities

Causly Server is an open-source local MCP server designed to give MCP-compatible AI agents access to a unified set of software-development capabilities.

The idea looks roughly like this: Instead of configuring an agent around a collection of completely separate tool interfaces, Causly Server gives it a common MCP layer.

The agent can discover the capability it needs and use it when the task requires it.

And importantly, Causly Server isn't tied to a specific AI agent.

If the agent supports MCP, the idea is that you can use it with Causly Server.

Claude, Cursor, Codex, or another MCP-compatible agent.

Use whatever agent you want. Give it Causly.

The real problem is context switching

Imagine asking your agent: Fix this issue, update the database, deploy the application, and tell the team what changed.

That's not one tool call.

The task crosses several boundaries.

Code
 ↓
Git
 ↓
Database
 ↓
Build
 ↓
Infrastructure
 ↓
Deployment
 ↓
Monitoring
 ↓
Communication

A capable agent shouldn't have to stop simply because the next part of the task lives somewhere else.

That's the bigger idea behind Causly Server.

Not more intelligence. More reach.

Why MCP?

MCP gives agents a common protocol for discovering and interacting with external capabilities.

Causly Server uses that protocol as the interface between the agent and the tools around the development environment.

There can be a large number of available capabilities, but they don't all need to be pushed into the agent's context at once.

Causly Server uses lazy discovery/loading so the agent can work with the capabilities relevant to the current task.

That's important.

If an agent is fixing a file, it doesn't need to spend its context thinking about every infrastructure or communication tool available.

The goal is capability without unnecessary context.

What can it do?

The current OSS project covers capabilities across areas such as:

Files and project management
Git and GitHub
Supabase
PostgreSQL and SQL
Docker
Terraform
Slack
Notion
Gmail
Vercel
Security and credential handling
Workflow tooling
Project intelligence
CI/CD-related operations

The project currently has a broad toolset, but it's still growing.

There are more capabilities I want to add, including things around Linear, Jira, Kubernetes, and additional cloud infrastructure.

It's local. And that's important.

Causly Server OSS doesn't currently provide a separate Causly-managed execution environment.

It runs in the user's environment.

That means credentials and external service configuration remain the user's responsibility.

Today, the setup is also intentionally developer-oriented: you fork the repository, clone it, configure the environment, and connect the server to your MCP-compatible agent.

There isn't a polished one-command installer yet.

That's one of the things I want to improve.

Giving an agent power also means giving it boundaries

A system that can interact with your environment shouldn't blindly execute everything.

Causly Server can require confirmation for potentially destructive operations.

For example:

Agent:
I need to run this Terraform operation.

This may modify your infrastructure.
Continue?

Yes
No

The same idea applies to potentially destructive Docker or infrastructure operations.

For workflows where the user explicitly wants fewer interruptions, an always-allow option can also be configured.

The goal isn't to make the agent powerless. It's to make its actions visible and controllable.

And there are still limitations

Causly Server is open source and still under active development. It doesn't have its own isolated execution environment yet.

Setup is still manual.
Some cloud operations intentionally require the user to perform the final operation themselves.
Some workflow/CLI tools can consume more tokens because a task may involve multiple tools and repeated operations.

And there are still integrations missing.

That's okay.

I'd rather show exactly where the project is today than pretend it is something it isn't.

Why open source?

Because I don't think the question of how AI agents should interact with software environments has a single answer.

There are interesting problems around:

Tool discovery
Permissions
Credential handling
Local execution
Destructive operations
Context management
Agent workflows
Infrastructure access
Security boundaries

Causly Server is my attempt to explore those problems in the open.

And I'd like other developers building with AI agents to help shape it.

What if your agent had hands?

That's the question behind Causly Server.

AI agents already have brains.

They can reason.
They can plan.
They can write code.

But software work doesn't happen inside a text box.

It happens across files, repositories, databases, infrastructure, deployment systems, communication tools, and everything around them.

Causly Server is an attempt to connect those worlds through one MCP interface.

Use whatever agent you want. Give it Causly.

And let it move from writing code to actually working on the software around that code.

🔗 Full article: https://www.causly.in/lab/causly-server-what-if-your-ai-agent-had-hands

💻 GitHub: https://github.com/KNIHAL/causly-server

I Spent 4 Hours Debugging Google OAuth… Then I Deleted the Feature (A Lesson While Building My First SaaS)

Kumar Nihal — Thu, 19 Mar 2026 14:35:27 +0000

A few days ago I shared the architecture flow diagram of my SaaS project, LeadIt.

After that, I also shared a post explaining the core backend components I built — things like the company search API, the analysis engine, lead scoring logic, and the AI outreach generator.

Since then I’ve been slowly turning those pieces into an actual working product.

Most of the backend core is now working, and I’ve also been building the landing page that explains the product and its workflow.

But while trying to implement the next feature — email automation using Gmail OAuth — I ran into a problem that ended up teaching me one of the most important lessons about building MVPs.

The Plan: Let Users Send Emails From the Platform

Once the backend intelligence layer was working, the next step felt obvious.
Users should be able to send outreach emails directly from LeadIt.

The flow I imagined was simple.
A user connects their Gmail account → LeadIt generates an AI outreach message → the user can send the email directly from the platform.
To make that work, I needed Google OAuth with Gmail API access.

The expected flow looked something like this:

User logs in using Google OAuth
LeadIt asks for permission to access Gmail
Google returns an access token and refresh token
Those tokens get stored in my Supabase database
LeadIt uses the Gmail API to send outreach emails automatically

On paper, this looked straightforward.
But implementing it was a completely different experience.

Setting Up Google Cloud

I started by setting up everything inside Google Cloud Console (GCP).

The usual steps:

Created a Google Cloud project
Enabled the Gmail API
Configured the OAuth consent screen
Generated Client ID and Client Secret
Added redirect URIs

Something like this:
http://localhost:3000/api/auth/callback/google

Then I added Gmail permissions using scopes like:
https://www.googleapis.com/auth/gmail.send

At this point everything looked correct.
The configuration seemed fine.
So I moved forward with integrating authentication in the app.

Authentication Worked… But the Token Didn’t

Here’s the weird part.
The Google login itself worked perfectly.
Users could sign in successfully.

That means:

OAuth redirect worked
Client ID was valid
Consent screen worked
Authentication succeeded

But the Gmail provider token never got stored in my database.
And that token is the most important part.

Without it:

no Gmail API calls
no sending emails
no automation

So even though authentication worked, the feature itself was useless.

The 4-Hour Debugging Spiral

This is where things started getting frustrating. I spent around 3–4 hours debugging the issue. And I checked almost everything I could think of.

Database Layer
First I checked Supabase.
Things I verified:

database connection
user table structure
provider token fields
row level security policies

Everything looked correct.

Server-Side Logic

Then I checked the backend logic.

Things like:

OAuth callback handler
parsing provider tokens
inserting tokens into the database
session handling

Still nothing.

Client-Side Flow

Then I checked the frontend flow.

Things like:

authentication session
provider response
token availability

Again… nothing.

Google Cloud Configuration

At this point I went back to Google Cloud.

Checked again:

OAuth scopes
redirect URLs
Gmail API permissions
client ID configuration

Everything looked fine.
Yet somehow the provider token was never reaching my database.

The Realization

After spending hours debugging this, I finally asked myself a simple question.
Do I actually need this feature right now?
And the honest answer was: No

The real core of LeadIt is not Gmail automation.

The real core is:

discovering companies
analyzing their websites
detecting opportunity signals
generating AI outreach messages

Sending emails automatically is definitely useful.
But it is not required to validate the product idea.
And that’s when I made a decision.

The Founder Decision: Cut the Feature

Instead of wasting more time on OAuth complexity, I decided to remove the feature from the MVP.
Gmail automation will move to Version 2.
For the MVP, the product will focus only on the core features:

company search
website analysis
lead discovery
lead scoring
AI outreach message generation

Instead of automatic email sending, users can simply: copy the generated message and send it manually.

It’s simple.
But for an MVP, simple is actually good.

Simplifying Authentication

While thinking about this, I also made another decision.

Instead of implementing complex OAuth systems right now, I’ll use simple Next.js authentication for the MVP.

OAuth systems bring a lot of complexity:

client IDs
redirect flows
token storage
refresh tokens
permission scopes

All of that takes time to build and even more time to debug.
Right now my focus is simple.
Ship the product.

Landing Page Progress

Alongside the backend work, I’ve also been building the LeadIt landing page.
It’s almost complete now.
Soon I’ll share a preview of the landing page and I’d genuinely love feedback from other builders here.
Things like:

does the product idea make sense?
is the value proposition clear?
would you try a tool like this?

Getting early feedback is honestly one of the most useful things when building something from scratch.

What Today Actually Taught Me

At first, today felt like a wasted day.
I didn’t ship the feature I planned.
But in reality, I learned something much more important.
Startups don’t need perfect products.
They need working MVPs.
That means:

shipping fast
avoiding unnecessary complexity
cutting features when needed
Sometimes the smartest engineering decision isn’t fixing the problem.
Sometimes it’s removing the problem entirely.

Final Thought

Building your first SaaS is messy.
You’ll spend hours debugging things that might not even matter in the final product.
But every one of those moments teaches you something about building, prioritizing, and shipping faster.
LeadIt is still very early.
But every small step is slowly turning the idea into a real product.
And honestly, that’s the fun part of the journey.

If you're building something right now, I’m curious:
Have you ever spent hours debugging a feature… only to realize you didn’t actually need it?

From Architecture to Reality: Building My First SaaS (LeadIt) with AI Outreach and Company Analysis

Kumar Nihal — Sat, 14 Mar 2026 12:21:03 +0000

Two days ago I shared the architecture flow diagram of my SaaS project LeadIt.

Today I want to share what actually happened after that.

Over the last two days, I started turning that architecture into real working modules. Instead of just diagrams and ideas, LeadIt now has actual APIs, a company analysis engine, and an AI-powered outreach generator.

This post is basically a build log of what I implemented and what I learned while building my first SaaS product.

What is LeadIt?

LeadIt is a project I’m building to help with B2B lead discovery and AI-powered outreach.

The idea is simple:

Find companies
Analyze their websites
Detect opportunity signals
Generate personalized outreach emails

Instead of manually researching companies and writing cold emails, the system tries to automate most of that process.

1. Setting Up the Company Search API

The first thing I worked on was the database layer.

I connected my backend with Supabase and verified that I could fetch company records successfully.

Once the connection was stable, I built a Company Search API.

This API supports:

searching companies by company_name
filtering by country
filtering by category
pagination using page, limit, and offset

Pagination was important because once the database grows, returning thousands of records in a single request would slow everything down.

I also made the response lightweight by returning only the required fields instead of full database objects.

After testing the endpoint, it successfully fetched companies like:

Zapier
Freshworks
Postman

Seeing clean API responses was a small but satisfying milestone.

2. Building the Company Analyze Engine

Once companies could be fetched from the database, the next step was analyzing them.

For this, I built what I call the Company Analyze Engine.
The idea is to automatically scan a company website and detect useful signals.
To achieve this, I used Playwright for automated browsing.

The engine visits key pages of a company website:

homepage
careers page
API documentation
integrations page
product pages

To keep the scraper lightweight and fast, I blocked heavy resources like:

images
fonts
CSS

This significantly improves scraping speed.

During analysis, the engine looks for business signals, such as:

hiring activity
availability of APIs
integrations with other tools
automation-related keywords

These signals help determine whether the company might be a good B2B opportunity.

3. Building the Lead Scoring Engine

After detecting signals, I implemented a rule-based lead scoring system.
The goal here is to turn raw signals into a clear opportunity score.

For example:

Companies hiring engineers may be scaling fast
Companies offering APIs may be developer-focused
Companies mentioning automation might be good targets for outreach tools

The system calculates a lead opportunity score and also explains the reason behind the score.

The company endpoint now returns:

detected signals
opportunity score
reasoning behind the score

This module basically acts as the intelligence layer of LeadIt.

4. Building the AI Outreach Generator

Once the system identifies potential opportunities, the next step is outreach.

So I built the AI Outreach Generator.

This module generates personalized cold emails using:

company signals
company context
user skills

For the AI model, I integrated Groq LLM using the llama-3.1-8b-instant model.

To make the emails more effective, I designed three outreach styles:

Observation Style: Point out something interesting about the company.
Opportunity Style: Suggest a possible improvement or opportunity.
Curiosity Style: Spark curiosity to encourage a reply.

The AI response is then parsed into structured output:

email subject
email body

The endpoint now takes company signals and generates context-aware outreach emails automatically.

5. Production Considerations

Even though this is an early version, I tried to keep production stability in mind.

Some safeguards I added include:

input sanitization
prompt injection protection
token limits
timeout protection
rate limiting
concurrency limits

These help prevent abuse and keep the system stable.

6. Debugging Moment: Tailwind CSS Version Conflict

Not everything went smoothly.

While setting up Next.js 14, I kept getting repeated build errors related to Tailwind CSS.
After debugging configs and dependencies, I realized the issue:

I had installed Tailwind CSS v4, which is designed for Next.js 15.
But my project runs on Next.js 14, which caused PostCSS and CSS compilation errors.

The fix was simply downgrading to: Tailwind CSS v3

Once I did that, the build errors disappeared.
A small mistake, but a good reminder about framework compatibility.

Where LeadIt Stands Now

After the last two days of development, LeadIt can now:

search companies from a database
analyze company websites automatically
detect business signals
calculate lead opportunity scores
generate AI-powered outreach emails

This is starting to look like the foundation of an automated B2B lead generation platform.

Still early days, but it’s exciting to see the architecture slowly turn into a real product.

Final Thoughts

Building your first SaaS product is chaotic.

You spend hours debugging small things.
You question your architecture decisions.
You rewrite code multiple times.

But the moment your system actually starts working — APIs responding, AI generating emails, data flowing — it feels incredible.

LeadIt is still early, but the core engine is finally starting to work.

And that feels like real progress.

If you're also building a SaaS or experimenting with AI tools,
I'd love to hear what you're working on.

Building my first AI lead generation SaaS (LeadIt) — MVP architecture

Kumar Nihal — Thu, 12 Mar 2026 09:41:07 +0000

Hi everyone 👋

I'm currently building my first SaaS product called LeadIt.

The idea behind LeadIt is simple:

Quality over quantity in lead generation.

Instead of scraping thousands of random leads, the system tries to identify companies that actually show signals of being a good fit.

This is still an MVP, and I'm trying to keep the architecture simple while validating the idea.

Here is the architecture I designed for the MVP:

Tech Stack

Frontend

Next.js UI

Backend

Next.js server API

Authentication

Google OAuth 2.0

Lead Analysis Modules

Scraper using Playwright
Web intelligence using Tavily API
Signals detection (job listings, API docs, integration pages)
AI-generated outreach emails

AI Layer

Groq for LLM processing

Data Layer

Supabase database

Outreach

Gmail API for sending emails

Workflow

The flow of the system is roughly:

User searches for companies
Scraper collects company data
Signals detection analyzes companies
AI generates personalized outreach emails
Emails are sent and tracked using Gmail API
Data is stored in Supabase

Why I'm building this

I noticed that most lead generation tools focus on volume, not relevance.

The goal of LeadIt is to find high-quality opportunities instead of sending thousands of cold emails.

Feedback welcome 🙏

Since this is still an MVP, I’d love feedback from other builders:

Does this architecture make sense?
Am I overengineering anything?
What would you simplify?

I'm building this in public, so I'll keep sharing progress as I go.

Thanks!