This is a submission for the Notion MCP Challenge

The Problem: The Notion Graveyard 🪦

We all love Notion. But let’s be honest: over time, every workspace falls victim to Workspace Decay. Quick ideas dumped into the “Inbox” stay there forever. Projects get abandoned. Duplicate pages multiply. Before you know it, your perfectly structured workspace becomes a messy graveyard of information where it’s impossible to separate the signal from the noise.

To fix this, we usually dedicate hours of manual “cleanup time.” But what if your workspace could clean, organize, and triage itself?

What I Built 🚀

I built NexusTriage: a custom Model Context Protocol (MCP) server that transforms Notion from a passive data repository into an active, self-healing system managed by AI.

NexusTriage acts as a proactive “Human-in-the-Loop” workspace manager. Built from the ground up using TypeScript and the official MCP SDK, it doesn’t just read and write pages. It orchestrates the entire workspace by:

1. Autonomously Triaging Inbox Tasks: Reading raw thoughts and routing them to the correct active projects.
2. Generating Executive Summaries: Scraping project progress and injecting visual AI summaries at the very top of project pages.
3. Preventing Workspace Decay: Identifying duplicates, empty pages, and stale tasks, and proposing soft-deletion cleanups.
4. Providing Visual Cues: Dynamically changing page icons (🚨, 🟢, 🛑) and covers based on real-time project health.

Video Demo 🎥

💻

I’ve open-sourced the entire MCP server. It’s built cleanly with a modular tool architecture, meaning anyone can add new capabilities in minutes.

How I Used Notion MCP (The Deep Dive) 🛠️

To build a system capable of semantic reasoning, my MCP server does far more than simple CRUD (Create, Read, Update, Delete) operations. I utilized the full potential of the Model Context Protocol paired with the bleeding-edge Notion API (Version: 2026-03-11).

Here is how the magic happens under the hood.

1. The Full MCP Triad: Tools, Prompts, and Resources

Most MCP implementations stop at simply providing “Tools”. NexusTriage implements the entire triad to give the AI context, capability, and autonomy.

14 Context Tools (Readers & Mutators): I built 14 incredibly specific tools. For example, get_database_schemaallows the AI to dynamically reverse-engineer any unknown database’s structure (properties, types, select options) without hardcoded mappings. link_task_to_projecthandles complex Notion Relations. get_page_commentsallows the AI to read human replies inside Notion, maintaining contextual chat history.

3 Semantic Orchestrations (Prompts): Instead of forcing the user to type complex instructions, I built MCP Prompts (triage_inbox, weekly_report, cleanup_workspace). These act as pre-defined logical workflows. By invoking the weekly_report prompt, the AI is automatically instructed on exactly how to fetch active projects, analyze blockers, and where to put the results.

Global Guidelines (Resources): I exposed a static workspace_guidelinesURI using MCP Resources. This acts as the “Rules of Engagement” for the AI—teaching it ground rules like “never permanently delete a page, use in_trash: true”, and “always leave an audit-trail comment when moving a task.”

2. Utilizing Unreleased & Brand New Notion Capabilities

To make NexusTriage feel like native magic, I had to use features that standard integrations don’t touch:

✨ The position: start Callout Injector
When the AI generates a weekly status report, nobody wants it buried at the bottom of a 50-block project brief. Using the newly introduced position: { type: "start" } feature in the Notion API, the inject_executive_summarytool forces the AI’s callout block to appear at the absolute top of the page. The moment a team member opens the project, they see the AI’s health summary instantly.

🎨 The update_page_style Tool
AI shouldn’t just write text; it should manipulate UI. This tool allows the AI to dynamically change page emojis and covers based on its findings. If the AI detects a project is blocked, it changes the project icon to 🚨. If a task is successfully triaged, it gets a ✨.

