Forem: Evan Lausier

Why Build a Local MCP Server (And How to Do It in 15 Minutes)

Evan Lausier — Tue, 14 Apr 2026 20:05:57 +0000

I've been working with MCP servers for a few months now. If you're not familiar, MCP (Model Context Protocol) is Anthropic's open standard for connecting AI models to external tools and data sources. Think of it as the API layer between an LLM and the stuff it can actually do.

There are already a bunch of prebuilt MCP servers out there. Ones that connect to GitHub, Slack, Google Drive, databases, you name it. You can plug them into Claude Desktop or VS Code and start using them immediately. So the obvious question is why would you build your own?

Here's why. Because the prebuilt ones solve general problems. Your problems are specific.

Maybe you have a local SQLite database with project data and you want Claude to query it conversationally. Maybe you have a folder full of markdown files that represent your team's internal documentation and you want an AI that can actually search them. Maybe you have a custom API at work that nobody outside your company will ever build an integration for.

That's the gap. MCP lets you fill it yourself. And the local version is the fastest way to get something running without deploying anything, paying for anything, or asking anyone for permission.

What You Need
Python 3.10 or higher and the fastmcp library. That's it.

shell pip install fastmcp

If you prefer TypeScript, there's an official MCP SDK for that too, but Python is the faster path for a first server.

The Simplest Possible Server
Here's a working MCP server in about 10 lines. This one exposes a single tool that searches through local text files in a directory.

from fastmcp import FastMCP
from pathlib import Path

mcp = FastMCP("Local Notes Search")

NOTES_DIR = Path.home() / "notes"

@mcp.tool()
def search_notes(query: str) -> str:
    """Search through local notes files for a keyword."""
    results = []
    for f in NOTES_DIR.glob("*.md"):
        content = f.read_text()
        if query.lower() in content.lower():
            results.append(f"**{f.name}**\n{content[:200]}")
    if not results:
        return f"No notes found matching '{query}'"
    return "\n\n".join(results)

That's a complete MCP server. One file. One tool. When connected to Claude Desktop, you can say "search my notes for anything about project deadlines" and it will actually read your local files and respond.

Connecting It to Claude Desktop

Open your Claude Desktop config file.
On Mac:

plaintext ~/Library/Application Support/Claude/claude_desktop_config.json

On Windows:

plaintext %APPDATA%\Claude\claude_desktop_config.json

Add your server to the config:

{
  "mcpServers": {
    "local-notes": {
      "command": "python",
      "args": ["/path/to/your/server.py"]
    }
  }
}

Restart Claude Desktop. Your tool should show up in the tools menu. That's it.

Making It More Useful
Once you've got the pattern down, you can add more tools to the same server. Here's what a slightly more practical version looks like with a few tools on one server.

from fastmcp import FastMCP
from pathlib import Path
import json

mcp = FastMCP("My Local Tools")

NOTES_DIR = Path.home() / "notes"
DATA_DIR = Path.home() / "data"

@mcp.tool()
def search_notes(query: str) -> str:
    """Search local markdown notes for a keyword."""
    results = []
    for f in NOTES_DIR.glob("*.md"):
        content = f.read_text()
        if query.lower() in content.lower():
            results.append(f"{f.name}: {content[:150]}")
    return "\n".join(results) if results else "No matches found."

@mcp.tool()
def list_notes() -> str:
    """List all available notes."""
    files = sorted(NOTES_DIR.glob("*.md"))
    return "\n".join(f.name for f in files) if files else "No notes found."

@mcp.tool()
def read_note(filename: str) -> str:
    """Read the full content of a specific note."""
    path = NOTES_DIR / filename
    if not path.exists():
        return f"File {filename} not found."
    return path.read_text()

@mcp.tool()
def query_json_data(filename: str, key: str) -> str:
    """Look up a key in a local JSON data file."""
    path = DATA_DIR / filename
    if not path.exists():
        return f"File {filename} not found."
    data = json.loads(path.read_text())
    if key in data:
        return json.dumps(data[key], indent=2)
    return f"Key '{key}' not found in {filename}."

Four tools, one file, no deployment. You can ask Claude to search your notes, read a specific file, or pull data from local JSON files. Everything runs on your machine. Nothing leaves your network.

When to Go Local vs. Remote
Local MCP servers make sense when you're working with files on your machine, querying local databases, prototyping a tool before deploying it, or connecting to internal APIs that are only accessible from your network.

