Added mcp tool filtering and unit test

[DanieleMorotti]

Summary

Considering multiple requests to add this feature #830, #851 , I added a parameter to MCP servers to filter out some tools.
Let me know if you want to implement something in a different way and if I have to update the documentation.

Test plan

I added a unit test to check that only the allowed tools are returned by the server.

Issue number

It should close #830 and #851 .

Checks

• [ ✅] I've added new tests (if relevant)
• I've added/updated the relevant documentation
• [✅ ] I've run make lint and make format
• [✅ ] I've made sure tests pass

[devtalker]

Hi @DanieleMorotti! 👋

What a coincidence! I was also working on the exact same feature and just submitted PR #861. It's really interesting that we both identified this need and decided to tackle it simultaneously - great minds think alike! 😄

I really appreciate your initiative in addressing issues #830 and #851. After looking at both approaches, I'd love to get your thoughts on the different implementation strategies we've taken.

From what I can see, your solution focuses on server-level filtering (which is definitely the right direction!). In my implementation, I tried to provide a bit more flexibility by offering a dual-layer filtering approach:

Server-level filtering (similar to your approach):

server = MCPServerStdio(
    params={...},
    allowed_tools=["read_file", "write_file"],
    excluded_tools=["delete_file"]
)

Agent-level filtering (additional layer):

agent = Agent(
    name="Assistant", 
    mcp_servers=[server1, server2],
    mcp_config={
        "allowed_tools": {
            "server1": ["tool1", "tool2"]
        },
        "excluded_tools": {
            "server2": ["dangerous_tool"] 
        }
    }
)

The idea is that server-level filtering controls what tools the server exposes, while agent-level filtering allows fine-grained control across multiple servers without modifying server configurations.

I also included support for both allowed_tools (whitelist) and excluded_tools (blacklist) at both layers, plus comprehensive tests and documentation.

What do you think about this approach? I'd really value your feedback - maybe there are aspects of your implementation that could improve mine, or perhaps we could combine the best of both approaches?

Would you be interested in taking a look at PR #861 and sharing your thoughts? I'm definitely open to collaboration and would love to hear your perspective! 🙏

[DanieleMorotti]

Hi @devtalker !

Thanks for your detailed reply and the work you put into PR #861 , it's indeed a funny coincidence we tackled this simultaneously! 😄

You're exactly right, my approach was focused purely on server-level filtering. However, your idea of adding flexibility at the agent-level certainly provides more granular control, which could be beneficial in some scenarios.

I'm not 100% convinced about having both allowed_tools and excluded_tools simultaneously. It may be better to provide a single option, but that's only my opinion.

In any case, let's wait to hear @rm-openai thoughts, in order to adopt the best approach to move forward.

[devtalker]

Hi @DanieleMorotti,

Thanks again for the feedback and being open to chat about it! 😊

I get where you're coming from with allowed_tools and excluded_tools feeling a bit redundant, but I’ve seen this dual approach used pretty commonly in access control systems — like feature flags or API permissions. It just gives users more flexibility depending on the use case.

For example:

• If you only want a few safe tools, allowed_tools is perfect.
• But if most tools are fine and you just want to block a couple risky ones, excluded_tools makes life easier.

It’s especially helpful when working with multiple servers or evolving configs over time — no need to rewrite everything just to tighten things up a bit.

Of course, we could go with just one option if needed, but I’d lean toward keeping both unless there's a strong reason not to.

I’ll be looking forward to hearing what @rm-openai thinks too — hopefully they can help us decide the best way forward!