88 posts tagged with "AI Agents"

There's a war happening on Reddit right now, and it's getting heated.

On one side: developers who believe the Model Context Protocol is overengineered middleware — that AI agents should just call gh issue create and curl like any terminal user. On the other: engineers running MCP in production who say the skeptics will inevitably reinvent every feature MCP provides, just worse.

Both sides are partially right. But the debate itself is framed wrong.

I spent the last day using our MCPBundles CLI to search Reddit via MCP tools — browsing posts, pulling comment threads, analyzing arguments — all through authenticated MCP tool calls executed from the command line. The irony was not lost on me: I was using CLI to call MCP to read arguments about whether we need MCP or CLI.

The answer, as it turns out, is both. But not in the way most people think.

We ran into a problem a few weeks ago that none of our tools could solve. It wasn't a technical problem — the code was fine, the infra was fine. We just needed someone to go do a thing on a website. Sign up, click around, grab some information, paste it into a form. Repeat a bunch of times.

AI couldn't do it. The sites had captchas, email verification, multi-step flows. We tried browser automation and it broke immediately. We needed a person.

So we thought: what if our AI agent could just hire one?

The Glama directory lists 22,775 MCP servers as of May 2026. Most are weekend projects. Some are brilliant. BlueRock Security found 36.7% of public MCP servers carry SSRF vulnerabilities, 41% have no authentication at all, and only 8.5% use OAuth — so a "list of every MCP server" is not a useful list.

This guide is the opposite: the ~80 servers that real teams run in production, grouped by job. Four to five of them will cover 80% of what you ask your AI to do. We've been running MCPBundles for over a year — a platform where teams connect their AI agents to production APIs — and have tested, wrapped, and maintained MCP servers for hundreds of services. This is what we've learned about which ones are worth your time, what to skip, and why.

Claude Code ships with built-in MCP (Model Context Protocol) support. Add external tools — databases, APIs, SaaS platforms — directly from the terminal with claude mcp add. This page covers every command, config option, and common fix.

Here's the thing nobody tells you about Cursor's agent mode: it's brilliant at working with code and completely blind to everything your code talks to.

Last week we were debugging a webhook handler. Cursor had the code open, understood the control flow, spotted a race condition in the retry logic. Genuinely impressive. Then we needed to know whether the bug was actually hitting production — were customers seeing duplicate charges? The agent that just did 15 minutes of sophisticated code analysis couldn't answer a basic factual question about our own Stripe data.

So we opened a browser tab, logged into Stripe, searched for the customer, scrolled through PaymentIntents, compared timestamps manually, went back to Cursor, and typed what we found. The AI had all the context and none of the data.

We got tired of being the copy-paste bridge between our IDE and our dashboards.

Glama indexes 20,000+ MCP servers. Smithery has 8,000+. mcp.so has 6,000+. There's no shortage of servers to find.

The problem is everything that happens after you find one.

You pick a promising-looking Stripe MCP server from a directory. Now you need to clone the repo, install its dependencies (hope they don't conflict with yours), figure out whether it uses env or args for the API key, add your key to a JSON config file in plaintext, start the process, and configure your AI client to talk to localhost:3000. If you're lucky, it works. If the repo hasn't been updated in three months, it probably doesn't.

Repeat that for every service you want to connect. We got to five local MCP server processes before we gave up and built something better.

Browse the full directory of remote and hosted MCP servers — 1,500+ live servers you connect via URL, no local process required.

If you've set up an MCP server before, you know the drill. Clone a repo. Install dependencies. Add your API key to a JSON config file. Start the process. Configure your AI client to connect to localhost:3000. Repeat for every service you want to use.

It works. Until it doesn't. The process crashes silently. Your laptop sleeps and the server dies. You upgrade Node and the dependencies break. A teammate wants access and you're sharing API keys over Slack. You add a third service and now you're managing three server processes, three config files, and three sets of credentials in plaintext on your machine.

Local MCP servers are fine for trying things out. For daily use across a team, you need hosting.

Yes, Windsurf supports MCP. Cascade — Windsurf's AI agent — can connect to external MCP servers to access databases, APIs, and SaaS platforms directly from your IDE. This guide covers setup, configuration, known limitations, and how to work around the 100-tool cap.

Every AI platform supports MCP tools. But what happens when the tool you need doesn't exist yet? Maybe you're working with an internal API, a niche SaaS, or a service that nobody has wrapped in MCP. Until now, you'd write a custom server.

Now your AI can do it itself.

MCPBundles has always worked as an MCP server. You add it to Claude Desktop, Cursor, ChatGPT, or any MCP-compatible client, and your AI gets access to Stripe, HubSpot, Postgres, PostHog, Gmail, and every other service you've connected — with real credentials, real permissions, and real data.

The MCPBundles CLI is an alternative way to access those same tools. Instead of configuring MCPBundles as a remote MCP server in your client, you install a command-line tool and authenticate with an API key. The AI agent discovers and calls your tools through shell commands — the same 10,000+ tools, the same credentials, the same workspace permissions.

pip install mcpbundles

Tool overload is real.

It shows up as lag. Wrong tool picks. Weird, half-finished workflows. Or the model just dumps a wall of raw data at you and calls it a day.

We’ve always had a simple answer: keep bundles focused. 5–15 tools for one job.

That still works great.

But sometimes you do want a big bundle. A real “everything I use for this role” bundle.

Now you can do that without turning your AI into a confused mess.

Every bundle can run in Dynamic.

Tool overload is real. Give AI 50 tools and it gets confused—slow, wrong tool selections, data dumps instead of answers. We've always solved this with focused bundles: give AI 5-15 tools for a specific workflow, and it works great.

But what about when you need data from multiple services at once?

That's why we built the Hub. It uses programmatic tool calling—AI discovers tools on-demand and writes code to orchestrate them—so you can work across all your connected services without the overload problem.

This builds on recent research from Anthropic—their work on advanced tool use and code execution with MCP. We took these patterns and made them accessible to anyone with an MCPBundles account.

When you're building MCP tools, there's a moment where you realize something counterintuitive: the description field isn't just documentation—it's instruction. Every parameter description you write is a teaching moment where the AI learns not just what a parameter is, but when to use it, why it matters, and how it impacts the operation.

This shift in thinking—from documenting to teaching—changes how you design tools. Let me show you what that looks like in practice.