Why MCPs are not the Silver Bullet for Product Integrations

MCPs (Model Context Protocol) have taken the AI development community by storm, and for good reason. The MCP establishes a standard way to give AI applications context in the form of tools, prompts, and other resources. Despite the short amount of time since Anthropic’s MCP announcement, the AI development community has gotten to work and are rapidly developing MCP servers that cover a variety of use cases, such as navigating your local file system, querying databases, and interacting with 3rd-party platforms like Slack and Google Drive.

The last point - interacting with 3rd-party platforms - has raised the question of if integrations platforms are still necessary as 3rd-party MCPs come out. However, there are many use cases MCPs currently don’t solve for out-of-the-box when it comes to AI product integrations for your B2B SaaS application. That’s why MCPs and integrations platforms like Paragon can be compliments, combining the benefits of a standard protocol with a standard method of developing integrations.

MCP built on top of Paragon’s Platform

To better understand how integration platforms can compliment MCPs, we built an MCP server powered by ActionKit - Paragon’s API to easily give agents access to 1000+ 3rd-party integration tools. Check out our MCP server starter repo and demo video.

Through the process of building this MCP server, we learned why and how MCP servers can work hand-in-hand with Paragon’s embedded integration platform, which we'll explore below.

MCP for 3rd-party Integrations

Before we go too much further, I want to briefly go over how MCPs work at a high level. Skip to the next section if you already feel comfortable with MCPs.

Similar to web applications, MCPs involve client and server applications. We have MCP clients within host applications like Claude Desktop, Cursor, and Windsurf that talk to MCP servers like Github’s MCP server.

The MCP server delivers the client/host application prompts, resources, tools, sampling, and other “context-specific” information so that your AI application can perform actions and perform better in that specific area.

The game-changer here is that the implementation for an MCP client connecting to an MCP server is standardized, meaning if you’re developing a client application that has different use cases like Github repo management or querying from Postgres, you can plug into the Github MCP server or the Postgres MCP server. This proposed standard from Anthropic has already seen a healthy amount of adoption with an extensive list of 3rd-party MCP servers.

For Product Integrations:

Back to the topic of integrations. After looking at the list of 3rd-party MCP servers, a natural question arises: can we use MCPs for all of our product integrations?

The answer: yes for local implementations; but for a rich set of integration features expected in B2B SaaS products, not quite.

A closer look at how these 3rd-party MCP servers work reveals that they can be incredibly useful to use on your own local MCP clients (i.e. your own local instance of Claude Desktop, Cursor, Windsurf, etc.), however they were not built with multi-tenant SaaS applications needs in mind.

Let’s look at a few examples. Starting with the Gmail MCP server, we can see that the installation instructions include having your OAuth keys stored locally.

For Slack, we see a similar example where client users are expected to provide their own tokens and IDs.

In short, most MCPs weren’t built to productize multi-tenant B2B applications' ability to interact with 3rd-party platforms on behalf of users natively. Rather, these MCP servers were designed to be set up and used by end-users of MCP host applications like Claude or Cursor.

A broader limitation of exclusively using MCPs for integrations is that they’re inherently built for LLM and AI agent applications, not for all the other features that a native product integration entails. For example, your SaaS application may need:

• To trigger agent workflows when a webhook is triggered in an integrated 3rd-party app (without prompting)

• Configurations that are better served via a standard UI (toggles, dropdowns, etc.) rather than chat

• 3rd-party actions that aren’t triggered via an AI tool call (clicking a button triggers a 3rd-party API call)

Paragon for 3rd-party Integrations

If you don’t know too much about Paragon yet, Paragon is an embedded integrations platform that makes it easy for product and engineering teams to scale their B2B applications' native integrations quickly. Paragon standardizes the way integrations are built and how your end users experience integrations.

1. For your end user experience, the SDK provides an embedded UI component (Connect Portal) for end-users to auth into any integration directly within your SaaS application.

1. For your developers, Paragon standardizes integrations development by providing two purpose-built products for all your use cases:

   1. Workflows for heavy workload asynchronous jobs such as data ingestion for RAG

      

   2. ActionKit for responsive synchronous 3rd-party requests such as AI agent tool calls, fetching data for UI components, and triggering CRUD requests in your product

const response = await fetch("https://actionkit.useparagon.com/projects/" +
									process.env.NEXT_PUBLIC_PARAGON_PROJECT_ID + "/actions", {
    method: "POST",
    headers: { "Content-Type": "application/json", "Authorization": "Bearer " + sessionStorage.getItem("jwt") },
    body: JSON.stringify({ action: 'NOTION_SEARCH_PAGES', parameters: {} })
  });

Paragon’s integration platform was built to support both AI and non-AI use cases, as we see a need for both AI specific solutions as well as non-AI features - automation, workflow, analytics, etc. - from our SaaS customers. For more information on popular Paragon use cases, browse our use case library and reference our synchronicity use case guide.

MCPs Built on Top of Paragon

It’s clear that MCPs and integration platforms aren’t direct alternatives to one another. And in fact, they can be complimentary tools.

When using an integration platform like Paragon, much of your application’s integration logic will be embedded in your code (such as calls to ActionKit for UI or API endpoints that interact with Paragon Workflows). However for AI agent tool calls, ActionKit can be used directly by your agent (directly in the Langchain framework or Vercel's AI SDK) or within an MCP.

Building an MCP with Paragon’s ActionKit, allows your team to take advantage of the benefits of MCP:

• Portability across server implementations

• Model & framework agnostic

While reaping the benefits of Paragon’s embedded integrations:

• Managed auth for your users (important for multi-tenant applications)

• Support across 100+ integration providers

• Different solutions for high workload jobs like RAG data ingestion using Workflows and quick-hitting low latency requests using ActionKit

  • Can be used throughout your application, not just within an AI use case

Paragon ultimately covers many of the shortcomings of MCP for B2B AI applications, across integration coverage, the ability to support ingestion/sync use cases, as well as the multi-tenant, embedded auth experience. Explore our MCP server starter repo to start exploring how a MCP server powered by Paragon can work for your AI application!

Wrapping Up

It’s exciting that MCP servers are setting a standard for how AI applications are built. Where Paragon comes in is standardizing integrations development across many of the nuances and use cases that MCP doesn’t cover. Paragon was thoughtfully built to support AI SaaS products and use cases, and Paragon’s solutions can be used in tandem with AI technologies - tool calling standards, agent frameworks, and of course MCPs.

If you’re interested in learning more about building integrations with Paragon, reach out to our team to schedule a demo.