If you need the server to be available across devices, shared with a team, or triggered by other services, that's when you look at hosting it remotely. But for personal productivity and experimentation, local is the move.

The Bigger Picture
The reason MCP matters isn't the protocol itself. It's that it turns AI from a thing you type questions into to a thing that can actually interact with your environment. Every local tool you expose is one less copy and paste cycle between your terminal and your chat window.

Start with one tool. Make it solve one problem you actually have. You'll find the second and third ones pretty quickly after that.

FUNN

Evan Lausier — Sun, 12 Apr 2026 03:38:20 +0000

April Fools Challenge Submission ☕️🤡

FrancisTRᴅᴇᴠ (っ◔◡◔)っ

Apr 7

Forem (Dev.to) is slow, so I del...optimized it.

#showdev #devchallenge #418challenge #discuss

Comments 45

5 min read

Congrats!

Evan Lausier — Sat, 11 Apr 2026 11:55:12 +0000

Beaver-powered databases and ancient AI

Jess Lee for The DEV Team

Apr 6

Oracle, AI, and Who Actually Pays for the Race

Evan Lausier — Sat, 04 Apr 2026 23:40:25 +0000

At some point in the last six months or so, we quietly stopped arguing about whether AI was real ot just the next tech bubble waiting to pop.

That shift matters more than most people realize. Not because the debate was resolved cleanly. It wasn’t. The hype merchants are still out there, still pitching dashboards and slide decks to executives who want to look smart at board meetings. The valuations are still stretched in places. The AI wrapper startups are still going to die by the hundreds.

But the underlying technology…. That part stopped being a question. We can debate the semantics around it, but it different forms of it are likely to be around for a while.

And now we are finding out what happens when tens of thousands of people wake up to the answer.

On March 31st, somewhere around 30,000 Oracle employees started their day the same way. An email arrived at 6 a.m., signed not by anyone they knew, not by a manager, not even by an executive with a name attached to it, but by something called “Oracle Leadership.” By the time most of them finished reading it, their system access was already gone. Their unvested stock was already forfeited. Their careers at one of the largest enterprise software companies in the world were already over.

This happened, by the way, in the same quarter Oracle posted a 95% jump in net income. $6.13 billion in profit.

I want to sit with that for a second… because it sounds so strange when you say it outloud…

Oracle is not the exception here. It is the clearest example of a pattern playing out in plain sight across the entire tech industry. The global tech sector has eliminated nearly 60,000 jobs in the first three months of 2026. That works out to roughly 700 jobs gone every single day. Amazon fired 16,000 people after posting record revenue of $716 billion in 2025. Meta is cutting up to 15,000 workers while simultaneously doubling its AI capital expenditure to $135 billion. Block, Jack Dorsey’s company, cut 40% of its entire workforce and framed it as a competitive necessity.

The companies doing the cutting are not struggling. They are thriving. They just need cash.

Specifically, they need cash for data centers.

Here is the uncomfortable part. The people losing their jobs right now cannot really console themselves with the idea that this is all going to blow over.

For the past couple of years, there has been a comforting narrative available. The bubble will burst. The dot-com comparison will hold. The breathless valuations will correct, the vaporware startups will vanish, and things will return to something recognizable. That narrative still has some truth in it. The hype bubble will deflate. The me-too AI companies with no moat and no margin will disappear. Stock prices will correct in places.

But the technology itself is not going anywhere.

The distinction matters and it is getting lost in the noise. The dot-com crash was built on ideas running on air. Pets.com. Webvan. Companies that were essentially PowerPoint presentations with server rooms attached. Today’s AI infrastructure buildout is different in kind. Oracle currently sits on $523 billion in remaining performance obligations, up 433% year over year. The contracts are real. The data centers being built are physical, steel-and-concrete, take-years-to-construct infrastructure. The demand is real. The technology works.

That is exactly why the layoffs are happening. Not despite AI succeeding. Because of it.

When a company like Oracle commits to $156 billion in AI capital spending, it has to find that money somewhere. According to analysis from TD Cowen, the layoffs free up somewhere between $8 billion and $10 billion in annual cash flow. In other words, the salaries, benefits, and unvested equity of 30,000 people are the down payment on the data centers Oracle needs to stay competitive in a race it cannot afford to lose.

I spent years working inside enterprise software. I know what the teams at a company like Oracle actually build and how long it takes to develop the institutional knowledge that makes a product work for the businesses depending on it. The people who just got that 6 a.m. email were not passengers. They were the product.

And the AI race ate them.

The hardest-hit divisions were Revenue and Health Sciences, SaaS operations, and the NetSuite India Development Centre. That last one matters to me specifically. NetSuite is the product that tens of thousands of mid-market businesses run their entire operations on. The people building it, supporting it, and extending it are not interchangeable. You cannot fire a development centre and replace it with a GPU cluster and get the same outcome. Not yet anyway.

But Oracle is making a bet that the math works out. That building the infrastructure to power the next decade of AI contracts is worth more than preserving the teams that built the last decade of enterprise software. Maybe they are right. Maybe the contract backlog and the data center revenue prove it out over the next few years.

The people who got that email at 6 a.m. will not be around to find out.

I am not arguing that AI is bad, or that the race should stop, or that any of this was avoidable given the competitive dynamics at play. I genuinely believe the technology is going to matter in ways we are still figuring out how to articulate. I use it every day. It is already embedded in how I work.

But I think we owe it to ourselves to be honest about what the cost actually looks like.

The question was never really whether AI would arrive. It was always who would pay for it.

Right now the answer is turning out to be the same people it usually is. The ones who built the thing in the first place.

A race this expensive has to be funded by someone. We just found out who.

Source:

Really Fun!

Evan Lausier — Fri, 03 Apr 2026 10:26:33 +0000

Top scores will feature in a monthly report

FrancisTRᴅᴇᴠ (っ◔◡◔)っ

Mar 30

What is your WPM (Words per Minute)? #1

#discuss #watercooler #challenge #community

Comments 89

1 min read

Very Helpful!

Evan Lausier — Sun, 29 Mar 2026 12:00:19 +0000

Mark

Mar 27

How to Talk to Managers (So They Actually Listen to You)

#career #beginners #productivity #programming

Comments 3

6 min read

Great Read! Very Relatable!

Evan Lausier — Sat, 28 Mar 2026 13:49:21 +0000

The irony of ignoring our own advice

Sylwia Laskowska

Mar 26

How I Almost Burned Out Doing Everything “Right”

#discuss #career #productivity #mentalhealth

192

Comments 112

6 min read

What is MCP?

Evan Lausier — Sat, 21 Mar 2026 21:40:33 +0000

If you've been anywhere near developer Twitter or LinkedIn lately, you've probably seen this diagram floating around. Credit to Alex Xu at ByteByteGo for putting it together so cleanly. It stopped me mid-scroll because it finally gave a clear visual to something I had been reading about in pieces.

MCP, or Model Context Protocol, is an open standard from Anthropic that gives AI models a structured way to connect to external tools, data sources, and services. Think of it as a universal adapter layer between the model and the rest of your stack. Instead of writing one-off integrations every time you want Claude to touch a database or call an API, MCP gives you a consistent protocol to build against.

The diagram breaks it down into two layers worth understanding. The top half shows the host architecture, where an MCP host like Claude Desktop or an IDE runs multiple MCP clients, each speaking to a dedicated MCP server that fronts a specific resource. The bottom half gets into the core building blocks, which are the five primitives the whole thing runs on.

Nobody Is Reading Your Blog Post. They Weren't Going To Read Mine Either.

Evan Lausier — Fri, 06 Mar 2026 19:16:10 +0000

I was building a slide deck last week... technical content, thoughtful structure, a solid wall of text I was genuinely proud of. Somewhere around slide four I had a moment of uncomfortable clarity.

Nobody is reading this.

Not because it's bad. Because nobody reads anything anymore. And AI-generated content isn't causing that. It's just proving it.

The Research Was Telling Us This for Decades

Back in 1997, Jakob Nielsen and the Nielsen Norman Group published eye-tracking research showing that users read roughly 20–28% of words on a typical webpage. They scan in an F-pattern: a horizontal sweep across the top, a shorter sweep a bit further down, then a vertical skim down the left edge. That's it.

The research has been replicated and updated many times since. The pattern holds.

Then in 2014, Tony Haile at Chartbeat — analyzing data across billions of page views — reported that 55% of visitors spent fewer than 15 seconds on a page. Scroll depth data from the same era consistently showed most readers never made it past the midpoint of an article.

So let's be precise about what AI-generated content actually revealed: the bar for "good enough to publish" was always lower than we wanted to admit, because the bar for "read carefully" was already underground.

