modelcontextprotocol / modelcontextprotocol/php-sdk

Builder::build() silently skips configured file-based discovery when symfony/finder is missing — should fail loudly

Abierto Apto para principiantes
#398 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

needs confirmation needs maintainer action Server
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

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. 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

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.