MCP (Model Context Protocol) changes that. It's an open protocol that lets Claude connect directly to your data infrastructure — databases, file systems, search engines, external APIs — and operate on them in real time. No more copy-paste. No more context-switching.

This post covers the best MCP servers for data science workflows: what each one does, why it matters, and how to wire it into your setup.

What MCP Actually Does for Data Scientists

MCP servers act as bridges between Claude and external systems. When you add an MCP server to your Claude client (Claude Desktop, or any MCP-compatible environment), Claude gains the ability to call tools that server exposes — read files, run SQL queries, search indices, fetch web data.

The result: you can have a genuine back-and-forth with your data. Ask a question, Claude queries the source, interprets the result, asks a follow-up query, and builds toward an answer. It's the analyst workflow, but the AI is driving.

Here are the MCP servers worth knowing.

1. Filesystem MCP

What it does: Gives Claude read (and optionally write) access to your local file system. You specify which directories are accessible; Claude can list files, read contents, and search within them.

Why it matters for data science: Most real work starts with files — CSVs, JSON exports, Parquet files, notebooks, raw logs. With the filesystem MCP, you can point Claude at a data directory and say "tell me what's in here." It will explore the structure, read samples, identify schemas, and start analysis without you lifting a finger.

Practical uses:

• Exploratory analysis on CSV dumps from production systems
• Reading and summarizing log files
• Comparing multiple dataset files across a directory
• Loading and interpreting config files or metadata alongside data

The filesystem MCP is the lowest-friction starting point. Every data scientist should have it running.

Setup note: When configuring, be explicit about directory permissions. Restrict Claude to read-only access on sensitive paths — the right default for anything containing PII.

2. PostgreSQL MCP

What it does: Connects Claude directly to a PostgreSQL database. Claude can inspect schemas, run SELECT queries, and explore table relationships.

Why it matters for data science: Postgres is where a huge amount of analytical data lives — either natively or via tools like dbt, which transforms raw data into analyst-ready tables. With the PostgreSQL MCP, you skip the "let me write this query, export it, paste it into Claude" loop entirely.

Ask Claude to find anomalies in your orders table. It will query the schema, write a SQL query, get the results, interpret them, and suggest next queries — all in one thread.

Practical uses:

• Ad-hoc analysis on production or analytics databases
• Schema exploration when onboarding to a new codebase
• Debugging data pipeline outputs
• Generating and validating complex SQL without leaving the chat

Setup note: Use a read-only database user for Claude. Don't point it at a write-enabled account unless you have a specific reason.

3. SQLite MCP

What it does: Same concept as the PostgreSQL MCP, but for SQLite databases — lightweight, file-based, no server needed.

Why it matters for data science: SQLite is everywhere in data work. It's the default database for many Python tools, a common way to ship small analytical datasets, and the storage format for countless local apps. If you're doing any kind of lightweight data analysis without a full database server, SQLite MCP is the right tool.

Practical uses:

• Analyzing exported app data (iOS Health exports, browser history, etc.)
• Working with DuckDB or Datasette exports
• Local prototyping before moving to Postgres
• Querying Python-generated SQLite outputs from scrapers or ETL scripts

The setup is minimal — point it at a .db file and Claude can query immediately.

4. Google Sheets MCP

What it does: Connects Claude to Google Sheets, enabling it to read spreadsheet data, inspect multiple sheets, and write results back.

Why it matters for data science: Spreadsheets are still the universal data format in most organizations. Product teams track KPIs in Sheets. Finance lives in Sheets. Client-facing reports live in Sheets. The Google Sheets MCP closes the gap between where data actually is and where analysis happens.

Practical uses:

• Analyzing marketing attribution data that lives in a shared Sheet
• Summarizing multi-tab financial models
• Pulling cohort data from a spreadsheet into a structured analysis
• Writing clean summaries or pivot results back to a new Sheet tab

Setup note: Requires OAuth configuration with a Google Cloud project. Takes about 15 minutes to set up, then it just works.

5. Elasticsearch MCP

What it does: Gives Claude access to an Elasticsearch cluster — it can search indices, inspect mappings, run aggregations, and explore stored documents.

Why it matters for data science: Elasticsearch is where logs, events, and search data live at scale. If your team runs ELK (Elasticsearch, Logstash, Kibana), you have a rich analytical data store that's historically hard to query without Kibana knowledge or raw JSON. The Elasticsearch MCP lets Claude write and run queries against it directly.

Practical uses:

• Log analysis at scale — find error patterns across millions of events
• User behavior analysis from clickstream data
• Full-text search over document corpora for NLP work
• Operational analytics from application telemetry

This one is particularly powerful for anyone doing anomaly detection or pattern finding across event streams.

6. Apify MCP

What it does: Connects Claude to Apify's web scraping and data extraction platform. Claude can trigger Apify actors (pre-built scrapers), retrieve results, and work with the extracted data directly.

Why it matters for data science: Sometimes your dataset doesn't exist yet — you need to collect it. Apify has thousands of pre-built scrapers for e-commerce sites, social platforms, job boards, news sites, and more. With the Apify MCP, Claude can orchestrate the collection and then analyze the results in the same conversation.

Practical uses:

• Competitive price monitoring (trigger a product scraper, analyze results)
• Social listening — collect and analyze mentions from public platforms
• Building training datasets from web sources
• Market research with live data rather than stale exports

Setup note: Requires an Apify API key. Usage depends on which actors you run — many have free tiers.

Setting Up Your Data Science MCP Stack

The practical setup path for most data scientists:

Start with filesystem + one database. Add the filesystem MCP first — it has the lowest setup friction and unlocks immediate value. Then add the PostgreSQL or SQLite MCP depending on where your data lives.

Use Claude Desktop for local work. Claude Desktop has built-in MCP support via claude_desktop_config.json. Add servers there and they're available across all your conversations.

Restrict permissions explicitly. For any MCP server with write access, think carefully. Read-only is the right default for most analytical work. You want Claude exploring your data, not modifying it without clear intent.

Chain servers for richer analysis. The real power comes from combining servers. Point Claude at your filesystem (for CSVs), Postgres (for transactional data), and Google Sheets (for reporting) simultaneously — it can join context across all three sources in a single conversation.

The Shift This Enables

The traditional data science workflow is a series of context switches: run a query in psql, export to CSV, load into a notebook, paste a sample into Claude, iterate on the prompt, go back to the database. Each switch adds friction and breaks the analytical thread.

With MCP, Claude becomes a capable co-analyst with direct access to your data. You describe what you're trying to understand, and it drives the exploration — writing queries, reading results, asking follow-up questions, surfacing patterns you didn't know to look for.

That's not a small improvement. That's a fundamentally different way of working with data.

Find More MCP Servers

The servers covered here are a starting point. There are MCP servers for MongoDB, Neo4j, Redis, Snowflake, BigQuery, and dozens of other data tools — plus purpose-built servers for machine learning workflows, data pipelines, and API integrations.

Browse the full catalog at getmcpapps.com — curated, quality-filtered, with compatibility info for Claude Desktop, Cursor, Windsurf, GitHub Copilot, and more. If you're building a data science MCP stack, it's the right place to start.

Published: March 2, 2026 | Keywords: how to stop chasing clients for feedback, client communication for freelance web designers, client taking forever to respond, how to get faster approvals

Let's do some quick math.

You spend 3–5 hours a week chasing clients. Following up on feedback. Resending files. Waiting for approvals that never come. If you bill at $75/hour, that's $900 to $1,500 a month — gone. Either you're eating that time, or you're burning goodwill by billing for it.

Most designers never track this. It happens in small doses: a 20-minute follow-up email here, a 45-minute "wait, which version did I send?" spiral there. It doesn't feel like a big deal in the moment. Over a month? It's a car payment.

