Is your feature request related to a problem? Please describe.

Feast 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.

In 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.

Describe the solution you'd like

Add first-class support for Streamable HTTP MCP transport in the Feature Server, and allow users to select the transport via configuration.

Proposed behavior:

• Introduce a Feature Server config option (name TBD), e.g. mcp_transport: "http" | "sse".
  • Keep the default as "sse" initially to minimize backward-compatibility risk (open to maintainer preference).
• When mcp_transport=http, mount MCP using FastApiMCP.mount_http() (Streamable HTTP).
• When mcp_transport=sse, keep existing behavior (prefer mount_sse() if available; otherwise fallback to mount() for older fastapi_mcp versions).
• 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).

Acceptance criteria (suggested):

• With mcp_transport=http, MCP clients can connect without external proxies and tools are discoverable/callable.
• With no config change, existing deployments behave exactly as today.
• Docs include how to enable Streamable HTTP and connect common MCP clients.

Describe alternatives you've considered

1. Keep SSE-only and document mcp-proxy as the workaround
   • Pros: minimal code changes
   • Cons: requires extra installation/configuration and doesn’t feel like “supported” out of the box
2. Switch the default transport to HTTP
   • Pros: aligns with the recommended transport immediately
   • Cons: potential compatibility risk for existing users/clients relying on legacy SSE behavior
3. Auto-detect transport based on client
   • Pros: fewer user-facing knobs
   • Cons: harder to reason about, larger scope, more complex to test/debug

Additional context

• Runtime warning indicates mount() is deprecated and suggests mount_http() (recommended) or mount_sse().
• Hitting GET /mcp returns text/event-stream and an SSE handshake (event: endpoint ... /mcp/messages/?session_id=...), confirming the legacy SSE transport.
• 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.

I’m happy to implement this and open a PR following the dev guide