Every developer building AI agents hits this question: should my agent talk to services through MCP servers, or just call REST APIs directly?

They solve different problems at different layers. Picking wrong costs you time and flexibility. Here is how to think about it clearly.

What REST Gives You

REST is the backbone of the web. Your agent can call any REST API with an HTTP client, an endpoint, and auth headers. Millions of APIs exist. Documentation is everywhere. Every language has mature tooling.

REST works well for agents when:

  • You are calling a single, well-documented API with a stable schema
  • The interaction is request/response with no ongoing context
  • You control the integration and can handle auth, pagination, and error codes yourself
  • The service does not need to know anything about your agent’s current state

A weather lookup, a database query, a payment charge. Clean REST calls. The agent knows what it wants, asks for it, gets a response.

What MCP Gives You

MCP was designed specifically for AI agents. Instead of your agent needing to understand every API schema in advance, an MCP server advertises its own capabilities. The agent discovers what tools are available, what parameters they accept, and what resources the server exposes through a standard protocol.

This means:

  • Discovery is built in. The agent does not need hardcoded knowledge of every service endpoint. It asks the server what it can do and gets a structured answer.
  • Context flows both ways. MCP supports resources (data the server provides for context), tools (actions the agent can invoke), and prompts (templated interactions). REST only gives you endpoints.
  • Transport is flexible. MCP works over stdio for local tools, HTTP for remote services, and SSE for streaming. You are not locked into HTTP request/response patterns.
  • Composability is native. An agent can connect to multiple MCP servers simultaneously. Each server is a self-contained capability module. Adding a new tool to your agent means connecting another server, not writing another API integration.

The Real Difference: Who Understands Whom

With REST, your agent must understand the service. You write the integration code. You parse the response format. You handle auth flows. You map parameters. The agent is doing translation work.

With MCP, the service understands agents. The MCP server exposes structured tool definitions that any MCP-compatible host can invoke without custom integration. The server is meeting the agent on its terms.

This is not a philosophical distinction. It has real consequences for how fast you can add capabilities to an agent system.

When MCP Wins

You are building a multi-tool agent. If your agent needs 5, 10, or 20 different services, MCP lets you compose capabilities without writing separate integrations for each. Each MCP server is self-describing, so the agent can work with tools it has never seen before.

You want runtime discovery. An agent connected to AgentNDX can search for MCP servers by category, find one that fits its task, and use it without developer intervention. That kind of runtime discovery is impossible with static REST integrations.

Local tool access matters. Tools like Playwright MCP and filesystem servers run as local processes via stdio. No network call, no latency, no API key. The agent spawns the server and talks to it through pipes. REST cannot do this.

You are building for multiple agent hosts. If your tool should work with Claude Desktop, Claude Code, Cursor, and other MCP-compatible hosts, building an MCP server means you write the integration once. Every host speaks the same protocol. With REST, each host would need its own wrapper.

Streaming and long-running operations. MCP over SSE supports server-sent events natively. If your tool needs to push updates as work progresses, MCP handles this cleanly. REST requires webhooks or polling.

When REST Wins

You are calling one API for one task. If your agent just needs to hit the Stripe API to charge a card, writing a full MCP server around that is overengineering. Call the API directly, handle the response, move on.

The API is well-documented and stable. When OpenAPI specs exist and the schema rarely changes, the discovery benefits of MCP add little value. Your integration code is already written.

Non-agent consumers need the same service. If your backend serves both agents and web frontends, REST is the shared language. You might add an MCP layer for agent-specific access, but REST remains the foundation.

Performance is critical. REST gives you full control over connection pooling, caching, retry logic, and request batching. MCP adds a protocol layer that may introduce overhead for high-throughput, latency-sensitive paths.

Auth is already solved. If you have OAuth flows and rate limiting working for a REST API, wrapping it in MCP means re-implementing that auth layer. Sometimes the simpler path is the right one.

The Hybrid Pattern

Most production agent systems use both:

  1. MCP for tool composition. The agent connects to MCP servers for capabilities it discovers and invokes through the standard protocol. Browser automation (Playwright MCP), web scraping (Firecrawl MCP), file operations, database queries.

  2. REST for point-to-point integrations. Payment processing, CRM writes, notification dispatch. These are direct calls where MCP’s discovery overhead adds nothing.

  3. MCP wrapping REST. Many MCP servers are thin wrappers around REST APIs. The GitHub MCP server calls GitHub’s REST API internally but exposes capabilities as structured MCP tools. Discovery and composability without abandoning existing APIs.

Use the protocol that matches the interaction pattern.

Decision Framework

Ask these questions in order:

  1. Does a well-maintained MCP server already exist for this service? If yes, use it. The integration work is already done. Check the AgentNDX directory to search by use case.

  2. Will multiple agent hosts need this capability? If yes, build or use an MCP server. Write once, work everywhere.

  3. Is this a one-off, stable API call? If yes, REST is simpler. Do not over-abstract.

  4. Does the agent need to discover capabilities at runtime? If yes, MCP is the only protocol designed for this.

  5. Is this a local tool (filesystem, browser, database)? If yes, MCP over stdio is purpose-built for this. REST requires running an HTTP server for no reason.

FAQ

Q: Can I migrate from REST to MCP incrementally? A: Yes. The most common pattern is wrapping existing REST APIs in MCP servers. Your backend does not change. You add an MCP layer that agent hosts can discover and call. Both access paths coexist. The Stripe MCP server is a good example of this approach.

Q: Is MCP replacing REST? A: No. MCP is a protocol for agent-to-tool communication specifically. REST remains the standard for service-to-service and client-to-server communication. MCP often runs on top of REST or alongside it.

Q: What about GraphQL or gRPC? A: Same logic applies. GraphQL and gRPC are transport/query protocols. MCP is an agent capability protocol. They operate at different layers. An MCP server can use GraphQL internally to fetch data, then expose that data as structured tools and resources to agents.