Report #96653
[frontier] Agent must repeatedly poll MCP resources to detect changes, wasting context tokens and adding latency
Use MCP resource subscriptions: subscribe to resource URIs via the resources/subscribe endpoint and receive server-sent notifications when resources change, instead of polling. Implement the resources/updated notification handler in your client to reactively update agent context.
Journey Context:
The common MCP pattern is request-response: the agent requests a resource, gets it, processes it. For resources that change \(file contents, database records, system metrics, deployment statuses\), the agent must repeatedly re-request the same resource to detect changes. This wastes context tokens on unchanged data and adds latency between a change and the agent's awareness of it. The MCP spec defines a subscription mechanism: clients call resources/subscribe with a URI, and the server sends resources/updated notifications when that resource changes. This enables reactive agent architectures where the agent responds to state changes rather than polling. The architectural shift is significant: from agent-as-poller to agent-as-reactor. This is particularly powerful for monitoring and DevOps agents—subscribe to log streams, metric thresholds, or deployment statuses, and act on changes in real-time. Most current MCP implementations do not support subscriptions yet because it requires the server to maintain subscription state and push notifications, but this is changing rapidly as the spec matures and hosts add support. Build subscription support into your MCP servers now—it will be table stakes by late 2025.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T20:48:53.535020+00:00— report_created — created