A RESTful HTTP Mental Model to Understand MCP

The Model Context Protocol (MCP) is a specification designed to facilitate interaction between AI models, tools, and resources. I was wondering about an experiment where we could try to describe MCP in a way that is similar to the RESTful HTTP architecture to make MCP more understandable for those coming from web development.

A Reference MCP Server

To put our methodology and HTTP’s RESTful mental model into play we’ll imagine a real-world use-case of an MCP Server.

Our reference MCP Server will be a “Travel Planner” that helps users plan trips by providing information about destinations, accommodations, and activities. The MCP Server will allow booking flights or hotels and cancelling reservations.

Here is a quick high-level code implementation in JavaScript of the MCP Server using Anthropic’s official @modelcontextprotocol/sdk package:

import { MCPServer } from '@modelcontextprotocol/sdk';

// Tool for searching flights
const searchFlightsTool = {
  name: 'searchFlights',
  description: 'Search for available flights based on destination and dates.',
  parameters: {
    destination: { type: 'string', description: 'Destination city or airport code' },
    departureDate: { type: 'string', description: 'Departure date in YYYY-MM-DD format' },
    returnDate: { type: 'string', description: 'Return date in YYYY-MM-DD format' },
  },
  execute: async (params) => {
    // Mock implementation of flight search
    return [
      { flightNumber: 'FL123', airline: 'AirExample', price: 300 },
      { flightNumber: 'FL456', airline: 'FlySample', price: 350 },
    ];
  },
};

// Tool for cancelling bookings
const cancelBookingTool = {
  name: 'cancelBooking',
  description: 'Cancel an existing booking using the booking ID.',
  parameters: {
    bookingId: { type: 'string', description: 'The ID of the booking to cancel' },
  },
  execute: async (params) => {
    // Mock implementation of booking cancellation
    return { success: true, message: `Booking ${params.bookingId} has been cancelled.` };
  },
};

Understanding MCP through RESTful HTTP

To better understand MCP, we can draw parallels to the well-known RESTful HTTP architecture, which is widely used in web development.

Quick reminder on the building blocks of RESTful HTTP:

• HTTP Methods drive actions (GET, POST, PUT, DELETE)
• Resources are the entities being acted upon (e.g., users, posts)
• Status Codes indicate the result of the action (e.g., 200 OK, 404 Not Found)
• Endpoints are the URLs where resources can be accessed (e.g., /api/users)

If we map the above RESTful concepts to MCP, we can see the following correspondences:

• HTTP Methods -map-to-> Tools (e.g., searchFlights, cancelBooking): meaning, what would be a DELETE HTTP method in RESTful would be a cancelBooking tool in MCP. A GET HTTP method would be a searchFlights tool in MCP.
• Resources -map-to-> business resources in an MCP Server (e.g., ‘flights’, ‘bookings’).
• Status Codes -map-to-> Tool Responses (e.g., success, or ‘not found’ responses).
• Endpoints -map-to-> MCP Server Resources (e.g., `flights://deals’, ‘bookings://{id}’).

As you can see, some of the concepts translate quite well between RESTful HTTP and MCP, with a strong correlation like Endpoints and MCP Server Resources, others, not so much.

Of course, keeping in mind that the underlying Model Context Protocol specification relies on a JSON-RPC 2.0 transport layer, which is maybe more akin to GraphQL than RESTful HTTP.

Applying MVC (Model-View-Controller Paradigm) to MCP

What if we also try to apply the MVC (Model-View-Controller) paradigm to MCP? How would that look?

An break-down of MVC architecture consists of:

• Model: Manages the data and business logic.
• View: Handles the display and user interface.
• Controller: Manages user input and interactions.

This is a classic software design pattern used for developing user interfaces that divides the related program logic into three interconnected elements and has dominated early-age web development until it was superseded by other paradigms like MVVM (known mostly for Single Page Applications (SPA) frameworks like Angular, React, Vue, etc.).

So if we try to map the MVC components to MCP, we could see something like this:

M - Services
V - Tool Response
C - Tools

    Model                 View                  Controller
      |                     |                      |
Business Logic        Tool Response        Tools or Resources  

With MCP-UI emerging in recent months, potentially the View component could be represented by the MCP-UI, which provides a user interface for interacting with the MCP Server. Would it make a better fit? Time will tell.

MVC likely makes a better paradigm for capturing a mental model of how MCP Servers are architected, however, I’ve only just scratched the surface here with just tools and resources, where-as MCP Servers have other capabilities like Prompts. Moreso, there’s also another player in the mix which is the MCP Client and capabilities more directly related to it like Elicitations and Sampling.

Conclusion

I find it an interesting exercise to explore the analogy of MCP with other prior technical concepts like REST and MVC and even when those don’t map perfectly, there’s hopefully a nugget to be found in the exercise and learn something new.

Keep on MCPing.