modelcontextprotocol / modelcontextprotocol/php-sdk
Builder::build() silently skips configured file-based discovery when symfony/finder is missing — should fail loudly
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- PHP
- Estrellas
- 1.6k
- Forks
- 173
- Merge medio
- 2 d 49 min
- PR fusionados (30 d)
- 23
Descripción
Calling setDiscovery() is an explicit declaration that the server's tools come from attribute discovery. But since symfony/finder is only a suggested dependency, a host application can easily end up without it — and when that happens, build() does this:
if (null !== $this->discoveryBasePath) {
if (null !== $this->discoverer || class_exists(Finder::class)) {
// ... discovery runs
} else {
$logger->warning('File-based discovery requires symfony/finder...');
}
}
The result is the worst failure mode available: the server builds successfully, initialize succeeds, and tools/list returns an empty array. The operator sees a healthy server; the symptom surfaces far from the cause, as confused MCP clients with no tools. The only breadcrumb is a single warning log line.
This also contradicts the SDK's own Discoverer::__construct(), which already throws RuntimeException('File-based discovery requires symfony/finder. ...') for exactly this situation — the builder's class_exists pre-check just routes around that guard, downgrading a configured-but-impossible feature from an error to a whisper.
Proposal: when discoveryBasePath is set, no custom discoverer was supplied, and Finder is unavailable, build() should throw (the Discoverer's existing message is perfect) instead of warning-and-skipping. This costs nothing for explicit-registration users, client-only users, or anyone without setDiscovery() — it only converts a silent production mystery into an immediate, actionable boot error for people who asked for discovery and can't have it.
Observed on v0.7.0. Context: we hit this failure mode while integrating the SDK into a Symfony bundle (pimcore/data-hub-simple-rest#312) and worked around it by requiring symfony/finder in the bundle directly — which remains the right consumer-side fix, but doesn't help the next integrator who doesn't know about the silent path.
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza localizando Builder::build() y el manejo de setDiscovery() descrito en el issue; después compara su rama en la que falta Finder con Discoverer::__construct(). Añade o actualiza una prueba específica para una ruta de discovery configurada sin symfony/finder. Se considera terminado cuando build() lanza la RuntimeException existente y accionable, en lugar de registrar una advertencia y producir una lista de herramientas vacía.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- php
- Área
- backend
- Tipo de issue
- Error
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Estado de actividad
- Tranquilo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 68/100