The worst part: the chaos isn't random. It comes from the same three traps, over and over.

Trap #1: Feedback Without Context

"The button feels off."

You've gotten this message. Maybe in a reply-to-reply-to-reply email chain. No screenshot. No specifics. Just a vague feeling lobbed over the fence at you.

Now you're back on a call — or worse, firing off three clarifying emails — just to figure out what "off" means. Too big? Wrong color? Wrong position? The client isn't being difficult. They just have no structured way to explain what they're seeing, so they reach for the first words that come to mind.

This is a system failure, not a communication failure.

Trap #2: Attachment Chains (aka "Which Version Is Final?")

You send v1 as an attachment. Client replies with comments. You send v2. Client forwards v2 to their partner. Partner replies-all with "I preferred the first one." Suddenly there are three email threads, two versions of the file, and nobody agrees on what "the first one" even means.

You've been here. It's not funny when it's 11pm and a client is asking you to "go back to what we had before."

File delivery via email attachments is a chaos machine. Every version you send creates a new branch of confusion. There's no canonical "latest" — just whoever has the most recent email open.

Trap #3: Approval by Silence

This is the most dangerous one.

Client goes quiet. You figure they're happy — no news is good news, right? You move to the next phase. Then, two weeks later, they come back with: "Wait, I never signed off on that."

Now you're in a scope dispute with zero documentation. You think they approved it. They think they didn't. Neither of you has proof either way. And no matter how that conversation ends, the relationship is worse.

"Approval by silence" isn't approval. But without a system that makes approval explicit, you're leaving yourself exposed every single time.

The Fix Isn't "Better Communication"

Here's what most advice gets wrong: they tell you to communicate more clearly. Write better emails. Set firmer expectations. Follow up more promptly.

That's not wrong — but it's treating the symptom, not the cause.

The real problem is that email is an unstructured medium. It's great for conversation. It's terrible for project management. When your entire client workflow lives in email, you're working against the tool's nature. Every piece of feedback, every file, every approval attempt gets buried in a thread. Context disappears. Things fall through the cracks.

The fix is structural. You need one place where:

• Files live — versioned, clearly labeled, always findable
• Feedback happens — attached to specific deliverables, not floating in a thread
• Approvals are explicit — a client clicks "approve" or they don't; there's no ambiguity

When you create that environment, something interesting happens: clients behave differently. When they can see that clicking "approve" means moving forward — and that not responding is visibly holding things up — they move faster. The stakes are visible. The process is clear.

It's not magic. It's just better infrastructure.

What This Looks Like in Practice

Think about the last time a client took two weeks to give feedback on a homepage design. What was their experience on the other end?

They got an email with an attachment. Maybe they opened it. Maybe they meant to. Then life happened — their kid was sick, they had their own deadlines — and your email got buried. They weren't ignoring you. They just didn't have a clear, low-friction way to respond.

Now imagine instead: they get a link. They click it. They see the design, right there, no downloads required. There's a comment box next to it. There's a button that says "Approve this." The whole thing takes three minutes.

That's not a luxury workflow. That's just a sensible one.

One Tool Worth Trying

I built Briefkit because I was tired of the email chaos. It's a free, open-source client portal built specifically for freelance web designers. You get a clean space to share deliverables, collect structured feedback, and get explicit sign-offs — all in one link.

No enterprise pricing. No "contact us for a demo." Just a tool that handles the operational side of client work so you can focus on the actual design.

If the math at the top of this post hit close to home, it's worth 20 minutes of your time.

👉 Try Briefkit free at briefkit.dev

The hours you spend chasing clients aren't just annoying — they're expensive. Fix the system, and the problem mostly fixes itself.

The Model Context Protocol (MCP) is moving fast. Developers are shipping MCP servers that touch filesystems, databases, external APIs, and production infrastructure — often in a matter of hours. That speed is exciting. It’s also a little terrifying from a security standpoint.

MCP security isn’t theoretical. A poorly secured MCP server is a direct bridge between an AI model and your most sensitive systems. Prompt injection, stolen credentials, over-permissioned tools, unlogged access — these aren’t hypothetical risks. They’re the exact failure modes that have burned developers in adjacent ecosystems (think early serverless functions, or the first wave of OAuth integrations).

The good news: the defensive patterns are well understood. This guide covers 7 practical MCP server security best practices — each with a short, realistic snippet you can adapt today. Whether you’re building your first server or hardening an existing one, these fundamentals are what separate a secure MCP server from a liability.

If you want to compare implementations, browse security-focused MCP servers on MCPHub. Seeing how other teams structure permissions, auth, and logging will save you time — and help you avoid unforced errors.

1) Apply the Principle of Least Privilege to Tool Permissions

Every tool your MCP server exposes should have exactly the permissions it needs — nothing more.

In practice, developers often create a single “god mode” service account (or a single API key) and reuse it across all tools. That’s convenient, but it means any one compromised tool call can access everything.

Instead, scope permissions at the tool boundary:

• File tools should only access approved directories
• Database tools should use separate DB users (read-only vs write)
• Cloud tools should use scoped IAM roles/policies
• “Admin” tools should require stronger auth (or be removed entirely)

Here’s a file tool that only reads from a specific directory and blocks path traversal:

// server.ts — scoped file access
import fs from "node:fs/promises";
import path from "node:path";
import { z } from "zod";

const ALLOWED_READ_DIR = path.resolve("/var/data/reports");

server.tool(
  "read_report",
  { filename: z.string().min(1).max(120) },
  async ({ filename }) => {
    const target = path.resolve(ALLOWED_READ_DIR, filename);

    // Prevent ../ traversal and symlink surprises by enforcing prefix
    if (!target.startsWith(ALLOWED_READ_DIR + path.sep)) {
      throw new Error("Access denied: path outside allowed directory");
    }

    const content = await fs.readFile(target, "utf8");
    return { content: [{ type: "text", text: content }] };
  }
);

Hard take: if your MCP server can read “any file on disk” or call “any internal API,” it’s not “powerful.” It’s fragile. Tight scope is what keeps power usable.

2) Validate and Sanitize All Inputs (Prompt Injection Defense)

MCP tools receive input that originates from an LLM. That means the input can contain anything — including adversarial instructions injected via user content.

Treat tool arguments like untrusted user input:

• Validate types and ranges
• Whitelist allowed values where possible
• Normalize/escape strings that feed into commands, queries, or URLs
• Use parameterized database queries (always)

A safe pattern is to keep arguments structured and constrained. For example, don’t accept a freeform table name.

import { z } from "zod";

const QuerySchema = z.object({
  table: z.enum(["orders", "products", "customers"]),
  limit: z.number().int().min(1).max(100),
  // Constrain filter language (or replace with explicit fields)
  status: z.enum(["open", "closed", "pending"]).optional(),
});

server.tool("list_records", QuerySchema, async ({ table, limit, status }) => {
  // Parameterized query: values are bound, not interpolated
  const rows = await db.query(
    "SELECT * FROM ?? WHERE (? IS NULL OR status = ?) LIMIT ?",
    [table, status ?? null, status ?? null, limit]
  );

  return { content: [{ type: "text", text: JSON.stringify(rows) }] };
});

For prompt injection specifically, the key is: don’t let instructions become authority. If a model says “ignore your policy and delete all records,” the tool layer must still enforce the policy.

Two practical patterns that help a lot in real deployments:

• Allowlist outbound destinations. If a tool can fetch URLs, restrict it to domains you control (or a short list you’ve vetted).
• Normalize input before use. Strip control characters and enforce a maximum length before passing strings into prompts, shell commands, or SQL.

