McpMixin for decorating Class methods

[strawgate]

Decorate class methods in Python, instantiate the class, and then turn the methods of the instantiated class into MCP Tools, Resources and prompts!

Example:

"Sample code for FastMCP using MCPMixin."""

 import asyncio

 from contrib.mcp_mixin.mcp_mixin import (
     MCPMixin,
     mcp_prompt,
     mcp_resource,
     mcp_tool,
 )
 from fastmcp import FastMCP

 mcp = FastMCP()


 class Sample(MCPMixin):
     def __init__(self, name):
         self.name = name

     @mcp_tool()
     def first_tool(self):
         """First tool description."""
         return f"Executed tool {self.name}."

     @mcp_resource(uri="test://test")
     def first_resource(self):
         """First resource description."""
         return f"Executed resource {self.name}."

     @mcp_prompt()
     def first_prompt(self):
         """First prompt description."""
         return f"here's a prompt! {self.name}."


 first_sample = Sample("First")
 second_sample = Sample("Second")

 first_sample.register_all(mcp_server=mcp, prefix="first")
 second_sample.register_all(mcp_server=mcp, prefix="second")


 async def list_components():
     print("MCP Server running with registered components...")
     print("Tools:", list(await mcp.get_tools()))
     print("Resources:", list(await mcp.get_resources()))
     print("Prompts:", list(await mcp.get_prompts()))


 if __name__ == "__main__":
     asyncio.run(list_components())
     mcp.run()

[Copilot]

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

[jlowin]

Nice!! This feels great!

Few minor thoughts:

• I know I suggested it yesterday but McpRegisterable as a class name feels a little awkward to me -- it describes what the class can do but not what it's intended for. What do you think about MCPPlugin or MCPComponent?
• hardly critical, but if you made the prefix optional this could be an interesting way to ship MCP objects without a server (e.g. just import them into your server without a prefix)
• I'm ok merging without tests, but in that case would prefer to put it in a new src/contrib/ directory (e.g. src/contrib/mcp_plugin/mcp_plugin.py, which can collect any contributed functionality without the burden of maintenance with the rest of the repo. Otherwise it's hard to know if changes to main classes inadvertently break it; contrib is a way of relaxing that requirement. If you agree, I'll also add documentation to that effect and to promote this! Having that folder also gives you a chance to (optionally) add a readme or any other info
• please move sample.py to src/contrib/mcp_plugin/example.py and remove the src import

[strawgate]

It was originally just supposed to be an example but I'll go ahead and clean it up (including thinking of a new name, adjust the prefix handling, move some stuff, and add tests

[jlowin]

Oh :) I like it as more than just an example! Either way I think contrib/ will be the best home as its more framework-y than "just" an example script.

[strawgate]

@jlowin let me know what you think

[jlowin]

@strawgate this is awesome! Thanks so much and welcome to the repo officially :) I made some minor changes because of some upstream method changes but LGTM!