Model Context Protocol vs Web of Things

[RobWin]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Hello,

I’d like to open a discussion about the current path of the Model Context Protocol (MCP) and its proposed client/server architecture. While we all appreciate the effort and innovation behind MCP, I have concerns that we might be reinventing the wheel rather than building on existing, open standards.

The concept of MCP as a protocol for describing tools, resources, and prompts appears to be a subset of what the W3C Web of Things (WoT) architecture already is capable of. WoT has proven its value in other domains, such as IoT, where it has successfully addressed fragmentation by offering:

• Protocol-Agnostic Interoperability: WoT supports a wide range of communication protocols (e.g., HTTP, MQTT, CoAP) while remaining decoupled from the specifics of any single protocol.
• Thing Descriptions (TDs): WoT uses metadata-rich JSON-LD documents to describe "Things" (e.g., devices, services, resources, tools or agents). A TD defines properties, actions, and events, along with protocol-specific details (forms).
• Semantic Web Integration: WoT builds on existing web standards like JSON Schema, Linked Data, and Semantic Web standards, which ensures extensibility and machine-readable interoperability.

Why Reinventing May Be Counterproductive

Rather than creating a new protocol standard, I believe the community should evaluate whether the W3C WoT standards could be leveraged for MCP.

Benefits of WoT for AI/LLM

WoT can already achieve many of the goals outlined for MCP:

• Protocol Flexibility:

  • Switch between HTTP, MQTT, or AMQP without rewriting the application logic.
  • Change from JSON to CBOR or other media types seamlessly.
  • Support both synchronous and asynchronous communication.

• Cross-Domain Compatibility:
  WoT is not limited to IoT. It’s flexible enough to describe and interface with agents, tools, and resources in AI systems.

  • Describe the capabilities of agents, tools and their APIs.
  • Enable inter-agent communication betwen agents written in different languages.
  • Facilitate metadata discovery of agents, tools across networks.

• Browser and Client Support:
  A standardized Scripting API already exists for browsers, allowing direct interaction with WoT-defined Things. This could be extended for agents and tools.

I've described a lot of the concepts and ideas here: https://lmos-ai.org/docs/multi_agent_system/overview
We use WoT to describe the capabilities of Agents and their API. We use it for inter-agent communication and metadata discovery. But it can be easily adapted to be used for "tools", "resources", "prompts" or other "things".

WoT is not just theoretical, it has implementations in multiple languages, including:

• TypeScript (node-wot)
• Kotlin (kotlin-wot)
• Python (wot-py)
• Dart (dart_wot)

These implementations can serve as a foundation for quickly adapting WoT for MCP use cases.

Call to Action

I’d love to get feedback from the community on this topic. Specifically:

1. Shouldn't we evaluate existing W3C standards before formalizing MCP?
2. Would adapting WoT to MCP bring tangible benefits, such as interoperability and reduced development overhead?
3. What barriers exist (if any) to applying WoT standards in MCP-like scenarios?

Let’s consider whether leveraging established standards like WoT could save time and effort while promoting interoperability across AI/LLM ecosystems. I look forward to hearing your thoughts!

[jspahrsummers]

Thanks for your thoughts here! I'm not massively familiar with WoT, but I believe MCP and WoT serve different needs that necessitate a separate protocol here, though there may be opportunities for cross-pollination.

MCP specifically focuses on making it as easy as possible to create new MCP servers (often just 100–200 lines of code, easily one-shottable using AI), and AI-specific features like prompts, resources, tools, and sampling. There are also a lot of inbuilt safety considerations, like how to keep humans in the loop, and how to expose just the right amount of information between clients and servers.

While WoT could theoretically be adapted to handle these cases, I worry we'd be introducing even more complexity—and we've already observed a fair amount of sensitivity to it.

Perhaps you could share how you imagine the MCP concepts mapping onto WoT, specifically with examples? It may be that the best solution is building some sort of bridge or intercompatibility, rather than actually rebasing the former onto the latter.

[RobWin]

Thank you for the quick response. I will use the following example of the weather service in your Python example, because funnily it's the same example we used :P

