Siebel MCP Gateway

Expone la API REST de Oracle Siebel como herramientas MCP sobre HTTP transmisible, de modo que un cliente agéntico pueda consultar/crear/actualizar/eliminar registros de Siebel y obtener el catálogo de objetos sin tener que gestionar credenciales de Siebel por sí mismo.

El modo simulado modela un esquema sintético de demostración de derivaciones sanitarias (paciente → derivación a comunidad/hospital → compromiso del Formulario 17 → historial de tratamiento), construido para reflejar fielmente un conjunto documentado de hallazgos deliberados de calidad de datos en lugar de suavizarlos: registros de pacientes duplicados en dos organizaciones, un campo de estado que en realidad contiene urgencia, un script que sobrescribe silenciosamente los límites declarados de un Workflow, dos campos de "visitas restantes" que divergen. Todos los datos son sintéticos.

Stack

Python 3.12+, el SDK oficial mcp (MCPServer, el nombre actual de lo que en versiones anteriores del SDK se llamaba FastMCP), httpx para las llamadas salientes a Siebel, uvicorn como servidor ASGI.

Related MCP server: MuleSoft Code MCP

Ejecución local

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# Fill in .env, or for a first run without a live Siebel instance:
#   MOCK_MODE=true
#   MCP_GATEWAY_TOKEN=<any string you'll also give your client>
MOCK_MODE=true MCP_GATEWAY_TOKEN=dev-token \
  uvicorn app.server:app --host 0.0.0.0 --port 8000

Comprobación de salud: curl http://localhost:8000/healthz → {"status":"ok"} (sin autenticación requerida, para que funcionen los comprobadores de salud de la plataforma).

Endpoint MCP: http://localhost:8000/mcp — cada solicitud necesita Authorization: Bearer <MCP_GATEWAY_TOKEN>, ya que el endpoint en sí no tiene otro control de acceso una vez desplegado públicamente.

Pruebas

python3 -m pytest -v

Todas las pruebas se ejecutan contra el almacén simulado en memoria o un transporte HTTP simulado — sin llamadas de red, sin necesidad de una instancia real de Siebel.

Despliegue en Render

1. Sube este repositorio a GitHub.

2. Concede acceso a Render al repositorio primero, si aún no está conectado. La aplicación de GitHub de Render solo ve repositorios a los que se le ha dado acceso explícitamente — un repositorio recién creado no aparecerá en el selector de repositorios de Render solo porque lo poseas. Ve a github.com/settings/installations → busca Render → Configurar → o cambia a "Todos los repositorios" o añade este repositorio a la lista permitida → Guardar. Solo entonces aparecerá de nuevo en la pantalla de conexión de Render.

3. En el panel de Render: Nuevo → Blueprint (no "Web Service" — este repositorio tiene un render.yaml, y Blueprint es lo que lo lee). Conecta el repositorio, confirma la rama main y la ruta predeterminada render.yaml.

4. Render muestra un formulario para cada variable de entorno marcada con sync: false en render.yaml — rellena estos campos antes de desplegar:

   • MCP_GATEWAY_TOKEN — genera uno, p. ej. openssl rand -hex 32

   • MOCK_MODE — true para empezar a servir datos simulados inmediatamente (recomendado mientras la instancia real de Siebel no esté lista), false si ya tienes credenciales reales de Siebel para introducir a continuación

   • SIEBEL_BASE_URL / SIEBEL_USERNAME / SIEBEL_PASSWORD — solo se requieren si MOCK_MODE=false; déjalos en blanco si empiezas en modo simulado

5. Haz clic en Deploy Blueprint. Render asigna https://<your-service>.onrender.com.

Para cambiar cualquiera de estos valores más adelante (p. ej. cambiar MOCK_MODE cuando la instancia real de Siebel esté lista): abre el servicio (no el Blueprint) → pestaña Environment → edita el valor → Save Changes, lo que desencadena un redespliegue.

