jarvis-mcp-server

Standalone MCP server(s) for Jarvis. It currently hosts a time server (in the time_server/ package) that reports the current local time for a city, and is structured to grow more tool domains over time — each added as its own package alongside time_server/.

Unlike a stdio MCP server (which a client launches as a subprocess), it runs as an independent network process over Streamable HTTP, so it has its own lifecycle and can be reached by the MCP Inspector, a CLI client, or a Cloud Run deployment.

Tools

get_current_time is a two-hop pipeline: Open-Meteo geocoding (city → lat/lon) → TimeAPI.io (lat/lon → local time). Both APIs are free and need no key. If the network is unavailable it falls back to the system UTC clock, so a call never hard-fails.

Tokyo weather digest (a scheduled agent)

The weather_digest/ package runs a continuous agent: while the server is up, a background thread collects the current weather once an hour for every tracked city (Open-Meteo, with a mock fallback when offline) and stores each reading in SQLite (weather_measurements table). The scheduler starts with the server (via the ASGI lifespan) and stops cleanly on shutdown — it runs independently of any tool call.

Tracked cities are managed at runtime. Tokyo is tracked by default; add_city / remove_city / list_cities change the set live (no restart). add_city does one immediate collection so a new city has data right away; remove_city only stops future collection — the city's stored history is preserved (re-adding resumes with it intact). The set is persisted in a tracked_cities table, so it survives restarts.

get_weather_digest(period, city) aggregates the stored readings over a window (city defaults to Tokyo):

{
  "city": "Tokyo", "period": "24h", "sample_count": 36,
  "average_temperature": 19.0, "min_temperature": 12.7, "max_temperature": 24.1,
  "most_common_condition": "overcast", "rainfall_occurrences": 7,
  "temperature_trend": "rising",
  "window_start": "...", "window_end": "..."
}

On a fresh/empty database the store auto-seeds 7 days of realistic hourly mock readings (multiple conditions, rainfall, diurnal temperature swing), so a digest is demoable immediately — before the hourly scheduler has collected anything live.

Cloud Run note: with --min-instances 0 the service scales to zero when idle, so the hourly collection only runs while an instance is alive. The seed data keeps the digest meaningful regardless; set --min-instances 1 for uninterrupted hourly collection.

Weather-anomaly pipeline (three chained tools)

A realistic workflow built from three tools the LLM chains automatically:

get_weather_readings → detect_weather_anomalies → send_telegram_alert

"Analyze Tokyo weather for the last week. If unusual weather conditions are detected, send a Telegram alert."

1. `get_weather_readings(city, period)` reads the stored measurements and rolls

them up server-side into a compact per-day report (mean/min/max temperature and rainy fraction per UTC day). The raw rows never leave the server, so the data the model relays to the next tool stays tiny. period is capped at 7 days.

1. `detect_weather_anomalies(weather_report)` applies deterministic rules to

that report and lists any anomalies. It accepts only a get_weather_readings report — a raw-readings array, a missing marker, too many day-buckets, or an oversized payload are rejected in code (not just by the prompt), so a large array can never be relayed in. Rules (thresholds overridable via ANOMALY_* env vars):

1. `send_telegram_alert(anomaly_report, notify_when_clear=false)` sends a

Telegram message only if anomalies were found (otherwise it skips). Pass notify_when_clear=true to also send a reassuring "all clear" message when no anomalies were detected — handy for a scheduled all-is-well check-in. If Telegram is not configured it reports that without failing. Uses the Telegram Bot API over stdlib urllib (no new dependency); the bot token is never logged or returned.

To get a TELEGRAM_CHAT_ID: message your bot, then open https://api.telegram.org/bot<token>/getUpdates and read result[].message.chat.id.

Run locally

python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python -m time_server.server          # serves http://0.0.0.0:8080/mcp

Configuration (env vars)

Security

• Auth: set MCP_API_KEY; clients must send it as the X-API-Key header.

Comparison is constant-time and the key is never logged. Leaving it unset logs a loud warning and runs the server open — fine for local Inspector testing, never for a public deployment.

• Health: GET /healthz is unauthenticated (for Cloud Run / curl probes).

Test with the MCP Inspector

In a second terminal (server still running):

npx @modelcontextprotocol/inspector

In the Inspector UI:

1. Transport Type: Streamable HTTP
2. URL: http://localhost:8080/mcp
3. Connect → open the Tools tab → run get_current_time with city = London.

Automated checks

python tests/smoke_http.py      # end-to-end over Streamable HTTP (server must be up)
pytest -q                       # offline unit tests (no network, no server)

Deployment

See DEPLOY.md for the Cloud Run build/deploy commands, secret setup, and how scaling / cold starts work.

Roadmap

• [x] Standalone Streamable HTTP server + tools (get_current_time, get_weather_digest)
• [x] Scheduled weather-digest agent (hourly collection → SQLite → aggregation)
• [x] Runtime-managed multi-city collection (add_city / remove_city / list_cities)
• [x] Weather-anomaly pipeline (get_weather_readings → detect_weather_anomalies → send_telegram_alert)
• [x] Local test via MCP Inspector
• [x] JarvisCLI client wired (auth-aware, degrades cleanly when down/unauthorized)
• [x] API-key auth middleware (pure-ASGI, constant-time, /healthz exempt)
• [x] Dockerfile (slim, non-root, port 8080)
• [x] Cloud Run deploy guide