Forem: Muhammed Safvan

How I Used Notion MCP to Screen 5,000+ Stocks and Write AI Research Reports

Muhammed Safvan — Thu, 19 Mar 2026 03:11:35 +0000

This is a submission for the Notion MCP Challenge

What I Built

StockPulse is an AI-powered Indian Stock Intelligence platform built entirely on Notion.

It solves the problem of scattered financial data by acting as a centralized, human-in-the-loop research hub. First, a Python data pipeline fetches daily price and delivery data from the NSE and BSE (Indian stock exchanges). It then runs 5,000+ stocks through a rigorous, battle-tested 12-condition fundamental screener.

The magic happens when the data enters Notion. By using the Model Context Protocol (MCP), StockPulse allows AI assistants (like Claude) to seamlessly read the screened data, identify anomalies, analyze fundamentals, and write comprehensive research reports directly back into Notion databases.

Video Demo

Notion page: https://www.notion.so/StockPulse-Home-Page-3221879420d180c785d1eb25e8956ce4

Show us the code

Safvan-tsy / stockpulse

Using Notion MCP to Screen 5,000+ Stocks and Write AI Research Reports

StockPulse India 📈

AI-Powered Indian Stock Intelligence on Notion — Built for the Notion MCP Challenge.

StockPulse takes daily price and delivery data from NSE & BSE, screens 5000+ stocks through 12 battle-tested fundamental conditions, and uses a dual-MCP architecture — the official Notion MCP for workspace I/O plus a custom StockPulse MCP for domain computation — to generate research reports, detect anomalies, and maintain a smart watchlist — all centralized in Notion.

What It Does

