KASPR Predict MCP · beta

Give automated work a better time to run.

Agents, batch jobs and transfers run over endpoints and networks beyond your control, and when they run decides how much of that they meet. One MCP, two servers, one key. The timing server answers a single question for calls, live streams, big uploads, agent batches and fixed live events: given a task at a proposed time and place, is there a materially better time? It answers in fixed wording, in every participant’s local time, and says nothing when nothing is better. The scheduling server ranks the hours between now and a deadline for batch jobs and agent loops: run now with retry and cache tuning, wait, or no good window. Both read KASPR’s typical week for every district on earth.

Get a key Install Documentation

https://mcp.kasprdata.com/timing/mcp · https://mcp.kasprdata.com/mcp

Beta version

KASPR Predict is in beta. Answers, wording and features may change, and the model’s parameters are still being calibrated.
Predictions are not based on the most recent data. They come from KASPR’s typical week for each place, built from measurements up to 16 July 2026, so they describe how a place usually behaves, not today’s conditions, outages or recent changes to a network.
Treat every answer as a tendency to weigh, not as advice to rely on. Each answer names the data vintage it was computed from.

Examples: ask the way you normally would

Everyday tasks, asked in Claude Code. The server checks the hour on every network involved and answers only when a materially steadier time exists. Pick a task.

claude — ~/work● kaspr-timing · kaspr-predict

>

Two people, two networks. The server names the hour in both places and proposes the nearest steadier one; when nothing is better, it says nothing.

Simulated session: the typing is staged, but every tool call, result and sentence is what the server returns for these places on KASPR’s typical week (data up to July 2026).

What goes wrong in production

Published measurements from AI gateways, observability vendors and academic studies, 2024–2026.

1 in 20

AI requests fail in production

Nearly one in twenty AI requests fails, and nearly 60 % of those failures are caused by capacity limits, in Datadog telemetry from thousands of organizations running AI in production. [1]

65.8 %

of provider failures are rate limits

Across an AI gateway’s April 2026 traffic, 429 responses were two-thirds of provider-emitted failures; all 5xx errors together were under 5 %. [2]

31.5 %

of agent cost is re-processed context

In 178,799 production agent sessions, prompt-cache evictions, paying again for context already processed, accounted for 31.5 % of monetary cost. [3]

up to 69×

latency varies with the time of request

End-to-end API latency for the same request varied by up to 69× depending on when it was sent, with clear time-of-day patterns measured across cloud regions. [4][5]

When an agent runs matters. KASPR Predict tells your agents and pipelines whether to start now or wait, and what timeouts and cache settings to use, from forecasts of network conditions. It answers the timing question for network-dependent work; a provider’s rate limits and capacity are a separate problem that it does not forecast.

What your agent can ask

“Tim in Nairobi wants a video call at 9 PM his time. I’m in Melbourne. Is that a good hour?”

check_timing names the hour in both places, says whether it is usually a steady, mixed or congested hour on the networks involved, and proposes the nearest hour that is at least a band steadier, if one exists inside the hours you allow. If none does, your agent says nothing about timing.

“Find the steadiest hour in Manila tomorrow between 6 AM and 6 PM for a call.”

best_window on the timing server takes a window instead of a time and returns the steadiest feasible hour in it, in every participant’s local time. Ask why and explain_last_verdict gives the reasoning behind the last answer.

“Summarise the 40,000 contracts in the Q3 bucket by 08:00 tomorrow. The job runs in ap-southeast-2 and calls an endpoint in Colombo. When should it start?”

The scheduling server classifies the task, ranks the hours between now and the deadline against running immediately, and answers run now with timeout, retry and cache tuning for the hour, or a ranked set of windows and how much each one is expected to save.

The tools

Three timing tools on the timing server and five scheduling tools on the scheduling server. Every answer is a verdict or a decision an agent can act on; a timing verdict never blocks, and every scheduling error carries a fallback of run now.

Server	Tool	Cost	What it does
timing	check_timing	no charge during the beta	Is a proposed time a usually rough hour on the networks involved, and is there a materially steadier hour nearby? For calls, live streams, uploads, agent batches and fixed live events. Answers with one sentence to show, or nothing.
timing	best_window	no charge during the beta	The steadiest feasible hour inside a window of up to twelve hours, in every participant’s local time, when no time has been proposed yet.
timing	explain_last_verdict	no charge during the beta	The reasoning behind the last verdict, for when the user asks why.
scheduling	exposure_class	free	Classifies a task as none, low, high or critical, and infers its profile. Call it before any long-running, retry-heavy, real-time or human-facing task.
scheduling	latency_forecast	1 credit per place per 24 h	The hourly chance of a rough connection, with jitter and latency levels, for up to 20 places. For when the agent needs the whole curve.
scheduling	best_window	free when the answer is run now; otherwise 1 credit, plus 1 per place beyond two	Ranked windows between the earliest start and the deadline, a comparison with running now, and the decision: run now, wait, or no good window, with retry and cache tuning.
scheduling	schedule_hold	1 credit	Holds a chosen window, re-scores it every fifteen minutes, and notifies on a drop.
scheduling	report_outcome	refunds 1 credit	Records what happened — duration, retries, success — so the model gets better. Opt-in, job metrics only.