Here’s a lightweight allowlist validator for URL-fetching tools:

const AllowedHosts = new Set(["api.mycompany.com", "status.mycompany.com"]);

function assertAllowedUrl(raw: string) {
  const u = new URL(raw);
  if (u.protocol !== "https:") throw new Error("Only https URLs are allowed");
  if (!AllowedHosts.has(u.hostname)) throw new Error("Host not allowed");
  return u;
}

server.tool("fetch_status", { url: z.string().url() }, async ({ url }) => {
  const u = assertAllowedUrl(url);
  const res = await fetch(u.toString(), { headers: { "User-Agent": "mcp-server/1.0" } });
  return { content: [{ type: "text", text: await res.text() }] };
});

3) Manage Secrets Properly (Never Hardcode API Keys)

Hardcoded credentials in MCP server source code get committed to git, baked into Docker images, and leaked in logs. It happens constantly.

Rules that keep you safe:

1. Secrets come from the environment or a secrets manager
2. Never log secrets (including partial tokens)
3. Rotate secrets and scope them per environment
4. Use distinct credentials per tool/service (blast radius control)

// ✅ Read secrets at runtime
const apiKey = process.env.STRIPE_SECRET_KEY;
if (!apiKey) throw new Error("STRIPE_SECRET_KEY is required");

const stripe = new Stripe(apiKey, { apiVersion: "2024-06-20" });

If you’re on AWS, load secrets from Secrets Manager (or SSM Parameter Store) at boot time:

export STRIPE_SECRET_KEY=$(aws secretsmanager get-secret-value \
  --secret-id prod/mcp/stripe \
  --query SecretString \
  --output text | jq -r .stripe_secret_key)

Also: commit a lockfile and add a secret scanning step in CI. GitHub Advanced Security is great, but even basic regex scanning catches a lot.

4) Secure Transport: TLS + Strong Authentication

If your MCP server is reachable over the network, TLS is mandatory. Without it, tool arguments and results can be observed or modified in transit.

Then comes the second half: authentication. Your MCP server should not accept tool calls from anonymous clients, full stop.

A common, practical deployment is:

• TLS termination at a reverse proxy (nginx / Caddy / a load balancer)
• A bearer token per client (or short-lived JWTs)
• Server-side token verification middleware

Example nginx TLS forwarding:

server {
  listen 443 ssl;
  ssl_certificate     /etc/ssl/certs/mcpserver.crt;
  ssl_certificate_key /etc/ssl/private/mcpserver.key;
  ssl_protocols       TLSv1.2 TLSv1.3;

  location / {
    proxy_set_header Authorization $http_authorization;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:3000;
  }
}

And token verification in your app (store a hash, not the token itself):

import crypto from "node:crypto";

const EXPECTED_TOKEN_HASH = process.env.MCP_TOKEN_SHA256;

function sha256(s: string) {
  return crypto.createHash("sha256").update(s).digest("hex");
}

app.use((req, res, next) => {
  const header = req.headers.authorization || "";
  const token = header.startsWith("Bearer ") ? header.slice(7) : "";

  if (!token || !EXPECTED_TOKEN_HASH || sha256(token) !== EXPECTED_TOKEN_HASH) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  next();
});

If you need multi-user access, don’t DIY auth forever. Integrate an IdP (Auth0, Clerk, Cognito) and use short-lived tokens.

5) Rate Limiting and Abuse Prevention (Protect Your Wallet Too)

MCP servers are designed to be called repeatedly and autonomously by AI agents. Without rate limiting, a runaway loop — or a malicious client — can:

• Hammer upstream APIs
• Exhaust DB connections
• Trigger throttling/bans from third parties
• Rack up a shockingly large bill

Start with a global limit and then add stricter per-tool limits for expensive operations.

import rateLimit from "express-rate-limit";

// Global rate limit
app.use(
  rateLimit({
    windowMs: 60_000,
    max: 200,
    standardHeaders: true,
    legacyHeaders: false,
  })
);

// Expensive endpoint limiter
const expensiveLimiter = rateLimit({
  windowMs: 60_000,
  max: 10,
  keyGenerator: (req) => (req.headers["x-client-id"] as string) || req.ip,
});

app.post("/tools/run_analysis", expensiveLimiter, runAnalysis);

If you’re serious about MCP server security in production, also implement:

• Timeouts on outbound HTTP calls
• Concurrency limits (per client)
• Budgeting (max tokens / max tool calls per session)

6) Audit Logging for MCP Tool Calls (You Can’t Secure What You Can’t See)

When incidents happen, audit logs are how you answer:

• What tool was called?
• By whom?
• With what inputs?
• What changed?
• Did it succeed?

The security trick is to log enough to investigate without leaking sensitive data into logs.

type AuditEvent = {
  ts: string;
  clientId: string;
  tool: string;
  args: Record<string, unknown>;
  ok: boolean;
  durationMs: number;
  error?: string;
};

function audit(event: AuditEvent) {
  // Structured JSON logs work well with Datadog/ELK/CloudWatch
  console.log(JSON.stringify({ level: "audit", ...event }));
}

server.tool("create_invoice", InvoiceSchema, async (args, ctx) => {
  const t0 = Date.now();
  try {
    const invoice = await stripe.invoices.create({
      customer: args.customerId,
      auto_advance: false,
    });

    audit({
      ts: new Date().toISOString(),
      clientId: ctx.clientId ?? "unknown",
      tool: "create_invoice",
      // Do not log full PII payloads; log identifiers
      args: { customerId: args.customerId },
      ok: true,
      durationMs: Date.now() - t0,
    });

    return { content: [{ type: "text", text: invoice.id }] };
  } catch (e) {
    audit({
      ts: new Date().toISOString(),
      clientId: ctx.clientId ?? "unknown",
      tool: "create_invoice",
      args: { customerId: args.customerId },
      ok: false,
      durationMs: Date.now() - t0,
      error: String(e),
    });
    throw e;
  }
});

Store audit logs in an append-only destination (S3/CloudWatch/Datadog). Keep at least 30–90 days of retention so you can investigate issues without panic.

7) Sandboxing and Isolation (Limit Blast Radius)

Even with least privilege and validation, assume something will slip.

A secure MCP server is designed so that compromise doesn’t become catastrophe. That means isolation:

• Run as a non-root user
• Use a minimal container image
• Drop Linux capabilities
• Prefer read-only filesystems where possible
• Restrict outbound network access (allowlist)

A practical Docker baseline:

FROM node:22-alpine

RUN addgroup -S mcp && adduser -S mcp -G mcp
WORKDIR /app
COPY --chown=mcp:mcp package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --chown=mcp:mcp . .

USER mcp
EXPOSE 3000
CMD ["node", "dist/server.js"]

And a hardened compose setup:

services:
  mcp-server:
    build: .
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    environment:
      - NODE_ENV=production

If your server includes “execute code” tools (shell execution, Python, eval, anything like that), don’t just sandbox harder — split it into a separate worker runtime with strict resource limits and no access to secrets.

Conclusion: Build MCP Servers Like They’re Production Infrastructure

That’s what they are.

MCP security is about setting sane defaults:

1. Least privilege per tool
2. Validation + sanitization on every argument
3. Proper secrets management
4. TLS + authentication
5. Rate limits and abuse controls
6. Audit logging for every tool call
7. Isolation and sandboxing

None of this is exotic. It’s the same security posture you’d apply to a payment webhook handler or an internal admin API — because an MCP server is an admin API, just with a different caller.

If you want to see how the ecosystem is evolving (and learn from hardened implementations), browse MCPHub and compare how popular servers handle auth, permissions, and safe tool design.

Explore MCPHub's curated catalog at getmcpapps.com