Data Pipeline — Downloads BhavCopy + delivery data from NSE/BSE, or reads from pre-built Excel workbooks
12-Condition Screener — Filters stocks for: profitability (PE, EPS), growth (sales, profit YoY), governance (promoter pledging), financial health (debt/equity, current ratio, ROCE)
Notion as Single Source of Truth — 5 linked databases: Stocks Master, Daily Prices, Screener Results, Watchlist, AI Reports
Dual-MCP AI Intelligence — The official Notion MCP (https://mcp.notion.com/mcp) handles all Notion reads/writes…

View on GitHub

How I Used Notion MCP

Notion MCP is the core I/O layer of this project. The AI agent uses it for every interaction with the Notion workspace:

Reading data via Notion MCP:

notion-search and notion-fetch to find and retrieve stock pages from the Stocks Master database
query-a-database-view to fetch screened stocks, price history, and watchlist entries with filters

Writing results via Notion MCP:

create-a-page to publish AI-generated research reports into the AI Reports database
create-a-page to add stocks to the Watchlist database with notes and status
update-a-page to set AI Ratings (Strong Buy / Buy / Hold / Avoid) on stock pages

The custom StockPulse MCP server complements Notion MCP as a stateless computation engine — it contains zero Notion SDK calls. It receives stock data (fetched by the AI via Notion MCP) as JSON input and returns analysis results:

screen_stock: Applies the 12 screening conditions and computes a weighted quality score (0–100)
detect_anomalies: Identifies stocks with Piotroski ≥7, promoter holding changes, and high delivery %
compare_sector: Ranks a stock against sector peers on ROCE, PE, debt, and other metrics
generate_report_content: Formats analysis into structured markdown for the AI to save via Notion MCP

The workflow loop:

AI fetches data from Notion databases → Notion MCP
AI passes data to screening/analysis → StockPulse MCP
AI writes reports, ratings, watchlist entries back → Notion MCP
Human reviews in Notion UI, adds notes → AI reads them next cycle → Notion MCP

This creates a true human-in-the-loop system where the Python pipeline crunches the hard numbers, Notion MCP provides seamless workspace access, StockPulse MCP adds domain intelligence, and Notion organizes it all beautifully for the investor to review and act on.

What If Your A11y Linter Could Actually Fix the Bugs It Found?

Muhammed Safvan — Sun, 15 Feb 2026 15:54:08 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

What if your linter could actually fix the problems it found?

That's a11y-pilot - a CLI that scans your frontend code for accessibility violations, then spawns GitHub Copilot CLI to fix each one. Not "here's a suggestion". it literally invokes copilot --prompt with a crafted fix instruction and lets the AI refactor your code in place.

I pointed it at a file with 12 accessibility issues. Ran a11y-pilot fix. Every single issue was resolved — <div onClick> became <button>, empty <img> got meaningful alt text inferred from the filename, unlabeled inputs got proper aria-label. Re-scanning the file: 0 issues. No manual edits.

Demo

npm: https://www.npmjs.com/package/a11y-pilot
GitHub: https://github.com/Safvan-tsy/a11y-pilot

How it works

Scan → Detect → Prompt Engineer → Copilot CLI Fixes → Done

Scan - Point it at any directory or file. It walks your project and parses JSX, TSX, HTML, Vue, Svelte, and Astro files using Babel AST (for JSX/TSX) and htmlparser2 (for HTML-like templates).
Detect - 15 accessibility rules run against every parsed element, checking for WCAG violations across 5 categories.
Auto-fix - For each issue, a11y-pilot builds a precise, context-rich prompt and spawns copilot --prompt <text> --allow-all-tools. Copilot CLI reads the file, understands the surrounding code, and applies the minimum diff needed. No blind find-and-replace actual AI-driven refactoring.

The Copilot CLI bridge — the core of the project

This is not just a scanner that suggests fixes. The entire point is that Copilot CLI is the execution engine. When you run a11y-pilot fix ./src, here's what happens under the hood:

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   a11y-pilot    │────▶│  Issue detected   │────▶│  Build prompt   │
│   scanner       │     │  (rule engine)    │     │  (context-rich) │
└─────────────────┘     └──────────────────┘     └────────┬────────┘
                                                          │
                                                          ▼
┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   File fixed!   │◀────│  Copilot applies  │◀────│  copilot CLI    │
│   ✔ Report      │     │  the fix          │     │  invoked        │
└─────────────────┘     └──────────────────┘     └─────────────────┘

Each rule carries a copilotPrompt field — a carefully crafted instruction that tells Copilot CLI exactly what's wrong and how to fix it. For example, the no-div-button rule generates prompts like:

"In file src/Hero.tsx at line 20, fix this accessibility issue: <div> has a click handler but is missing role and tabIndex. Replace this <div> element with a native <button> element. Move the onClick handler to the button. Remove any cursor: pointer styling (buttons have it by default). Only modify the minimum code necessary."

Copilot CLI then reads the full file context, understands the surrounding JSX structure, and makes intelligent fixes — not just string replacements, but real refactoring. It adds meaningful alt text based on image filenames, converts <div onClick> to proper <button> elements, wraps navigation links in <nav> with appropriate aria-label, and more.

Category Dashboard

After scanning, a11y-pilot renders a visual breakdown dashboard right in the terminal:

  ✖ Found 46 issues (35 errors, 11 warnings) in 4 files (5 scanned)

  📊 Issue Breakdown
  ──────────────────────────────────────────────────
   ♿ Accessibility       ████████░░░░░░░░░░░░   19 (41%)  19E
   🏗️ Semantic HTML      █████░░░░░░░░░░░░░░░   11 (24%)  4E 7W
   ⌨️ Keyboard            ███░░░░░░░░░░░░░░░░░    7 (15%)  5E 2W
   🏷️ ARIA               ██░░░░░░░░░░░░░░░░░░    5 (11%)  5E
   👆 Interaction         ██░░░░░░░░░░░░░░░░░░    4 (9%)   2E 2W
  ──────────────────────────────────────────────────
  14 rules triggered: img-alt, form-label, no-div-button, ...

This gives you an instant snapshot of where your accessibility debt lives — is it ARIA misuse? Keyboard traps? Missing semantics? You know exactly where to focus.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI was central to this project in two distinct ways:

1. Copilot CLI as the product's engine

The marquee feature of a11y-pilot is --auto-fix. When triggered, it spawns copilot --prompt <text> --allow-all-tools for each detected issue. I discovered the --prompt flag enables non-interactive mode, and --allow-all-tools auto-approves tool use — this combination is what makes programmatic Copilot CLI invocation possible.

The quality of fixes was surprisingly excellent. Given a file with <div onClick={() => alert('clicked')}>, Copilot CLI didn't just slap a role="button" on it — it actually converted the entire element to a <button>, moved the handler, and preserved the className. For empty <a href="/profile"></a>, it added aria-label="Profile" — inferring the label from the URL. These aren't template fixes; they're context-aware refactoring.

The key insight was prompt engineering per rule. Each of the 15 rules carries a copilotPrompt field — a precisely crafted instruction that gives Copilot CLI enough context to understand the problem and the expected fix pattern, without being so prescriptive that it loses the ability to adapt to surrounding code. This prompt design is what turns a11y-pilot from "accessibility linter" into "accessibility linter + AI-powered fixer."

2. Copilot CLI as a development tool

Beyond the product itself, Copilot CLI was my primary development companion throughout the build:

Parser logic — Writing Babel AST traversal for JSX elements with normalized attribute handling required getting a lot of edge cases right (spread props, expression containers, member expressions). Copilot CLI helped iterate on the visitor pattern and handle the @babel/traverse ESM default export quirk (_traverse.default || _traverse).
Rule implementation — For each of the 15 rules, I used Copilot CLI to reference WCAG criteria and ensure the check() functions handle edge cases correctly — like not flagging <a> tags without href in the aria-hidden-focus rule, or skipping input[type="hidden"] in form-label checks.
Debugging — When the copilot-bridge initially used shell: true and hit the Node.js DEP0190 deprecation warning, Copilot CLI helped me switch to direct binary resolution with execFileSync('which', ['copilot']) and proper spawn() without shell.

What impressed me

The thing that stood out most was Copilot CLI's ability to handle file-level context. When I pointed it at a file with 12 accessibility issues and said "fix the <div onClick> on line 20," it didn't break the other 11 problematic lines. It made surgical, minimal edits. That's the property that made the auto-fix feature viable — I could confidently fix issues one-by-one or in batches without worrying about cascading breakage.

Project links

npm: npm install -g a11y-pilot
GitHub: https://github.com/Safvan-tsy/a11y-pilot
Try it now: npx a11y-pilot scan ./src

🚀 Why Everyone Uses localhost:3000 - The History of Dev Ports (3000, 8000, 8080, 5173)

Muhammed Safvan — Mon, 20 Oct 2025 10:25:36 +0000

TL;DR:

Ever wondered why your dev servers always run on localhost:3000 or localhost:5173?
These ports have fascinating histories that trace back through decades of developer habits, from Java and Python to Node.js and Vite. Let’s unpack the stories behind them.

💡 What Is a Port, Anyway?

Think of your computer like an office building, every port is a numbered door that leads to a specific “room” (or service).

When you visit localhost:3000, you’re basically knocking on door #3000 and asking,

“Hey, can you show me my app?”

There are 65,535 possible doors (ports). Here’s how they’re grouped:

Range	Purpose	Example
0–1023	System / Reserved	HTTP(80),HTTPS(443),SSH(22)
1024–49151	User / Registered	3000, 8000, 8080
49152–65535	Dynamic / Private	Temporary OS connections

So yes, port 3000 is just one of tens of thousands of valid options.

⚙️ Port 3000 - The Node.js Default

When Node.js and Express.js exploded in the early 2010s, the official docs used this snippet:

app.listen(3000, () => console.log('Server running on port 3000'));

That one line shaped an entire generation of developers.
Tutorials, bootcamps, and boilerplates copied it word-for-word.

Then React came along… and reused it.
Next.js came along… and reused it again.

💬 Fun fact: There’s no special reason for port 3000 - it was just arbitrary and unclaimed.
But familiarity is powerful. Now, 3000 is the unofficial “Hello World” port of web dev.

Update (Oct 23, 2025): A few readers pointed out that the use of port 3000 actually originated from Ruby on Rails, and frameworks like Express.js later adopted the same convention. Thanks for the comments, great catch!

🐍 Port 8000 - The Python Classic

Long before Node.js, Python devs were already spinning up local servers with:

python3 -m http.server

And what port did that use by default?
👉 8000

No deep reasoning, just a round, safe number above 1024 that didn’t require root privileges.
Frameworks like Django adopted it too:

Starting development server at http://127.0.0.1:8000/

So for Python developers, 8000 became the go-to number for “I’m just testing something locally.”

☕ Port 8080 - Java’s Legendary Port

Back in the 1990s, running a web server on port 80 (the official HTTP port) required root access.
So Java developers working on Apache Tomcat and Jetty picked something clever:

80 => 8080 (double eighty)

It looked similar, worked without admin rights, and became the perfect HTTP alternative.

To this day, Java servers (like Spring Boot) still default to 8080. It’s now a symbol of “serious backend work.”

⚡ Port 5173 - The Vite Generation

Fast forward to the 2020s.
Evan You (creator of Vue.js) introduced Vite, a blazing-fast build tool for frontend frameworks.

They needed a default port and instead of picking a boring number, then added this Easter egg:

51 = “VI” (Roman number 'V' => 5)
73 = “TE”
5173 => “VITE”

Run npm run dev in a Vite project, and you’ll see:

VITE v5.0 ready in 220 ms
Local: http://localhost:5173/

It’s geeky, clever, and memorable and that’s why you’ll see 5173 everywhere now.

🧠 Are You Using Localhost “Wrong”?

Not wrong, but maybe limiting yourself.
Many devs stick to 3000 and panic when they get:

Error: Port 3000 already in use

In reality, you can safely use any port up to 49151.
Try something fun:

npm run dev -- --port=42069

or in Vite:

vite --port=13337

You’ll avoid conflicts and earn bonus nerd points.

🕰️ A Fun Bit of Dev History

Each port tells a story:

8080 - Java’s clever HTTP workaround
8000 - Python’s practical simplicity
3000 - Node’s accidental tradition
5173 - Vite’s self-referential Easter egg

From the 1990s to today, these numbers have quietly shaped how millions of developers work every day.

✨ The Takeaway

Next time you spin up a dev server and see:

Local: http://localhost:3000/

Remember you’re tapping into a piece of developer history that spans decades of innovation.

So the next time port 3000 is busy, don’t just kill the process.
Pick another number. Maybe even make it your signature port. 😉

You can safely use any port between 1024 and 49151 - 3000 isn’t the only game in town!

Node.js Performance Optimization : Cluster Module

Muhammed Safvan — Sun, 11 May 2025 09:28:01 +0000

In 2025, we're still seeing a curious phenomenon in production: powerful multi-core servers running Node.js applications on just a single CPU core. This isn't because Node.js can't utilize multiple cores it's because many developers have forgotten (or never learned) about Node's built-in clustering capabilities.

The Single-Core Problem

Node.js uses a single-threaded event loop model by default. This is excellent for handling asynchronous operations efficiently but means your application can only utilize one CPU core no matter how many cores your server has. In an era of 16, 32, or even 64-core machines, this represents a significant waste of computing resources.

The Overlooked Solution: Node's Cluster Module

While developers often reach for external solutions like Docker, Kubernetes, or PM2, many overlook that Node.js ships with a native clustering solution: the cluster module.

This powerful module allows you to create worker processes that share the same server port, effectively distributing the workload across all available CPU cores. The primary (master) process is responsible for spawning workers and managing their lifecycle, while the workers handle the actual request processing.

Implementation in Under 20 Lines of Code

Here's how you can implement clustering in your Node.js application with minimal code:

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers, one per CPU
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died`);
    // Replace the dead worker
    cluster.fork();
  });
} else {
  // Workers share the TCP connection
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('Hello from Node.js cluster\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

This simple implementation:

Detects the number of CPU cores available
Spawns one worker process per core
Automatically restarts workers if they die
Allows all workers to share port 8000

Cluster vs. Worker Threads vs. External Tools

It's important to understand when to use each performance optimization strategy:

Cluster Module

Best for: I/O-bound workloads (most web applications)
How it works: Spawns multiple processes that share server ports
Advantages: Zero dependencies, simple implementation, full isolation between workers
Disadvantages: Higher memory usage than worker threads

Worker Threads

Best for: CPU-intensive tasks (calculations, image processing)
How it works: Creates threads within the same process
Advantages: Lighter weight than full processes, shared memory
Disadvantages: Not ideal for I/O-bound applications

PM2

What it is: A process manager that wraps Node's cluster module with additional features
Advantages: Adds monitoring, logs, and easier management
Disadvantages: External dependency, additional complexity

Docker & Kubernetes

What they are: Container and orchestration platforms
Advantages: Full infrastructure management, auto-scaling, self-healing
Disadvantages: Significant complexity, overhead, learning curve

Performance Impact

Let's look at some benchmark data comparing a single-process Node.js server versus a clustered implementation on a 16-core machine:

Configuration	Requests/sec	Latency (avg)	CPU Usage
Single Process	8,500	120ms	100% (1 core)
Clustered (16 workers)	112,000	35ms	95% (all cores)

These numbers represent a typical I/O-bound REST API with database connections and moderate business logic.

The Cloud Context

While some argue that Kubernetes or serverless architectures eliminate the need for application-level clustering, consider these points:

Cost efficiency: Running efficiently on fewer, larger instances often costs less than many small containers
Reduced complexity: Native clustering requires no orchestration tooling
Hybrid approach: You can use both clustering within containers AND container orchestration for different scaling needs

Remember that in cloud environments, efficient resource utilization directly impacts your bottom line.

Implementation Tips

When implementing clustering in production:

Connection pooling: Ensure database connections are properly pooled across workers
Sticky sessions: If using session data, implement sticky sessions or session stores
Graceful shutdown: Handle SIGTERM signals properly to avoid dropped connections
Monitoring: Track worker health and restart failed workers
Memory management: Watch for memory leaks that could affect all workers

Conclusion

Node's cluster module represents one of the most straightforward ways to dramatically improve application performance and resource utilization. Before reaching for complex orchestration tools, consider whether this simple, built-in solution might meet your needs.

The next time you deploy a Node.js application, ask yourself: "Am I leaving performance on the table by running single-threaded?" Utilizing all available CPU cores isn't just about raw performance it is about responsible engineering and resource efficiency.

True expertise means understanding your runtime environment deeply before adding layers of abstraction. Sometimes, the most elegant solution is already built into the platform you're using.

Are you still running single-threaded Node applications? It might be time to reconsider your approach.

Accidentally Committed Secrets? A Simple Git Fix Is Not Enough!

Muhammed Safvan — Sun, 23 Mar 2025 02:36:51 +0000

It happens to the best of us. A moment of distraction, and suddenly we've committed a .env file, an API key, or another secrets file to our Git repository. If you think simply removing the file and committing again will fix the issue, think again. The file will still exist in your Git commit history, posing a security risk.

In this article, we’ll explore how to effectively remove secrets from Git history and mitigate potential security risks.

The Problem

When we commit a file to a Git repository and then remove it in a subsequent commit, the file isn't actually deleted from the repository's history. Git is designed to maintain a complete historical record, which means anyone with access to our repository can:

Browse through previous commits
View the contents of those commits, including our secrets
Extract sensitive information with simple Git commands

# For example, someone could do this to see our secrets:
git checkout <commit-hash-with-secrets>
cat path/to/secrets/file

The Solution

Scenario 1: Haven't Pushed to Remote Yet

If the commit with secrets is still only in our local repository. This is the easiest scenario to fix. :

Use git reset to undo the commit
Remove the sensitive data
Commit again with the sanitized files

# Undo the last commit, but keep the changes in our working directory 
git reset --soft HEAD~1 

# Alternatively, if we want to discard the changes completely 
git reset --hard HEAD~1

Scenario 2: Already Pushed to Remote

To truly remove sensitive information, we need to rewrite our Git history to completely eliminate the file from all commits. Here's how to do it effectively:

Step 1: Identify the Secret Files
First, clearly identify which files contain sensitive information that needs to be removed.

Step 2: Remove the Files from Git History

1) Using git filter-branch

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch PATH_TO_SECRET_FILE" --prune-empty --tag-name-filter cat ----all

Replace PATH_TO_SECRET_FILE with the path to file containing secrets.

For replacing specific strings (like API keys) while keeping the file:

git filter-branch --tree-filter "find . -type f -name '*.config' -exec sed -i 's/YOUR_API_KEY/PLACEHOLDER_KEY/g' {} \;" HEAD

2) Using filter-repo

git-filter-repo isn't built-in to git itself
First, install git-filter-repo:

# For Python users
pip install git-filter-repo

# For macOS
brew install git-filter-repo

Then run:

git filter-repo --path path/to/secrets/file --invert-paths

for more info regarding git-filter-repo refer this

Step 3: Push those Changes
After cleaning history, we need to force push the changes:

git push origin --force --all

CAUTION: Force Pushing Is Irreversible ⚠️

Additional Recommendations

Revoke any exposed API keys or tokens
Add sensitive files to .gitignore: Ensure secret files are never tracked.
Use Environment Variables: Store secrets in environment variables instead of committing them.
Use Git Hooks: Automate pre-commit hooks to prevent secret files from being added.
Use GitHub’s Secret Scanning If you're using Github or use Secret push protection for Gitlab.

Note: Remember that if your secret was exposed for any period of time, even briefly, you should consider it compromised and rotate it immediately.