Add the Model Context Protocol Server integration #134122
Conversation
| ) -> None: | ||
| """Test the tools list endpoint.""" | ||
|
|
||
| async with mcp_session(mcp_sse_url, hass_supervisor_access_token) as session: |
There was a problem hiding this comment.
For reviewer: This is using the MCP SDK client library for testing the MCP and SSE protocol for the integration end to end. This is not typical for a Home Assistant test, but since this is adding a new protocol it seemed to make sense. If desired, we can make the tests lower level.
There was a problem hiding this comment.
I like this, because it guarantees that our implementation works instead of trying to keep our lower level tests in sync with the spec.
| {LIGHT_DOMAIN: [{"platform": "test"}]}, | ||
| ) | ||
|
|
||
| async_expose_entity(hass, CONVERSATION_DOMAIN, TEST_ENTITY, True) |
There was a problem hiding this comment.
Not to be solved in this PR, but we should come up with a better way to expose entities. We can't tie everything that is not Google/Amazon to conversation.
There was a problem hiding this comment.
Yeah, i don't really think i understand the product direction here at the moment for this being tied together.
Having Home Assistant as an MCP client also raises some other broader points: Do we add exposed tools to another API? or add them to Assist? Do we want to find a way to make discovered prompts usable with other models? e.g. revisit config sub entries.
It seems like there are more degrees of freedom generally that we'll want here and exposed entities is one example.
| "llm_hass_api": "[%key:common::config_flow::data::llm_hass_api%]" | ||
| }, | ||
| "data_description": { | ||
| "llm_hass_api": "The method for controling Home Assistant to expose with the Model Context Protocol." |
There was a problem hiding this comment.
Should we translate this as "Control", as we do for LLMs?
| "llm_hass_api": "The method for controling Home Assistant to expose with the Model Context Protocol." | |
| "llm_hass_api": "Control" |
(btw, I guess no control means really not much to be done)
There was a problem hiding this comment.
We're using [%key:common::config_flow::data::llm_hass_api%] above which is Control Home Assistant. Just to make sure: Are you making this comment for the data field or data_description field? This is for data_description and I didn't see that the LLM integrations have a data_description` field.
Let me know and I can address as a follow up.
Co-authored-by: Paulus Schoutsen <[email protected]>
Proposed change
Add the Model Context Protocol Server integration.
See https://modelcontextprotocol.io/introduction#general-architecture for background on how MCP works.
This exposes an MCP server using the SSE Transport. This is an updated version of https://github.com/allenporter/home-assistant-model-context-protocol but with native SSE support, rather than websockets, now that Home Assistant core supports pydantic v2. This adds dependencies on the mcp python SDK, as well as aiohttp-sse/anyio for generating responses. Note: We can move more of
http.pyinto a library if desired to push more SSE protocol details out of Home Assistant.Protocol roadmap: https://modelcontextprotocol.io/development/roadmap -- the actual final definition for how remote MCP servers work is still in progress, as well as authentication.
Remaining work items in draft:
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: