MCP Server: Do You Actually Need One?

An analysis of the Model Context Protocol (MCP) argues that most companies do not need a dedicated MCP server and should instead use standard LLM API integrations for adding AI features. The piece identifies three scenarios where MCP deployment is justified: technical B2B sales, agent orchestration, and developer platforms. For teams with 5-10 core actions, building an MCP server typically takes one engineer a few weeks, with the main challenge being tool design rather than protocol implementation.

MCP Server: Do You Actually Need One? Claude /en/tags/claude/ , Cursor, or a client's internal agent stack—to trigger actions in your product on a user's behalf. If your goal is simply to add an AI feature inside your own app, skip the MCP overhead and just use a standard LLM API integration. It's faster and usually cheaper. The Model Context Protocol MCP is essentially a thin adapter. It takes your existing product actions—things like "create invoice" or "check order status"—and exposes them as tools in a schema that an agent can read and reason about. It doesn't grant your software new powers; it just gives external agents a standardized way to access the capabilities you already have. When to actually deploy MCP In my experience rolling out AI tools at work, we hit this exact crossroads with our outreach engine. A client asked if they could point their own internal agent stack at our tool instead of using our UI. That's the litmus test: does the user want to interact with your product as a tool within their own agent, rather than as a standalone website? I see three real-world scenarios where this is a requirement: Technical B2B Sales: If your buyers are already running their own agent workflows and asking for API connectivity for their agents, an MCP server turns a "custom integration" conversation into a "plug-and-play" win. Agent Orchestration: If your product acts as a layer that needs to expose sub-tools to a supervising agent. Developer Platforms: When "AI-native integration" is a core part of your value proposition. For everyone else, a well-documented REST API with an OpenAPI spec is often enough, as most agent frameworks can already consume those. The implementation cost If you have 5-10 core actions, building an MCP server is a small API project, not a rewrite. It typically takes one engineer a few weeks, provided your backend logic is clean. The real time-sink isn't the protocol; it's the tool design. We learned this the hard way when we tried to collapse a two-step "extract facts, then draft email" flow into a single call. Figuring out the right granularity for what to expose to the agent takes far more thought than writing the actual adapter code. The workload generally splits into: Tool design: Determining which actions to expose and how granular they should be. Schema definition: Mapping those actions into the MCP format. Next Azure Linux VM: A Practical Tutorial → /en/threads/2454/