Question 1

How to fix World Monitor desktop v2.10.0 showing empty news panels with 403 'agent_request_blocked' error?

Accepted Answer

This is a known bug in v2.10.0: the local sidecar forwarded cloud fallback requests without a User-Agent header, so the API's User-Agent policy blocked them with 403 `agent_request_blocked`, leaving regional news panels empty. **Fix:** upgrade to World Monitor v2.11.1+, where the sidecar always sends `User-Agent: WorldMonitor-Desktop/<version> (sidecar)` on cloud fallback requests; this release also routes desktop RSS through `/api/rss-proxy`, fixing related CORS failures. **Temporary workaround on v2.10.0:** in `src-tauri/sidecar/local-api-server.mjs`, inside `proxyToCloud()`, add `headers.set('User-Agent', 'WorldMonitor-Desktop/2.10.0 (Windows; desktop application)');` after the existing `Origin` header, then restart the app.

Question 2

Why does clicking Sign in do nothing in the World Monitor desktop app on macOS (Intel)?

Accepted Answer

This is a known bug in World Monitor desktop v2.11.0: Clerk's authentication rejected the desktop app's local origin, so the sign-in window never opened. It is fixed in v2.11.1. To resolve: 1) Download and install `World.Monitor_2.11.1_x64.dmg` from https://github.com/koala73/worldmonitor/releases/tag/v2.11.1 (use the x64 build for Intel Macs), or accept the in-app update prompt. 2) After updating, clicking Sign in opens the flow in your system browser, so passkeys, Google login, and password managers work as on the website. 3) Once signed in, Pro subscriptions activate in the desktop app and cloud data loads in all panels (previously signed-in desktops showed empty panels).

Question 3

Why does the WorldMonitor desktop app show blank or empty panels with no error?

Accepted Answer

Update to v2.11.1 or later — this is fixed on main (PRs #8154, #8320). Root cause: the desktop sidecar had no Redis credentials (UPSTASH_* was not forwarded to it), so 29 seed-backed API domains returned empty HTTP 200 responses instead of data, and the sidecar's cloud fallback only triggered on non-OK responses — an empty 200 looked like success. The hardcoded cloudPreferred list covered only 5 of 34 domains. The fix makes the sidecar always send seed-only routes to the cloud (~110 exact routes, 15 whole seed-only families, scorecard, and /api/v2/shipping/), and any route that fails locally is remembered as cloud-routed for the rest of the session. A regression test (tests/sidecar-cloud-preferred-seed-only.test.mjs) re-derives every seed-only handler on each run and fails the build if one would serve a local empty 200. Since v2.11.1, signed-in Pro desktops also authenticate on those cloud calls (#9424).

Question 4

Why does a failed MCP tools/call with 'Invalid params' (-32602) still count against my daily allowance?

Accepted Answer

Known issue (#9306): in `api/mcp/dispatch.ts` the allowance is reserved *before* argument validation runs — `reserveFreeAccountAllowance` for free accounts, `reserveQuota` for Pro/API plans. The tool only throws `RpcValidationError` (mapped to -32602) later, inside `_postFilter`/`_execute`, and the reservation is deliberately never rolled back once dispatch begins (GHSA-hcq5). So calls with retired `dataset` values (e.g. `["tariffs"]`), unresolvable `country`/`country_code`, or non-integer `limit` still burn a slot — painful on free accounts with only 5 calls/day.

Workaround until the fix ships:
1. Validate arguments client-side against the tool's `inputSchema` before sending — check `enum`/`items.enum` values, types, and integer bounds.
2. Confirm dataset names are still supported (retired ones fail after charging).
3. Never auto-retry a -32602 call with unchanged arguments; each retry spends another allowance unit.

Planned server-side fix: validate args against `inputSchema` plus an optional synchronous per-tool `_validateArgs(params)` hook *before* the reservation block, returning -32602 with `error.data.violations` without touching the counter.

Question 5

Why does WorldMonitor MCP fail to answer per-country oil export comparisons (e.g., "UAE oil exports, last 6 months vs the 6 before") and how to fix it?

Accepted Answer

Four verified pipeline bugs cause missing or wrong answers. Fixes: 1) `scripts/seed-jodi-oil.mjs` only kept the newest month per country — change the seeder to persist the full monthly JODI time series per country so N-vs-N month comparisons are possible. 2) The JODI seeder treated assessment code 3 ("not assessed") as missing — treat code 3 as a valid reported value; this restores discarded crude export series for Saudi Arabia, Kazakhstan, Nigeria, Venezuela, Mexico, Algeria and Azerbaijan. 3) UAE cannot be answered from JODI at all: the UAE has filed only placeholder cells (`-`) since 2019-01. Return null for uncovered months (never zero) and include per-source status and as-of dates in the MCP response. 4) `scripts/seed-portwatch-port-activity.mjs` keeps only two 30-day aggregates — retain longer history, and do not interpret PortWatch AIS as ground truth: it undercounts real exports (~0.3x for the UAE during the Hormuz closure) and has port-polygon gaps (Zirku Island and Jebel Dhanna show 0 calls every month), so "Gulf terminals are dark" was a data artifact. Also fix `get_chokepoint_status`, which reports `cached_at` as the oldest `fetchedAt` across all keys — the static chokepoint-baselines registry (seeded 2026-04-05) made live transit data look stale; compute `cached_at` from the live transit keys only. Done criteria: MCP returns monthly per-country production and declared export series with N-vs-N comparisons, per-source status/as-of dates, and null (not zero) for uncovered months.

worldmonitor

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects