12 posts tagged with "Developer Tools"

Databases are the highest-impact MCP use case we've found. Nothing else comes close in terms of time saved per tool call.

Think about how much of your day involves ad-hoc queries. "How many users signed up this week?" "What's the distribution of plan types?" "Show me the last 10 failed webhook deliveries." Each of these used to mean opening a database client, remembering the schema, writing the SQL, running it, copying the results somewhere useful. With a database MCP server, you describe what you want in plain English and the AI writes the query, runs it, and summarizes the results — in the same conversation where you asked.

We run PostgreSQL MCP as part of our daily workflow at MCPBundles. It handles ad-hoc reporting, data exploration, schema understanding, and debugging. It's the first tool we recommend to anyone evaluating MCP.

Yesterday a support engineer asked "how many workspaces are using custom bundles?" Instead of opening a SQL client, remembering the join between workspace_bundle_access and mcp_bundles, and filtering for user-created bundles — the AI wrote the query, ran it against our read-only replica, and returned the count with a breakdown by plan tier. Thirty seconds from question to answer, including the plan-tier breakdown nobody asked for but everyone wanted.

DevOps engineers live in a dozen dashboards. Datadog for metrics, Sentry for errors, PagerDuty or Opsgenie for on-call, GitHub for PRs, some combination of Terraform and cloud consoles for infrastructure. Every incident means opening five tabs, correlating timestamps across three tools, and context-switching until the problem is resolved or you've forgotten what you were looking at.

MCP servers change this by letting AI agents query those tools directly. Instead of navigating a Datadog dashboard, you ask your agent to pull the metric. Instead of clicking through Sentry issues, you ask it to summarize the top unresolved errors from the last 24 hours. The agent handles authentication, pagination, and response formatting — you stay in one interface.

We run MCPBundles and maintain MCP servers across monitoring (21), cloud infrastructure (19), project management (48), and developer tools (184). This guide covers the ones that matter most for DevOps and platform engineering work.

Two Saturdays ago our error rate spiked at 2 AM. Instead of opening Datadog, Sentry, and GitHub in three separate tabs, one prompt: "Show me the error rate for the API service in the last hour, the top 5 unresolved Sentry issues tagged api, and the last three merged PRs." The AI correlated the spike with a dependency update that shipped at 1:47 AM — a library bump that changed how connection timeouts were handled. Rollback PR was up in 15 minutes. Without MCP, the investigation phase alone would have taken longer than the fix.

The terminal is having its best year since the invention of cloud infrastructure.

Every major AI lab shipped a coding agent CLI. Every major SaaS company shipped or meaningfully updated a service CLI. And a new category is emerging — CLIs that connect the two, giving your coding agent access to production services without leaving the terminal.

We've been running MCPBundles for over a year — a platform where teams connect AI agents to production APIs. We built a CLI because we kept watching agents context-switch between writing code and needing to call Stripe, query a database, or check analytics. This guide covers everything worth installing in 2026, organized by what it actually does for you.

Claude Code has built-in MCP (Model Context Protocol) support that lets your AI coding agent connect to external services — databases, APIs, SaaS platforms — directly from the terminal. This guide covers everything: the native CLI commands, configuration options, transport types, and how to scale beyond a handful of servers.

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.

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.

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

So we built an integration for Cursor's Cloud Agents API. Not because it was on some roadmap or anything. We did it because Cursor's literally our favorite coding tool and we use it every single day.