Appendix A. Market research & prior art¶
Part of the design document
Section numbers (§1–§13) run across the whole design document, split here into Design spec, Implementation notes, Release notes, and Prior art.
Survey conducted July 2026 via web research. Quantitative figures below are as reported in the cited papers' abstracts and project pages; several full texts were not independently verified — spot-check any number before quoting it externally.
A.1 The MCP gateway landscape — nobody competes on latency¶
The MCP proxy/gateway space is crowded, but every incumbent competes on security, governance, and aggregation — auth/RBAC (MCPJungle, TrueFoundry, Portkey, Obot, ToolHive), guardrails and PII scrubbing (Lasso mcp-gateway, Docker MCP Gateway interceptors), zero-trust portals (Cloudflare), federation/registry (IBM ContextForge, agentgateway), transport bridging (sparfenyuk/mcp-proxy, TBXark/mcp-proxy), K8s lifecycle (Microsoft mcp-gateway), or REST→MCP conversion (Unla). None of them advertises speculative or predictive prefetching of tool calls; latency, as of this survey, is an unclaimed differentiator in gateway marketing.
The closest existing things:
- Reactive caching proxies, tiny and obscure: duriandrivendesign/mcp-cache (transparent proxy caching
tools/call/resources/readon first use, ~month-long default TTLs, ignoresreadOnlyHint, no prefetch), figma-mcp-cached (per-server disk cache to dodge rate limits). Cache-on-first-call only helps repeated identical calls; it does nothing for the first ask, which is what speculation targets. tools/listcaching is common in SDKs and gateways (e.g. the OpenAI Agents SDK cacheslist_tools()), and industry guidance (Gravitee, fast.io) explicitly recommends against cachingtools/callresults except for deterministic tools — consistent with Speculate's short-TTL, conservative buffer design.- GitHub searches for "MCP speculative prefetch" return zero repositories. The only speculative-tool-execution open-source artifact found at all is joelvarun/speculative-tools — a 0-star Python library (n-gram next-tool prediction + async execution + 30 s TTL cache) bound to one agent framework, not protocol middleware.
A.2 Academic validation — speculating agent actions works¶
Speculative execution of agent actions became an active research area between late 2024 and mid-2026. Key reported results:
| System | Layer | Reported result |
|---|---|---|
| PASTE / "Act While Thinking" (Microsoft, 2026) | Serving layer | Pattern-mined tool-sequence prediction; −48.5% avg task latency, −67% tool-wait time; 27.8% top-1 / 43.9% top-3 predictor recall (a compounded ~94% system hit rate is reported on repetitive workflow loops — treat as best-case, not typical) |
| Speculative Actions (ICLR 2026) | Agent framework | Fast model predicts next action, executes in parallel, slow model verifies; ~55% next-action accuracy → 10–20% latency cut |
| SPAgent (2025) | Inference engine | Adaptive speculation for search agents; 1.65× end-to-end speedup at ~40% action-buffer hit rate |
| IdleSpec (2026) | Agent framework | Uses tool-wait idle time for speculative planning; >50% perceived-latency cut on GAIA/FRAMES |
| DSP (2025) | Agent framework | Online RL tunes speculation depth against dollar cost; −30% total cost, −60% wasted-speculation cost |
| Accio (2026) | Web agents | Structural-regularity speculation; −33% latency, −1.9× cost, accuracy preserved |
| SpecHop (2026) | Retrieval agents | Continuous speculation with commit/rollback; −40% latency; measures tool time at 73% avg of E2E latency |
| Ghost Tool Calls (2026) | Analysis | Speculative calls leak inferred intent to external services at issue time — read-only ≠ disclosure-free (addressed in §4 and §11 risk 11) |
Three things follow. First, the mechanism works: reported next-action accuracies of ~28–55% buy 20–50% latency reductions in these systems. An important asymmetry, though: every cited system sees more than a proxy does (model state, plans, sometimes the prompt itself); Speculate sees only protocol traffic, so its achievable hit rate should be assumed lower until measured (§10's thresholds encode this). Second, every one of these systems lives inside the agent runtime, the serving stack, or the inference engine — each requires adopting a framework or modifying infrastructure; none is deployable as protocol middleware. Third, the field has already mapped the failure modes (waste cost, staleness, intent leakage), which this design addresses in §4, §6, §7, §11 rather than discovering in production.
Also relevant: a TDCommons defensive publication (June 2026) describes intent-predicted prefetching of agent retrieval backends with probability-×-value-÷-cost scoring. As deliberately published prior art it forecloses patenting the broad idea (by anyone), which is fine for an open-source project; it is a disclosure, not a product.
Complementary (not competing) lines of work: parallel/async function calling (LLMCompiler, AsyncLM) accelerates calls the model has already emitted, while speculation covers calls it hasn't — the two compose (§8). Speculative retrieval (Speculative RAG, predictive RAG prefetching, SpeQL — which precomputes predicted SQL while the user is still typing, the closest "predict-then-precompute at an intermediary" analogy) shows the same trick working at other layers of the stack.
A.3 Precedents outside AI — the pattern is proven at planet scale¶
- Browsers are the strongest analogy: Chrome's Speculation Rules API is declarative, confidence-tiered, side-effect-constrained prefetch/prerender at the platform layer — Google Search prerendering cut LCP measurably, and Ray-Ban's deployment cut mobile LCP ~43%. Speculate is the same shape: policy-driven speculation at a shared layer, with the "safe to speculate" boundary drawn by the platform, not the app.
- CPUs have rested the entire modern performance model on speculative execution behind branch predictors for three decades — predict, execute, cheap rollback.
- Gmail prefetches message images so opens render instantly; its known side effect — 1–6% "false opens" polluting email-open analytics — is the concrete cautionary example behind §4's side-effect rules.
A.4 Spec trajectory — the ground is shifting in Speculate's favor¶
- Tool annotations (
readOnlyHint,destructiveHint,idempotentHint,openWorldHint) are ratified spec, and the MCP blog's "Tool Annotations as Risk Vocabulary" is explicit that they are untrusted hints — which §4 already assumes. Precedent for acting onreadOnlyHintexists: Claude Code uses it for parallel dispatch and plan-mode auto-permitting. Notably, the official annotations guidance never mentions caching/prefetching as a use case — the space is open. - SEP-2549 caching metadata (
ttlMs,cacheScope; final spec expected 2026-07-28) formally acknowledges caching intermediaries —cacheScope: "public"is defined so that "any client or intermediary (e.g., shared gateway, caching proxy) MAY cache" — but deliberately excludestools/callresults (§6.2 covers how Speculate relates to this). - The 2026-07-28 RC also makes the protocol stateless (no
initializehandshake, no session pinning), which lowers the cost of building MCP intermediaries — while making session identity the deployer's problem, which is why the shared-gateway shape is deferred (§3.2).
A.5 Verdict¶
The mechanism is validated; the layer is unoccupied. Speculative tool execution is demonstrably effective in research systems, and no shipping MCP proxy/gateway/middleware does it. Speculate's defensible position is precisely the deployment model: drop-in, protocol-native, agent-agnostic, and model-agnostic — the browser's speculative-loading trick, placed at the one layer of the agent stack every harness already passes through. The differentiation to maintain is the deployment layer and the safety/observability envelope, not prediction-technique novelty (PASTE has already published the pattern-mining approach Tiers 1–2 resemble). Main market risks: incumbent gateways could add this as a feature (mitigant: none has, their roadmaps center on governance, and a focused OSS tool can move faster), and harness-level parallelization eroding part of the intra-turn win (mitigant: parallelization can't touch un-emitted or result-dependent calls, and the TTL-bounded slice of the between-turn window it harvests — §8).