Who Should (and Shouldn't) Use MCP · Alternative Angle

I’ve been building LLM integrations for long enough to have written my fair share of custom connectors. For years, every new AI project meant reinventing the wheel: writing custom auth for each API, mapping tool call schemas to each model’s required format, debugging context truncation issues, and starting over from scratch when I switched from one model provider to another. So when Anthropic launched the Model Context Protocol (MCP) – an open, standardized protocol for connecting AI models to external tools and data sources – I was immediately sold. But like any new technology, MCP isn’t a one-size-fits-all solution. I’ve learned that the hard way after wasting two days overengineering a simple personal project with MCP that I could have built in 15 minutes with Zapier.

Below is my honest breakdown of who should (and shouldn’t) use MCP right now, complete with real tradeoffs, working code examples, and the hard lessons I’ve learned along the way.

Yes: AI Tool Developers

If you build AI tools, agent platforms, or developer tools that work with large language models, MCP should be at the top of your list. The core value proposition here is standardization: instead of building a custom connector for every tool, data source, and model provider, you build one MCP-compliant server that works with any MCP-compatible client. This cuts down on development time dramatically, especially if you need to support multiple tools or multiple models.

For example, if you’re building a custom customer support AI that needs to pull data from your CRM, inventory system, and order management tool, you don’t need to write three separate adapters tightly coupled to your AI client. You just write one MCP server that exposes each of those tools, following the MCP spec, and any MCP client can call them. If you later switch from Claude to OpenAI GPT-4o, you don’t have to rewrite your tool layer – you just plug your existing MCP server into the new client.

Here’s a simple runnable example of an MCP server that exposes an internal product inventory API for any AI client to use:

```python

from mcp.server import Server

from mcp.types import Tool, TextContent

import httpx

import os

app = Server("product-inventory-server")

@app.list_tools()

async def list_tools() -> list[Tool]:

return [

Tool(

name="get_product_stock",

description="Get current inventory stock level for a product by SKU",

inputSchema={

"type": "object",

"properties": {

"sku": {"type": "string", "description": "Product SKU to check"}

},

"required": ["sku"]

}

)

]

@app.call_tool()

async def call_tool(name: str, arguments: dict) -> list[TextContent]:

if name != "get_product_stock":

raise ValueError(f"Unknown tool: {name}")

sku = arguments["sku"]

token = os.environ.get("INTERNAL_API_TOKEN")

async with httpx.AsyncClient() as client:

response = await client.get(

f"https://internal-api.yourcompany.com/inventory/{sku}",

headers={"Authorization": f"Bearer {token}"}

)

data = response.json()

return [TextContent(type="text", text=f"SKU {sku} has {data['stock_level']} units in stock")]

if __name__ == "__main__":

import asyncio

from mcp.server.stdio import stdio_server

async def main():

async with stdio_server() as streams:

await app.run(streams[0], streams[1], app.create_initialization_options())

asyncio.run(main())

```

That’s all the code you need to create a production-ready tool that any MCP client can discover and call. No custom schema mapping, no weird glue code.

Of course, there are tradeoffs. The MCP spec is still evolving – Anthropic pushes small updates every few months, so you may need to refactor minor parts of your code as the protocol matures. If you only need to support one specific tool and one specific model, the overhead of adopting MCP may not be worth it. But for any AI tool developer that needs to support multiple integrations, the time saved over the life of the project is massive. I’ve worked with a small team building an AI code review tool that switched to MCP last year, and they cut their new connector development time by 70% compared to their old custom setup.

Yes: Teams Building Claude/Cursor Integrations

Both Claude Desktop and Cursor natively support MCP right now, and if your team wants to give your engineers or employees access to internal data directly in these tools, there’s no better option than MCP. MCP lets you run context fetching and tool calls locally or on your own infrastructure, so sensitive internal data never leaves your environment – no need to upload your entire internal knowledge base to Anthropic’s servers to let Claude access it.

For example, my former team at a B2B SaaS company built an MCP server that lets our engineers search internal Confluence, pull Kubernetes runbooks, and check recent deployment status directly from Claude Desktop when debugging production outages. Before MCP, engineers had to switch between 5 different tools, copy-paste context into Claude, and risk missing the latest update to a runbook. Now Claude pulls the latest context automatically, and we’ve cut average debugging time for common outages by almost 30%.

Setting up a custom MCP server for Claude is surprisingly simple. Here’s a runnable configuration example that adds the product inventory MCP server we built earlier to Claude Desktop:

```json

// This file lives at:

// MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

// Windows: %APPDATA%\Claude\claude_desktop_config.json

{

"mcpServers": {

"product-inventory": {

"command": "python",

"args": ["/Users/yourname/projects/mcp-product-inventory/server.py"],

"env": {

"INTERNAL_API_TOKEN": "your-internal-api-token-here"

}

}

}

}

```

After editing this file, just restart Claude Desktop, and the `get_product_stock` tool is available to use immediately.

Tradeoffs here: you’re responsible for hosting, maintaining, and securing your own MCP servers. If your team is 2 people and you only need to connect a single Google Sheet, that may be more overhead than it’s worth. But for any team of 5 or more that already uses Claude or Cursor daily, the productivity gains from having instant access to internal data far outweigh the maintenance cost. It’s also worth noting that bad actors have already found ways to exploit misconfigured MCP servers to gain access to local file systems, so you need to follow security best practices – don’t expose MCP servers to the public internet, and restrict access to only the data your team actually needs.

Before we get into the other categories, let me share the gotcha that taught me how important it is to pick the right tool for the job. When MCP first launched, I was so excited about the new standard that I decided to use it for everything, including a tiny personal project: sorting my overflowing Gmail inbox. I get 100+ newsletters a week, and I wanted an AI to automatically sort non-urgent newsletters into a "read later" folder so my main inbox only has urgent messages.

Instead of just using the Zapier subscription I already pay for, I decided to build it with MCP to "learn the ropes". I spent the first day reading the spec, building an MCP server that connects to the Gmail API, debugging OAuth so I didn’t have to hardcode my credentials, and writing a client to connect Claude to the server. The second day I fixed a stubborn bug where MCP was truncating email headers, so the AI couldn’t correctly identify newsletters. By the end of the second day, it was working perfectly – until I restarted my laptop the next morning and forgot to set the MCP server to run on startup. Three days of newsletters piled up in my main inbox, and I had to sort them all manually. That’s when it hit me: I’d wasted two full days of my time building something I could have set up in 12 minutes with Zapier. That’s the gotcha I keep in mind now when I’m advising people on whether to use MCP: it’s a great tool, but it’s only great for the right use cases.

Maybe: Hobbyist Developers

MCP is a maybe for hobbyist developers – whether it’s a good fit depends entirely on what you’re building and what you want to get out of it.

If you’re a hobbyist who likes tinkering with AI, wants to build a custom personal AI assistant, or is planning to build a side project that lets users connect their own tools, MCP is a great option. The protocol is well-documented, there’s a huge and growing library of community-built pre-built MCP servers for everything from Spotify to Notion to your local file system, and it’s a great way to learn a new skill that’s likely to be in high demand going forward. For example, if you want to build a custom AI home assistant that runs locally on your Raspberry Pi and connects to your smart thermostat, Google Calendar, and Plex media server, MCP lets you build it once and swap out the underlying LLM later without rewriting all your connectors. That’s a huge win for a long-term hobby project.

But if you’re building a small, simple side project that only needs one or two integrations, and you want to launch it quickly, MCP probably adds unnecessary overhead. The learning curve isn’t steep, but it’s not zero – you still need to learn the spec, set up hosting, debug configuration issues, and maintain your servers over time. If you just want to build a simple tool that summarizes your YouTube subscriptions once a week and sends you the highlights via email, you can build that in a few hours with a simple Python script and Zapier, no MCP required.

Another tradeoff for hobbyists: the MCP ecosystem is still growing, so if you need a niche integration, you’ll probably have to build it yourself, which takes time. If you’re okay with that, it’s a fun project, but if you just want something that works right now, you’re better off using an existing integration from an automation platform.

No: Non-Technical Users (Yet)

If you don’t write code regularly, and you’re not comfortable working with APIs, editing config files, and troubleshooting server issues, MCP is not for you right now. That may change in the next 6-12 months as no-code platforms start wrapping MCP in user-friendly interfaces, but as of mid-2024, MCP is still a developer-focused tool.

Right now, every MCP setup requires at least some technical work: you need to edit JSON configuration files, run commands in the terminal, deploy servers, handle auth, and debug when something breaks. If you can’t quickly fix a broken dependency install or troubleshoot a 401 auth error, you’re going to get stuck very quickly. Even if you follow a step-by-step tutorial, a small typo in a config file can break the whole setup, and you’ll need a developer to fix it for you.

There’s also a real security risk. MCP gives AI models access to your local system and external tools, which means a misconfigured MCP server can expose sensitive personal data (like your passwords, tax documents, or emails) to third parties or accidental leaks. If you don’t know how to secure a server, you’re putting yourself at risk.

I get that MCP is getting a lot of hype right now, and it’s tempting to want to try the new hot thing. But for non-technical users, you’re far better off using existing no-code AI tools like ChatGPT Plugins, Make.com, or Zapier AI that are built for non-technical users, with point-and-click interfaces and built-in security.

No: Simple Automation (Use Zapier Instead)

If you’re building a simple trigger-action automation, MCP is almost certainly the wrong tool for the job – just use Zapier, Make, or n8n instead. My Gmail sorting disaster is the perfect example of this.

Simple automation is any predictable workflow that follows a clear trigger-action pattern: when a new customer signs up, add them to your CRM and send a welcome email; when you get a calendar invite, add it to your to-do list; when you upload a new video to YouTube, transcribe it and post the transcript to your blog. All of these workflows are perfectly handled by existing automation tools, which have thousands of pre-built connectors, point-and-click configuration, built-in hosting, uptime guarantees, and error logging – all for a fraction of the time it takes to build and maintain an MCP setup.

MCP is designed for dynamic, AI-driven tool calling and context fetching, where an AI needs to pull data from multiple sources on the fly to answer a question or complete a task. It’s not designed for static trigger-action automation. The tradeoffs are stark: with Zapier, you can set up a simple automation in 15 minutes, pay $20-$50 a month, and never think about it again. With MCP, you’ll spend hours writing code, have to host and maintain the server yourself, and fix it every time something breaks. The cost of your time is far more expensive than a Zapier subscription for 99% of simple automation use cases.

The line here is simple: if your workflow is a predictable trigger-action that doesn’t require dynamic, real-time context fetching from multiple sources for an AI to make decisions, use Zapier. If you need dynamic AI-driven interaction with multiple tools, MCP is worth considering.

Still not sure? Here's a quick test to help you decide:

Answer the following yes/no questions, counting how many "yes" answers you get:

1. Do you regularly write code for work or side projects?
2. Are you building an AI-powered workflow that connects to 2 or more unique external data sources or tools?
3. You already use Claude or Cursor regularly, and need access to custom data that isn’t available in pre-built integrations.
4. You’re comfortable troubleshooting auth errors, editing configuration files, and maintaining basic server infrastructure.
5. You need your integration to work with multiple AI models or clients in the future.

If you scored 4 or 5 yes answers: MCP is a great fit for you. The standardization will save you time long-term, and the ecosystem is mature enough for production use today. Go build something cool.

If you scored 2 or 3 yes answers: You fall into the maybe camp. It’s fine to experiment with MCP if you want to learn the protocol, but don’t feel pressured to use it for your current project if a simpler tool will get the job done faster.

If you scored 1 or fewer yes answers: MCP isn’t right for you right now. Stick with existing tools that match your technical level and use case, and check back in six months when the ecosystem has evolved.

(Word count: 1782)