Los servidores MCP se están convirtiendo en plataformas de capacidades, no en envoltorios de herramientas.
Los servidores MCP se están convirtiendo en plataformas de funcionalidades: transformación de herramientas, búsqueda, espacios de nombres, proxies, habilidades, tareas y control de versiones, además de indicaciones sobre cuándo esperar.
Fuentes: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Cualquiera que haya puesto en producción un servidor MCP ya conoce la lista de verificación: contratos explícitos para las herramientas, entradas y salidas estructuradas, semántica de errores adecuada, autenticación, capacidad de observabilidad, una separación clara entre lo que controla el modelo y lo que proporciona el entorno de ejecución (el ID de usuario, el inquilino, los roles y los alcances), autorización en el momento de ejecución, y un modelo de despliegue escalable. El siguiente paso no consiste en un nuevo transporte ni en otro marco de agentes, ni es motivo para reescribir toda la infraestructura. Se trata de que un servidor MCP se asemeja cada vez más a una verdadera plataforma de aplicaciones con capacidades completas, y no a un simple punto de conexión con unas pocas herramientas añadidas al azar.
La diferencia cobra importancia cuando se cuentan con docenas de herramientas, varios servidores MCP, múltiples equipos, usuarios con permisos diferentes, clientes variados, flujos de trabajo de larga duración, habilidades reutilizables, versiones y una cantidad cada vez mayor de contexto. En ese punto, la pregunta ya no es cómo exponer una función de Python como herramienta, sino algo mucho más amplio:
¿Cómo se da forma, se descubre, se compone, se gestiona, se ejecuta, se observa, se prueba y se evoluciona toda una superficie de capacidades sin cargarlo todo en el modelo?
Esa es la dirección hacia la que se dirige MCP, y el resto de este texto la explora en detalle.
El primer servidor MCP y los servidores MCP actuales son cosas muy distintas
Los primeros ejemplos de MCP fueron deliberadamente pequeños: un servidor albergaba un puñado de herramientas:
MCP server
├── search_documents
├── create_ticket
└── get_customer
El cliente enumeró las herramientas, el modelo leyó los esquemas y eligió uno, y el servidor lo ejecutó. Para una configuración pequeña, ese modelo mental sigue siendo adecuado. Con cinco herramientas claras, un backend, un equipo y un caso de uso, no se necesita nada más complejo.
Ahora, aplique el mismo diseño a una empresa real:
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
Eso ya no es un servidor de herramientas. Es un ecosistema de capacidades. Si simplemente concatenas todos los esquemas y los envías al modelo, surgen tres problemas al mismo tiempo: el contexto se pierde antes de que comience la tarea, la selección de herramientas se vuelve más difícil, y el modelo ve capacidades que pueden ser irrelevantes, arriesgadas o confusas para este usuario y este flujo de trabajo.
La presión es similar a la que se discute en temas de seguridad y descubrimiento, pero tiene una consecuencia más amplia que es fácil pasar por alto: el catálogo de herramientas es en sí mismo un artefacto de ingeniería. Puedes buscarlo, transformarlo, filtrarlo y asignarle nombres de espacio de nombres. Puede construirse a partir de las ofertas de otros servidores, y puede contener habilidades y recursos reutilizables. Algunas operaciones pueden pausarse para hacer una pregunta al usuario, las tareas largas pueden ejecutarse en segundo plano, los contratos pueden versionarse, y toda la interfaz puede probarse como cualquier API de producción.
Esa evolución es la que tratan las secciones siguientes.
FastMCP es una buena implementación de esa idea, no la idea en sí
FastMCP aparece en todos los ejemplos porque su arquitectura actual hace que estos patrones sean excepcionalmente visibles. Los proveedores suministran componentes. Las transformaciones remodelan la superficie del componente antes de que el cliente lo vea. La búsqueda puede reemplazar un catálogo enorme por una interfaz de descubrimiento muy sencilla. Los proxies pueden fusionar otros servidores MCP. Las habilidades pueden convertirse en recursos. Las operaciones lentas pueden convertirse en tareas en segundo plano. Las versiones pueden coexistir. Y la superficie MCP resultante puede probarse mediante un cliente real en lugar de llamando directamente a las funciones de implementación.
Eso es útil, pero la lección no es que “todos deberían adoptar FastMCP”. Estos se están convirtiendo en patrones arquitectónicos reutilizables para sistemas MCP. Las mismas ideas pueden implementarse en Python, TypeScript, Go, C#, Java, Rust o en una plataforma interna, con otro framework, con componentes desarrollados a mano o con una pasarela gestionada. Lo importante es darse cuenta de hacia dónde se está desviando la abstracción. El protocolo estandariza la forma en que los clientes se comunican con las capacidades, mientras que la arquitectura de su servidor determina cómo será la interfaz de esas capacidades, y esa interfaz ahora puede ser mucho más inteligente que una lista estática de funciones decoradas.
1. Transformación de herramientas: una API de backend no debería convertirse automáticamente en la API del agente
Una de las ideas más prácticas aquí también es una de las más simples. Una herramienta expuesta por un servicio upstream puede ser técnicamente correcta pero aún así inútil para un LLM.
Imagínese una integración interna de Salesforce que ofrezca esta operación:
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
Dentro del servicio que lo posee, esa firma puede estar bien. ¿Debería el modelo ver exactamente ese contrato? Probablemente no. La versión destinada al modelo se leería mejor de esta manera:
find_customer_account(
company_name,
include_archived=False,
)
La operación subyacente permaneció igual. Lo que cambió es la interfaz que se presenta al modelo, y eso es la transformación de herramientas.
FastMCP lo ofrece a través de una capa de transformación dedicada: cambiar el nombre de una herramienta, reescribir su descripción, cambiar los nombres de los argumentos, modificar los valores predeterminados, ocultar argumentos que no son necesarios, ajustar etiquetas y anotaciones, y envolver la ejecución en lógica personalizada. En resumen, el flujo es el siguiente:
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
Varios motivos hacen que esto sea valioso.
Un modelo no necesita conocer detalles de la infraestructura. Campos como tenant_uuid, internal_region, api_version o include_deleted_internal_records corresponden al ámbito del backend. Cuando el modelo no debe decidir un valor, hay que excluirlo por completo de su esquema. Esto sigue la regla del contexto en tiempo de ejecución: los valores confiables deben permanecer fuera de los límites de las capacidades del modelo y nunca aparecer en los argumentos definidos por él.
En segundo lugar, el nombre que utilice el sistema upstream puede quedar fuera del alcance del agente. Un proveedor o servicio heredado podría publicar operaciones diseñadas para desarrolladores humanos, lo cual resulta inadecuado para un LLM que debe elegir entre 80 herramientas. La pasarela puede ofrecer un vocabulario más ordenado sin pedir al equipo upstream que renombré su API.
En tercer lugar, el contrato del agente puede mantenerse estable mientras el backend cambia. Esto es más importante de lo que parece a primera vista. Si el backend pasa a una nueva versión de la API de Salesforce, renombra un parámetro interno o convierte una operación en un par, la herramienta que ve el modelo no necesita cambiar en absoluto. La capa de transformación actúa como una capa de protección entre quien consume la funcionalidad y quien la implementa. Es una arquitectura de software habitual, simplemente aplicada ahora a las interfaces orientadas a agentes.
El contrato del backend sirve al sistema que posee la funcionalidad. Lo que presenta la capa MCP debe servir al agente que la llamará.
2. Búsqueda de herramientas: el catálogo se convierte en un contexto buscable
Esto cobra importancia en cuanto el ecosistema crece. Una implementación típica inicial se realiza de la siguiente manera:
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
Eso funciona mientras la lista es corta, pero se vuelve más ineficiente con cada herramienta adicional. El enfoque más maduro es el siguiente:
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
La función de búsqueda de herramientas de FastMCP hace concreta esta idea. En lugar de devolver el catálogo completo, el servidor expone herramientas de descubrimiento sintéticas como search_tools y call_tool. Las estrategias integradas actuales son la coincidencia con expresiones regulares y el ranking BM25. BM25 es un sistema de ranking léxico, no una búsqueda vectorial semántica, pero la arquitectura no depende de BM25. En su propia plataforma, el ranking podría provenir de palabras clave, embeddings, un recuperador híbrido con reranking, filtros de metadatos, estadísticas de uso, puntuación basada en políticas, o un índice creado específicamente para las capacidades de su dominio.
El punto clave es que las herramientas se convierten en objetos recuperables. En lugar de incluir 300 definiciones de herramientas en el contexto, el modelo podría llamar a search_tools("find customer opportunities and open deals") y obtener tres o cuatro resultados, como por ejemplo salesforce_find_account, salesforce_list_opportunities y salesforce_get_pipeline_summary. Solo esos esquemas pasan a la siguiente etapa.
Eso representa más que un simple ahorro de recursos. Mejora las decisiones que debe tomar el modelo. “Elegir una capacidad entre 300 esquemas” y “buscar capacidades relacionadas con esta tarea y luego elegir entre los cuatro resultados relevantes” son problemas de razonamiento muy diferentes.
El descubrimiento progresivo también sirve de base a los enfoques de ejecución de código, pero la búsqueda de herramientas es útil incluso si nunca se ejecuta código escrito por un modelo, y funciona con llamadas a herramientas completamente normales. Hay una regla de seguridad que debe heredarse del trabajo de autorización: buscar en el catálogo que al usuario le está permitido descubrir, y no en el catálogo completo de la plataforma. Si la búsqueda muestra los nombres y esquemas de herramientas administrativas prohibidas, los detalles de las capacidades se han filtrado, incluso cuando se rechaza su ejecución posteriormente. Por lo tanto, el verdadero flujo de trabajo necesita el filtro de autorización antes de la búsqueda.
Considérelo como ingeniería de contexto aplicada a las capacidades.
3. Espacios de nombres: la composición genera un problema de identidad antes que un problema de escalabilidad
Al comenzar a combinar servidores MCP, surge de inmediato un problema extremadamente molesto: cada servidor viene con nombres genéricos como search, get_user, list_files o create_note. Si se fusionan un servidor de Salesforce, uno de Google Drive, uno de base de conocimientos y uno de GitHub, siendo que tres de ellos exponen la función search, las dudas se acumulan. ¿Cuál search está siendo llamado por el modelo? ¿Cuál aparece en los registros? ¿Cuál está cubierto por una regla de política? ¿Cuál cambió cuando se modificó la huella del esquema?
Por eso los nombres de espacio son importantes una vez que MCP deje de ser un servidor aislado. FastMCP ofrece una transformación de nombres de espacio que agrega un prefijo a los componentes durante su composición, de modo que search se convierte en salesforce_search, gdrive_search, knowledge_base_search y github_search. Las URI de recursos también pueden tener nombres de espacio en su ruta.
Evitar colisiones es la ventaja obvia. La trazabilidad es la más sutil: un prefijo registra el origen de una capacidad, y ese origen sirve para establecer reglas de política, rastros de auditoría, seguimiento, límites de velocidad, propiedad, migraciones, depuración y las descripciones que lee el modelo.
No exageres, sin embargo. Un nombre como enterprise_internal_platform_team_alpha_salesforce_v2_search_customer no es mejor solo porque es único a nivel global. Un espacio de nombres establece la identidad, y la transformación aún puede hacer que la interfaz final sea agradable para el modelo. Son dos problemas relacionados pero distintos:
Source identity
→ Namespace
Agent usability
→ Transformation
4. Visibilidad: la ingeniería de contexto no se trata solo de texto
Cuando se menciona la ingeniería de contexto, la mayoría de las personas piensa en prompts de sistema, documentos recuperados, memoria, historial de chats y quizás descripciones de herramientas. Sin embargo, cualquier capacidad que el modelo pueda ver también forma parte de su contexto.
Tomemos un flujo de trabajo de investigación con clientes. ¿Qué haría el modelo con herramientas como rotate_api_key, terminate_employee, rebuild_search_index, publish_release y admin_delete_tenant, incluso si el usuario tiene derechos sobre algunas de ellas? Nada de eso sirve para la tarea. Una interfaz más ordenada podría ser:
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
La visibilidad en tiempo de ejecución se encarga de esto. La visibilidad de componentes de FastMCP le permite activar o desactivar componentes por nombre, clave o etiqueta; un componente desactivado desaparece de las listas y no puede ser resuelto a través de la interfaz del servidor habitual. Los conjuntos de capacidades específicos para flujos de trabajo, las banderas de funcionalidad, las diferencias entre entornos, las herramientas beta, los períodos de mantenimiento, los productos específicos para cada cliente, los perfiles de agente, o simplemente un espacio de acción más reducido para el modelo, todos utilizan el mismo mecanismo:
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
La distinción con respecto al trabajo de seguridad sigue vigente: la visibilidad no es un sustituto de la autorización. La visibilidad responde a si una capacidad pertenece a la superficie actual. La autorización responde a si este principal autenticado realmente tiene permiso para usarla. Una buena plataforma MCP empresarial generalmente busca ambas cosas, reduciendo primero la superficie y aplicando luego la autorización.
5. Proxy MCP: un servidor como puerta de enlace a otros
Ahora el diseño se vuelve realmente interesante. Un servidor no necesita poseer todas las capacidades que ofrece; puede situarse delante de otros servidores MCP. El proveedor de proxy de FastMCP obtiene herramientas, recursos e indicaciones de un servidor MCP remoto y los vuelve a publicar desde el actual.
Así, una cadena simple como esta:
AI client
↓
Salesforce MCP
puede convertirse en una pasarela que conecte varios servidores upstream, y dicha pasarela no necesita copiar ninguna lógica de negocio de ellos. Proxía sus capacidades y añade una capa de plataforma alrededor: autenticación, políticas, nombramiento, visibilidad y observabilidad.
Eso representa un cambio significativo en la forma en que se diseñan los sistemas: los servidores MCP dejan de ser islas separadas y pueden formar una red. Un equipo puede encargarse de la integración con Salesforce, otro del conocimiento del proyecto y otro de las operaciones de infraestructura, mientras que la pasarela empresarial combina todo en una única interfaz de producto sin obligar a los equipos a utilizar un repositorio compartido o un ciclo de lanzamiento común.
Los proxies también son útiles de maneras poco llamativas: conectan los transportes, proporcionan un punto de conexión estable frente a servidores en la cadena de suministro que cambian constantemente, centralizan la autenticación, añaden capacidad de observación, aplican políticas uniformes, organizan los nombres y mantienen la topología interna alejada de los clientes.
Nada de esto implica que toda empresa necesite una única pasarela central enorme. Puedes tener varias, divididas por área: ingeniería, ventas, investigación, operaciones de plataforma. MCP proporciona los límites del protocolo que permiten combinarlas de manera ordenada.
En el momento en que los servidores MCP pueden consumir y reorganizar entre sí, la unidad natural de diseño deja de ser un único servidor. Se convierte en un grafo de capacidades gestionadas.
6. Habilidades como recursos MCP: un servidor puede distribuir conocimientos, no solo acciones
Las herramientas responden a qué puede hacer el sistema. Los recursos indican qué información puede obtener un cliente. Las habilidades plantean una tercera pregunta: ¿cómo debe un agente llevar a cabo un tipo específico de tarea?
Una habilidad suele encontrarse en un directorio que contiene instrucciones además de material de apoyo como ejemplos, esquemas, scripts, listas de verificación, referencias o guías del dominio. Tradicionalmente, estos directorios estaban dentro del entorno de un cliente, en ubicaciones como ~/.claude/skills/, ~/.cursor/skills/ o ~/.gemini/skills/. En cambio, el proveedor de habilidades de FastMCP las publica como recursos MCP, de modo que una habilidad recibe direcciones del formato skill://customer-research/..., que incluyen su archivo principal SKILL.md, un manifiesto, un archivo de ejemplos y un esquema JSON.
Esto es más importante de lo que parece, ya que el servidor ahora puede distribuir conocimientos procedimentales junto con capacidades ejecutables. Imagine una plataforma interna de investigación de clientes cuya interfaz MCP ofrece herramientas como search_salesforce, search_knowledge_base y generate_report, además de habilidades que reflejan cómo el equipo define una oportunidad calificada, la metodología de investigación, el formato esperado del informe, los requisitos de evidencia y ejemplos de informes de calidad.
La herramienta indica al agente qué puede ejecutar. La habilidad le muestra cómo espera su organización que se realice el trabajo. La división es útil: no es necesario incluir cada procedimiento operativo en un único prompt de sistema enorme, ni es preciso copiar manualmente la misma habilidad en cada cliente de IA. Un cliente que comprende los recursos MCP puede descubrir y obtener la habilidad a través de la misma interfaz de protocolo, mientras que un cliente limitado a herramientas aún puede acceder a los recursos mediante una capa de adaptación que los envuelve en llamadas a herramientas.
Un servidor MCP puede empaquetar capacidades, contexto y conocimientos operativos como un único límite de producto reutilizable.
7. Inducción: permitir que una capacidad haga una pregunta al usuario
La interacción más simple con las herramientas es unidireccional: el modelo llama a una herramienta y esta devuelve un resultado. Los flujos de trabajo reales son más complicados. Supongamos que el usuario pide crear un nuevo entorno en la nube para el proyecto de análisis, y la herramienta encuentra tres regiones válidas y dos perfiles de despliegue. O resulta que el entorno solicitado costará aproximadamente 420 dólares al mes. O aparecen dos cuentas de Salesforce con nombres casi idénticos. La siguiente acción adecuada no siempre es adivinar; a veces la herramienta debe hacer la pregunta.
Esa es la idea detrás de la elicitación mediante MCP. FastMCP cuenta con una API práctica para solicitar entrada estructurada al usuario, pero este patrón pertenece a MCP y no a ningún framework de Python en particular.
La especificación MCP del 2026-07-28 rediseñó este intercambio en torno a las solicitudes de múltiples viajes (MRTR), de modo que se adapte al nuevo modelo de protocolo sin estado en lugar de depender de una sesión que permanezca abierta en ambas direcciones. Lo que cambió fue el mecanismo de transmisión. La capacidad en sí se mantuvo: una operación del servidor aún puede pausarse a la espera de la entrada del usuario en medio de un flujo de trabajo. Los usos típicos incluyen resolver entidades ambiguas, completar parámetros faltantes, confirmar operaciones costosas, revisar el contenido generado antes de su publicación, elegir un entorno de destino y recopilar información estructurada de forma gradual.
Existe una advertencia de seguridad en este caso: preguntar al usuario no equivale a autorizar la acción. Cuando la eliminación requiere aprobación, el propio backend debe almacenar y hacer cumplir ese estado de aprobación. Un amable “¿está seguro?” en lenguaje natural no resuelve el asunto. En operaciones sensibles, la intervención humana debe traducirse en un cambio real de estado.
8. Registro de actividades: útil para el cliente, pero la observabilidad en producción va más allá
El registro de actividades se divide en dos conceptos distintos. Uno es la información que se proporciona al cliente sobre la ejecución: “Buscando en Salesforce… Se encontraron 18 oportunidades coincidentes… Generando informe… Informe creado”. El otro es la observabilidad en producción: identificadores del seguimiento, la solicitud, el usuario principal y el arrendatario, además del nombre de la herramienta, el proveedor, la latencia, los intentos de reintentar, la decisión de la política, cualquier ID de tarea y el código de error. Trátelos como tareas separadas.
FastMCP sigue documentando el registro de actividades por parte del cliente, en el cual un servidor envía mensajes de depuración, información, advertencia o error de vuelta a un cliente MCP que los soporta. Esto ayuda durante el desarrollo y permite al cliente tener una idea de qué está haciendo una determinada funcionalidad. Pero hay un cambio importante en el protocolo para 2026: la función de registro propia del protocolo fue obsoleta para nuevas implementaciones en MCP a partir de 2026-07-28. Por lo tanto, un nuevo diseño de observabilidad en entornos de producción no debería depender de los mensajes de registro de MCP. Utilice la observabilidad habitual de las aplicaciones: registros estructurados, trazas de OpenTelemetry, métricas, Datadog, Grafana y Tempo, CloudWatch, ELK, o cualquier otra herramienta que ya utilice su organización.
Una forma de abordarlo es la siguiente: los mensajes de estado permiten que el usuario o el anfitrión se mantengan al tanto de lo que ocurre, mientras que la telemetría del lado del servidor ayuda al equipo de ingeniería, seguridad y operaciones a comprender el sistema. En una implementación empresarial, este segundo tipo es indispensable. Una solicitud de usuario puede viajar desde un anfitrión de IA a través de una pasarela MCP, hasta un servidor proxy, luego a una API SaaS y finalmente a un proceso en segundo plano, y un único seguimiento debería explicar toda esa ruta. Cuanto más fácil sea proxyear y componer MCP, mayor importancia tendrá esta visión distribuida.
9. Tareas en segundo plano: una capacidad puede tener un ciclo de vida de ejecución
El flujo clásico de las llamadas a herramientas consta de solicitud, ejecución y resultado, y supone que el trabajo cabe dentro de una sola solicitud. Muchas capacidades empresariales valiosas no se adaptan a este modelo: un informe de cliente de 60 páginas, el indexado de 20,000 documentos, un análisis de un repositorio grande, una exportación completa de las oportunidades de Salesforce, la creación de una presentación con materiales de apoyo, un escaneo de cumplimiento o un gran lote de registros. Estos trabajos pueden durar minutos, requerir intentos repetidos, sobrevivir a la desconexión del cliente, informar sobre su progreso o ejecutarse en un proceso diferente al endpoint MCP.
La extensión MCP Tasks proporciona un ciclo de vida propio del protocolo para las ejecuciones de larga duración. Las tareas en segundo plano de FastMCP lo demuestran claramente: un componente se marca como capaz de ejecutar tareas, el cliente recibe un identificador de tarea y la ejecución pasa a un proceso en segundo plano respaldado por un sistema de tareas, en lugar de mantener abierta la llamada original.
Eso difiere de escribir asyncio.create_task(...). La concurrencia en Python mantiene el trabajo dentro de su proceso, mientras que una tarea a nivel de protocolo establece un contrato entre servidor y cliente para tareas de larga duración, de modo que dicha capacidad tiene un ciclo de vida que el cliente comprende. Otra indicación de que un servidor MCP se está convirtiendo en una superficie de aplicación completa y no en un mero complemento RPC es que su función no se limita a llamar a una función y devolver JSON; también puede tener que iniciar tareas, mantener el estado, mostrar el progreso, gestionar las cancelaciones, recuperarse de fallos y devolver el resultado más tarde.
10. Versionado: cuando los agentes dependen de tus herramientas, el esquema es una API
Toda plataforma interna exitosa llega a un momento en el que alguien modifica el esquema y daña a un consumidor del que nadie sabía que existía. MCP no es inmune a esto por arte de magia.
Supongamos que la versión 1 de una capacidad es calculate_risk(project_id), y la versión 2 se convierte en calculate_risk(project_id, methodology="v2", include_history=True). Si se implementa el nuevo contrato de inmediato en todos los agentes y clientes, se habrá realizado un cambio en la API que rompe la compatibilidad anterior.
La versiónado de componentes de FastMCP permite que varias implementaciones de una misma herramienta, recurso o comando operen bajo un único identificador lógico. Por defecto, se sirve la versión más reciente, y los filtros de versión pueden crear interfaces distintas para clientes específicos o períodos de migración concretos.
La arquitectura general es más importante que la API específica. Una vez que MCP se convierte en infraestructura compartida, la evolución de sus capacidades merece el mismo enfoque que cualquier contrato de servicio público. ¿Qué cambios están causando problemas? ¿Qué clientes siguen utilizando la versión v1? ¿Pueden v1 y v2 funcionar simultáneamente, y cuánto tiempo debería durar el período de migración? ¿Qué versión cuenta con aprobación para uso en producción, quién tiene acceso a cada una y en qué momento se retira la versión antigua? Un registro empresarial útil podría llegar a registrar el nombre de la herramienta, el proveedor, la versión, la huella del esquema, el propietario, la clase de riesgo, la fecha de aprobación y quien la aprobó, además de la fecha en que se dejó de usar.
Para un servidor con cinco herramientas, esto podría parecer excesivo. Pero para una plataforma que atiende a 20 equipos, no lo es.
En cuanto otro sistema dependa de tu esquema MCP, se trata de una API, tenga nombre o no.
11. Pruebas: verifica toda la superficie de MCP, no solo la función en Python
Las pruebas son el aspecto menos llamativo aquí, pero muy probablemente el más importante. Imagine que esta función funciona sin defectos:
async def find_customer(company_name: str):
...
Aun así, el servidor MCP podría estar dañado, con el problema en cualquier parte relacionada con esa función: un esquema generado incorrectamente, una descripción que engaña, una transformación que oculta el argumento equivocado, un espacio de nombres que renombra silenciosamente la herramienta, una visibilidad que expone capacidades de administrador, un filtrado de autorización para el usuario incorrecto, un proxy que no transmite las credenciales, una capa de búsqueda que no puede localizar la herramienta, un filtro de versión que proporciona la versión v1 cuando se pretendía v2, una salida que no coincide con su estructura, o un trabajo en segundo plano que nunca alcanza un estado final.
Por eso, probar la interfaz real de MCP es una mejor práctica. La guía de pruebas de FastMCP ejecuta un cliente real contra el servidor dentro del mismo proceso, de modo que se puede probar el comportamiento del protocolo sin necesidad de desplegar un servicio separado. En lugar de probar solo la implementación:
result = await find_customer("Acme")
assert result
También pruebe qué es lo que realmente ve el consumidor de MCP:
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
Para una plataforma de capacidades de producción, al menos cuatro capas merecen pruebas.
Las pruebas de contrato verifican que el nombre de la herramienta, su descripción, los esquemas de entrada y salida, las anotaciones y la versión coincidan con las expectativas.
Las pruebas de detección determinan qué herramientas puede ver un usuario y flujo de trabajo determinado y cuáles permanecen ocultas, si la búsqueda encuentra la capacidad adecuada y si es posible que aparezcan accidentalmente capacidades prohibidas.
Las pruebas de ejecución comprueban si la llamada tiene éxito, si los errores están estructurados correctamente, si las reintentos son seguros, si los proxies transmiten la identidad adecuada y si la autorización se vuelve a verificar en el momento de la ejecución.
Las pruebas de ciclo de vida analizan si las tareas en segundo plano finalizan o fallan de manera limpia, si se pueden cancelar, si una migración de versión mantiene funcionales a los clientes antiguos y qué ocurre cuando un servidor MCP ascendente está inactivo.
Nada de eso está probando el framework. Está probando el contrato de tu producto. Una vez que MCP sea la capa de funcionalidades para varios clientes y agentes, ese contrato merece la misma disciplina que se le daría a REST, gRPC o interfaces basadas en eventos.
Al combinar todas las piezas, el servidor se ve muy diferente
Si unimos todas estas ideas, lo que resulta permite el descubrimiento, el enrutamiento, la adaptación de interfaces, el control de contexto, las políticas, flujos de trabajo interactivos, ejecución asíncrona, conocimientos operativos reutilizables, compatibilidad y un ciclo de vida de ingeniería. Hace tiempo que dejó de ser simplemente un servidor con algunas herramientas; es una interfaz de producto. Mejor aún, nada de esto exige que el proveedor del modelo posea la lógica de negocio, ya que la misma plataforma puede operar detrás del host compatible con MCP que elija la organización. Esa es la parte estratégicamente importante.
Parte de la mejor optimización ocurre antes de que el modelo vea algo
Muchos debates sobre el rendimiento de la IA se centran en el modelo: cuál elegir, cuántos parámetros tiene, cuán grande es su ventana de contexto y qué tan bueno es su razonamiento. Todo eso es importante, pero en entornos de producción la arquitectura que rodea al modelo puede eliminar una enorme cantidad de tareas innecesarias.
Supongamos que la plataforma cuenta con 300 herramientas. Una implementación ingenua incluye los 300 esquemas en el contexto del LLM con la esperanza de que elige bien. Una implementación más cuidadosa reduce gradualmente esa cantidad. Las políticas establecidas reducen las 300 a 85 permitidas. La visibilidad del flujo de trabajo reduce esas a 24 que son relevantes. La búsqueda deja solo 4 candidatos, y solo esos 4 esquemas se cargan para que el modelo haga su elección final.
El modelo no se volvió más inteligente. El sistema sí. Esa es una razón importante por la cual estos patrones son importantes en la producción: el contexto disminuye, la precisión de la selección mejora, las acciones irrelevantes desaparecen, la autorización se vuelve más clara, los contratos del backend permanecen fuera del modelo, y los equipos independientes pueden trabajar sin fusionar código, todo antes de que se le pida al LLM que razone sobre su próxima acción.
Una buena arquitectura de agentes no se limita a mejorar el razonamiento del modelo. También da forma al material sobre el cual el modelo debe razonar.
De un servidor MCP a una red de ellos
En los sistemas empresariales, aquí es donde la evolución se vuelve realmente interesante. La unidad original se veía así:
AI client
↓
MCP server
↓
API
La unidad siguiente se asemeja más a una pasarela en el centro, con servidores de dominio y trabajadores detrás de ella. Cada servidor MCP se mantiene enfocado, cada equipo gestiona su propio dominio y cada servicio se lanza según su propio calendario. La pasarela crea la interfaz adecuada para cada usuario, el modelo solo descubre lo que necesita, un flujo de trabajo extenso se convierte en una tarea, y una habilidad enseña al agente cómo la empresa espera que funcione el flujo de trabajo, todo ello permaneciendo accesible a través de los límites de MCP.
Eso se parece mucho más a una plataforma de aplicaciones distribuidas que a un conjunto de envoltorios de funciones, y por eso calificar a los servidores MCP como “solo herramientas para LLM” subestima cada vez más lo que realmente están convirtiéndose.
No construyas una plataforma hasta que aparezca un problema relacionado con una plataforma
El peligro es evidente. Después de leer todo esto, uno podría concluir que un servidor interno con cinco herramientas necesita tres pasarelas, un registro de capacidades, búsqueda integrada en los esquemas de las herramientas, unos pocos espacios de nombres, negociación de versiones en tiempo de ejecución, una cola distribuida para tareas, un mercado de habilidades y una docena de transformaciones en capas.
Por favor, no lo haga.
¿Un servidor con seis herramientas estables que todo usuario debería ver? Simplemente envíe esas seis. Si el esquema del backend ya está limpio, no agregue una transformación solo porque un framework la soporta. Con un único servidor no hay necesidad de una topología de proxy. Si una operación termina en dos segundos, probablemente no necesite una tarea. Si ya nadie utiliza la versión v1, no hay razón para mantener vivas dos versiones para siempre.
La arquitectura debe surgir como respuesta a un problema, y no al revés. El objetivo no es maximizar la cantidad de características del framework en tu repositorio. Se trata de que, cuando aparece el problema, MCP ya no te obligue a crear una plataforma de IA completamente personalizada alrededor de él. El ecosistema ahora ofrece bloques de construcción reutilizables para los mismos problemas que enfrenta cualquier plataforma de aplicaciones madura, y eso es progreso.
Se puede cambiar el framework; lo que realmente importa es la arquitectura
FastMCP merece reconocimiento por hacer que muchas de estas ideas estén visibles en un solo lugar. Sus documentaciones explican en detalle los proveedores, las transformaciones, la búsqueda, la asignación de nombres, la visibilidad, el proxying, las habilidades, la obtención de información, las tareas, las versiones y las pruebas, lo que facilita comprender cómo se relacionan las distintas partes de un servidor MCP. Varios de estos patrones se utilizan en la práctica porque resuelven problemas reales: reducir el contexto de las herramientas, separar los contratos orientados a los modelos de los del backend, limitar las capacidades que se exponen, integrar diferentes componentes y mantener la estructura resultante más sencilla de operar.
Aun así, los equipos deberían adoptar la idea y no la API de la biblioteca. Pregúntense: ¿necesitamos descubrimiento de herramientas bajo demanda? ¿Una capa de transformación orientada a modelos? ¿Una pasarela de capacidades? ¿Visibilidad específica para flujos de trabajo? ¿Habilidades distribuidas a través de recursos MCP? ¿Un ciclo de vida duradero para operaciones prolongadas? ¿Contratos de capacidades versionados? ¿Estamos probando lo que realmente ve el cliente? Luego construyan las soluciones con la tecnología que mejor se adapte a su organización.
El protocolo brinda interoperabilidad. El framework ofrece comodidad. La arquitectura sigue siendo suya.
Qué cambió
El cambio más importante en MCP no es una lista de funciones más extensa. Se trata del alcance cada vez mayor que se espera que tenga un servidor MCP. Al principio era sencillo: se publicaba una herramienta, el modelo la llamaba y se obtenía un resultado. El modelo que está tomando forma actualmente implica obtener capacidades de varios sistemas, normalizar sus contratos, organizar las identidades mediante nombres específicos, filtrar según la relevancia, autorizar lo que está permitido, buscar información en grandes catálogos según sea necesario, distribuir habilidades y contexto reutilizables, hacer una pregunta al usuario cuando se necesita una elección, trasladar tareas lentas a una ejecución duradera, observar todo el proceso, versionar los contratos y probar la funcionalidad como un producto real.
Eso es un trabajo completamente diferente. MCP sigue siendo deliberadamente un protocolo y no un marco de aplicaciones, pero el ecosistema que lo rodea está convirtiendo a los servidores MCP en una verdadera frontera de aplicaciones, donde se pueden crear capas de enrutamiento, gobernanza, ciclo de vida, compatibilidad y composición al igual que en los backends maduros.
Un servidor MCP bien construido ya no es simplemente una forma de darle a un LLM una función adicional. Puede ser un producto de capacidades reutilizables que sirva a agentes, modelos, equipos y aplicaciones de clientes por igual. Un servidor aislado puede mantenerse pequeño, mientras que una red de ellos puede convertirse en una plataforma empresarial. El modelo sigue siendo flexible, la capa de capacidades permanece regulada, y el cliente superior puede cambiarse sin tener que reconstruir la capacidad empresarial subyacente.
Leer más
- MCP 2026-07-28: Cómo la especificación sin estado cambia el diseño de los servidores remotos — Cómo la versión 2026-07-28 sin estado de MCP elimina las sesiones y el proceso de handshake, agrega MRTR, tareas y sugerencias de caché, y qué implica esto para la migración.
- Navegador en la nube: Una plataforma de navegador remoto segura para cualquier agente de IA — Un diseño de referencia para un servicio de navegador remoto neutral con respecto a los modelos: gateway, workers, vista en vivo con WebRTC, procesos de aprobación, protecciones contra SSRF, reproducción y cada configuración posible.