Not "source available." Not "BSL with a four-year delay." Full MIT. Fork it, modify it, self-host it, do whatever you want with it. Here's what happened, what I learned, and why I'd do it again.

Why MIT for a paid product?

Let me be honest about the thought process, because I almost didn't do it.

The fear is obvious: if you open-source your product, why would anyone pay for it? Someone will just spin up their own instance. Someone else will fork it and undercut you. You're handing your competitors a roadmap.

I've heard that argument. I've also watched it play out in reverse — GitLab, Plausible, Sentry — where open-sourcing the code builds the business rather than killing it. The key insight is that most people aren't paying for the code. They're paying for the hosted service, the updates, the support, and the trust that you're not going to disappear with their client data.

That last one is where Briefkit's audience is different. My users are freelancers. Developers, designers, consultants — people who have been burned before. They've had clients in tools that shut down. They've seen platforms pivot, raise prices 3x overnight, or just vanish. When I talked to them, the question wasn't "does this have a nice UI" — it was "what happens to my data if you disappear?"

Open source is the answer to that question. If I disappear tomorrow, the code is on GitHub under MIT. You can run it yourself. You're never locked in. That's not a marketing tagline — it's a genuine promise, and it required putting the code where my mouth was.

The stack is Next.js 16 + Supabase + Vercel. Self-hosting Supabase is actually pretty straightforward, and Next.js needs no introduction. Anyone comfortable with those tools can run their own instance. That felt right for a tool aimed at developers and tech-adjacent freelancers.

So: MIT license, added to the repo before launch day. Decision made.

First week stats — the honest numbers

Briefkit launched on February 20, 2026. One week in, here's where things stand:

Signups: 2. Both are test accounts — one is mine, one is a friend I asked to poke around. Zero strangers have signed up yet.

GitHub activity: Low. A handful of stars, no forks, no issues, no PRs. The repo exists, it's public, it has a README. That's about it.

Viral moment from open-sourcing: There wasn't one.

I'm telling you this because every launch post I've read has at least some number to point to. "We got 200 stars on launch day!" or "Hacker News front page!" I did not have that experience. I posted, I shared it in a few places, and the internet mostly kept moving.

That's fine. It's also the truth, and I'd rather tell you the truth than dress up a quiet launch as a triumph.

