myhotlunchbox-mcp

Servidor MCP para My Hot Lunchbox — lee el calendario de comidas escolares, gestiona estudiantes, realiza y modifica pedidos, y sigue entregas y pagos en una cuenta de padre.

Desarrollado y mantenido por IA (Claude Code). Úsalo bajo tu propio criterio.

Instalación

npx myhotlunchbox-mcp

O como plugin de Claude Code:

/plugin marketplace add chrischall/myhotlunchbox-mcp
/plugin install myhotlunchbox-mcp

Related MCP server: Corben MCP Server

Configuración

MYHOTLUNCHBOX_USERNAME=you@example.com
MYHOTLUNCHBOX_PASSWORD=…

Eso es toda la configuración. El servidor realiza un inicio de sesión real del lado del servidor contra ordernow.myhotlunchbox.com (concesión de contraseña OAuth2) y renueva la sesión con el token de actualización que recibe — sin extensión de navegador, sin pestaña iniciada, sin cookie capturada. No se escribe nada en el disco.

MYHOTLUNCHBOX_BASE_URL anula el origen de la aplicación si alguna vez se mueve.

El servidor arranca sin credenciales para que la sonda tools/list del host en el momento de la instalación siga funcionando; el error de configuración aparece en la primera llamada a una herramienta.

Herramientas

34 herramientas, todas con el prefijo mhlb_. Las 20 herramientas de lectura están verificadas en vivo contra una cuenta de padre real (node scripts/verify-reads.mjs); las 14 de escritura no — ver más abajo.

Cuenta — mhlb_whoami, mhlb_session_reset

Estudiantes — mhlb_list_students, mhlb_get_student_form, mhlb_new_student_form, mhlb_create_student, mhlb_update_student, mhlb_delete_student

Calendario — mhlb_get_calendar, mhlb_get_day

Pedidos — mhlb_get_cart, mhlb_get_cart_tabs, mhlb_get_menu, mhlb_get_order_form, mhlb_get_order, mhlb_create_order, mhlb_update_order, mhlb_delete_order

Facturación — mhlb_list_transactions, mhlb_get_transaction, mhlb_list_subscriptions, mhlb_get_subscription_settings, mhlb_set_subscription_enabled, mhlb_unsubscribe_order, mhlb_list_gift_cards, mhlb_apply_gift_card, mhlb_get_coupon, mhlb_apply_coupon, mhlb_remove_coupon

Pago — mhlb_init_checkout, mhlb_checkout

Informes — mhlb_print_calendar, mhlb_print_orders, mhlb_print_transaction. Estas devuelven PDFs reales; cada una escribe el archivo y devuelve su ruta, o los bytes en línea con inline: true. Establece MYHOTLUNCHBOX_OUTPUT_DIR para elegir dónde se guardan (por defecto, el directorio de trabajo); los archivos existentes nunca se sobrescriben.

Las escrituras están controladas por confirmación

Cada herramienta mutadora requiere confirm. Sin confirm: true no realiza ninguna llamada de red y devuelve una vista previa de simulación (dry-run) de exactamente lo que enviaría.

mhlb_checkout cobra un método de pago real. El servidor calcula el cargo a partir de orderIds, por lo que nada del lado del cliente puede fijar el importe — no hay total en la solicitud contra el que comprobar. Por lo tanto, expectedTotal es atribución, no una salvaguarda: indicas lo que esperabas, y se registra en la simulación y en el resultado para que un cargo inesperado sea rastreable hasta la llamada que lo causó. Lo que la herramienta sí rechaza de plano es pagar un total distinto de cero sin orderIds.

Escrituras: formas capturadas, aceptación no verificada

npm run capture:writes ejecuta cada herramienta mutadora contra un proxy local que reenvía las lecturas al servicio real pero responde a las escrituras él mismo, de modo que las cargas útiles se construyen a partir de modelos reales del servidor y no ocurre nada en el sistema ascendente. También demuestra que las 13 se niegan a enviar nada sin confirm: true.

Lo que eso estableció y corrigió: mhlb_delete_order y mhlb_unsubscribe_order toman {orderId, eventDate, studentId, isRepeated, isSubscribed} — no el modelo de pedido — y el pago toma {orderIds, checkoutType, couponCode, giftCardCode, schoolDonations}.

Lo que aún no está verificado es si el servidor acepta estos cuerpos. La forma no es aceptación; solo una escritura real lo demuestra, y no se ha hecho ninguna. Inspecciona la vista previa de simulación antes de confirmar, y vuelve a leerla después — un 200 no es prueba de que una escritura haya persistido.

Dos límites específicos de mhlb_checkout:

• Solo puede pagar con una tarjeta ya guardada en la cuenta. Pagar con una tarjeta nueva requiere un token de Stripe generado por Stripe.js en un navegador, que ningún cliente del lado del servidor puede producir.

• Genera una clave de idempotencia y la devuelve. Si un pago falla de forma ambigua, reintenta con esa misma idempotencyKey en lugar de una llamada nueva — eso es lo que evita que un reintento se convierta en un segundo cargo.

Los pedidos son de lectura-modificación-escritura

No existe una llamada "añadir artículo X". Obtén el modelo, edítalo, envíalo completo:

1. mhlb_get_menu — qué se puede pedir para un estudiante en una fecha

2. mhlb_get_order_form — el modelo de pedido a rellenar

3. mhlb_create_order — envíalo de vuelta (con confirm: true)

4. mhlb_init_checkout → mhlb_checkout — precio, luego pago

Los campos omitidos de la carga útil se borran, no se conservan.

Habilidad de shell

skills/myhotlunchbox cubre la misma cuenta desde un shell con curl — sin necesidad de proceso MCP. Útil en scripts, o en una máquina donde este servidor no esté instalado.

Notas

• /deliveryInfo/* y /calendar/viewMatchedVendors parecen orientados al padre en el cliente compilado, pero devuelven 403 para una cuenta de padre — pertenecen a los paneles de escuela/proveedor. Ninguna herramienta los envuelve.

• Solo está conectado el rol de padre. La misma API también sirve a los roles de administrador escolar y proveedor; esos endpoints devuelven 403, que el cliente informa como un desajuste de rol en lugar de una sesión rota.

• docs/MYHOTLUNCHBOX-API.md registra cómo se mapeó la API y exactamente qué está verificado. docs/api-surface.txt es la extracción completa de 359 endpoints.

Licencia

MIT