🗣️ True Human-in-the-Loop Dialogues
Triage isn’t always black and white. If the AI finds an ambiguous task, it uses the add_commenttool to ping the human: “I can’t tell if this is marketing or dev. Leaving it here for review.” The user can literally reply to that comment inside Notion, and the next time the AI scans, it will use the get_page_commentstool to read the human’s instruction and execute it.

Conclusion

NexusTriage proves that with MCP, AI doesn’t just need to “read and write” your notes as a passive chatbot. It can be an active, localized agent that manages, triages, and curates your organization’s workflow while you sleep.

A sandwich attack is a sophisticated form of Maximal Extractable Value (MEV) exploitation. A predatory bot identifies your pending swap, wraps your transaction between its own buy and sell orders, and siphons off profit from the artificial price volatility it creates.

While common on Ethereum, this phenomenon is rampant across all AMM-based ecosystems, including Solana, BSC, Base, and Monad. For most retail traders, these attacks are the primary cause of “invisible losses” — slippage that feels like market volatility but is actually a calculated extraction.

The Illusion of Chronological Processing

To grasp how a sandwich attack is even possible, we must debunk the myth that blockchains process transactions in the exact order they are received.

Blockchains operate in batches called blocks. Instead of executing your swap the microsecond you click the button, the network collects all incoming requests within a specific time window. The order of execution within that block is determined by validators — often influenced by who pays the highest priority fee.

In 2026, block times vary significantly across chains. Solana leads at roughly 0.4 seconds, Arbitrum pushes 0.25 seconds, and major Layer 2s like Base, Optimism, and Polygon operate on 2-second intervals. BNB Chain runs at 3 seconds, and Ethereum remains the slowest at 12 seconds.

Regardless of speed, the vulnerability is the same: submission time does not equal execution order. A transaction submitted at 12:00:01 PM might end up as the 5th trade in a block, while a transaction submitted at 12:00:10 PM — carrying a massive priority fee — lands in the 1st slot. MEV bots exploit this mechanic to position themselves perfectly around your trade.

The Anatomy of a Sandwich: Three Steps

A sandwich attack exploits the price impact of your trade. Every time you buy a token, you push its price up slightly. The bot simply ensures it profits from that move.

1. Detection
The bot monitors the public transaction pipeline — the mempool on Ethereum, or the forwarding layer on Solana. It spots your pending buy order and calculates exactly how much your trade will move the price.

2. Front-Run
The bot submits a buy order for the same token with a much higher fee, forcing the validator to place the bot’s trade immediately before yours. The bot buys at the current market price, which raises the price for you.

3. Victim Execution + Back-Run
Your trade executes at the inflated price. You receive fewer tokens than expected. Within the same block, the bot sells its position into your buying pressure and pockets the difference as pure profit.

A real-world example: a bot buys $616 worth of a token, the victim buys a small amount at a marked-up price, and the bot sells for $617.84. Less than a second, nearly $2 extracted from a single small trade. Scale this across thousands of trades per hour and the MEV tax becomes a multi-million dollar industry.

When Does Your Trade Become a Target?

MEV bots are profit-maximizing algorithms. They target specific conditions:

• Low liquidity pools — A $100 trade moving the price by 1–2% is a goldmine for bots.
• Excessive slippage settings — Setting 10% slippage essentially gives bots permission to steal up to 10% of your trade’s value.
• Large orders — The bigger your swap relative to pool depth, the more predictable the price movement and the more likely you are to be sandwiched.

How to Protect Your Capital

1. Use Private Transaction Routing

The most effective defense is staying invisible. If the bot can’t see your transaction, it can’t sandwich it.

On Solana: Route all trades through Jito Bundles. These bypass the public pipeline and go directly to the Jito Block Engine. If you use a trading bot or DEX that asks for a “Jito Tip,” you are already using this protection.

On Ethereum/EVM: Use a private RPC like Flashbots Protect or MEV Blocker. These services keep your transaction in a private queue until it is safely included in a block.