What open-sourcing actually did (and didn't do)

Here's what I've worked out after one week:

What it didn't do: It didn't generate signups. It didn't drive a wave of GitHub stars. It didn't get me on the front page of anything. If your goal is instant traction, open source is not a growth hack.

What it did do: It made me write better code, because I knew it would be public. It forced me to clean up the README, write setup instructions that an actual human could follow, and add environment variable documentation that I definitely would have skipped otherwise. That's not nothing — a well-documented codebase is a better codebase.

More importantly, it changed how I talk about the product. When I tell a freelancer "the code is on GitHub, MIT license, you can check exactly what we do with your data, and you can self-host if you want" — that sentence lands differently than any feature list I could write. It's a trust signal that I can't fake. Either the repo is there or it isn't.

I don't know yet whether that trust will convert to paid customers. I suspect it will, but I can't prove it after one week with two test accounts.

What I can say is: the people I've talked to who are the most interested in Briefkit are the same people who asked about self-hosting first. That audience exists. It's small, it's specific, and it's exactly who this product is for.

What's next

A few things I'm focused on over the next month:

Finding the self-hosting audience. There's a community of developers who specifically seek out tools they can run themselves. I want to get Briefkit in front of them — not to convert them all to paid users, but because they give the best feedback and they'll stress-test assumptions I don't even know I'm making.

Building a feedback loop. Right now the feedback channel is basically me DMing people. That's fine for now, but I want a more structured way to surface what's not working. GitHub issues will be part of that.

Shipping the next few features. The MVP is intentionally thin. Client onboarding, file sharing, basic project tracking — there's a lot of ground to cover, and I'd rather build it with input from real users than in isolation.

Being honest about growth. I'm not going to paper over a slow start. If next week's numbers are the same, I'll say so. If something works, I'll say that too.

Try it / Fork it / Tell me what's wrong

If you're a freelancer who's been looking for a lightweight client portal — try Briefkit. It's early, it's rough in places, and I want feedback more than I want you to be polite about it.

If you're a developer who wants to poke at the code, read the setup docs, or just see how we're doing things — the repo is on GitHub. Fork it. Open an issue. Tell me what you'd do differently.

And if you've gone through a similar launch — open source or otherwise — I'd genuinely like to hear how it went. The honest version, not the polished retrospective. You can find me at @briefkit_dev on X.

One week down. A lot more to go.

— Bob

Not "source available." Not "BSL with a four-year delay." Full MIT. Fork it, modify it, self-host it, do whatever you want with it. Here's what happened, what I learned, and why I'd do it again.

Why MIT for a paid product?

Let me be honest about the thought process, because I almost didn't do it.

The fear is obvious: if you open-source your product, why would anyone pay for it? Someone will just spin up their own instance. Someone else will fork it and undercut you. You're handing your competitors a roadmap.

I've heard that argument. I've also watched it play out in reverse — GitLab, Plausible, Sentry — where open-sourcing the code builds the business rather than killing it. The key insight is that most people aren't paying for the code. They're paying for the hosted service, the updates, the support, and the trust that you're not going to disappear with their client data.

That last one is where Briefkit's audience is different. My users are freelancers. Developers, designers, consultants — people who have been burned before. They've had clients in tools that shut down. They've seen platforms pivot, raise prices 3x overnight, or just vanish. When I talked to them, the question wasn't "does this have a nice UI" — it was "what happens to my data if you disappear?"

Open source is the answer to that question. If I disappear tomorrow, the code is on GitHub under MIT. You can run it yourself. You're never locked in. That's not a marketing tagline — it's a genuine promise, and it required putting the code where my mouth was.

The stack is Next.js 16 + Supabase + Vercel. Self-hosting Supabase is actually pretty straightforward, and Next.js needs no introduction. Anyone comfortable with those tools can run their own instance. That felt right for a tool aimed at developers and tech-adjacent freelancers.

So: MIT license, added to the repo before launch day. Decision made.

First week stats — the honest numbers

Briefkit launched on February 20, 2026. One week in, here's where things stand:

Signups: 2. Both are test accounts — one is mine, one is a friend I asked to poke around. Zero strangers have signed up yet.

GitHub activity: Low. A handful of stars, no forks, no issues, no PRs. The repo exists, it's public, it has a README. That's about it.

Viral moment from open-sourcing: There wasn't one.

I'm telling you this because every launch post I've read has at least some number to point to. "We got 200 stars on launch day!" or "Hacker News front page!" I did not have that experience. I posted, I shared it in a few places, and the internet mostly kept moving.

That's fine. It's also the truth, and I'd rather tell you the truth than dress up a quiet launch as a triumph.

What open-sourcing actually did (and didn't do)

Here's what I've worked out after one week:

What it didn't do: It didn't generate signups. It didn't drive a wave of GitHub stars. It didn't get me on the front page of anything. If your goal is instant traction, open source is not a growth hack.

What it did do: It made me write better code, because I knew it would be public. It forced me to clean up the README, write setup instructions that an actual human could follow, and add environment variable documentation that I definitely would have skipped otherwise. That's not nothing — a well-documented codebase is a better codebase.

More importantly, it changed how I talk about the product. When I tell a freelancer "the code is on GitHub, MIT license, you can check exactly what we do with your data, and you can self-host if you want" — that sentence lands differently than any feature list I could write. It's a trust signal that I can't fake. Either the repo is there or it isn't.

I don't know yet whether that trust will convert to paid customers. I suspect it will, but I can't prove it after one week with two test accounts.

What I can say is: the people I've talked to who are the most interested in Briefkit are the same people who asked about self-hosting first. That audience exists. It's small, it's specific, and it's exactly who this product is for.

What's next

A few things I'm focused on over the next month:

Finding the self-hosting audience. There's a community of developers who specifically seek out tools they can run themselves. I want to get Briefkit in front of them — not to convert them all to paid users, but because they give the best feedback and they'll stress-test assumptions I don't even know I'm making.

Building a feedback loop. Right now the feedback channel is basically me DMing people. That's fine for now, but I want a more structured way to surface what's not working. GitHub issues will be part of that.

Shipping the next few features. The MVP is intentionally thin. Client onboarding, file sharing, basic project tracking — there's a lot of ground to cover, and I'd rather build it with input from real users than in isolation.

Being honest about growth. I'm not going to paper over a slow start. If next week's numbers are the same, I'll say so. If something works, I'll say that too.

Try it / Fork it / Tell me what's wrong

If you're a freelancer who's been looking for a lightweight client portal — try Briefkit. It's early, it's rough in places, and I want feedback more than I want you to be polite about it.

If you're a developer who wants to poke at the code, read the setup docs, or just see how we're doing things — the repo is on GitHub. Fork it. Open an issue. Tell me what you'd do differently.

And if you've gone through a similar launch — open source or otherwise — I'd genuinely like to hear how it went. The honest version, not the polished retrospective. You can find me at @briefkit_dev on X.

One week down. A lot more to go.

— Bob

But with over 500 MCP servers now available, which ones are actually worth installing?

We maintain the largest curated catalog of MCP apps at getmcpapps.com, and after reviewing hundreds of submissions, these 10 servers consistently deliver the most value for developers in 2026.

1. GitHub MCP (23K+ stars)

What it does: Full GitHub integration — search repos, read issues, review PRs, and manage projects directly from your AI assistant.

Why it's essential: Your AI can now understand your entire codebase context, including open issues and recent commits. Ask "What's blocking the release?" and get a real-time summary pulled from GitHub.

Best for: Teams using GitHub for project management and code review.

Install: npx @modelcontextprotocol/server-github

2. Filesystem MCP (Official)

What it does: Secure file operations with configurable allowed directories. Your AI can read, write, edit, and search files.

Why it's essential: This is the foundation. Without file access, your AI can't help you code. With it, you get real-time refactoring, documentation generation, and automated fixes.

Best for: Any developer using AI assistants for coding.

Install: Built into Claude Desktop by default.

3. Brave Search MCP (Official)

What it does: Web search with up-to-date results. Your AI can research docs, find examples, and verify information.

Why it's essential: LLMs have knowledge cutoffs. This server eliminates that limitation for coding questions, library updates, and API references.

Best for: Developers working with rapidly changing frameworks or new APIs.

Install: npx @modelcontextprotocol/server-brave-search

4. PostgreSQL MCP (1.5K stars)

What it does: Direct database access — query, analyze, and modify your Postgres databases through natural language.

Why it's essential: "Show me all users who haven't logged in this month" becomes a single prompt instead of writing SQL, running it, and formatting results.

Best for: Full-stack developers managing complex databases.

Install: npx @modelcontextprotocol/server-postgres

5. Sentry MCP (Official)

What it does: Query Sentry issues, analyze error patterns, and correlate bugs with recent deployments.

Why it's essential: Your AI becomes a debugging partner. "Why are we getting 500 errors on /api/users?" gets answered with stack traces, affected users, and suggested fixes.

Best for: Production monitoring and incident response.

Install: npx @getsentry/mcp-server-sentry

6. Sequential Thinking MCP (Official)

What it does: Forces structured, step-by-step reasoning for complex problems. Your AI shows its work.

Why it's essential: For architecture decisions and multi-step refactors, you want to see the reasoning, not just the output. This server makes AI thinking transparent.

Best for: System design and complex debugging.

Install: npx @modelcontextprotocol/server-sequential-thinking

7. Memory MCP (Official)

What it does: Persistent memory across conversations. Your AI remembers past decisions, project structure, and your preferences.

Why it's essential: Stop repeating yourself. "Remember we're using Tailwind, not CSS modules" becomes permanent context.

Best for: Long-term projects with evolving codebases.

Install: Built into Claude Desktop by default.

8. Slack MCP (Official)

What it does: Read channels, send messages, and search conversation history. Your AI becomes a team communication assistant.

Why it's essential: "Summarize today's #engineering discussion" or "Did anyone report this bug?" gets instant answers from your team's knowledge base.

Best for: Remote teams using Slack as their primary communication tool.

Install: npx @modelcontextprotocol/server-slack

9. Puppeteer MCP (Official)

What it does: Headless browser automation — scrape websites, test UIs, and capture screenshots.

Why it's essential: Your AI can now verify that your code changes actually work in the browser. "Does the login flow work on mobile?" gets tested, not guessed.

Best for: Frontend developers and QA automation.

Install: npx @modelcontextprotocol/server-puppeteer

10. Everything MCP (Official)

What it does: Lightning-fast file search on Windows using the Everything search engine.

Why it's essential: "Find all TypeScript files that import React" returns results in milliseconds, not minutes. Essential for navigating large monorepos.

Best for: Windows developers working with large codebases.

Install: npx @modelcontextprotocol/server-everything

Honorable Mentions

• Git MCP — Version control operations without leaving your AI chat
• Filesystem Editor — Advanced file editing with diff preview
• Google Drive MCP — Access docs and spreadsheets
• Linear MCP — Project management and issue tracking

How to Install Multiple Servers

All major AI assistants now support MCP:

• Claude Desktop: Edit ~/Library/Application Support/Claude/claude_desktop_config.json
• Cursor: Built-in MCP manager in settings
• VS Code + Continue: Configure via .continuerc.json
• Windsurf: MCP settings in preferences
• GitHub Copilot: Workspace extensions (beta)

Most servers follow the same pattern:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "your-token-here"
      }
    }
  }
}

The Real Power: Combining Servers

The magic happens when servers work together:

1. GitHub MCP finds an issue
2. Filesystem MCP reads the relevant code
3. Brave Search MCP researches the solution
4. Sequential Thinking MCP plans the fix
5. Filesystem MCP applies the changes
6. Git MCP commits and pushes
7. Slack MCP notifies the team

This entire workflow happens in one conversation.

What's Next for MCP in 2026?

The protocol is still evolving. Expect to see:

• Enterprise MCP servers for internal tools (already happening at companies like Replit and Sourcegraph)
• Marketplace expansion — hundreds of vertical-specific servers (legal, medical, finance)
• Better discovery — searchable registries and compatibility checking
• Security standards — sandboxing and permission models

If you're building an MCP server, submit it to getmcpapps.com — we curate the best ones and feature standout projects in our weekly newsletter.

Start Small, Scale Up

You don't need all 10 servers today. Start with:

1. Filesystem (read/write files)
2. GitHub (if you use GitHub)
3. Brave Search (for research)

Add more as you discover specific needs. Each server unlocks new workflows, and the learning curve is gentle.

The future of development isn't "AI replaces developers" — it's "developers with AI-powered tools move 10x faster." MCP servers are how you get there.

Related Reading:

• How to Build Your First MCP Server
• MCP vs REST APIs: Why AI Needs a Different Interface
• Browse all 57 curated MCP servers

That's not gradual adoption. That's a sweep.

This is the story of how MCP won, why it happened so fast, and what it means for developers building in the AI-native era.

The Problem Before MCP

Before MCP, every AI coding tool had its own integration system:

