Basically I want to read calendar events and take actions but I don't want AI to ever change my events, so I added a little bit of helpers for that case, also added filtering because sometimes tool calls are limited.

Should be a flexible and backwards compatible change.

@hongkongkiwi Thanks for putting together this PR. I like the implementation filtering tools before they are registered.

It might be overkill to have three separate flags when the main goal is to allow read-only vs all operations, but I don't have strong opinions on this. However, if we do filter tools via a black list or whitelist let's make sure there is logic to determine if the supplied tools exist to prevent silent failures if there is a mismatch. Also, it would be good to throw errors if the user attempts an invalid combination of flags.

The reason for the flags really is because some implementations e.g. cursor limit number of tool calls to 48 or something because they have their own bundled tools.

Sometimes you might want to have read write but you only needed a specific function, in that case limited tools might make sense.

I had to do this on the GitHub MCP due to the sheer overwhelming number. But totally agree might be overkill here. Since this is an issue some products e.g. cursor have added a function to ignore specific tool calls now. Which is recent.

Thanks for the explanation, I have run into similar issues especially with the Github MCP. It probably makes sense to allow more granular filtering for the MCP clients that don't yet support enabling and disabling of specific tools.

Happy to merge this in once there is validation of the tool names being filtered.