This example illustrates how a WeatherService Tool can be modeled using a Thing Description, with HTTP as the primary communication protocol, although alternative protocols such as WebSockets, AMQP or MQTT may also be utilized.
The metadata describes who is the provider of the tool, which service is used to provide weather information. The tool offers a single action, "get_forecast". Action Input and Output is defined in JSON Schema.

The service is secured using basic authentication and is accessed via a POST request to a specified endpoint, but other security schemes, such as OAuth2 tokens, can also be used.
But with WoT the tool could easily publish events like weather warnings or have state.
With Semantic Web you can create an ontology for the Model Context Protocol. The ontology formally defines entities, relationships, and properties in the domain. For data you can also use existing ontologies. e.g. from https://schema.org/.

{
    "@context": [
        "https://www.w3.org/2022/wot/td/v1.1",
        {
            "htv": "http://www.w3.org/2011/http#",
            "ex": "http://api.openweathermap.org"
        },
        "https://schema.org/"
    ],
    "id": "urn:uuid:6f1d3a7a-1f97-4e6b-b45f-f3c2e1c84c77",
    "title": "WeatherTool",
    "version" : {"instance": "1.0.0"},
    "description": "A tool which can provide weather forcasts",
    "@type": "ex:Tool",
    "links": [{
      "rel": "service-doc",
      "href": "http://api.openweathermap.org/manual.pdf",
      "type": "application/pdf",
      "hreflang": "en"
    }],
    "ex:metadata": {
        "ex:vendor": {
            "ex:name": "OpenWeather Inc.",
            "ex:url": "http://api.openweathermap.org"
        },
        "ex:serviceIntegration": {
            "ex:weatherAPI": "OpenWeatherMap",
            "ex:apiVersion": "v2.5",
            "ex:apiDocumentation": "https://openweathermap.org/api"
        },
        "ex:dataPrivacy": {
            "ex:dataRetentionPeriod": "30 days",
            "ex:anonymizationMethod": "HASHING"
        },
        "ex:compliance": {
            "ex:regulatoryCompliance": "GDPR"
        }
    },
    "securityDefinitions": {
        "basic_sc": {
            "scheme": "basic",
            "in": "header"
        }
    },
    "security": "basic_sc",
    "actions": {
        "get_forecast": {
            "description": "Get weather forecast for a city",
            "idempotent": false,
            "synchronous": true,
            "input": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "City name"
                        "default": "London"
                    },
                    "days": {
                        "type": "number",
                        "description": "Number of days (1-5)",
                        "minimum": 1,
                        "maximum": 5
                        "unit": "d"
                    }
                },
                "required": ["city"]
            },
            "output": {
                "type": "object",
                "properties": {
                    "temperature": {
                        "@type": "ex:Temperature",
                        "type": "number",
                        "description": "Temperature in degrees Celsius",
                        "unit" : "C°"
                    },
                    "conditions": {
                        "@type": "ex:Conditions",
                        "type": "string",
                        "description": "Weather conditions (e.g., sunny, cloudy, rain)"
                        "enum": ["sunny", "cloudy", "rain"]
                    },
                    "humidity": {
                       "@type": "ex:Humidity",
                        "type": "number",
                        "unit": "%",
                        "minimum": 0,
                        "maximum": 100,
                        "description": "The current measured relative humidity."
                    },
                    "wind_speed": {
                        "@type": "ex:WindSpeed",
                        "type": "number",
                        "description": "Wind speed in km/h",
                         "unit": "km/h",
                        "description": "The current wind speed."
                    },
                    "timestamp": {
                        "type": "string",
                        "format": "date-time",
                        "description": "Timestamp of the forecast"
                    }
                },
                "required": ["temperature", "conditions", "humidity", "wind_speed", "timestamp"]
            },
            "forms": [
                {
                    "op": "invokeaction",
                    "href": "https://weatherai.example.com/forecast",
                    "contentType": "application/json",
                    "htv:methodName": "POST"
                }
            ]
        }
    }
}

The Thing Description can be easily mapped to the JSON Schema of Tools.
We use it to describe APIs of Agents as well.
You can also use Thing Descriptions and Json Schema to model Resources, Tools, Prompts.

