What makes MCP different from the REST API

Warning

This feature is only available in Visual Studio Code.

REST API and the Model Context Protocol (MCP) cannot be meaningfully compared: they operate at different levels of abstraction and serve fundamentally different purposes in AI systems.

Architectural differences

Characteristic MCP REST API
State management Stateful: Maintains context across interactions. Stateless: Each request is independent.
Connection type Persistent, bidirectional connections. One-way request-response.
Communication style Based on JSON-RPC with active sessions. Based on HTTP with discrete requests.
Context handling Context is built into the protocol. Context must be managed manually.
Tool discovery Available tools are discovered at runtime. Integration is design-time, requiring prior knowledge.
Approach to integration Runtime integration with dynamic capabilities. Design-time integration requiring code changes.

Different levels, different purposes

In the technology stack, REST API and MCP serve distinct layers:

  • REST is a low-level web communication pattern used for operations on resources.
  • MCP is a high-level AI protocol that orchestrates tool usage and maintains contextual awareness.

MCP often uses REST APIs internally, but in an AI-abstracted way. Think of MCP as middleware that transforms discrete web systems into a single environment to facilitate AI operation.

Context persistence

MCP's stateful design solves a key limitation of REST in AI apps:

  • REST: Each call is isolated; context must be explicitly provided with each new step.
  • MCP: Single context persists across multiple tool invocations.

For example, AI debugging a codebase can open a file, run tests, and identify errors, all while retaining prior context. An MCP session maintains awareness of previous actions and their results.

Dynamic tool discovery

MCP enables AI agents to discover and use tools at runtime:

// AI discovers available tools
{
  "tools": [
    {
      "name": "readFile",
      "description": "Reads file contents",
      "parameters": {
        "path": { "type": "string", "description": "File path" }
      }
    },
    {
      "name": "createTicket",
      "description": "Creates a ticket in the issue-tracking system",
      "parameters": {
        "title": { "type": "string" },
        "description": { "type": "string" }
      }
    }
  ]
}

With this capability, you add new tools without redeploying or modifying the AI itself.

Example: Multi-service workflow

Consider a task that involves multiple services: Check the latest commits, create a JIRA ticket to fix the bug, and post it in Slack.

REST-based approach:

  • Requires separate integrations with Git, JIRA, and Slack APIs.
  • Relies on custom code to manage context between API calls.
  • Fails if a service changes its API.

MCP-based approach:

  • Uses a single, unified protocol for all tools.
  • Maintains context throughout your entire workflow.
  • Allows you to add new tools without any code changes.

Why Code Assistant uses MCP

Code Assistant leverages MCP to deliver:

  • Expandability: you add unlimited custom tools without waiting for official integrations.
  • Context awareness: your tools can access conversation history and project context.
  • Simplified integration: one standard protocol instead of dozens of disparate API patterns.
  • Runtime flexibility: discover and explore new capabilities on the fly.

MCP acts as a universal connector between Code Assistant and external services, which often rely on REST APIs under the hood.

MCP does not replace REST API; rather, it builds on top of REST APIs.

REST is best suited for exposing discrete, stateless solutions, whereas MCP excels at orchestrating them for AI agents.

The key distinction is that MCP is AI-native: it treats your AI model as a real user, providing the contextual, stateful interaction layer that AI agents need to operate effectively in complex, real-world environments.