SubTrack — Rastreador de suscripciones y facturas recurrentes (servidor MCP)

El problema que resuelve: casi todo el mundo está perdiendo dinero en silencio con suscripciones y facturas recurrentes que ha olvidado: una prueba de streaming que se convirtió en pago, una membresía de gimnasio, una renovación anual de dominio que se cobra una vez y se olvida durante 11 meses. SubTrack permite que un LLM (Claude, o cualquier cliente MCP) haga un seguimiento de todo ello, le diga qué se renueva pronto y le muestre el gasto total normalizado a una cifra mensual, aunque sus suscripciones se facturen semanal, mensual, trimestral, anualmente o en un ciclo personalizado.

Qué hace

Además de un recurso subtrack://categories (lista de categorías editable) y una plantilla de prompt renewal_digest_prompt que pide al asistente que redacte un resumen amable de lo que se avecina.

La parte de ingeniería interesante es next_renewal_date(): avanza correctamente por ciclos basados en días (semanales/quincenales/personalizados) con aritmética modular, y por ciclos basados en calendario (mensuales/trimestrales/anuales) sumando meses naturales reales (de modo que una suscripción que empezó el 31 de enero cae correctamente en el 28 de febrero, no "31 días después").

Related MCP server: subscription-tracker-mcp

Por qué las herramientas son async def

Todas las herramientas aquí son async def, y todo el acceso a SQLite pasa por aiosqlite en lugar de la biblioteca estándar sqlite3. Merece la pena entender por qué, ya que es un punto de confusión habitual:

• FastMCP ya ejecuta las herramientas def normales en un grupo de hilos por defecto, así que una versión síncrona de este servidor no se congelaría literalmente bajo carga ligera.

• Pero async def + un controlador bloqueante (sqlite3) en su interior es peor que quedarse en síncrono: FastMCP no descarga en hilos las herramientas async def (se ejecutan directamente en el bucle de eventos), por lo que una llamada bloqueante dentro de una de ellas detendría cualquier otra petición concurrente.

• Así que: o se mantienen las herramientas como def y se deja que el framework las descargue en hilos, o se usa async def y un controlador realmente asíncrono de principio a fin. Este servidor hace esto último, que es el patrón más escalable para un servidor remoto que pueda recibir llamadas concurrentes de varios clientes: no consume un hilo de trabajo por llamada a BD en curso, y se compone limpiamente si luego se añade otra E/S awaitable (llamadas HTTP, etc.).

• La única excepción: la pequeña lectura de categories.json sigue siendo síncrona. Son unos pocos cientos de bytes que se leen una vez por llamada; hacerla "asíncrona" supondría añadir aiofiles sin un beneficio real de concurrencia.

Estructura del proyecto

subtrack-mcp/
├── server.py          # the whole server — module-level `mcp` object
├── pyproject.toml     # project metadata + deps (managed by uv)
├── uv.lock            # locked, reproducible dependency versions
├── .python-version    # pins the Python version uv uses
├── .gitignore
└── README.md

categories.json y subscriptions.db no se confirman en el repositorio: server.py los crea automáticamente en el primer arranque (ver init_categories() / init_db()). Si quieres que tu propia lista fija de categorías sobreviva a los redespliegues, elimina categories.json de .gitignore y confirma tu versión editada.

Ejecutarlo localmente (uv)

No se necesita crear un venv manualmente: uv run crea y sincroniza .venv a partir de uv.lock automáticamente la primera vez que lo uses.

El bloque __main__ en server.py ejecuta el servidor por HTTP en 0.0.0.0:8000 por defecto (se puede sobrescribir con la variable de entorno PORT): el mismo transporte que usa FastMCP Cloud en producción, de modo que las pruebas locales coinciden con lo que realmente vas a desplegar:

uv run server.py
# Starting MCP server 'SubTrack' with transport 'http' on http://0.0.0.0:8000/mcp

Nota: este bloque solo se ejecuta cuando ejecutas el archivo directamente. FastMCP Cloud lo ignora por completo: importa el objeto mcp y lo sirve él mismo, así que nada de aquí afecta al servidor desplegado.

Pruébalo con un pequeño script de cliente (uv run python client_test.py):

import asyncio
from fastmcp import Client

async def main():
    async with Client("http://127.0.0.1:8000/mcp") as client:
        result = await client.call_tool("add_subscription", {
            "name": "Netflix", "amount": 15.99, "billing_cycle": "monthly",
            "start_date": "2026-08-05", "category": "Streaming", "subcategory": "Video"
        })
        print(result.data)

asyncio.run(main())

Si quieres probar con un cliente MCP que espere stdio en su lugar (por ejemplo, conectando esto a Claude Desktop para uso local), ejecútalo a través de la CLI de FastMCP, que sobrescribe el transporte independientemente de lo que haya en __main__:

uv run fastmcp run server.py:mcp --transport stdio

Añadir o actualizar dependencias

No edites a mano la lista de dependencias de pyproject.toml: deja que uv la gestione para que uv.lock se mantenga sincronizado:

uv add some-package             # add a new dependency
uv add some-package --upgrade   # bump one dependency
uv lock --upgrade               # re-resolve everything to latest compatible versions

Desplegar en FastMCP Cloud

1. Sube esta carpeta a un repositorio de GitHub: confirma pyproject.toml y uv.lock (no confirmes .venv/, está en gitignore).

2. Inicia sesión en fastmcp.cloud con GitHub y crea un nuevo proyecto desde el repositorio.

3. Establece el punto de entrada a:

   server.py:mcp

4. Despliega. FastMCP Cloud detecta automáticamente las dependencias desde pyproject.toml (también entiende un requirements.txt simple, pero no necesitas uno aquí). Obtendrás una URL como https://<project>.fastmcp.app/mcp que cualquier cliente MCP —incluido Claude, mediante un conector personalizado— puede llamar.

Una nota sobre el almacenamiento

Este servidor usa SQLite en el disco local por simplicidad, lo cual es ideal para aprender y para un despliegue de una sola instancia. No se garantiza que sobreviva a un redespliegue en la mayoría de las plataformas gestionadas (un despliegue nuevo suele significar un sistema de archivos nuevo). Una vez que estés contento con la lógica de las herramientas, el siguiente paso natural —y un buen ejercicio para seguir aprendiendo sobre servidores MCP remotos— es sustituir sqlite3 por una base de datos alojada (Turso/libSQL, Postgres vía asyncpg, Supabase, etc.) usando una variable de entorno para la cadena de conexión, configurada en el panel de FastMCP Cloud (os.getenv("DATABASE_URL")).

Ideas para ampliarlo

• Añadir un mcp.tool() que envíe por correo o push un resumen usando la salida de renewal_digest_prompt.

• Añadir una tabla price_history y una herramienta para registrar los aumentos de precios a lo largo del tiempo.

• Añadir autenticación (FastMCP soporta autenticación por token de portador) cuando estés listo para hacer el servidor privado en lugar de abierto.