Proposal: Extract Discovery module from core SDK for better modularity

[butschster]

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.

[chr-hertel]

For this one I clearly see a benefit. I was thinking of that myself - I clearly see the benefit of having the discovery as feature here - makes it easy to start, but also a reason we didn't have it in the Symfony one - similar stuff can be solved with the container there, yes.

However, to me we have two options here:

• have it flexible around registry, capabilities and reference, to enable frameworks to decorate and integrate easily - basically overriding the discovery, but keeping it in the package
• only having the flexibility and core structures, and moving this implementation of discovery back to a php-mcp/discovery package or similar

Additional thoughts => that also explain why it is like it is:

• We (and I consider @pronskiy and @CodeWithKyrian) here, thought about having something easy to start, not depending on frameworks
• I don't buy "let's keep it small" arguments, when it only is about plain text files - we're not talking megabytes here - you mention dependencies and that's a real difference, but we're not acting on real pain here, but theory - and tbh, i don't expect any pain from symfony/finder :D