Add filter tool functionality in MCP servers and allow specifying MCP type

[wasaybaig201]

Feature Type

I cannot use LiveKit without it

Feature Description

Currently, the LiveKit Agents framework automatically creates MCP server connections using MCPServerHTTP, but there's no way to:

• Specify which MCP transport type to use (SSE vs Streamable HTTP)
• Filter which tools are exposed from an MCP server to the agent

When integrating with MCP servers (especially third-party services like Pipedream), we often need to control which tools are available to specific agents to prevent agents from calling inappropriate or unnecessary tools, and
choose the transport mechanism which is not dependent on MCP URL.

Workarounds / Alternatives

Currently, I've implemented a custom workaround by creating a MCPServerHTTPFiltered class that wraps the standard MCPServerHTTP, with an addition that it has an allowed_tools and type attributes. I can create a PR for this.

Additional Context

No response

[chenghao-mou]

Specify which MCP transport type to use (SSE vs Streamable HTTP)

Currently, if you provide the url with something like http://localhost:8000/sse, it will use SSE by default.

Search and filtering have been active topics in the MCP protocol community for a while. Unfortunately, they have decided not to move forward with this in the core spec for the time being. See comment. This means this no current standard on how to interact with MCP server/client for this use case. We can keep the issue open to gather more inputs if we want to implement this specifically for agents.

[wasaybaig201]

@chenghao-mou
Thank you for your reply.

I think what I am talking about is different from your mentioned comment. I am just saying that the agent code can have an allowed_tools argument when adding an MCP server. This argument will be provided by the client so the agent only discovers the subset of tools (provided by the client), not all of them.

For example in Zapier's MCP, one can add several tools such as for Google Calendar and Linear. If the goal is to make two agents, one is a specialized Linear agent and the other is a specialized Gogle Calendar agent then instead of having two separate MCP servers, the client can provide the Google Calendar tools to one agent and Linear tools the other agent. The tools will follow the standard name by the provided such as linear-get-current-user or google_calendar_find_events. It will be up to the client to provide the correct tool names.

For the second issue, that is what I am saying that not all MCP URLs accurately represent the transport type for a particular MCP server. For example Pipedream's MCP URL does not end with either /sse or /mcp even though it uses streamable HTTP. The livekit code right now falls back to SSE in that case which throws me an error from Pipedream.

You can view my PR here: #4365

[chenghao-mou]

This argument will be provided by the client so the agent only discovers the subset of tools (provided by the client), not all of them.

I think it is the same "filtering" concept, e.g. namespace:

Bringing this up as other background conversations have been going on - namespaces (formerly modelcontextprotocol/modelcontextprotocol#334, now modelcontextprotocol/modelcontextprotocol#993) are looking like they'll evolve to support filtering in tools/list, and I see modelcontextprotocol/modelcontextprotocol#1269 is proposing extending tools/list for prefix filtering as well.

For example in Zapier's MCP, one can add several tools such as for Google Calendar and Linear. If the goal is to make two agents, one is a specialized Linear agent and the other is a specialized Gogle Calendar agent then instead of having two separate MCP servers

I definitely can see the appeal of having the ability to filter, but in this example, it would deviate from the MCP server design principle, which states

Servers should be highly composable
Each server provides focused functionality in isolation

w.r.t transport protocols, I am more than happy to review a PR to allow specifying the transport type. But for the allow_tools part, we can keep it open to see if enough people share the same interest.