What is MCP (Model Context Protocol)?

MCP is an open standard that lets AI applications connect to external tools and data through one protocol instead of custom integrations. Introduced by Anthropic in November 2024 and an industry standard within a year, it does for AI agents roughly what a common port did for peripherals — the “USB-C for AI” line every explainer reaches for. The sharper framing for a backend developer: an MCP server is an API adapter. Your existing backend already knows how to answer requests; MCP is how you make it discoverable and callable by an AI model rather than by hand-written client code.

Key takeaways

An MCP server wrapping a backend you already have

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.tool('query_tasks', { status: z.string() }, async ({ status }) => {
  const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
    headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
  });
  return { content: [{ type: 'text', text: await res.text() }] };
});
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

The JavaScript tab is the whole idea in fifteen lines: a query_tasks tool is a described, discoverable wrapper over a REST call the backend already serves. The agent reads the description at runtime, decides when the tool fits, and calls it — hitting the same endpoints, ACLs, and rate limits your app hits. A new kind of client, not a new backend.

How MCP Solves the N×M Integration Problem

Before MCP, wiring N AI clients to M tools meant up to N × M bespoke integrations. A shared protocol collapses that to N + M: each client and each server implements MCP once. The official architecture names three roles — the host is the AI application; it spawns one client per connection; each server provides capability — over JSON-RPC, with stdio for local same-machine servers and Streamable HTTP for remote ones (the original HTTP+SSE transport is now deprecated).

The three primitives

A single database server typically exposes all three: a query tool, a schema resource, and a few-shot prompt for common asks — “here is what I can do, what I know, and how to ask me.”

MCP vs. API vs. function calling

The two comparisons resolve cleanly. Versus an API: MCP doesn’t replace it — it wraps it, adding runtime discovery so the model chooses the call instead of your application code. Versus function calling: function calling is the model emitting a structured request; MCP standardizes how that request is discovered and executed across apps and providers. MCP adds standardization and portability, not capability — anything MCP does, bespoke function calling could do for one integration; MCP makes it work everywhere without rewriting.

The security surface, honestly

The section the neutral pages skip and the security vendors over-sell. The protocol is not the threat; the trust model is. Prompt injection rides in through tool outputs — a document a tool returns can contain instructions the model then follows. Tool poisoning hides malicious instructions in a tool’s description, which the model reads before any human sees it — now catalogued in OWASP. Rug pulls: a server approved once can change its tool definitions later. And the quiet one: the supply chain of community servers — thousands exist, and installing one grants it a foothold in your agent’s context. The mitigations are ordinary security discipline applied to a new surface: least-privilege scopes per server, human-in-the-loop approval for tool calls that act, pinning and allow-listing the servers you trust, real auth on remote servers, and never handing an MCP server broader credentials than the task needs.

The spec today

MCP moves fast, and most explainers froze in mid-2025 — a freshness note worth keeping current. The transport consolidated on Streamable HTTP (HTTP+SSE deprecated); remote servers standardized on OAuth-style auth; recent spec revisions moved toward a stateless protocol with per-request metadata and server-side capability discovery, and deprecated a couple of early client features. Governance is the bigger signal: at the end of 2025 the protocol was donated to a vendor-neutral open-source foundation — the structural marker of a real standard rather than one vendor’s convention. The practical takeaway for a builder: pin to a spec version, read the changelog before upgrading, and treat “MCP” as a moving target with a stable core.

Common use cases

• Coding agents — IDE assistants reaching your repo, database, and issue tracker through servers instead of bespoke plugins.
• Enterprise data chat — an assistant querying internal systems, each wrapped as a permissioned MCP server.
• Backend exposure — turning an existing REST/GraphQL API into agent-callable tools without rebuilding it.
• Desktop and workflow automation — local stdio servers bridging the model to files and applications on one machine.
• Multi-provider portability — one server serving every host that speaks MCP, so an integration outlives any single model choice.

Should you use MCP? A decision matrix

Limitations and trade-offs

• It’s a moving standard. Fast spec evolution means integrations need version pinning and changelog vigilance; “supports MCP” is a dated claim.
• The trust model is new. Tool descriptions and outputs are attack surface; agents acting on unvetted servers is the current era’s curl \| bash.
• Overhead below the crossover. For a single integration, MCP adds a protocol and a server process where a function call would do.
• Discovery shifts control to the model. Runtime tool selection is powerful and less predictable than hardcoded calls — auditing and approval matter more, not less.
• It wraps, it doesn’t fix. An MCP server over a badly-secured API exposes that API to agents faster; the underlying permissions still do the real work.

MCP and Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The API-adapter framing lands naturally here: a Back4app app already exposes the surface an MCP server wraps — REST and GraphQL over every class, plus Cloud Code functions — so making it agent-accessible is a matter of mapping find objects, run function, and read schema to tool definitions, as the code tabs sketch. The security section becomes concrete guidance: give the MCP server a scoped key, never the master key; let the platform’s ACLs and class-level permissions constrain what an agent’s calls can touch, exactly as they constrain your app’s; and put irreversible actions behind Cloud Functions with their own checks rather than raw table access. The agent becomes one more client of a backend that already knows how to say no.