René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support Streamable HTTP transport for Feature Server MCP integration","articleBody":"**Is your feature request related to a problem? Please describe.**\n\nFeast Python Feature Server’s MCP (Model Context Protocol) integration currently uses fastapi_mcp.FastApiMCP.mount(). This produces a deprecation warning at runtime (e.g., “mount() is deprecated… Use mount_http() …”) and mounts MCP using the legacy SSE-based transport.\n\nIn practice, the SSE MCP endpoint (/mcp) can be unreliable with some MCP clients (e.g., Claude Code / certain IDE MCP integrations). Even when the Feature Server is healthy, the MCP client may show “failed / not authenticated” or fail to connect, forcing users to add a proxy (e.g., mcp-proxy) as a workaround. This reduces usability and makes MCP adoption harder despite Feast being correctly configured.\n\n**Describe the solution you'd like**\n\nAdd first-class support for **Streamable HTTP** MCP transport in the Feature Server, and allow users to select the transport via configuration.\n\nProposed behavior:\n\n- Introduce a Feature Server config option (name TBD), e.g. `mcp_transport: \"http\" | \"sse\"`.\n    - Keep the default as `\"sse\"` initially to minimize backward-compatibility risk (open to maintainer preference).\n- When `mcp_transport=http`, mount MCP using `FastApiMCP.mount_http()` (Streamable HTTP).\n- When `mcp_transport=sse`, keep existing behavior (prefer `mount_sse()` if available; otherwise fallback to `mount()` for older `fastapi_mcp` versions).\n- If `mount_http()` is unavailable due to an older `fastapi_mcp`, fail fast with a clear error message (and/or bump the minimum required version).\n\nAcceptance criteria (suggested):\n\n- With `mcp_transport=http`, MCP clients can connect without external proxies and tools are discoverable/callable.\n- With no config change, existing deployments behave exactly as today.\n- Docs include how to enable Streamable HTTP and connect common MCP clients.\n\n**Describe alternatives you've considered**\n\n1. **Keep SSE-only and document `mcp-proxy` as the workaround**\n    - Pros: minimal code changes\n    - Cons: requires extra installation/configuration and doesn’t feel like “supported” out of the box\n2. **Switch the default transport to HTTP**\n    - Pros: aligns with the recommended transport immediately\n    - Cons: potential compatibility risk for existing users/clients relying on legacy SSE behavior\n3. **Auto-detect transport based on client**\n    - Pros: fewer user-facing knobs\n    - Cons: harder to reason about, larger scope, more complex to test/debug\n\n**Additional context**\n\n- Runtime warning indicates `mount()` is deprecated and suggests `mount_http()` (recommended) or `mount_sse()`.\n- Hitting `GET /mcp` returns `text/event-stream` and an SSE handshake (`event: endpoint ... /mcp/messages/?session_id=...`), confirming the legacy SSE transport.\n- In a local setup, a Claude Code client only connected reliably after inserting `mcp-proxy` as a stdio↔SSE bridge; once bridged, tool discovery and calls (e.g., `get_online_features`) worked as expected.\n\nI’m happy to implement this and open a PR following the dev guide \n\n","author":{"url":"https://github.com/HaJunYoo","@type":"Person","name":"HaJunYoo"},"datePublished":"2026-01-14T02:09:19.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/5853/feast/issues/5853"}