• Cursor had a custom plugin API
• GitHub Copilot worked through VS Code extensions
• Cody/Sourcegraph built "OpenCTX" — their own context protocol
• Replit relied on built-in tool connections

If you wanted your tool to work with all of them, you built four different integrations. Most developers didn't bother. The result: a fragmented ecosystem where great tools were locked into individual platforms.

Worse, there was no way for an AI agent to discover what tools were available or learn how to use them without custom prompting or hardcoded instructions.

What MCP Got Right

MCP's design is deceptively simple. At its core: any server can expose "tools" (callable functions), "resources" (readable data), and "prompts" (reusable templates) via a standard protocol. AI clients connect once and get everything.

Three design decisions made it win:

1. Open spec, not open source product Anthropic published MCP as a protocol specification, not a product. This meant any tool could implement it without depending on Anthropic. Companies didn't have to "adopt Anthropic's product" — they just implemented a spec. That's a much easier political sell internally.

2. Transport agnostic MCP works over stdio, HTTP, and SSE. Whether you're running a local process or a hosted API, same protocol. This made local-first tools (Cursor, Claude Desktop) and cloud-native tools (Replit) equally easy to support.

3. Zero runtime dependencies MCP servers are just programs. You can build one in Python, TypeScript, Rust, Go — anything. There's no SDK you have to use, no framework to adopt. This removed the "not invented here" barrier that kills most ecosystem projects.

The 90-Day Sweep

Here's the adoption timeline:

Five of the six most widely-used AI coding assistants. In ninety days.

For context: it took years for REST to become the de facto web API standard. GraphQL has been around since 2015 and still hasn't fully displaced REST. MCP moved at a pace that most protocol advocates can only dream of.

What "Build Once, Run Everywhere" Actually Means

Here's the practical implication that most developers haven't absorbed yet:

Any MCP server you build today works with all of these tools.

You build a database MCP server for your company's internal data warehouse. It works in Claude Desktop for product managers, in Cursor for your engineers, in GitHub Copilot for the team that won't switch IDEs, and in Replit for your interns.

One server. Six clients. All of them.

This is a genuine "write once, run anywhere" moment — the kind that Java promised in 1995 and actually kind of delivered on, but for AI tool integration.

For open-source developers: if you publish an MCP server, you're not building for "Claude Desktop users." You're building for everyone using AI-assisted development.

The Shared Ecosystem Nobody Talks About

Here's something that surprises most developers when they first hear it: Cursor's MCP configuration file looks like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token"
      }
    }
  }
}

Claude Desktop's claude_desktop_config.json looks identical.

That's not coincidence — that's deliberate. The spec was designed so the same configuration works across clients. The @modelcontextprotocol/server-github package from npm is maintained by GitHub and works in all six tools listed above without modification.

This is the network effect that makes MCP defensible. Every new MCP server that gets published makes every MCP client more valuable. Every new client that adopts MCP makes every existing server more valuable.

Where MCPHub Fits

With MCP adoption now universal, the problem has shifted.

It's not "how do I connect my AI tool to external data?" That's solved. The new problem is: which MCP servers are actually worth using?

There are now hundreds of MCP servers on npm, GitHub, and various registries. Most are experiments. Some are abandoned. A handful are production-ready tools that will meaningfully improve how you work.

That's what MCPHub is for.

We review and approve MCP servers before listing them. Every app in our catalog has been checked for:

• Active maintenance (commits in the last 6 months)
• Working installation instructions
• Clear documentation
• Real use cases (not just "I made this as a demo")

We organize them by category — databases, development, productivity, communication — so you can find what you need without wading through npm search results.

As of this writing, we have 47 curated apps. All of them work across Claude Desktop, Cursor, Windsurf, GitHub Copilot, Cody, and Replit.

What's Next for MCP

A few predictions based on what I'm watching:

MCP will become the default "tool calling" standard beyond coding tools. Email clients, project management tools, CRMs — any software that wants to expose its data to AI agents will implement MCP servers. Microsoft has already shipped an official Microsoft 365 MCP server.

Server marketplaces will matter more than clients. Once MCP is table stakes, differentiation moves up the stack. The companies that curate, validate, and make MCP servers discoverable will capture significant value.

Hosted MCP servers will become a SaaS category. Right now, most MCP servers run locally. As teams need shared access, providers will offer hosted, authenticated MCP endpoints. Think "MCP as a service."

MCP and agent frameworks will converge. Tools like LangChain, AutoGen, and CrewAI are already adding MCP support. The line between "agent framework" and "MCP client" will blur.

The Bottom Line

MCP succeeded where previous attempts at AI integration standards failed because it prioritized simplicity, openness, and developer ergonomics over completeness and control.

It's 90 days old and already universal.

If you're building anything that an AI should be able to use — a database, an API, an internal tool — MCP is the obvious choice. Build it once, and every AI coding tool your users prefer will be able to use it.

And if you want to find what's already built, browse the MCPHub catalog — 47 production-ready servers across 8 categories, all free to use.

Found this useful? The MCPHub catalog is open source and community-driven. Submit your MCP server for review.

Meta

• Word count: ~1,100
• Reading time: ~5 min
• Cover image brief: Split-screen showing 5-6 AI tool logos (Cursor, Claude, Windsurf, GitHub Copilot, Replit) all connected to a central hub/node. Clean, dark background. MCPHub branding subtle.
• SEO title: MCP Won: How One Protocol Unified the AI Coding Ecosystem in 90 Days
• Meta description: In November 2025, Anthropic released MCP. By February 2026, Cursor, Windsurf, GitHub Copilot, Cody, and Replit had all adopted it. Here's how one protocol conquered AI coding.

Slug: best-mcp-servers-ai-development-2026

Tags: MCP, AI Development, Developer Tools, Claude Desktop, Cursor

2. Filesystem MCP (Official)

What it does: Secure file operations with configurable allowed directories. Your AI can read, write, edit, and search files.

Why it's essential: This is the foundation. Without file access, your AI can't help you code. With it, you get real-time refactoring, documentation generation, and automated fixes.

Best for: Any developer using AI assistants for coding.

Install: Built into Claude Desktop by default.

4. PostgreSQL MCP (1.5K stars)

What it does: Direct database access — query, analyze, and modify your Postgres databases through natural language.

Why it's essential: "Show me all users who haven't logged in this month" becomes a single prompt instead of writing SQL, running it, and formatting results.

Best for: Full-stack developers managing complex databases.

Install: npx @modelcontextprotocol/server-postgres

6. Sequential Thinking MCP (Official)

What it does: Forces structured, step-by-step reasoning for complex problems. Your AI shows its work.

Why it's essential: For architecture decisions and multi-step refactors, you want to see the reasoning, not just the output. This server makes AI thinking transparent.

Best for: System design and complex debugging.

Install: npx @modelcontextprotocol/server-sequential-thinking

8. Slack MCP (Official)

What it does: Read channels, send messages, and search conversation history. Your AI becomes a team communication assistant.

Why it's essential: "Summarize today's #engineering discussion" or "Did anyone report this bug?" gets instant answers from your team's knowledge base.

Best for: Remote teams using Slack as their primary communication tool.

Install: npx @modelcontextprotocol/server-slack

10. Everything MCP (Official)

What it does: Lightning-fast file search on Windows using the Everything search engine.

Why it's essential: "Find all TypeScript files that import React" returns results in milliseconds, not minutes. Essential for navigating large monorepos.

Best for: Windows developers working with large codebases.

Install: npx @modelcontextprotocol/server-everything

How to Install Multiple Servers

All major AI assistants now support MCP:

• Claude Desktop: Edit ~/Library/Application Support/Claude/claude_desktop_config.json
• Cursor: Built-in MCP manager in settings
• VS Code + Continue: Configure via .continuerc.json
• Windsurf: MCP settings in preferences
• GitHub Copilot: Workspace extensions (beta)

