ALPS and MCP: Dialogue with AI Created by REST Constraints

+

Introduction

REST (REpresentational State Transfer) was defined by Roy Fielding in 2000 as an architectural style for distributed systems, and has since been widely adopted as a standard approach for Web API design. The essence of REST lies in resource-oriented architecture, self-descriptive messages, representation of state transitions through hypermedia, and a unified interface.

Application-Level Profile Semantics (ALPS) is a profile description format for defining the semantics (meaning) of REST APIs. ALPS promotes understanding and use of APIs by clearly defining the meaning of resources and their operations. It provides contextual information about “what” an API represents and “how” it can be operated.

Meanwhile, agents with natural‑language interfaces—such as large language models (LLMs)—have become increasingly common and now interact directly with applications. Against this backdrop, REST principles and semantic definitions through ALPS effectively function as a structure for understanding and operating APIs in context.

This article examines what kind of dialogue model can be constructed between LLMs and REST resources by combining ALPS and Model Context Protocol (MCP).

Client Evolution and MCP

Traditional web application design assumed “humans” (web browsers, mobile apps) and “machines” (API clients) as the main clients. However, with the emergence of LLMs, “AI” must now be included in the design as a new client. AI clients interact with applications through natural language and invoke functions, requiring structured interfaces and clear context provision.

Model Context Protocol (MCP) has been introduced to address this requirement. MCP is a protocol for providing application functionality in a format that LLMs can understand and operate, and it has high affinity with REST design principles.

Client Evolution:
├── Human (Web UI, mobile apps)
├── Machine (API clients)
└── AI (LLM + MCP)

By combining semantic definitions through ALPS and MCP, a single resource design can accommodate three types of clients. This provides the following benefits:

• Avoiding duplicate adapter implementations: No need for separate processing branches or data formatting for each client type (Web, API, AI).
• Interface consistency: Unified access through HTTP methods and URIs makes it easier to standardize specifications and test cases.
• Commonality in testing and operations: Common unit tests and monitoring settings can be applied to the same resource design, reducing operational costs.

Resource Design and Affordance

Resources based on REST are designed with a unified interface based on HTTP methods, enabling the provision of similar logic to all clients. The hypermedia constraint, in particular, is an important feature that allows resources to present their affordances (possible operations).

{
  "id": "order-123",
  "status": "shipped",
  "total": 5000,
  "items": [ ... ],
  "_links": {
    "self": { "href": "/orders/123" },
    "doPayment": { "href": "/payments?order_id=123" },
    "doCancel": { "href": "/cancellations?order_id=123" },
    "doTracking": { "href": "/tracking?order_id=123" }
  }
}

By including link relations (_links), the state transitions (affordances) provided by the resource can be explicitly shown. For LLMs, this serves as an indicator of “next possible actions,” enabling natural suggestions in dialogues with users.

For example, by providing the above resource to an LLM through MCP, the LLM can generate utterances such as:

• If status is “shipped”: “Would you like to check the shipping status?”
• If “pending”: “Would you like to complete your payment?”
• If “processing”: “Would you like to cancel your order?”

This becomes a strength when utilizing AI as an agent. While traditional “JSON APIs” simply conclude with receiving data, hypermedia APIs using MCP create dialogue that “receives meaning and prompts the next action.”

Differences in Dialogue Created by REST Constraints: OpenAPI Comparative Analysis

Fundamental Difference in Design Philosophy

While OpenAPI specifications pursue accuracy as a “contract,” the ALPS+MCP approach aims for “conversation.” This is not just a technical difference but can be seen as a worldview distinction in how AI is perceived.

In OpenAPI-based systems, AI responds within the range of specifications it has remembered in advance. On the other hand, resources with integrated MCP act as a living grammar that communicates to AI “what can be done in this context right now” by continuously presenting possible operations as links.

Unified interface reduces the learning load for AI, hypermedia naturally guides the flow of conversation, and self-descriptiveness ensures context at each state.

If OpenAPI is a city map, REST-based MCP is like a friendly signpost at every street corner. MCP can be thought of as a guidebook for the traveler (LLM) reading these signs. It guides users and creates a structure where it’s difficult to get lost.

Potential as an AI Agent

By combining resource affordances and semantics through ALPS, LLMs gain functionality as agents beyond mere information retrieval or operation execution.

As agents, LLMs can understand user intentions and select/execute actions appropriate to the current situation. For example, after checking order information, they can naturally suggest the next steps (payment, cancellation, shipment tracking, etc.) according to its status. This is not just an API call but the realization of goal-oriented dialogue.

While data stops conversation, meaning continues it. This is precisely an example of how REST design’s essence—providing affordances and changing application and resource states by selecting them—is utilized in the new field of dialogue with AI.

Affinity with A2A (Application‑to‑Application AI)

A2A (Application‑to‑Application AI), announced by Google in April 2025, is a new protocol that enables applications to communicate directly with each other via AI. Whereas ALPS + MCP provides an approach for “bridging semantics,” A2A takes this a step further by enabling “real‑time interaction between applications.”

Going forward, combining MCP’s hypermedia‑based guidelines with A2A’s bidirectional interoperability will enable more autonomous and seamless collaboration among AI agents.

From Data to Meaning: Semantic Definition with ALPS

ALPS is a standardized profile description format for defining API semantics (meaning), proposed by Mike Amundsen and others in 2013. It is not a data exchange format itself but meta-information describing the semantic structure of APIs, emerging as a response to the long-standing challenge of the “semantic interface” of REST APIs.

Clarifying the relationship between ALPS and MCP, “ALPS is a ‘dictionary’ that describes the meaning of APIs, and MCP is the ‘conversation rules’ for dialoguing with LLMs using that dictionary.”

The main values provided by ALPS are as follows:

1. Establishing a semantic layer - Separating the technical implementation and semantic structure of APIs, clearly defining domain-specific vocabulary and operations
2. Explicit nature of operations - Communicating the essential nature of operations such as safe (read-only), idempotent (same result regardless of how many times executed), unsafe (state changing)
3. Ensuring semantic consistency - Promoting consistent understanding by using common vocabulary across multiple APIs and versions
4. Machine-readable documentation - Describing the meaning of APIs in a format understandable not only by humans but also by machines (including LLMs)

With ALPS, REST APIs evolve beyond mere data exchange interfaces into dialogues with meaning and context. For LLMs, this semantic layer serves as a bridge to understand and operate API functionality from natural language.

For detailed specifications and implementation examples, refer to the ALPS-ASD site and RFC6906 Profile specification.

Affinity Between REST Abstraction and LLMs

The abstract constraints of REST (resource orientation, hypermedia, self-descriptive messages, unified interface) are also extremely effective for stateless, context-dependent clients like LLMs. These principles transform APIs into structures that are “easy to learn” and “easy to operate” for LLMs.

• Resource orientation: LLMs can understand operation targets as entities
• Hypermedia: Possible operations are presented as links, guiding dialogue
• Self-descriptive messages: Include all information necessary for exchanges within the message
• Unified interface: Learned patterns can be applied to any resource

Thus, REST abstraction can be evaluated as a design that naturally accommodates unanticipated users (LLMs).

Implications for the Future: The Power of Constraints and the Future of APIs

The combination of ALPS and MCP is a new framework that integrates REST’s abstract design power with AI’s interactive API operations. Without special extensions, REST principles and semantic definitions through ALPS already possess the elements necessary for context understanding and intention inference by LLMs.

Self-descriptiveness and navigation through hypermedia were originally designed for scalable, loosely coupled distributed systems, but they can be considered notable characteristics from the perspective of operability by AI as well.

What the combination of ALPS and MCP demonstrates is that the true value of technical standards lies not in solving specific problems but in providing a “thinking framework” that can address unknown problems. REST in 2000, ALPS in 2013, and MCP in the modern era of 2025 form a chain of design thinking that transcends time.

“Good constraints have already solved problems we haven’t yet encountered” — The history of REST and ALPS embodies this statement. The REST principles designed in 2000 and ALPS that defines its semantics possess universal value that can naturally address challenges such as dialogue with LLMs, which did not even exist at the time.

Story

To help you grasp the technical concepts in this article, we’ve prepared a concept story: “2030: The Age of Meaning”. Please give it a read.