2. Aggressive Slippage Management

Don’t use auto-slippage on volatile tokens. Manually set your slippage to the lowest amount that allows the trade to succeed — usually 0.5% to 1.5%. This leaves almost zero profit margin for a bot after paying their own transaction fees.

3. Order Splitting

Don’t swap $10,000 in one transaction. Break it into five $2,000 swaps. Smaller trades have less price impact, often making them not worth the gas cost for an MEV bot to attack.

4. Verify Your History

Use transparency tools like sandwiched.me to scan your wallet’s history. Frequent “Sandwiched” flags indicate your current RPC or DEX settings are leaking value to bots.

Sandwich Attack vs. Normal Market Volatility

It is important to distinguish a sandwich attack from a regular price drop.

If the price of your token goes down 10% over an hour, that’s the market. However, if the price spikes a split second before you buy and crashes a split second after — all within the same block — you have been sandwiched.

By using MEV-protected routing, tightening your slippage, and avoiding low-liquidity traps, you can ensure your capital stays in your wallet rather than feeding the bots.

I spent this week building a YouTube pipeline UI — upload queue, analytics dashboard, search with metadata editing — inside a marketing platform that already has 5,000+ tests. Every component was built with strict TDD discipline. None of the component tests render a single React element.

That sounds wrong. Here is why it works, what breaks, and what it teaches about testing strategy when you are building at speed with AI agents.

The Constraint

The platform runs Vitest in a Node environment. No jsdom. No React Testing Library. No render(). The AI agent building these components cannot mount them, click buttons, or assert on DOM output.

The obvious response: add jsdom. Configure a browser environment. Write proper component tests.

We did not do that. Here is why.

The platform has 302 test files and 5,070 tests. They all run in Node. Adding a browser environment would mean either migrating the entire suite or maintaining two test configurations. Both options cost more than the problem they solve.

So instead, we test component structure by reading the source file as a string.

const content = fs.readFileSync('YouTubeDashboard.tsx', 'utf-8');

// Does the component export exist?
expect(content).toMatch(/exports+(const|function)s+YouTubeAnalyticsPanel/);

// Does it fetch from the right endpoint?
expect(content).toMatch(//api/youtube/analytics/);

// Does it have the date range picker?
expect(content).toMatch(/7d|7s*days/i);
expect(content).toMatch(/30d|30s*days/i);
expect(content).toMatch(/90d|90s*days/i);

This is not the test you would write in a tutorial. But it catches real failures: missing exports, wrong API endpoints, forgotten UI elements, stale stub text that should have been replaced.

What Breaks

Regex-based component tests are fragile in specific ways that teach you something about testing philosophy.

Character count assumptions fail. Early in the sprint, a test checked that two components appeared within 1,000 characters of each other in the file. The implementation was longer than expected. The test failed even though the code was correct. The fix: match the relationship, not the distance. expect(content).toMatch(/tab.*trust|trust.*TrustScoreDashboard/s) — this verifies the tab system references the component without assuming how many lines of code separate them.

Negative assertions are surprisingly powerful. The most useful test in the suite was this:

expect(content).not.toMatch(/coming in OAS-130-T2/);

Each YouTube tab started as a stub saying “coming in OAS-130-T2.” When the component was implemented, this test confirmed the stub was actually replaced. Simple. Catches a real class of bug — implementing the component but forgetting to wire it into the tab container.

Service tests carry the weight. The string-matching tests catch structural issues. But the real confidence comes from testing the backing services with actual SQLite databases, real data round-trips, and proper Result type assertions. The component tests tell you the UI references the right things. The service tests tell you those things work.

The Result Pattern That Eliminates Try/Catch

Every service in the platform returns Result<T, string> — never throws. This is not original. Rust, Go, and functional TypeScript libraries have done this for years. But it changes how you write tests in a way that compounds.

const result = analytics.storeVideoMetrics(metrics);
expect(isOk(result)).toBe(true);
if (isOk(result)) {
  expect(result.data.views).toBe(15420);
}

No try/catch in tests. No .rejects.toThrow(). The error path is just another return value you can assert on:

const result = analytics.getVideoMetrics('nonexistent', 'ch-001');
expect(isOk(result)).toBe(false);

When every method returns a Result, you can write 8 service tests that each exercise a different code path without a single exception handler. The tests read like a specification document.

The API Signature Change That Broke 4 Tests

Here is the most instructive failure of the week.

The YouTube analytics service had a scheduleCollection method with positional arguments:

scheduleCollection(videoId: string, channelId: string, options?: { intervalHours?: number })

A new ticket required an object-form signature:

scheduleCollection(params: { video_id: string; channel_id: string; interval_hours?: number })

The new tests passed. The full suite ran. Four tests in the original test file failed with RangeError: Too few parameter values.

This is the kind of regression that matters. Not because it is hard to fix — updating five call sites took two minutes. But because it demonstrates why you run the full suite, not just the file you changed. The AI agent that built the new feature did not know about the old tests. The test suite knew.

What This Means for Multi-Agent Development

This platform is approaching the point where two AI agents will work the same sprint simultaneously — different stories, different files, same codebase. The test patterns described above are not incidental. They are infrastructure for that future.

When Agent A changes a service signature and Agent B depends on that service, the full test suite is the only thing that catches the collision. Not code review. Not the agents coordinating. The tests.

The string-matching component tests serve a similar purpose. When one agent adds a tab to App.tsx and another agent adds a component that should appear in that tab, the test that says expect(appContent).toMatch(/YouTubeDashboard/) is a contract between them. Neither agent needs to know about the other.

This is not a theoretical concern. It happened this week. The signature change broke tests written by a previous session. The fix was trivial but the detection was essential.

The Honest Assessment

These are not the tests I would write if I had unlimited time. String-matching React components is a compromise. It catches maybe 60% of the bugs that proper component rendering would catch. It misses state management issues, event handler wiring, conditional rendering logic.

But it catches 60% in 30 seconds of test execution time, with zero additional dependencies, in a suite that already runs 5,000 tests in 30 seconds total. That tradeoff is worth understanding, even if it is not the tradeoff you would make.

The real lesson is simpler: test what you can with what you have. Do not let the perfect test strategy prevent you from catching real bugs today.

Building the ORCHESTRATE Marketing Platform — a system where AI agents plan, build, test, and deploy content across LinkedIn, YouTube, Dev.to, and Reddit with TDD discipline and memory that persists between sessions. The platform runs 5,070 tests across 302 files. All of them pass.

Michael Polzin is the author of The ORCHESTRATE Method — a framework for professional AI outputs.

Value Types vs Reference Types, Struct vs Class, and Boxing & Unboxing

These three topics are deeply connected.

You cannot fully understand struct vs class without understanding the stack and heap.

You cannot fully understand boxing and unboxing without understanding value and reference types.

This guide covers all three together — the way they should be taught.

How .NET Manages Memory

Before anything else, you need to understand two memory regions.

The Stack

• Fast allocation and deallocation
• LIFO (Last In, First Out) structure
• Stores value types and method call frames
• Memory is automatically reclaimed when the method exits
• Limited in size

The Heap

• Slower allocation
• Stores reference types (objects)
• Managed by the Garbage Collector (GC)
• Much larger than the stack
• Memory is reclaimed by the GC, not deterministically

This distinction is the foundation of everything that follows.

Value Types

A value type holds its data directly in memory.

When you assign a value type to another variable, a copy is made.

int a = 10;
int b = a;
b = 20;

Console.WriteLine(a); // 10 — not affected
Console.WriteLine(b); // 20

Common value types

• int, float, double, decimal
• bool, char
• DateTime, TimeSpan
• struct
• enum
• Nullable value types (int?)

Where they live

Value types declared as local variables live on the stack.

Value types declared as fields inside a class live on the heap alongside the object.

Reference Types

A reference type stores a reference (pointer) to the actual data on the heap.

When you assign a reference type to another variable, both variables point to the same object.

var person1 = new Person { Name = "Alice" };
var person2 = person1;

person2.Name = "Bob";

Console.WriteLine(person1.Name); // Bob — both point to the same object

Common reference types

• class
• string
• interface
• delegate
• Arrays
• object

Where they live

The reference (the pointer) can live on the stack.

The actual object data always lives on the heap.

The Key Difference — Side by Side

Struct vs Class

struct is a value type.

class is a reference type.

This single difference drives all the behaviour below.

Struct example

public struct Point
{
    public int X { get; set; }
    public int Y { get; set; }
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1; // copy

p2.X = 99;

Console.WriteLine(p1.X); // 1 — unaffected
Console.WriteLine(p2.X); // 99

Class example

public class Point
{
    public int X { get; set; }
    public int Y { get; set; }
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1; // same reference

p2.X = 99;

Console.WriteLine(p1.X); // 99 — both affected
Console.WriteLine(p2.X); // 99

Struct vs Class — Feature Comparison

When to Use Struct

Use a struct when:

• The data is small (typically under 16 bytes)
• The type is logically a single value (a point, a colour, a coordinate)
• Immutability is desired
• You want to avoid heap allocation and GC pressure
• The type will be used heavily in tight loops or collections

// Good struct candidates
public struct Coordinate { public double Lat; public double Lon; }
public struct Rgb { public byte R; public byte G; public byte B; }
public struct Money { public decimal Amount; public string Currency; }

When NOT to use struct

• The data is large (copying becomes expensive)
• The type needs inheritance
• The type has mutable state that gets passed around
• The type will be used as an interface (triggers boxing — explained below)

Boxing and Unboxing

Boxing and unboxing happen when a value type is treated as a reference type.

Boxing

Converting a value type to object (or an interface type).

int number = 42;
object boxed = number; // Boxing — a copy is placed on the heap

What happens under the hood:

1. Memory is allocated on the heap
2. The value is copied from the stack into the heap object
3. The object variable holds a reference to that heap memory

Unboxing

Converting a boxed object back to a value type.

object boxed = 42;
int unboxed = (int)boxed; // Unboxing — copies value back from heap to stack

What happens under the hood:

1. The runtime checks the type matches
2. The value is copied from the heap back to the stack

Why Boxing is Expensive

Boxing seems harmless. It isn’t.

Every boxing operation:

• Allocates heap memory
• Triggers the Garbage Collector more frequently
• Copies data (twice — once to box, once to unbox)
• Adds CPU overhead from type checking

In hot paths — tight loops, high-frequency operations, large collections — boxing degrades performance significantly.

The Classic Boxing Trap — ArrayList

// ❌ Old way — ArrayList boxes every int
var list = new ArrayList();
for (int i = 0; i < 1_000_000; i++)
{
    list.Add(i); // Boxing happens 1,000,000 times
}

// ✅ New way — List<T> avoids boxing entirely
var list = new List<int>();
for (int i = 0; i < 1_000_000; i++)
{
    list.Add(i); // No boxing
}

List<T> uses generics — no boxing required.

ArrayList treats everything as object — boxing on every insert.

Another Common Trap — Interfaces and Structs

public interface IPrintable
{
    void Print();
}

public struct Message : IPrintable
{
    public string Text;
    public void Print() => Console.WriteLine(Text);
}

IPrintable msg = new Message { Text = "Hello" }; // ❌ Boxing!

Assigning a struct to an interface causes boxing.

The struct is copied to the heap so it can be referenced as an interface.

Spotting Boxing at Runtime

Boxing shows up as:

• Increased GC collections (especially Gen0)
• Memory pressure in profilers
• System.Object allocations in heap snapshots

Use tools like:

• dotMemory (JetBrains)
• BenchmarkDotNet with memory diagnostics
• Visual Studio Diagnostic Tools
• GC.GetTotalMemory(false) for quick checks

Real-World Scenario

Scenario: Logging with string interpolation

int userId = 101;
bool isActive = true;

// ❌ Older pattern — potential boxing with format args
string.Format("User {0} active: {1}", userId, isActive);

// ✅ Modern — string interpolation compiles efficiently
$"User {userId} active: {isActive}";

// ✅ Best for hot paths — structured logging with no boxing via generics
_logger.LogInformation("User {UserId} active: {IsActive}", userId, isActive);

ILogger<T> uses generic overloads to avoid boxing on primitive arguments.

Interview-Ready Summary

• Value types store data directly — assignment copies the value
• Reference types store a pointer — assignment shares the reference
• Stack = fast, limited, deterministic; Heap = larger, GC-managed
• struct is a value type; class is a reference type
• Use struct for small, immutable, short-lived data
• Boxing converts a value type to object and allocates on the heap
• Unboxing copies the value back from the heap
• Boxing in loops or large collections silently destroys performance
• Generics (List<T>) were introduced specifically to eliminate boxing
• Assigning a struct to an interface triggers boxing

A strong interview answer:

“Value types hold their data directly and live on the stack by default, while reference types store a pointer to heap memory. Structs are value types best suited for small, immutable data. Boxing wraps a value type in a heap-allocated object — it’s implicit, easy to miss, and expensive at scale. Generics eliminate boxing by preserving type information at compile time.”

⭐ Add-On — Why This Matters More Now With record struct

C# 10 introduced record struct — a value type with built-in immutability and value equality.

public record struct Coordinate(double Lat, double Lon);

var a = new Coordinate(1.0, 2.0);
var b = new Coordinate(1.0, 2.0);

Console.WriteLine(a == b); // True — value equality, no boxing

This gives you the clean syntax of records without the heap allocation of reference-type records.

For high-performance scenarios where you want immutable data structures, record struct is now the go-to choice.

Last week, I wrote about the most painful lesson my best job taught me. The concept of a “plan” generated some discussion. Here I’m expanding on that.

It took me over 10 years to connect the dots.

For years, I didn’t have a career plan. I jumped from job to job feeling something was missing. OK, when I say “jump,” I mean fired, bored, and laid off. That was my most painful lesson. It cost me my health at the lowest point.

A “plan” sounds like a blueprint with every career scenario figured out in advance.

Nobody starts with a perfect plan. The early stages of our careers are about discovery, experimentation, and building our coding skills while learning to navigate the corporate world.

Plans are hard to follow when layoffs are always around the corner and AI is changing job descriptions.

An intention helps you decide when to move

Instead of “plan,” think of an intention:

A guiding principle that helps you decide whether to stay or move on.

There’s always luck, setbacks, and resets. It’s impossible to account for all of them in a “plan.” But an intention pushes you to act instead of waiting.

Here’s how an intention helps you in practice.

If your intention is money, a couple of years without raises or bonuses should push you to move. That’s not the job that will fill your pockets. Maybe a better choice would be joining a startup in early stages.

If your intention is growing a network, sitting in a cubicle isn’t the best idea. A better role might be DevRel, evangelist, or consultant, positions that takes you out of your cubicle.

Money was just an example. It could be gaining leadership experience, climbing the ladder, or learning opportunities.

Use your career intention as your flashlight. Otherwise, wait to leave only when bored, fired, or burned out. I wish someone had told me that when I started my coding career. It would have saved lots of headaches. Set your intention today.

If you liked this lesson, you’re going to like, Career Lessons From the Trenches, my free 7-day email course where I distill 10+ years of career lessons into 7 short emails–to help you navigate your coding career.