Proposal: Extract Discovery module from core SDK for better modularity

No specific files or tests are named. Start by reviewing the core SDK's Discovery module, including its symfony/finder, phpdocumentor/reflection-docblock, and custom tokenization dependencies, then compare the proposed mcp/discovery package boundary with integrations for Spiral, Laravel, and Symfony. Done means the team has agreed on an extraction design and its framework integration boundaries.

Hey team,

I can see a lot of thought went into making the developer experience smooth with the Discovery module. The automatic scanning and registration is definitely a nice convenience feature.

I was reviewing the SDK architecture and noticed that the Discovery functionality is currently bundled directly into the core SDK package. While this makes getting started really easy, I'm wondering if we might want to consider a different approach for the long-term health of the project.

Here's what I'm thinking about:

Maintenance and Release Complexity

The Discovery module brings in some pretty heavy dependencies like symfony/finder and phpdocumentor/reflection-docblock, plus it includes custom tokenization logic. This means the SDK's release cycle could get tangled up with Discovery-related updates.

Framework Integration Challenges

I've been looking at how this would integrate with frameworks like Spiral, Laravel, and Symfony, and they already have really mature discovery systems with optimized caching and pre-compilation. It seems like we might be asking framework developers to choose between using their battle-tested discovery systems or staying compatible with our SDK approach.

Architectural Separation

What do you think about splitting this into separate concerns? Something like:

• Keep the SDK focused on the core MCP protocol implementation (message handling, JSON-RPC transport, tool schemas)
• Move Discovery into either a separate mcp/discovery package or framework-specific integrations
• Let applications choose the discovery approach that fits their architecture

This way:

• The core SDK stays lightweight with minimal dependencies
• Framework integrations can use their native discovery systems
• Standalone apps can still use convenient auto-discovery if they want
• We can evolve Discovery independently from protocol updates

Specific Benefits

For microservices that just need manual tool registration, they wouldn't carry the file scanning dependencies. Framework developers could contribute optimized integrations for their specific ecosystems. And SDK maintenance could focus on what it does best - implementing the MCP protocol cleanly.

I might be missing some context about the design decisions here, so I'd love to hear your thoughts! Is there a specific reason Discovery needs to be in the core SDK, or would a more modular approach work better?

Happy to discuss this further or help with any refactoring if the team thinks this direction makes sense.