Implementation of the proposal for modular design

[DamyanBG]

Motivation and Context

Implementation of #767

How Has This Been Tested?

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[DamyanBG]

I want to mention that I have to add changes for resources and prompts. I am waiting for feedback on my issue #767 and the way of my implementation.

[DamyanBG]

@ihrpr @dsp-ant Hello,

Can I ask you to take a fast look and tell me do you want me to continue on that proposal in #767 ?

Thank you in advance!

[felixweinberger]

Hi @DamyanBG thank you for this contribution and proposal!

I think your best bet is likely going to be to get some informal feedback on the idea on the Discord for the Python-SDK first. While I understand the attractiveness of modularity here, it'd be good to validate that it's actually a common issue and blocking others before we take on the maintenance burden of this additional complexity.

This change may also require a SEP to ensure feature parity between different implementations of the Spec.

You can find the link to the community Discord on https://modelcontextprotocol.io/community/communication

[felixweinberger]

Closing this one for now as it's been a while - we're currently going through older PRs to ensure we prioritize limited maintainer time appropriately.

If you'd like more feedback on the idea of modularity, feel free to check out the resources mentioned in the above comment.