Volver a la Biblioteca
Standards

Estándar de código de módulos MCP

Última actualización: 14 de julio de 2026

Por qué importa un estándar de código

Cada conector que entregamos se ve igual. Eso no es un accidente — es una disciplina. Cuando llega una segunda integración, las capacidades del agente son más fáciles de probar, auditar e intercambiar porque cada módulo MCP sigue la misma estructura, nomenclatura y contrato de errores.

Este documento define el estándar para todos los módulos MCP en la columna vertebral de orquestación de IdeaBosque. Cubre el diseño de directorios, el registro de herramientas, los esquemas de entrada/salida, el manejo de errores, los límites de tasa, el registro de auditoría y el manejo de PII en la frontera.

Estructura de directorios

Cada módulo MCP vive en su propio directorio bajo app/mcp_modules/ con un diseño consistente:

app/mcp_modules/<slug>/
  __init__.py
  module.py          # Registro de herramientas + handlers
  schemas.py         # Modelos Pydantic de entrada/salida
  tests/
    test_module.py
  README.md

Registro de herramientas

Cada módulo registra sus herramientas a través de una interfaz estándar. La columna vertebral de orquestación descubre las herramientas escaneando el punto de entrada register_tools() — sin cableado manual.

def register_tools(registrar):
    """Registrar todas las herramientas proporcionadas por este módulo."""
    registrar.tool(
        name="search_catalog",
        description="Buscar catálogo de proveedores por SKU o nombre",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # llamadas por minuto
    )

Manejo de errores

Los módulos deben lanzar excepciones tipadas, no strings sueltos. La columna vertebral captura subclases de MCPToolError y las convierte en respuestas estructuradas que el agente puede razonar:

  • MCPAuthError — credenciales faltantes o expiradas
  • MCPRateLimitError — límite de tasa del upstream alcanzado
  • MCPTimeoutError — la llamada al upstream excedió el timeout configurado
  • MCPValidationError — la entrada no pasó la validación del esquema
  • MCPUpstreamError — el upstream devolvió un estado de error

Límites de tasa

Cada herramienta declara su propio límite de tasa en la llamada de registro. La columna vertebral los aplica por agente, por herramienta y por ventana. Cuando se alcanza un límite, el agente recibe una respuesta 429 con un header Retry-After — no se cuelga ni reintenta a ciegas.

Registro de auditoría

Cada llamada a herramientas se registra con: timestamp, ID del agente, nombre de la herramienta, hash de entrada (no entrada raw — frontera de PII), estado de salida, duración y sistema upstream. Los logs se escriben en JSON estructurado y se envían al pipeline de observabilidad.

"Cada llamada a herramientas se registra y es auditable" no es una característica que agregamos después. Es lo primero que el estándar exige.

Manejo de PII en la frontera

Los módulos deben declarar qué campos de entrada contienen PII. La columna vertebral hashea estos campos antes de registrarlos y nunca envía PII raw al pipeline de auditoría. Los campos PII se marcan en el esquema:

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

Cuando pii=True está activo, el logger de auditoría reemplaza el valor con un hash SHA-256. El handler de la herramienta sigue recibiendo el valor raw — el manejo de PII se aplica en la frontera de logging, no dentro de la lógica de negocio.

¿Quieres esto construido para tus sistemas?

Cada documento aquí viene de trabajo real de producción. Si tienes un sistema objetivo y un flujo en mente, podemos definir un proyecto en una semana.

Solicitar un proyecto

Descubrimiento de una semana. Obtienes un inventario de sistemas, mapa de flujos y alcance fijo — decidas o no construir con nosotros.