MW
Comparison 14 min read

MCP vs REST API (and more)

MCP is not a replacement for REST or GraphQL — it is a new layer purpose-built for AI agents. Here is how each approach fits WordPress, when to combine them, and what to ship first.

MCP REST API GraphQL Architecture AI Agents WordPress
Auto-cycle
MCP — a typed protocol agents discover instead of hard-coding endpoints.

Click a node to compare

1. Quick comparison

At a glance: MCP is the agent-native protocol; REST and GraphQL are general-purpose APIs you already know; custom integrations are the escape hatch when nothing standard fits.

Aspect Recommended MCP REST API GraphQL Custom
Purpose AI-native protocol layer General HTTP resource API Flexible query API One-off bespoke glue
Architecture Client ↔ MCP server ↔ WordPress App ↔ REST routes ↔ WordPress Client ↔ GraphQL ↔ WP Custom scripts / plugins
Data fetching Tools + resources + prompts Fixed endpoints per resource Client shapes the query Whatever you code
AI-native Built for agents Adapted via prompts Adapted via schema Fully manual
Schema / typing Capability negotiation OpenAPI / ad hoc Strong schema None unless you add it
Auth model Per-client + scoped tools App passwords / OAuth Token + field rules Varies wildly
Best for Agent workflows CRUD integrations Flexible UIs Legacy one-offs

2. Architecture overview

Each stack shows who talks to whom. MCP inserts a dedicated server between the agent and WordPress; REST and GraphQL expose WordPress data through HTTP; custom code skips the shared contract entirely.

Recommended
MCP

AI Agent

Claude, Cursor, ChatGPT

MCP Protocol

JSON-RPC transport

WordPress

Posts, users, settings

REST API

App / Client

Mobile, SaaS, script

REST Endpoints

/wp-json/wp/v2/...

WordPress

Core data layer

GraphQL

Client App

React, mobile, agent

GraphQL Layer

Single endpoint

WordPress

Resolvers → data

Custom

Integrator

Your team / agency

Custom Code

PHP, cron, webhooks

WordPress

Direct DB / hooks

3. How requests & responses work

The request lifecycle differs more than the transport name suggests. MCP emphasizes capability discovery and typed tool calls; REST emphasizes resource URLs; GraphQL emphasizes shaped queries.

Recommended
MCP
1

Client opens session and negotiates capabilities.

2

Agent discovers tools, resources, and prompts.

3

Model picks a tool with structured arguments.

4

Server executes on WordPress and returns typed JSON.

Stateful, context-rich, AI-first

REST API
1

Client builds HTTP request to a known route.

2

WordPress authenticates and routes to controller.

3

Core returns JSON for posts, users, or meta.

4

Client parses response and continues workflow.

Stateless, resource-oriented, mature

GraphQL
1

Client sends one query with selected fields.

2

GraphQL validates against schema.

3

Resolvers fetch only requested data.

4

Nested response returned in one round trip.

Flexible queries, fewer round trips

Custom
1

Developer writes integration logic by hand.

2

Calls WP functions, SQL, or remote APIs.

3

Formats output for the consumer.

4

Every new client may need new code.

Maximum control, least reuse

4. When to use what?

Most WordPress products will run REST (or GraphQL) for humans and apps, and add MCP when AI agents need the same backend with a discoverable, auditable tool surface.

Recommended
MCP

AI agents that need tools + context

Multi-client support (Claude, Cursor, ChatGPT)

Typed, discoverable capabilities

Long-running agent workflows

REST API

Mobile apps and headless frontends

CRUD on posts, users, media

Well-documented public APIs

Integrations that predate agents

GraphQL

Complex UIs with nested data

Minimizing over-fetching

Apps that own the query shape

Teams already on WPGraphQL

Custom

Legacy one-off automations

Highly specialized business rules

When no standard API fits

Short-lived internal scripts

MCP complements, not replaces

REST and GraphQL stay the backbone for apps and headless sites.

MCP adds the agent-native layer WordPress has been missing.

  • AI-native
  • Context aware
  • Extensible
  • Future ready