You Are Using MCP Wrong: When to Use Model Context Protocol (And When Not To)

#ai #javascript #react #frontend

Originally published on NextFuture

The dev community has strong opinions about MCP (Model Context Protocol). Some love it, others call it overengineered and unreliable. Here is the thing — both sides are right, but for the wrong reasons. The problem is not MCP itself, it is that most people are using it in the wrong context entirely.

Where MCP Actually Shines

MCP is genuinely great for exactly two use cases:

GUI client integrations — tools like Claude Desktop, Cursor, and AI-enabled IDEs. MCP provides a standardized protocol for tools to communicate with these clients.
Documentation servers — exposing static docs, schemas, and context for an LLM to read on demand.

Where MCP Falls Apart

This is where most devs go wrong: wiring up tool calling in agent code. If you are writing Python or TypeScript to call an LLM API and want to add tools, do not reach for MCP — use native function calling directly.

// ❌ Wrong: MCP in agent/pipeline code
const mcpClient = new MCPClient({ server: "my-tools" });
const result = await mcpClient.callTool("search", { query });

// ✅ Right: Native function calling
const response = await anthropic.messages.create({
  model: "claude-opus-4-5",
  tools: [{
    name: "search",
    description: "Search the web for information",
    input_schema: {
      type: "object",
      properties: { query: { type: "string", description: "Search query" } },
      required: ["query"]
    }
  }],
  messages: [{ role: "user", content: "Find the latest React news" }]
});

The Right Way to Use MCP

MCP shines when you are building a server that exposes tools to GUI clients:

// ✅ Right: MCP server for Cursor / Claude Desktop
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "my-dev-tools", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "read_file",
    description: "Read a file from the project directory",
    inputSchema: {
      type: "object",
      properties: { path: { type: "string" } },
      required: ["path"]
    }
  }]
}));

const transport = new StdioServerTransport();
await server.connect(transport);
// Now Cursor and Claude Desktop can discover and use this tool automatically

Why the Confusion Exists

Marketing framed MCP as a "universal protocol for AI tools" — which sounds like it should be used everywhere. In reality, it is a communication layer between an AI client and a tool server, not a framework for writing agent logic. Once you internalize that distinction, everything clicks.

The Decision Rule

✅ Building a tool for Cursor, Claude Desktop, or another GUI client? → Use MCP
✅ Serving documentation or static context to an LLM? → Use MCP
❌ Writing agent pipeline code with tool calls? → Use native function calling
❌ Building an API that an agent talks to directly? → Use REST/HTTP, not MCP

MCP is a well-designed protocol. Use it for what it was designed for.

This article was originally published on NextFuture. Follow us for more frontend & AI engineering content.

DEV Community