Todos los artículos

Servidores MCP en PHP: qué ofrece el SDK oficial y cuándo no usarlo

Herramientas de IA · 4 min de lectura ·

El Model Context Protocol tiene un SDK oficial para PHP, hecho junto a The PHP Foundation y el proyecto Symfony, y esta semana apareció en la lista semanal de repositorios PHP en tendencia de GitHub. Si vives de PHP, eso significa que puedes abrir tu aplicación a un asistente de IA sin cambiar de lenguaje. Antes de hacerlo conviene tener claro qué estás construyendo: una puerta a tu sistema a la que un modelo va a llamar.

MCP en dos frases

MCP es un protocolo abierto que permite a una aplicación de IA descubrir y llamar herramientas (acciones), leer recursos (datos) y usar prompts (plantillas) que expone un servidor. La aplicación de IA es el host, tu código es el servidor, y se comunican con mensajes estructurados en lugar de que el modelo adivine tu API leyendo la documentación.

App de IA (el host) arranca tu script mensajes por STDIO o HTTP, si el servidor es remoto Tu servidor MCP en PHP hecho con mcp/sdk Tools Recursos Prompts acciones, datos, plantillas
Con STDIO, el host ejecuta tu script PHP como proceso hijo y habla con él por su entrada y su salida. Nada escucha en un puerto.

Qué te da el SDK de PHP

El SDK no depende de ningún framework y cubre los dos lados: servidores y clientes, herramientas, recursos y prompts, transportes STDIO y HTTP, sesiones y autorización. También habla las dos generaciones del protocolo, el handshake antiguo que empieza con initialize y la revisión sin estado del 2026-07-28. Se instala con composer require mcp/sdk, más symfony/finder si quieres que descubra tus herramientas recorriendo el código. El ejemplo de servidor del README se lee de un tirón:

class Calculator
{
    /** Adds two numbers. */
    #[McpTool]
    public function add(int $a, int $b): int { return $a + $b; }
}

exit(Server::builder()
    ->setServerInfo('Calculator', '1.0.0')
    ->setDiscovery(__DIR__, ['.'], excludeDirs: ['vendor'])
    ->build()
    ->run(new StdioTransport()));

Un atributo convierte una función de la clase en herramienta (tool, en el vocabulario de MCP), el comentario de documentación pasa a ser su descripción y los parámetros tipados pasan a ser su entrada. Un recurso funciona igual, con #[McpResource] y una URI. Pero la línea del README que más importa no está en el código: hasta la primera versión mayor, el SDK se considera experimental. Fija la versión y cuenta con cambios.

Como no depende de ningún framework, funciona dentro de una aplicación Laravel como cualquier otro paquete de Composer. El README menciona integraciones construidas encima para Symfony, API Platform, Drupal y otros. Comprueba si existe una integración para Laravel antes de escribir el pegamento tú mismo.

Cuándo un servidor es la herramienta adecuada, y cuándo no

Un servidor MCP se gana su sitio cuando le da al modelo algo que no puede conseguir de otra forma: datos en vivo de tu base de datos, o una acción dentro de tu sistema, como consultar el estado de un pedido o abrir un ticket de soporte. Para documentación estática encaja mal. Cristian Tabacitu, que mantiene Backpack for Laravel, escribió esta semana que el servidor MCP que montaron para consultar su documentación dio resultados irregulares, porque el agente tiene que decidir llamarlo y casi nunca lo hace. Si el agente ya tiene la información, o puede leerla en tu código, un servidor añade una pieza más que mantener y poco más.

Cada argumento de una herramienta es entrada no confiable

Una herramienta es una acción, y sus argumentos vienen de un modelo que ha leído cuanto le han puesto delante. Trátalos exactamente igual que un formulario enviado por un desconocido. Lo que sigue es práctica general, no algo que el SDK haga por ti:

frontera de confianza entrada no confiable tus reglas El modelo elige un tool Llamada al tool con argumentos Tu validación tipo, rango, usuario Tus datos mínimo privilegio Rechazado, registrado
Los parámetros tipados comprueban la forma de un argumento. Solo tu propio código puede comprobar si este usuario puede tocar este registro.

Valida cada argumento como validarías el cuerpo de una petición. Da a cada herramienta el permiso más pequeño que le baste: una conexión de solo lectura para una herramienta de consulta, una tabla en lugar del esquema completo. No expongas nunca una herramienta que ejecute cualquier SQL o cualquier comando de shell que le pasen. Decide quién llama y autoriza por usuario, igual que hacen tus controladores. Y registra cada llamada, para que cuando una herramienta haga algo raro puedas ver qué argumentos lo pidieron.

Un int en la firma de la función te dice que el argumento es un número. No te dice que ese número pertenezca a quien lo pide.

Si quieres probarlo, empieza con una sola herramienta de solo lectura sobre datos que tu asistente hoy no ve, ejecútala por STDIO en tu máquina y lee cada llamada en el log durante una semana antes de añadir una herramienta que escriba algo. Fuente: el SDK oficial de MCP para PHP en GitHub.

Notas de los lectores

  1. Todavía no hay notas. La primera siempre es la más valiente.
¿Estás construyendo algo parecido? Puedo ayudarte. Escríbeme por WhatsApp