Your README Is Unread. Your Docs Are Unread. Your Blog Post Was Unread.

If you've been writing technical content for any meaningful stretch of time, you've felt this. The PR where you wrote a detailed description that someone clearly didn't read before commenting. The documentation page that generates the same support ticket every week. The README with a Prerequisites section that people routinely skip until something breaks.

This isn't a character flaw in your users. It's a behavior pattern baked in by information overload. We all do it. I do it. You do it.

We skim for the thing that matches our immediate problem. We ctrl+F. We scroll until something catches our eye. We open five tabs and read none of them completely.

AI content farms figured this out before most publishers did, which is why they're effective at scale. They're not fooling careful readers. There aren't enough careful readers to matter for their metrics.

So What Actually Works

None of this means writing is pointless. It means the format has to do work that the reader won't.

Front-load everything. TL;DRs, key takeaways at the top, summary sections before the detail. If the most important sentence is in paragraph six, it will be missed by most people.

Headers are navigation, not decoration. Someone scanning your post is making micro-decisions at every header: is this the part I need? Write headers that answer that question directly.

Short paragraphs aren't just stylistic. White space gives the eye a place to land. Walls of text read as "skip this block" to a scanner.

Code blocks are a rest stop. For a technical audience, a well-formatted code snippet is often more read than the paragraphs around it. Use them strategically.

The first and last sentence of every section carries disproportionate weight. That's where scanners pay attention. Write accordingly.

The Uncomfortable Part

Here's what I keep coming back to: the AI content problem isn't really an AI problem.

It's a publishing-into-a-vacuum problem that we've been doing for years and only now have a mirror for. When a GPT-generated article with thin sourcing and a generic structure outperforms a carefully researched post, that's not AI winning. That's formatting, SEO, and headline copy winning — the same things that were always winning.

The slide deck I was building? I'm still going to make it. But I rebuilt it with one idea per slide, tight headlines, and the details pushed to speaker notes where they belong.

The audience was always skimming. The only new thing is that I stopped pretending otherwise.

Has your approach to technical writing or documentation changed as you've gotten more honest about reading behavior? I'm curious what's actually worked — drop it in the comments.