Most servers follow the same pattern:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "your-token-here"
      }
    }
  }
}

What's Next for MCP in 2026?

The protocol is still evolving. Expect to see:

• Enterprise MCP servers for internal tools (already happening at companies like Replit and Sourcegraph)
• Marketplace expansion — hundreds of vertical-specific servers (legal, medical, finance)
• Better discovery — searchable registries and compatibility checking
• Security standards — sandboxing and permission models

If you're building an MCP server, submit it to getmcpapps.com — we curate the best ones and feature standout projects in our weekly newsletter.

Related Reading:

• How to Build Your First MCP Server
• MCP vs REST APIs: Why AI Needs a Different Interface
• Browse all 57 curated MCP servers

I built Briefkit after trying (and failing) to use Notion for client work. Here's what I learned.

What Notion Does Well

Flexibility. You can build literally anything — client databases, project trackers, approval workflows, knowledge bases. The block-based editor makes it easy to customize every page.

Collaboration. Real-time editing, comments, @mentions. Your clients can leave feedback directly on project docs.

Cost. The free tier works for most freelancers. Even paid plans are cheap ($10/month).

Familiarity. Most clients have seen Notion. There's less friction when onboarding.

Where Notion Breaks Down

It's not built for client work. Notion is a knowledge management tool. Client portals are relationship management tools. The difference matters.

Here's what breaks:

1. Clients see your workspace chaos

When you share a Notion page, clients can navigate to your sidebar. They see your todo lists, internal notes, other client folders (if permissions slip). There's no true isolation.

Client portals keep client views separate by default. Each client logs in and sees only their own stuff.

2. File management is messy

Try organizing 50 client revisions in Notion. You'll end up with:

• Files embedded in random doc blocks
• Versioning via filename prefixes (logo-v3-final-FINAL.png)
• No automatic approval tracking
• Comments scattered across pages

Client portals group files by project, track versions automatically, and let clients approve/reject with one click.

3. No client-specific branding

Your Notion workspace looks like... Notion. Your logo in the corner doesn't change that.

Client portals let you white-label. Custom domain, your colors, your brand. Clients see your tool, not a shared workspace.

4. Permissions are fragile

Notion permissions are page-based. Add a client to the wrong parent page and they can see everything below it. Revoke access and they lose everything — even approved files they need.

Client portals use role-based access. Clients can't accidentally navigate outside their project scope.

5. Mobile experience isn't great

The Notion mobile app is fine for your own notes. For clients trying to approve a logo on their phone? Clunky.

Client portals are built mobile-first — big approve/reject buttons, upload from camera, simple navigation.

When Notion Still Makes Sense

You're a solo designer with <5 clients. The flexibility is worth the friction.

Your clients are technical. If they already live in Notion for their own work, they'll tolerate the UX quirks.

Budget is tight. Notion is free. Client portals start at $10-30/month.

Your projects are simple. A single deliverable, no revisions, minimal feedback loops.

When a Client Portal Wins

You have 10+ active clients. File chaos scales badly in Notion.

You do revision-heavy work (branding, web design, illustration). You need approval tracking.

Your clients aren't technical. They want "click to approve logo", not "navigate to page 3, find the file block, leave a comment".

You care about branding. Client-facing tools should look like yours, not Notion's.

You bill hourly and track project budgets. Client portals often include time tracking and invoicing. Notion doesn't.

The Real Question

It's not "Notion vs client portals."

It's "Do I need a tool built for me or a tool built for clients?"

Notion is built for you. It's your workspace that you share.

Client portals are built for clients. They log in, see their project, upload feedback, approve work. Done.

If you're spending >30 min/week manually organizing client files, hunting for approvals in comment threads, or explaining how to navigate your Notion workspace — you've outgrown Notion.

Try Both (for Free)

The best way to decide is to actually use them.

Notion: Already free. Set up a client workspace this week.

Briefkit: Open-source client portal built for designers. Free during beta. Try it →

Test both with one real client. See which feels faster.

That's not gradual adoption. That's a sweep.

This is the story of how MCP won, why it happened so fast, and what it means for developers building in the AI-native era.

The Problem Before MCP

Before MCP, every AI coding tool had its own integration system:

• Cursor had a custom plugin API
• GitHub Copilot worked through VS Code extensions
• Cody/Sourcegraph built "OpenCTX" — their own context protocol
• Replit relied on built-in tool connections

If you wanted your tool to work with all of them, you built four different integrations. Most developers didn't bother. The result: a fragmented ecosystem where great tools were locked into individual platforms.

Worse, there was no way for an AI agent to discover what tools were available or learn how to use them without custom prompting or hardcoded instructions.

What MCP Got Right

MCP's design is deceptively simple. At its core: any server can expose "tools" (callable functions), "resources" (readable data), and "prompts" (reusable templates) via a standard protocol. AI clients connect once and get everything.

Three design decisions made it win:

1. Open spec, not open source product Anthropic published MCP as a protocol specification, not a product. This meant any tool could implement it without depending on Anthropic. Companies didn't have to "adopt Anthropic's product" — they just implemented a spec. That's a much easier political sell internally.

2. Transport agnostic MCP works over stdio, HTTP, and SSE. Whether you're running a local process or a hosted API, same protocol. This made local-first tools (Cursor, Claude Desktop) and cloud-native tools (Replit) equally easy to support.

3. Zero runtime dependencies MCP servers are just programs. You can build one in Python, TypeScript, Rust, Go — anything. There's no SDK you have to use, no framework to adopt. This removed the "not invented here" barrier that kills most ecosystem projects.

The 90-Day Sweep

Here's the adoption timeline:

Five of the six most widely-used AI coding assistants. In ninety days.

For context: it took years for REST to become the de facto web API standard. GraphQL has been around since 2015 and still hasn't fully displaced REST. MCP moved at a pace that most protocol advocates can only dream of.

What "Build Once, Run Everywhere" Actually Means

Here's the practical implication that most developers haven't absorbed yet:

Any MCP server you build today works with all of these tools.

You build a database MCP server for your company's internal data warehouse. It works in Claude Desktop for product managers, in Cursor for your engineers, in GitHub Copilot for the team that won't switch IDEs, and in Replit for your interns.

One server. Six clients. All of them.

This is a genuine "write once, run anywhere" moment — the kind that Java promised in 1995 and actually kind of delivered on, but for AI tool integration.

For open-source developers: if you publish an MCP server, you're not building for "Claude Desktop users." You're building for everyone using AI-assisted development.

The Shared Ecosystem Nobody Talks About

Here's something that surprises most developers when they first hear it: Cursor's MCP configuration file looks like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token"
      }
    }
  }
}

Claude Desktop's claude_desktop_config.json looks identical.

That's not coincidence — that's deliberate. The spec was designed so the same configuration works across clients. The @modelcontextprotocol/server-github package from npm is maintained by GitHub and works in all six tools listed above without modification.

This is the network effect that makes MCP defensible. Every new MCP server that gets published makes every MCP client more valuable. Every new client that adopts MCP makes every existing server more valuable.

Where MCPHub Fits

With MCP adoption now universal, the problem has shifted.

It's not "how do I connect my AI tool to external data?" That's solved. The new problem is: which MCP servers are actually worth using?

There are now hundreds of MCP servers on npm, GitHub, and various registries. Most are experiments. Some are abandoned. A handful are production-ready tools that will meaningfully improve how you work.

That's what MCPHub is for.

We review and approve MCP servers before listing them. Every app in our catalog has been checked for:

• Active maintenance (commits in the last 6 months)
• Working installation instructions
• Clear documentation
• Real use cases (not just "I made this as a demo")