Scheduling server resources: kaspr://taxonomy, kaspr://coverage, kaspr://calibration, kaspr://changelog. Prompt: schedule_task.

Install

Both servers speak streamable HTTP and take the same bearer key. Create a trial key in your account and paste it where the examples say your key; developer and team keys are issued by hand during the beta. Add the timing server for calls, streams, uploads and fixed events; add the scheduling server for jobs with a deadline; or both.

Claude Code

One command per server, then /mcp inside Claude Code lists kaspr-timing with three tools and kaspr-predict with five.

claude mcp add --transport http kaspr-timing https://mcp.kasprdata.com/timing/mcp --header "Authorization: Bearer <your key>"
claude mcp add --transport http kaspr-predict https://mcp.kasprdata.com/mcp --header "Authorization: Bearer <your key>"

Cursor and other clients with a JSON config

Add one or both servers to the client’s MCP configuration (for Cursor, .cursor/mcp.json).

{
  "mcpServers": {
    "kaspr-timing": {
      "url": "https://mcp.kasprdata.com/timing/mcp",
      "headers": { "Authorization": "Bearer <your key>" }
    },
    "kaspr-predict": {
      "url": "https://mcp.kasprdata.com/mcp",
      "headers": { "Authorization": "Bearer <your key>" }
    }
  }
}

Claude Desktop

Claude Desktop reaches remote servers through the mcp-remote bridge; add this to claude_desktop_config.json (swap the URL for the scheduling server if you want that one).

{
  "mcpServers": {
    "kaspr-timing": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.kasprdata.com/timing/mcp", "--header", "Authorization: Bearer <your key>"]
    }
  }
}

On your own device

Beta testers can also run either server locally over stdio. The scheduling server then measures your device’s own latency to the model endpoint you use and folds it into the decision; those measurements never leave the device. Ask us for the source.

uv run kaspr-mcp --stdio --timing   # the three timing tools
uv run kaspr-mcp --stdio             # the five scheduling tools

To check that it works, ask your agent the first question above.

Full documentation: every tool, parameter, verdict and limit →

How it decides

—Timing verdicts come from KASPR’s typical week for each place: every hour of the week is steady, mixed or congested relative to that place’s own week. A two-party call is judged by its worse side, and that side is named.
—A steadier time is suggested only when it is at least one band better and materially so, inside the window and the local hours you allow at every participant; otherwise the verdict is silent and your agent says nothing about timing. A fixed event gets advice, never a different time.
—Scheduling decisions for batch jobs, agent loops and transfers rank the hours between now and the deadline against running immediately. Run now comes with timeout, retry, backoff and cache tuning for the hour; wait is reserved for incidents the device probe can see now and expects to clear before the deadline.
—Nothing here is a live measurement of the network. The model knows how a place usually behaves, hour by hour, from a frozen data vintage; only the on-device scheduling mode sees today.

What stays on your device

—The hosted servers never measure you. They answer from the model and your request alone, and the timing server returns no numbers at all: bands, times and a sentence.
—In on-device mode, the rolling series of your own latency measurements, your baseline and the probe targets live in one file on your machine, readable only by you.
—The only call the device makes to KASPR is a forecast by place id — a cell, a region or a country, coarsened on your device if you ask. No query string, no body.
—Outcome reports are opt-in and carry job metrics only: a window id, the duration, the retries, success or not.

Plans during the beta

The timing server is not metered during the beta: no daily or per-minute caps. Credits meter the scheduling server’s forecast and scheduling tools; classification is always free. Keys are issued by hand.

Free

500 credits a month

Timing: uncapped during the beta · scheduling: 10 requests a minute, forecasts up to 24 hours ahead for up to 2 places

Developer

20,000 credits a month

Timing: uncapped during the beta · scheduling: 60 requests a minute

Team

250,000 credits a month

Timing: uncapped during the beta · scheduling: 300 requests a minute, custom allowances on request

Questions

Which clients work?: Any MCP client that can call a streamable-HTTP server with a bearer header: Claude Code, Cursor, and Claude Desktop through the mcp-remote bridge. Others that support the same transport should work too. Both servers use the same key.
Why did it say nothing?: Because nothing was materially better. The timing server is a quiet advisor: it speaks only when a steadier hour exists inside your window and the hours you allow, and it never blocks the time you proposed.
Is this live network conditions?: No. The forecast is KASPR’s typical week for each place, projected onto the hours ahead; verdicts say so in their own words (“usually”, “typically”). The on-device scheduling mode adds what your own device measures right now; the hosted servers do not.
What does it cost?: During the beta, nothing. The timing server has no caps; the scheduling server’s keys come with monthly credits by tier, and the table above says how far they go.
Can I get the data instead?: The MCP returns verdicts, decisions and curves for the places you ask about. For the underlying data, the API or bulk files, talk to sales.

Ask for a beta key.

Get a key