Proposal: Extract Discovery module from core SDK for better modularity
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Refactorisation
- Clarté
- À clarifier
- Activité
- Calme
- Stack technique
- php
- Domaine
- backend-api-design
Piste de recherche
Aucun fichier ni test spécifique n’est nommé. Commencez par examiner le module Discovery du SDK principal, notamment ses dépendances symfony/finder, phpdocumentor/reflection-docblock et de tokenisation personnalisée, puis comparez la limite de package proposée pour mcp/discovery avec les intégrations pour Spiral, Laravel et Symfony. La tâche sera terminée lorsque l’équipe se sera accordée sur une conception d’extraction et sur les limites de ses intégrations avec les frameworks.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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/discoverypackage 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.
- Langage dominant
- PHP
- Étoiles
- 1.6k
- Forks
- 180
- Merge moyen
- 3 j 12 min
- PR mergées (30 j)
- 44
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de modelcontextprotocol/php-sdk
-
[Server] Handler type uses bare Closure, hard to decorate RegistryInterface under strict PHPStanOuverteServer
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
modelcontextprotocol/php-sdk#468 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Builder::build() silently skips configured file-based discovery when symfony/finder is missing — should fail loudlyPeut-être pris @ousamabenyounes l’a pris il y a 56 jours. Ouverteneeds confirmation needs maintainer action Server
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
modelcontextprotocol/php-sdk#398 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
modelcontextprotocol/php-sdk#370 ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 4/5 3-5 jours Accessibilité débutants 52/100
modelcontextprotocol/php-sdk#587 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 3/5 Une demi-journée Accessibilité débutants 60/100
modelcontextprotocol/php-sdk#586 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de modelcontextprotocol/php-sdk
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
L: java:gradle L: java:maven L: ruby:bundler T: bug 🐞
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
dependabot/dependabot-core#16547 ·
Les mainteneurs répondent en général sous 1 jour
-
cloning objets from planningOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
glpi-project/glpi#25922 ·
Les mainteneurs répondent en général sous 1 jour
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Automattic/safe-publish#726 ·
Les mainteneurs répondent en général sous 1 jour
-
Translation TwigBridge
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
symfony/symfony-docs#23308 ·
Les mainteneurs répondent en général sous 3 jours