weather_daily fails with genuine 401 invalidAuthorization from weatherkit.apple.com (intermittent, recurring)

[Techlifter]

Environment

• macOS: 26.5.1 (build 25F80)
• iMCP version: 1.4.1 (latest release)
• MCP client: Claude Code

Problem

weather_daily (and other WeatherKit-backed tools) intermittently fail with a genuine invalidAuthorization 401 returned directly from weatherkit.apple.com — not a local TCC/XPC issue (Location Services and other iMCP services work fine throughout).

Error

Error: invalidAuthorization(<NSHTTPURLResponse> { URL: https://weatherkit.apple.com/api/v2/weather/en-US/33.775/-84.296?timezone=America/New_York&dataSets=forecastDaily&country=US&deviceLanguages=en-US&clientMetadata=... }
{ Status Code: 401, Headers {
    Connection = (close);
    Server = (Apple);
    "Strict-Transport-Security" = ("max-age=31536000; includeSubdomains");
    "X-Content-Type-Options" = (nosniff);
    "X-Frame-Options" = (SAMEORIGIN);
    "X-XSS-Protection" = ("1; mode=block");
} })

Timeline

Observed via a scheduled automation that calls weather_daily every morning and logs failures:

• Down: Aug 6–13, 2026 (6 consecutive daily runs)
• Recovered: Aug 14, 2026 (worked with no local changes)
• Down again: Aug 23–25, 2026 (3 consecutive daily runs, still failing as of Aug 25 ~7:20 PM ET when I reproduced it directly, outside the scheduled task)

What I ruled out locally

• location_current / Location Services work fine — not a TCC permission issue.
• iCloud is signed in normally.
• iMCP is on the latest release (1.4.1); no update available.
• Quit/relaunched the iMCP app and helper processes — did not change the outcome (though I wasn't able to re-verify post-restart in the same session due to an unrelated MCP reconnect limitation on my end).

This looks like a WeatherKit entitlement/quota issue on the app's provisioning rather than anything client-side, given the multi-day-outage-then-spontaneous-recovery pattern with no local state changes between the working and failing periods. Filing in case others are seeing the same intermittent pattern, or in case this points at something on the developer-account side (e.g. WeatherKit call quota, provisioning profile renewal).

[scottkuma]

+1, seeing the same error today

Environment

• macOS: 27.0 Beta (26A5421a) "Golden Gate"
• Hardware: MacBook Air (M2, 2022)
• iMCP version: 1.4.1 (same as OP)
• MCP client: Claude (Cowork mode, desktop app)

Problem

weather_hourly, weather_daily, and weather_current are all failing today with the same invalidAuthorization 401 directly from weatherkit.apple.com described above. Unlike OP's intermittent pattern, mine has failed on every single call I've made today — at least 4 separate attempts spread across ~4 hours (roughly 10:2x AM, 10:56 AM, 11:17 AM, and 11:25 AM ET), all with the identical error shape:

Error: invalidAuthorization(<NSHTTPURLResponse> { URL: https://weatherkit.apple.com/api/v2/weather/en-US/39.319/-84.227?timezone=America/New_York&dataSets=forecastHourly&country=US&deviceLanguages=en-US,en&clientMetadata=... }
{ Status Code: 401, ... })

No local changes were made between calls, and other iMCP tools (calendar events_fetch) worked fine throughout, so this doesn't look like a general connectivity or permissions issue on my end — consistent with OP's read that this is on the WeatherKit provisioning/entitlement side rather than client-side. I ended up falling back to fetching the NWS point forecast directly instead.

Happy to share more logs/timestamps if useful for narrowing down the pattern.

[mattt]

Hi @Techlifter and @scottkuma. Thanks for the detailed timelines; they helped.

I pulled apart the shipped 1.4.1 build: it's signed with the WeatherKit entitlement and an embedded distribution profile that's valid until 2044, so nothing on the app side expired. A 401 straight from weatherkit.apple.com on machines that otherwise work, coming and going in multi-day stretches with no local change, points at Apple's side validating my developer account rather than anything in the app. I'm checking the account (agreements, WeatherKit service on the App ID) now and will report back here. If either of you can note the next time it flips from failing to working, the timestamp would help me correlate.