Home Assistant MCP integration vs Sume's POST-only MCP URL

The short answer

Do not paste https://mcp.sume.com/mcp into Home Assistant's Model Context Protocol integration and expect it to work. Home Assistant's page describes a client that polls an **SSE endpoint** (its field is called SSE Server URL), while Sume's hosted MCP endpoint answers a plain GET with 405 and only accepts POST JSON-RPC requests.

That is an inference from two documented behaviours, not a claim that Home Assistant has been tested against Sume. The reliable route for a Home Assistant automation is Sume's REST API, called through Home Assistant's own RESTful Command integration. The rest of this post lays out both sides so you can check them yourself.

What each side documents

Home Assistant's Model Context Protocol page says the integration acts as a client using the Server-Sent Events transport, and that for stdio-only servers you need a proxy such as mcp-proxy to expose them over SSE. Its configuration options are an SSE Server URL plus an optional OAuth Client ID and Client Secret.

Sume's MCP docs give one hosted URL, https://mcp.sume.com/mcp, with OAuth or an API key. In the Sume server code a GET on that route returns 405 with an allow: POST header and the body Remote MCP uses POST JSON-RPC requests.

Why a proxy is not the obvious fix

The proxy Home Assistant mentions bridges a stdio server to SSE. Sume's endpoint is already remote HTTP, so that bridge does not apply, and Sume's docs say a local stdio MCP is not launched in current CLI releases, so there is nothing local to put behind it. Adding a second hop whose behaviour neither vendor documents is the kind of setup that works on one release and breaks on the next.

Home Assistant also marks everything except tools as unsupported, which is fine here: the Sume tools you would want from an automation are submit, wait, and fetch result, and those map directly to three REST calls.

Use RESTful Command instead

Home Assistant's RESTful Command page documents url (a template), method (get, patch, post, put or delete), headers, payload (a template), content_type, and a timeout that defaults to 10 seconds. A minimal Sume submit looks like this, with the key stored in secrets.yaml as a full Bearer ... string.

Submit with mode: async so the call returns a job id well inside the 10-second default; polling is covered in the job status docs. One caveat: the Home Assistant page documents headers as a plain map and shows a secret in it, not a template, so a per-automation Idempotency-Key header is not something its page promises. If you retry submits, keep the retry in a tool that can set that header per request.

rest_command:
  sume_image:
    url: "https://api.sume.com/v1/images"
    method: post
    headers:
      authorization: !secret sume_bearer
    content_type: "application/json"
    payload: >-
      {"model":"sume/auto","mode":"async",
       "prompt":"{{ prompt }}"}
    timeout: 10

What to check before you build on it

Run the action once from Developer Tools and read the response variable (status, content, headers) to confirm you got a 2xx with a job id. Then read the API reference for the status and result routes. If a later Home Assistant release adds a streamable HTTP option to the MCP integration, its page is the place that will say so; until then, REST is the documented path on both sides.