Calling an Agent or Tools includes the discovery of the Thing Description. You can use mDNS, well-known URLs, or just an endpoint.
But as you can see, the client code does not contain any protocol-specific details and is similar for HTTP, MQTT or WebSockets. The client is fetching all information from the form fields of the thing description to communicate with the Thing.

// Fetch the Thing Description
const td = await WoT.requestThingDescription("http://weatheragent.example.com/td");

 // Consume the Thing Description
const thing = await WoT.consume(td);

// Prepare input parameters for the action
const inputParams = {
    city: String
};

// Invoke the getWeather action
const weatherResponse = await thing.invokeAction("fetchWeather", inputParams);
const weatherData = await weatherResponse.value();

In node-wot you can create a server (Servient) which supports multiple protocols at the same time.

A server looks as follows:

const { Servient } = require("@node-wot/core");
const { HttpServer } = require("@node-wot/binding-http");
const { MqttBrokerServer } = require("@node-wot/binding-mqtt");
const servient = new Servient();
servient.addServer(new HttpServer());
servient.addServer(new MqttBrokerServer({ uri: "mqtt://test.mosquitto.org" }));
servient.start()

A client looks similar

const servient = new Servient();
servient.addClientFactory(new HttpClientFactory());

A Server/Thing is also easy to implement. For example in my kotlin-wot, just create a class.
The Thing Description is automatically generated. Just drop in a protocol binding (library dependency) to support either HTTP, MQTT or some other protocol. It's also already specified how to create new protocol bindings to improve interoperability. There is also a binding for files.

@Thing(
    title = "WeatherTool",
    type = "Tool"
    description = "A tool which can provide weather forcasts."
)
@VersionInfo(instance = "1.0.0")
class WeatherTool {

    @Action(name = "get_forecast")
    fun getForCast(coty: String) : WeatherForecast{
       // call the remote service
        val weatherForecast = ...
        return weatherForecast
    }
}

data class WeatherForecast(
    val temperature: Double, // Temperature in degrees Celsius
    val conditions: Condition, // Weather condition as an enum
    val humidity: Double, // Humidity percentage (0-100)
    val windSpeed: Double, // Wind speed in km/h
    val timestamp: LocalDateTime // Timestamp of the forecast
) {
    enum class Condition {
        SUNNY,
        CLOUDY,
        RAIN
    }
}

For some background information about myself:

A year ago, we started developing the open-source platform LMOS (Language Model Operating System) as the basis for Deutsche Telekom's digital assistant, which can be accessed via multiple channels such as web, app, hotline and WhatsApp. We are still in the progress of making it open-source.
This assistant is currently deployed in Europe and has been successfully processing hundreds of thousands of customer inquiries in production. LMOS is based on a microservice, multi-agent architecture.
One of the outcomes of our experience running a large-scale LLM system in production was the creation of a client/server architecture which uses WoT Thing Descriptions to describe the APIs of Agents and Tools. Which also allows a dynamic metadata propagation and discovery of Agents and Tools in a cloud environment.

The concepts, along with further details, are outlined on lmos-ai.org.
I really think it would make sense to align the concepts a bit to make them future-proof.
Feel free to contact me, if you have further questions.

[kaikreuzer]

I'd say @RobWin has a point here. We all know the standards proliferation more than we like to and W3C is the best standard body we have for the web - so using what is there should be the first thought.

To my understanding, WoT is not tied to IoT, but you can rather think of "generic services and stuff" interoperating on the web - so it should be worth to dive into it, because MCP does not seem to target anything different - and the list of "stuff" you might want to make available through MCP on the long run will only increase for sure.

though there may be opportunities for cross-pollination.

I'm long enough in the IT industry to smell that this is rather a lame excuse for not going deeper into it, sorry. 😉
From the discussions I see around MCP, it feels to be in a very early stage and many challenges have not yet been thought through or addressed. Examples are additional protocols (SSE not being a good candidate for all situations), protocol-agnostic implementation, authentication, discovery, other interaction schemes than RPC, etc. All such things are already solved in WoT and just cross-polinating, (i.e. looking at it and then re-inventing it) feels like a waste of time and resources.

Nonetheless, if it turns out that WoT is a mismatch for what really is required in the AI/models space, one should not try to misuse WoT for different purposes.