Cómo diseñar tools MCP seguras: específicas, con mínimo privilegio y sin sorpresas

Este artículo forma parte de la serie Capacitaciones IThreex: contenido derivado de las formaciones internas que damos a nuestro equipo de ingeniería e implementación de agentes IA sobre la plataforma ABLE.

La tentación de la tool genérica

Cuando se construye un MCP server, la tool genérica parece la decisión inteligente: una sola herramienta que ejecuta cualquier consulta, y el agente decide qué necesita. Menos código, más flexibilidad, menos mantenimiento.

Es también la peor decisión de seguridad posible. Una tool que ejecuta sentencias SQL arbitrarias le entrega al agente —y a cualquiera que logre manipularlo— acceso completo al sistema subyacente.

El patrón correcto: específico y parametrizado

En lugar de una herramienta que recibe una consulta libre, se definen herramientas con estructura fija y parámetros acotados:

• consultar_estado_pedido(id_pedido) en vez de ejecutar_sql(query)
• listar_disponibilidad(fecha_desde, fecha_hasta, tipo_habitacion) en vez de consultar_tabla(nombre, filtros)
• buscar_cliente_por_documento(documento) en vez de select(campos, tabla, where)

La lógica vive en el server, no en la instrucción que el modelo redacta. El modelo aporta los valores; el server decide qué se puede ejecutar con esos valores.

Principios de diseño

1. Mínimo privilegio

Lectura por defecto. La escritura se habilita únicamente cuando el caso de uso la requiere, con alcance acotado a los campos y registros necesarios. Un agente que consulta pero no modifica reduce enormemente el impacto de cualquier incidente.

2. Validación del lado del server

Todo parámetro que llega del modelo se valida antes de ejecutar: tipos, rangos, pertenencia al tenant, autorización del usuario que originó la conversación. Nunca se asume que el LLM envía valores razonables.

3. Descripciones limpias

La descripción de una tool viaja en el contexto y puede filtrarse. No debe contener credenciales, endpoints internos ni información de infraestructura. Solo lo necesario para que el modelo decida cuándo usarla.

4. Sin operaciones irreversibles automáticas

Borrados, pagos, envíos externos y cambios de datos maestros pasan por aprobación humana. El agente propone la acción; la persona la confirma.

5. Trazabilidad completa

Cada invocación registrada: qué agente, qué usuario, qué parámetros, qué resultado. Sin ese registro, un incidente es imposible de reconstruir.

El caso de las tools por defecto

Un detalle que aparece en la práctica: casi todos los agentes vienen con herramientas base (obtener hora actual, cliente HTTP). Son inofensivas en apariencia, pero un cliente HTTP genérico permite alcanzar cualquier endpoint. Vale la pena revisar qué trae habilitado por defecto cada agente y desactivar lo que no se usa — es contexto que se paga y superficie que se expone.

Qué revisar antes de publicar un MCP server

• ¿Existe alguna tool que acepte una consulta o comando libre? Reemplazarla.
• ¿Alguna tool escribe sin necesidad? Bajar a lectura.
• ¿Los parámetros están validados y tipados del lado del server?
• ¿Las descripciones exponen infraestructura o secretos?
• ¿Hay operaciones irreversibles sin aprobación humana?
• ¿Cada invocación queda registrada y es atribuible?

Los MCP publicados en el marketplace de MCPs pasan por esta revisión antes de estar disponibles.