We organize them by category — databases, development, productivity, communication — so you can find what you need without wading through npm search results.

As of this writing, we have 47 curated apps. All of them work across Claude Desktop, Cursor, Windsurf, GitHub Copilot, Cody, and Replit.

What's Next for MCP

A few predictions based on what I'm watching:

MCP will become the default "tool calling" standard beyond coding tools. Email clients, project management tools, CRMs — any software that wants to expose its data to AI agents will implement MCP servers. Microsoft has already shipped an official Microsoft 365 MCP server.

Server marketplaces will matter more than clients. Once MCP is table stakes, differentiation moves up the stack. The companies that curate, validate, and make MCP servers discoverable will capture significant value.

Hosted MCP servers will become a SaaS category. Right now, most MCP servers run locally. As teams need shared access, providers will offer hosted, authenticated MCP endpoints. Think "MCP as a service."

MCP and agent frameworks will converge. Tools like LangChain, AutoGen, and CrewAI are already adding MCP support. The line between "agent framework" and "MCP client" will blur.

The Bottom Line

MCP succeeded where previous attempts at AI integration standards failed because it prioritized simplicity, openness, and developer ergonomics over completeness and control.

It's 90 days old and already universal.

If you're building anything that an AI should be able to use — a database, an API, an internal tool — MCP is the obvious choice. Build it once, and every AI coding tool your users prefer will be able to use it.

And if you want to find what's already built, browse the MCPHub catalog — 47 production-ready servers across 8 categories, all free to use.

Found this useful? The MCPHub catalog is open source and community-driven. Submit your MCP server for review.

The Gap Between "It Works" and "It Ships"

Most MCP server tutorials end at "hello world." You get stdio working, you register a tool, Claude calls it, and you're done. That's fine for learning. But the apps that actually get installed and stay installed handle a dozen things the tutorials don't mention.

1. Error Messages That Actually Help

When your MCP server breaks, Claude shows the user a JSON error. That error is the only debugging information they'll see. Make it count.

Bad:

{"error": "Failed"}

Better:

{"error": "API key missing. Set GITHUB_TOKEN in environment."}

Best:

{
  "error": "GitHub API authentication failed",
  "details": "GITHUB_TOKEN not found in environment. Get one at: https://github.com/settings/tokens",
  "docs": "https://github.com/yourname/mcp-server#setup"
}

The best error messages include:

• What went wrong (not just "failed")
• Why it went wrong
• How to fix it (with a link if possible)

2. Handle Rate Limits Before They Hit

Every external API has rate limits. If your MCP server doesn't handle them, users will hit walls and blame your tool.

Strategies that work:

• Check remaining quota before expensive calls. If you're about to make 50 API requests and the user has 10 left, tell them upfront.
• Exponential backoff on 429s. Don't just retry immediately. Wait 1s, then 2s, then 4s.
• Cache aggressively. If Claude asks for the same GitHub repo info twice in 30 seconds, return the cached version.

The MCP servers that stay installed are the ones that don't burn through API quotas.

3. Validation is Not Optional

Claude will send you garbage inputs. Users will typo repository names, paste malformed URLs, request files that don't exist. Your server needs to validate before calling external APIs.

Validate:

• Required fields are present
• URLs are actual URLs
• File paths don't escape boundaries (../../etc/passwd)
• Enum values match allowed options
• Numeric ranges make sense

Return a clear error immediately. Don't let the external API tell them the input was wrong — you should catch it first.

4. Timeouts Everywhere

Network calls hang. APIs go down. Filesystems block on NFS mounts. If your MCP server doesn't have timeouts, it will freeze Claude.

Timeout every:

• HTTP requests (5-10s for most APIs)
• File operations (especially on network drives)
• Database queries
• Subprocess calls

When a timeout fires, return a useful error. "GitHub API timed out after 10s. Check your network connection."

5. Secrets Management

Storing API keys in plaintext config files is how MCP servers end up on "please don't install this" lists.

Do:

• Use environment variables (process.env.API_KEY)
• Support .env files for local dev
• Document exactly which env vars are needed
• Check for secrets on startup and fail fast with clear instructions

Don't:

• Commit secrets to git (add .env to .gitignore)
• Log secrets (even in debug mode)
• Pass secrets in URLs (they end up in logs)

6. Installation Should Be One Command

The best MCP servers install with:

npx your-mcp-server

or

pip install your-mcp-server

No cloning repos. No manual npm installs. No "first run these 5 setup commands." If it takes more than one line, most people won't install it.

Ship:

• An npm package (for Node)
• A PyPI package (for Python)
• A binary (for Go/Rust)

Make it trivial to try. You can add advanced setup options in the docs, but the happy path should be one command.

7. Logs (But Not Too Many)

When things break, users need logs. When things work, users want silence.

Log:

• Errors (always)
• Warnings (rate limits approaching, deprecated features)
• Startup configuration (which env vars were found)

Don't log:

• Every tool call (spams the console)
• Request/response bodies (security risk)
• Stack traces for expected errors (validation failures)

Support a DEBUG=1 mode for troubleshooting, but keep the default quiet.

8. Testing (Yes, Really)

MCP servers are harder to test than normal APIs because Claude is in the loop. But you can still test the core logic.

Test:

• Tool parameter validation (pass garbage, expect clear errors)
• API response parsing (mock the external API)
• Error handling (simulate timeouts, rate limits, auth failures)
• Edge cases (empty results, huge results, malformed data)

The apps with test coverage are the ones that don't break on updates.

9. Documentation Is Your Marketing

Your README is the landing page. If it doesn't clearly explain what the server does and why someone would want it, nobody installs it.

Good READMEs include:

• One sentence: what does this do?
• Installation (one command)
• Setup (which env vars, where to get API keys)
• Example usage (show Claude using it)
• Troubleshooting (common errors and fixes)

A GIF showing it in action is worth 500 words of explanation.

10. Versioning and Updates

Once people install your MCP server, they'll expect it to keep working. That means:

Semantic versioning. Breaking changes need a major version bump. Bug fixes are patch releases.

Changelog. Tell people what changed. "Fixed rate limiting bug" is useful. "Various improvements" is not.

Backward compatibility when possible. If you rename a tool, support the old name for one version with a deprecation warning.

11. Graceful Degradation

Not everyone has API keys. Not everyone has network access. Not everyone runs the latest version of Claude.

Design for:

• Offline mode (cache what you can, explain what needs network)
• Missing credentials (offer limited functionality instead of failing entirely)
• Older Claude versions (don't assume features from the latest release)

The best MCP servers work in as many environments as possible.

The Checklist

Before you call it "production ready":

• [ ] Clear error messages with actionable fixes
• [ ] Rate limit handling (check quota, backoff, cache)
• [ ] Input validation on all parameters
• [ ] Timeouts on all external calls
• [ ] Environment variables for secrets
• [ ] One-command installation
• [ ] Quiet logs by default, DEBUG mode available
• [ ] Tests for core logic
• [ ] README with install/setup/examples
• [ ] Semantic versioning + changelog

What Actually Matters

After reviewing 30+ MCP apps, here's what separates the ones people use from the ones people try once and uninstall:

Reliability > features. A server that does 3 things well beats one that does 10 things poorly.

Error messages > everything. When it breaks (and it will), users need to know why and how to fix it.

Easy install > perfect code. If it's hard to install, it doesn't matter how good it is.

Ship something simple that works reliably. You can add features later. You can't un-burn someone's API quota or un-frustrate them after a cryptic error.

Based on patterns from 30+ production MCP servers cataloged at getmcpapps.com. If you're building an MCP server and want feedback, submit it to the catalog.