Apuntar tu cliente MCP al gateway desplegado

• URL: https://<your-service>.onrender.com/mcp

• Transporte: HTTP transmisible

• Autenticación: un token estático de portador/clave de API, no OAuth — establece la cabecera a Authorization: Bearer <MCP_GATEWAY_TOKEN> (el mismo valor del paso 4 anterior). Si la interfaz de autenticación de tu cliente pide un nombre de cabecera y un valor bruto por separado en lugar de una cabecera combinada, el nombre de cabecera es Authorization y el valor es Bearer <token> (incluye la palabra "Bearer") — si eso da un 401, prueba a darle solo el token bruto, ya que algunos clientes añaden el prefijo Bearer ellos mismos.

Notas de un despliegue real

• El almacén simulado es solo en memoria. Cualquier cosa creada/actualizada/eliminada durante una sesión persiste solo mientras ese proceso de servidor siga activo. Un redespliegue, o la instancia del nivel gratuito de Render que se apaga tras ~15 minutos de inactividad y arranca en frío en la siguiente solicitud, lo restablece a los datos iniciales sembrados. Eso es el comportamiento esperado del modo simulado, no un error.

• La dependencia de transporte del lado del cliente del SDK de Python mcp es httpx2, no httpx simple — solo relevante si escribes tu propio cliente MCP contra este gateway usando el helper streamable_http_client del SDK en lugar de una aplicación cliente de nivel superior; espera un httpx2.AsyncClient para el argumento http_client=, no un httpx.AsyncClient normal.

Lista de verificación para pasar a producción

Una vez que la instancia real de Siebel esté disponible:

• Establece SIEBEL_BASE_URL a la instancia real (sin barra final), p. ej. https://<siebel-host>/siebel/v1.0

• Establece SIEBEL_USERNAME / SIEBEL_PASSWORD

• Establece SIEBEL_VERIFY_TLS=false solo si la instancia aún usa un certificado autofirmado — vuelve a true cuando tenga uno real

• Establece MOCK_MODE=false

• Redespliega y luego haz una prueba de humo con siebel_list_objects y search_facilities antes de dirigir tráfico real de agentes hacia él

Herramientas

Genéricas (funcionan con cualquier Business Component: Contact, Employee, Medical Facility, Appointment Slot, Referral Request, Commitment Form, Treatment History):

Envoltorios de conveniencia, superficie más reducida para peticiones comunes de demostración:

Notas sobre los supuestos de la API REST de Siebel integrados aquí

• La autenticación es HTTP Basic en cada llamada saliente (separada de la comprobación de token de portador de este gateway en las solicitudes MCP entrantes — dos capas de autenticación distintas, no las confundas).

• La gramática de URL es {BASE}/data/{BusinessObject}/{BusinessComponent}. BO y BC no siempre tienen el mismo nombre aquí — p. ej. Referral Request es un BC hijo bajo el BO Patient Referral, Appointment Slot es un BC hijo bajo Appointment Management. Las herramientas toman el nombre del BC; el cliente busca el BO correcto internamente. Los segmentos de ruta están codificados en URL, por lo que los nombres con varias palabras funcionan.

• Las respuestas de listado llegan como {"items": [...]}; el array "links" de cada registro se elimina antes de devolverlo al modelo, para ahorrar tokens.

• Las respuestas no-2xx se muestran como el código de estado HTTP más el texto de mensaje propio de Siebel; un 401 recibe un prefijo claro de "comprueba las credenciales de Siebel". Las llamadas salientes tienen un tiempo de espera de 30s.

• Varios campos son calculados, no almacenados (Age, Days Waiting, Visits Remaining, Is Expired, Entry Gap Days, y los campos de unión Facility/Doctor/Patient) — se derivan de nuevo en cada lectura, coincidiendo con cómo se comportarían como campos calculados/de unión reales de un Business Component en lugar de columnas físicas.