MCP Servers Are the New Microservices Sprawl (And We're Making All the Same Mistakes)

Evan Lausier — Tue, 17 Feb 2026 15:05:45 +0000

Remember 2016? When every team decided their monolith needed to be 47 microservices? And then two years later everyone was writing blog posts titled "Maybe We Didn't Need Microservices" while quietly hiring a platform team to wrangle the mess?

Yeah. We're doing it again. Except this time it's MCP servers.

The Pattern We Keep Repeating

Here's how this plays out every single time in our industry:
New thing emerges. New thing is genuinely useful. New thing is easy to spin up. Every developer spins one up. Nobody tracks them.

Nobody governs them. Eighteen months later, someone with "Platform" in their title gets hired to clean it up.

Containers. Microservices. Lambdas. Kubernetes clusters. And now, MCP servers.

The Model Context Protocol has become the standard way AI agents talk to external tools and data sources. Anthropic open-sourced it, Google launched managed MCP servers in December, and the Linux Foundation just stood up the Agentic AI Foundation around it. It's real. It's not going anywhere.

But the adoption curve is outpacing the governance curve by a mile. And if you've been in this industry long enough, you know exactly what that means.

The Numbers Are Already Ugly

Unofficial registries like mcp.so are indexing over 16,000 MCP servers. GitHub likely has north of 20,000 repositories implementing them. And that's just what's public.

Inside enterprises? It's worse. Any developer can spin up an MCP server in minutes. Which means they are. Across teams, across projects, with no central catalog, no consistent auth, and no visibility into what's actually running.

Here's the stat that should concern you: a large-scale analysis of over 5,200 open-source MCP server implementations found that 88% require credentials to operate. Of those, 53% rely on long-lived static secrets — API keys and personal access tokens sitting in environment variables or, let's be honest, hardcoded in config files. Only 8.5% use OAuth.

That's not a security posture. That's a collection of future incident reports.

"But It's Just a Protocol"

This is the thing I keep hearing. "MCP is just a protocol. It's fine."

Sure. HTTP is just a protocol too. And we still managed to build entire categories of security tooling around the fact that people used it carelessly.

MCP doesn't solve authentication. It doesn't solve identity management. It doesn't provide audit trails, observability, compliance, rate limiting, or error handling. It describes how servers and clients communicate. That's it. Everything else is your problem.

And right now, most organizations are treating that "everything else" as someone else's job. Security teams can't monitor what they don't know exists. And most companies don't even have an internal MCP registry — which, to me, is the absolute bare minimum.

So what actually happens? Two things:

Shadow MCP. Developers introduce servers that IT has no idea about. Works fine until it doesn't. And when it doesn't, security has no context on what that server touches, who owns it, or what credentials it holds.

Server sprawl. Multiple teams build slightly different MCP servers for the same API. Nobody decommissions the old ones. The attack surface expands quietly, like mold behind drywall.

Sound familiar? It should. We had the exact same conversation about microservices in 2018 and Kubernetes namespaces in 2020.

Real Vulnerabilities, Right Now

This isn't theoretical. Researchers have already found serious vulnerabilities in some of the most popular MCP servers, including ones from Microsoft and Anthropic themselves.

Path validation bypasses. Arbitrary file overwrites. Credential exposure through cloud metadata services. And the fun one: chaining multiple medium-severity issues into full remote code execution.

These aren't exotic zero-days. They're the boring, predictable result of moving fast without governance. The same kind of bugs we've been finding in rushed microservice deployments for years.

What Actually Needs to Happen

I'm not here to say "MCP bad, don't use it." MCP is genuinely useful. My team uses it. The protocol itself is solid. The problem is the operational model around it.

If you're adopting MCP at any kind of scale, here's my short list:

Build an internal registry. If you don't know what MCP servers exist in your org, you can't secure them. This doesn't need to be fancy. A spreadsheet with owner, purpose, permissions, and last review date is better than nothing. But build toward something with automated discovery.

Standardize on OAuth 2.1. The 53% of servers running on static API keys need to stop. Short-lived tokens, PKCE for user-facing apps, mutual TLS for service accounts. This is solved work. We just need to actually do it.

Deploy a gateway. An MCP gateway is the same pattern as an API gateway — single entry point, centralized policy enforcement, consistent logging. It turns a chaotic multi-server topology into something you can actually operate. If you learned anything from the microservices era, it's that you need a control plane before you need more services.

Treat MCP servers like infrastructure, not experiments. The moment an MCP server touches production data, it's infrastructure. It needs an owner, a lifecycle, and a decommission plan. The "I'll just spin one up real quick" mindset is how you end up with 200 unmanaged endpoints and a SOC 2 auditor asking questions you can't answer.

The Part Nobody Wants to Hear

Gartner is predicting 40% of agentic AI projects will fail by 2027. Not because the tech doesn't work, but because organizations are automating broken processes. MCP sprawl is a symptom of that exact problem.

We keep doing this thing where we adopt the technology first and figure out the operations later. And every time, we act surprised when it gets messy. Microservices taught us that distributed systems need centralized governance. MCP is a distributed system. The lesson applies.

The organizations that get this right won't be the ones with the most MCP servers. They'll be the ones that actually know how many they have.

Love it!

Evan Lausier — Wed, 11 Feb 2026 11:21:31 +0000

Sylwia Laskowska

Feb 10

How Seriously Should We Take State of JS and Other Developer Surveys?

#javascript #node #frontend #webdev

Comments 72

4 min read

Enter Ant Man!

Evan Lausier — Wed, 04 Feb 2026 12:32:23 +0000

Well this was too fun not to share! I am still waiting for Ant Man to pop out somewhere!!

https://x.com/NightSkyToday/status/2018441295065395398?s=20

The Core Claim:

On December 9, 2024, Google Quantum AI announced its Willow processor, a 105-qubit superconducting quantum chip. The headline achievement: Willow completed a Random Circuit Sampling (RCS) benchmark computation in under 5 minutes that would take today's fastest supercomputers (like Frontier) approximately 10 septillion (10²⁵) years — a timeframe vastly exceeding the age of the universe (~13.8 billion years).

Google's Hartmut Neven suggested the chip's performance "lends credence to the notion that quantum computation occurs in many parallel universes, in line with the idea that we live in a multiverse." EDRM

Its important to note, this claim is highly contested. That said, I personally think this technology is so cool. Google's chip sort of working cannot be interpreted as evidence for parallel universes because its function is entirely consistent with theories in which ours is the only universe. But its still fun to watch as the technology grow.