Should you build MCPs before APIs?

In 2025, AI agent compatibility is table stakes, irrespective of what you're building. And the tech giants are toeing the MCP line to support AI agents. What was once an experimental idea is quickly becoming the default for enterprise platforms.

Major dev tool and SaaS companies are on board: for example, Atlassian launched a remote MCP for Jira/Confluence to let Claude summarize and create issues securely (Cloudflare blog).

Stripe built an "agent toolkit" and hinted that MCP could become the default way services are accessed in the near future.

Cloudflare's platform alone has seen over 10 leading companies deploy MCP servers to bring AI capabilities to their users.

That brings us to a practical question every modern engineering team faces today: Should you stick with traditional APIs, or dive straight into using the Model Context Protocol (MCP)?

Let's unpack this together.

Short primer on MCP

Think of MCP as a universal language designed specifically for AI agents (If you want a done-to-death comparison, it's the "USB-C" of the AI agent era). It helps AI agents easily connect with different tools and data sources. MCP emerged because traditional APIs (like REST) weren't built with AI agents in mind. They were made for humans who read documentation and write code to connect applications manually.

MCP flips this around. It's built for AI-first interactions, allowing agents to dynamically discover available tools, maintain conversations over multiple steps, and handle complex tasks efficiently.

Why consider MCP-first?

Built for AI from day one

Building MCP-first bakes in AI-readiness. Your service exposes its capabilities (functions, data, workflows) through MCP so that AI assistants can use them autonomously. This future-proofs your product in an era where users increasingly rely on AI agents to interact with software. MCP ensures your product is "visible" to AI by providing a standard interface for real-time inventory, content, or services.

Standardization and consistency

MCP provides a universal, self-describing interface that every AI agent can understand. With MCP, an AI client can query any MCP-compliant server to discover available functions, their inputs/outputs, and usage examples at runtime (via endpoints like ^tools/list). On the other hand, traditional APIs all have custom endpoints, auth schemes, and docs that developers (or fine-tuned models) must handle separately.

Faster integration with more tools

Instead of writing custom API wrappers or function calls for each model integration, you expose a single MCP interface that any compliant AI client (Anthropic Claude, OpenAI functions, open-source agents, etc.) can tap into. Rather than juggling multiple APIs with varying formats, MCP allows a standardized format that allows for faster development, without the quirks of each specific API.

The payoff is quicker integration, not just with one AI, but an entire ecosystem of agent tools and AI clients that speak MCP. This way, your team spends less time grinding out API connectors and more time on core product features.

Thriving MCP community

Going MCP-first aligns you with a surging industry momentum and community. Since Anthropic open-sourced the Model Context Protocol in late 2024, adoption has skyrocketed. (On a side note, check out our MCP market map here)

The open source community has been booming: MCP Market lists over 12,000 MCP servers; MCP.so has indexed over 16,000 MCP servers. In short, choosing MCP now means plugging into a rich and growing ecosystem of third-party libraries, forums, and partnerships. Developer communities on platforms like Discord and Reddit are actively buzzing with thousands of users.

Use cases for MCP-first

AI-native applications: If your product is inherently built around AI or agents performing tasks, MCP-first is a natural fit. These are tools designed from the ground up for AI-agent interaction rather than human-driven UIs.

Workflow automation and toolchains: Platforms whose value lies in chaining tasks across multiple tools or services should strongly consider MCP. MCP servers allow an AI agent to coordinate multiple tools in one continuous conversation, dynamically allowing it to determine what to use next.

Enterprise integration tools: Enterprise software that aims to connect and expose internal systems for AI consumption finds great strategic sense in MCP-first. Think of data integration hubs, API gateways, or internal developer platforms that large companies use. An enterprise integration server could use MCP to let an AI agent list available company data sources, fetch records, or trigger workflows, all while enforcing security centrally.

Devtools: Any product, like an API or service for developers, should weigh MCP-first, especially if those developers are building AI applications. By offering an MCP server, you give developers a plug-and-play way to incorporate your service in their AI/LLM workflows.

Why consider building APIs first?

Despite MCP's advantages, traditional APIs still make sense in several scenarios.

Mature and proven: APIs like REST have decades of development behind them, providing a highly stable, predictable environment. They are well-documented and have extensive support networks and communities.

Extensive tooling: The mature ecosystem around APIs offers sophisticated tools for security, monitoring, debugging, and scaling. Companies looking for reliable, battle-tested solutions may prefer traditional APIs.

Simpler integration needs: If your application primarily involves straightforward, predictable interactions, APIs offer quicker setup, easier maintenance, and lower upfront complexity.

API-first use cases

High-volume microservices: A financial services company relies on APIs to manage millions of daily transactions, benefiting from the straightforward scalability and robust performance of traditional REST APIs.

Compliance-heavy industries: EHR platforms (Electronic Health Records) like Epic and Cerner expose APIs via HL7 FHIR standards to ensure compliance with HIPAA and data security requirements.

Multi-platform e-commerce: Shopify's API-first approach enables merchants to sell across web, mobile, social media, and in-store channels from a single backend, with third-party developers building thousands of integrations that extend platform capabilities.

Global content delivery: Netflix uses APIs to orchestrate content streaming across dozens of countries, managing user preferences, content recommendations, and adaptive bitrate streaming while supporting multiple device types and regional content libraries.

Should you still build an API after building MCP?

In many cases, building APIs alongside MCP can be beneficial:

• Compatibility: APIs can ensure backward compatibility for existing customers and integrations.
• Redundancy: APIs provide a reliable fallback and support simpler interactions where MCP's advanced features aren't required.
• Flexibility: Having both MCP and API interfaces gives you more flexibility in how you expose functionality.

Case study 1: E‑commerce platform with an AI shopping assistant (MCP-first)

Challenge: ShopNow is a fictional mid-sized e-commerce platform that wants to offer shoppers an AI assistant for product recommendations and support. In early 2025, they noticed more consumers using AI chatbots to find products. The challenge was enabling an AI shopping assistant to query product catalogs, check inventory, answer policy questions, and even place orders, all without customers leaving the chat interface.

MCP-first decision: The team chose an MCP-first approach over a traditional API expansion. They already had REST APIs for their mobile app, but they realized an MCP server would make AI integration plug-and-play. By building an MCP layer, an AI assistant could dynamically discover ShopNow's "tools": e.g., ^{search_products}, ^{check_inventory}, ^{get_shipping_options}, ^place_order.

Implementation: The architecture they settled on placed the MCP server as a thin layer on top of microservices. It essentially acted as an orchestrator that mapped AI tool calls to internal API calls. For example, when the AI calls ^{search_products} with a query, the MCP server invokes the existing search API and returns results in the JSON format the AI expects. Importantly, they designed some multi-step tools for a better user experience. One tool, ^{find_and_discount}, would take a product query and user ID, then internally: search for the product, check the user's loyalty status via API, apply a discount if applicable, and return a personalized offer.

Results: Once deployed, ShopNow's MCP-first AI assistant was a hit. Users could ask things like "Find me a waterproof hiking jacket under $100 and available to ship today," and the agent would deliver precise recommendations, something that used to require manually filtering on the website.

Case study 2: Data analytics SaaS with hybrid interface (MCP development followed by API)

Challenge: DataInsights is building a SaaS analytics platform where users can run queries on their business data and create visualizations. They want to add an AI agent that can answer questions in natural language and generate charts, essentially a conversational BI assistant.

Hybrid approach: They chose a hybrid interface strategy: MCP for the AI assistant features, and traditional APIs for the rest of the platform. Rather than going all-in on MCP for every function, they identified which capabilities made sense to expose to an AI. They built an MCP server for the AI-facing tools. For the main web UI and third-party integrations, they built a REST API (which is more efficient for well-structured queries and bulk data).

Implementation: Under the hood, both the REST API and the MCP server funnel into the same business logic. For example, there's a core function to execute a SQL query and return results. The REST API exposes it as GET /query?sql=... for developers, while the MCP exposes it as a run_query tool that takes a query and dataset name for AI agents.

The MCP server was stateful in that it maintained the user's context (like which dataset they had currently selected, to allow the AI to omit that in follow-up questions). The web UI didn't need that because state is in the frontend, but for the AI agent, they used an MCP session to carry context between questions.

Performance impact: Purely on speed, the AI was slower and cost some compute. However, for more complex questions like "Compare this quarter's sales with the same quarter last year and explain the difference," the AI agent shone.

It automatically ran two queries, got the data, and produced a narrative and chart, something that would take a human much longer and maybe multiple tool usages. The team found that for single, simple queries, direct API calls were more efficient (and they continue to support those). But for multi-step analytical tasks, the MCP+AI combination drastically improved user productivity.

Decision matrix: When to build MCP vs API

Use this decision matrix to guide your choice:

• If your criteria align strongly with MCP-first, prioritize MCP.
• If they align with API-first, traditional APIs may be your best option.
• If your criteria span both columns, a hybrid approach could be ideal.

Final word

For a devtool startup wanting to attract developers and AI enthusiasts, MCP-first could be a key strategic differentiator (plus you might use your own product as an MCP use case). For an enterprise SaaS with many existing integrations, a cautious hybrid might make more sense initially, so you don't disrupt customers.

MCP-first development offers a compelling vision of software that's ready for the AI-centric world with dynamic discovery, standardized interactions, and agent-ready features built in.

‍