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.

[tadasant]

I hadn't heard of WoT before it started coming up in these discussions, so I want to spend some more time with this and I really appreciate the effort folks are putting into explaining how WoT might apply to MCP (especially @RobWin 's examples of how it might map). Some high level reactions that I'll be trying to assess for myself as I dig in, but thought I'd throw out there in case anyone has already thought through them and would like to share:

• One of the benefits of MCP is its relatively simple surface area. It's reaching a very broad developer audience (i.e. "vibe coders" can work with it). And it's still getting occasional (IMO unwarranted, but it's there) criticism for being too confusing. Is there a path to adopting WoT without forcing the MCP developer community to learn and understand WoT-specific concepts like Things and ThingDescriptions? In theory, it seems possible that that level of detail could be abstracted away by MCP SDK's and the like, but I'm wondering if there's a trade off to be cautious of here.
• What are some of the tangible benefits MCP gets by rebasing on WoT? I'm sure they exist, so enumerating these in MCP terms could be helpful. For example, if WoT presents answers to the long and windy ongoing recent discussions like auth, transports, etc; that could make adoption an easier sell. If WoT is so flexible as to not really provide answers, and just a kind of schema for enshrining those answers, then it seems the primary benefit would be interoperability. Which would beg the question: interoperability with what?

I spent a chunk of my career building both apps and a developer platform at the bleeding edge of FHIR, the healthcare data interop standard. While FHIR feels very necessary and a standard worth fighting for due to how otherwise fragmented the US healthcare ecosystem is, I also saw how it frequently bogged us down and even ended up creating bad end-user experiences as we occasionally overfit to the standard. And how often we missed things in the expansive standard and had to thrash to stay adherent to it. I don't regret it - it was a standard worth the tradeoffs - but there were definitely tradeoffs.

[RobWin]

Hey, thanks for your feedback!

Next Friday at 9 AM CET, I'll be presenting Eclipse LMOS, LMOS Protocol and WoT in a joint call with three W3C Community Groups: WebAgents, Web of Things, and the WebThing Protocol Community Group.
Hopefully, members of the Agent-Network-Protocol community will also be available. We are in discussions to align both protocols and work toward a unified solution with support for W3C DID.

You can find the event details here: https://www.w3.org/events/meetings/5a77b997-467b-4d5d-bb40-b84789c17d2e/20250314T090000/

My goal is to explain how we use Eclipse LMOS at Deutsche Telekom and why WoT can be applied for modeling Agents and Tools. I also hope to address questions. Plus, several other W3C WoT experts will be available for insights and discussion.

Every protocol starts simple. However, as more features are added—such as support for multiple authentication schemes, multiple transport protocols, multiple communication patterns (request-reply, event-driven, real-time, single request-multi-response), transport QoS, end-to-end message acknowledgments, Registry-based discovery, mDNS-based discovery, decentralized digital identities, and more—the specification inevitably grows in complexity.

A significant amount of effort has gone into documenting and standardizing these features within open W3C specifications to support implementers. Yet, the cycle continues: people argue that the protocol is too complex—so a new one is created, only for it to eventually reach a similar level of complexity, leading to the same debate.
I agree that it is very important that SDK are available which hide the complexity of protocols. No one would use Kafka or AMQP if they had to implement them from scratch — but with a well-designed SDK, they become simple to use.

At some point, we need to stop reinventing protocols and instead focus on reducing fragmentation within ecosystems.

Looking forward to the discussion!