Qué descubre MCP en una sesión nueva de Claude Code

Model Context Protocol (MCP) conecta Claude Code con servicios y herramientas externos. En una prueba de Bit Cloud relatada de primera mano por un ingeniero de esa empresa para The New Stack, dos llamadas permitieron a una sesión nueva encontrar cuatro componentes y sus dependencias, incluida una entidad de tickets compartida por la aplicación y el servicio. El autor declaró que trabajaba en Bit Cloud.

Qué encontró MCP en una sesión nueva

La sesión empezó sin código local ni historial de conversación. Según el autor, la única orientación del espacio de trabajo era un AGENTS.md genérico creado por bit new. Claude Code consultó primero read_scope y después read_components: así recuperó la estructura de una aplicación React, un servicio Express respaldado por MongoDB, una entidad compartida de tickets y un componente de pasarela.

La aplicación y el servicio dependían de la misma versión de la entidad de tickets. Ese registro versionado aportó una pista concreta sobre cómo se relacionaban las piezas, aunque el conocimiento recuperado era estructural: no describía por sí mismo cómo se comportaba el servicio en ejecución.

Del mapa de componentes al cambio de código

Tras consultar los registros, Claude Code importó los cuatro componentes e inspeccionó el código. El cambio solicitado —filtrar tickets por estado y persona asignada— se hizo en la aplicación, del lado del cliente, sin modificar la entidad ni el servicio.

El autor informó de 41 pruebas aprobadas, incluidas nueve nuevas para los filtros. Las pruebas de integración de MongoDB podían omitirse si el ejecutor no lograba iniciar una base de datos temporal, de modo que el total no demuestra que esas pruebas se ejecutaran. El autor también comprobó manualmente la persistencia: creó un ticket y un comentario, reinició la plataforma con la misma base de datos y verificó que ambos seguían allí.

La referencia de API de la aplicación enumeraba cuatro rutas para un servicio simulado usado en las pruebas. El autor no comprobó si coincidían con las del servicio real. En esa demostración, la cuenta era predefinida y el secreto de firma, público; seguían pendientes el control de concurrencia, las migraciones, los procedimientos de recuperación y la obligatoriedad de las pruebas de base de datos.

La diferencia entre registros de dependencias y memoria también importa. El relato de The New Stack describe los primeros como información vinculada a versiones de componentes; las notas de memoria, en cambio, pueden guardar instrucciones o decisiones del proyecto, como el motivo para descartar una función. Son datos distintos para recuperar en una sesión. Si buscas profundizar en la memoria de Claude Code entre proyectos, puedes leer el análisis de NeoTeo sobre esa función.

Cómo elegir el alcance de configuración de MCP

Anthropic distingue tres alcances para configurar MCP en Claude Code: local se aplica al proyecto actual en el equipo del desarrollador; project comparte la configuración con el equipo mediante .mcp.json en la raíz del proyecto; y user conserva la configuración para los proyectos de esa persona. La guía rápida de Anthropic indica que local es el alcance predeterminado. (Documentación de configuración de MCP)

Para probar una conexión solo en tu entorno, el alcance local corresponde al proyecto actual. Si el equipo necesita compartir la configuración del servidor, Anthropic describe project como la opción para hacerlo desde el archivo .mcp.json del proyecto.

Qué carga MCP en el contexto

Anthropic explica que los nombres de las herramientas MCP se cargan al inicio de la sesión, mientras que sus esquemas completos se incorporan cuando hacen falta. La empresa describe como bajo el coste de contexto de las herramientas MCP inactivas; esa descripción no cuantifica el consumo de cada llamada ni de sus resultados. Anthropic también distingue MCP, que conecta con sistemas externos, de Skills, que aportan conocimiento o flujos de trabajo reutilizables. (Descripción de las funciones de Claude Code)