El SDK de Python de MCP rompe las librerías que lo envuelven al saltar a la 2.0
La versión 2.0.0 del paquete mcp eliminó y renombró APIs públicas, y las librerías que lo envuelven sin techo de versión fallan al instalar. Así se detecta y se fija hacia atrás.
El paquete mcp de Python, el SDK oficial del protocolo, publicó la 2.0.0 el 28 de julio de 2026 con APIs públicas eliminadas y renombradas. En PyPI la última es la 2.2.0, así que un pip install mcp a secas resuelve a la rama 2.x: cualquier librería que dependa de él sin techo de versión ha avanzado sola y ahora falla al instalar, con una traza que apunta a tu código y no a la dependencia.
Una colisión de nombres confunde el diagnóstico. El SDK de Python es mcp, en PyPI; el de Rust es rmcp, en crates.io, va por la 3.x y es el que usan Goose y otros agentes escritos en Rust. Si depuras un agente en Rust, esta historia no es la tuya.
Los tres cortes
El primero es el import. streamablehttp_client, en mcp.client.streamable_http, ahora se llama streamable_http_client, con guiones bajos, y el gestor de contexto devuelve una tupla de dos elementos: get_session_id ha desaparecido. Ese segundo detalle no falla al importar; la librería carga bien y revienta en ejecución con ValueError: not enough values to unpack (expected 3, got 2). El yield está en mcp/client/streamable_http.py, sobre la línea 753.
El segundo son los argumentos de transporte. StreamableHTTPTransport.__init__ en 2.x solo acepta (self, url); timeout, sse_read_timeout, headers y auth ya no se admiten ahí y hay que pasarlos al AsyncClient de httpx2. Si los dejas puestos, salta un TypeError: unexpected keyword argument 'timeout'. Conviene ser justos: sse_client sí mantiene timeout y sse_read_timeout. El que cambió es el camino de streamable HTTP.
El tercero es el más silencioso. Los modelos Pydantic renombraron campos a snake_case: inputSchema pasa a input_schema, isError a is_error, structuredContent a structured_content y nextCursor a next_cursor. El JSON en el cable sigue en camelCase porque los alias lo mantienen, así que servidores y clientes se siguen entendiendo; lo que rompe es tu Python, con un AttributeError. Y model_dump() sin by_alias=True devuelve diccionarios en snake_case sin quejarse, capaz de contaminar lo que venga después si espera la forma del protocolo.
Quién está roto
Dos casos verificados bajando los paquetes, no fiándose de un changelog. autogen-ext 0.7.5 declara mcp>=1.11.0 sin techo, usa streamablehttp_client, desempaqueta la tupla de tres y lee inputSchema e isError: su extra [mcp] está roto contra el mcp actual, y a mediados de septiembre seguía así. llama-index-tools-mcp 0.5.0 fallaba igual, con el matiz de que declaraba mcp>=2.0.0 y aun así desempaquetaba la tupla de tres. Se corrigió en la 0.5.1 a finales de agosto; la actual es la 0.6.0.
Si no necesitas las funciones de 2.x, fija hacia atrás. Las notas de la 2.0.0 piden a los autores de librerías un techo <2, y la rama 1.x sigue recibiendo parches de seguridad: instalar mcp>=1.28,<2 con pip resuelve hoy a la 1.30.0. Si la librería que envuelve ya se arregló, actualízala en vez de bajar el SDK.
Antes de dar palos de ciego, mira qué versión tienes instalada y busca en el pyproject.toml de la librería una dependencia de mcp sin techo. Ese techo que falta es el bug entero, y volverá a aparecer en el siguiente salto mayor. Y dos cosas que no son este fallo, por si las has leído: una herramienta que devuelve una lista vacía y produce cero bloques de contenido es comportamiento antiguo de FastMCP en _convert_to_content, idéntico en 1.29.1 y en 2.2.0; y la 2.x quitó además el envoltorio automático del valor de retorno en el Server de bajo nivel.
