Proposal: Extract Discovery module from core SDK for better modularity

没有指定具体的文件或测试。首先检查 core SDK 的 Discovery 模块，包括其对 symfony/finder、phpdocumentor/reflection-docblock 以及自定义标记化依赖项的使用，然后将提议的 mcp/discovery 包边界与 Spiral、Laravel 和 Symfony 的集成进行比较。当团队就提取设计及其框架集成边界达成一致时，即表示完成。

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.