A Zero MCP Task TTL Did Not Expire the AI Agent’s Result

The sharp question: what does zero milliseconds retain?

A durable MCP task can hold an AI agent’s tool arguments, status, output and diagnostic state after the initiating request is gone. TTL therefore controls two opposing needs: preserving enough evidence to recover an expensive result, and deleting sensitive or stale state when its declared lifetime ends.

In the SDK 1.30.0 demonstration store, ttl: 0 did not mean immediate expiry. It meant no automatic cleanup timer at all. A negative value took the opposite path and became an almost-immediate Node timer. A positive value changed clock origin when the result arrived.

Chronology: one field accumulated three meanings

The task proposal opened October 20, 2025 and entered the 2025-11-25 protocol release as an experimental durable state machine. That specification described requested lifetime and returned retention from task creation. A December 26 SDK pull request removed null from client requests so clients could omit TTL but not request an unlimited lifetime.

On March 25, 2026, that SDK change merged. The same day, protocol pull request 2408 merged a fix allowing null in generated response schema, where null means unlimited. SDK 1.30.0 shipped July 27. This reproduction ran September 3 against the published package.

The protocol starts the clock at creation

The task-creation section says requestors may ask for a lifetime duration in milliseconds since creation. Retention guidance says receivers may override that request, must include the actual ttl duration—or null for unlimited—in task responses, and may delete the task and result after the TTL lifetime has elapsed regardless of status.

Deletion is a MAY, not a mandatory deadline. This experiment therefore does not claim that every extra millisecond is a protocol violation. The narrower finding is that a store returned values described as duration from creation while its actual cleanup policy used zero as no timer and restarted positive timers from completion.

TTL is an AI data boundary, not timer trivia

A long-running agent task may contain retrieved documents, code patches, database extracts, model-generated drafts or failure details. Under-retention can strand a caller that reconnects after expensive work. Over-retention enlarges the period in which task metadata or results remain available, especially when authorization context is weak.

The MCP security guidance explicitly suggests shorter TTLs to reduce exposure where tasks cannot be bound to an identified requestor. A returned zero that acts like unlimited storage defeats that operational intuition even if the demonstration store is never intended for production.

The validator accepted both sides of zero

The installed TaskCreationParamsSchema represented ttl as z.number().optional(). It did not require an integer, a positive value or a nonnegative value. Both safeParse({ ttl: 0 }) and safeParse({ ttl: -10 }) succeeded in both runs.

The protocol’s pinned TypeScript interface likewise uses number without a numeric refinement. That establishes an input gap, not an instruction that zero or negative duration has useful semantics. A receiver still owns the actual lifetime it returns and enforces.

The store used truthiness as retention policy

InMemoryTaskStore sets actualTtl to the requested value when present, otherwise null. It returns that value in Task.ttl. Its creation path then schedules cleanup under if (actualTtl), a JavaScript truthiness check rather than an explicit finite-positive validation.

Zero is falsy, so no timer is entered into cleanupTimers. Negative ten is truthy, so it reaches setTimeout. The same field is returned unchanged even though those branches do not describe comparable retention durations.

The fixture tested storage, not a model

Each scenario constructed the public InMemoryTaskStore and a synthetic tools/call request named synthetic_inference. No inference occurred. The name makes the control-plane consequence concrete without pretending that model behavior was measured.

The zero case waited 75 ms, then checked both getTask and listTasks. The negative case polled until the record disappeared. The positive case created ttl: 80, waited 50 ms, stored a completed synthetic result, checked after another 40 ms and then measured deletion.

Zero remained visible until manual cleanup

Run one checked at 80.4 ms; run two checked at 79.4 ms. In both, getTask returned the zero-TTL task and listTasks included it. The harness then called the store’s cleanup method so the test left no retained state.

The measured wait is not a proof of eternal process lifetime. The implementation evidence supplies the stronger boundary: no TTL timer was scheduled for zero. The record remains until explicit cleanup, store loss, process exit or another untested operation removes it.

Negative ten became roughly one millisecond

Both negative-TTL tasks returned ttl: -10. Node emitted TimeoutNegativeWarning, stating that the duration was set to 1. The polling loop observed deletion after 2.0 ms and 2.5 ms.

Those elapsed measurements include scheduling and polling overhead; they are not precision timer benchmarks. They corroborate Node’s documented coercion and show that an accepted negative duration became rapid deletion instead of a rejected task-creation request.

Completion moved the positive clock

The 80 ms task completed at 52.1 ms in run one and 51.4 ms in run two. The store cleared the creation timer and started another 80 ms timer when storeTaskResult saved the terminal result. At approximately 92.1 ms and 91.4 ms from creation, each task was still present.

Deletion arrived at 132.8 ms and 133.4 ms from creation, leaving the result for 80.7 ms and 82.0 ms after completion. The return value remained ttl: 80; it did not disclose that the enforced clock had moved.

The source comment confirms the reset is intentional code

The distributed store says “Reset cleanup timer to start from now” in storeTaskResult. updateTaskStatus has a parallel terminal-state branch that also clears and replaces the timer. This was not an accidental artifact of the harness’s polling loop.

The store’s interface commentary, however, describes TTL as time to keep results after completion, while TaskCreationParamsSchema says duration from creation. That documentation split helps explain the implementation, but it does not give one returned Task.ttl two clock origins on the wire.

Independent work found adjacent representation mismatches

Protocol pull request 2408 reported that generated JSON schema rejected null even though the source and documentation used null for unlimited response retention. Its author traced that mismatch to schema generation and supplied a surgical nullable annotation. This is independent evidence that TTL representation had already diverged across artifacts.

SDK pull request 1339 addressed the other direction: clients should omit ttl rather than request null, while receivers may return null. Neither contributor tested zero, negative values or completion-time reset. No independent public reproduction of the exact three observations was found, so these two clean local runs remain the only evidence for those outcomes in this article.

Do not promote the demonstration store by accident

The SDK labels InMemoryTaskStore experimental, for demonstration, and unsuitable for production because restart loses all data. Yet examples have a habit of becoming defaults. A service can inherit retention ambiguity if it wraps the store, ports its timer logic into Redis or uses it in a supposedly temporary internal deployment.

Production task storage needs an explicit expiry timestamp persisted with the record, not only an in-process callback timer. Multi-instance services also need atomic ownership, authorization binding, durable status transitions and deletion behavior that survives restarts and clock changes.

Choose and expose one clock origin

If TTL means duration from creation, compute expiresAt = createdAt + acceptedTtl once and do not move it when status changes. If the product instead promises a post-completion retrieval window, expose that as a separate contract and account for a maximum execution lifetime. Do not silently reuse one wire field for both.

Return the accepted value after enforcing local minimum and maximum policy. Reject non-finite, fractional, zero and negative values unless the protocol profile explicitly assigns them tested semantics. Use null only for a deliberate, authorized unlimited response lifetime.

Verify deletion as a distributed invariant

Test just before and after expiry for working, input-required, completed, failed and cancelled states. Repeat through get, result, list, reconnect and every replica. Restart the service between creation and expiry. Verify that indexes, queues, caches, logs and object payloads do not outlive the record’s declared policy.

Measure requested TTL, accepted TTL, createdAt, expiresAt, terminalAt, deletedAt and deletion lag. Alert on zero or negative inputs, null lifetimes, timer overflow, records visible after expiry, results deleted before the recovery objective and stores whose policy changes after status transition.

Separate recovery time from privacy limits

A team may need ten minutes for an agent to reconnect while policy allows raw tool output for only one hour. Encode both requirements: a minimum recovery window and a maximum retention boundary. Encrypt sensitive results, bind every operation to authorization context and minimize stored arguments and diagnostics.

Where context binding is unavailable, do not advertise tasks/list and prefer shorter bounded retention, as the specification advises. Cryptographically strong task IDs reduce guessing; they do not erase data, authorize a caller or make an open listing safe.

What this run does not establish

The experiment did not use a language model, production agent, McpServer, Client, HTTP, stdio, network, database, Redis, multiple processes, concurrent tasks, authentication, authorization context, crash recovery, wall-clock manipulation, browser, credential, payment, external action or user data. It directly exercised one public demonstration-store class.

It does not establish a vulnerability, exploitability, prevalence, memory cost, data breach, production impact or behavior in another SDK, runtime, store or protocol version. Millisecond timings vary with scheduling. The protocol permits receivers to delete after expiry rather than requiring an exact deletion instant, and MCP tasks remain experimental.

Decision: deploy only a measured retention contract

Deploy durable MCP tasks only when the receiver rejects ambiguous numeric TTLs, returns the lifetime it actually enforces, exposes one clock origin, binds records to authorization context, persists expiry, verifies deletion across every access path and retains results long enough for the agent’s tested recovery objective.

Circuit-break new task creation when zero acts unlimited, negative input becomes a timer, completion silently extends retention, expired results remain enumerable, active work disappears before policy allows, or operators cannot reconcile accepted and actual expiry. An AI agent’s durable result is data with a lifecycle—not a JavaScript truthiness branch.

Disclosures

AccessAllGPT created and ran only the synthetic local fixture in the checked-in harness. Protocol pull request 2408 and TypeScript SDK pull request 1339 are independent contributor records about adjacent TTL representation boundaries; neither reproduces the zero, negative or completion-reset outcomes. No independent public reproduction of those exact outcomes was found. No model, production client, third-party server, credential, endpoint, inference workload, payment, external action or user data was used. The MCP project, contributors, SDK maintainers, Node.js project, npm and Zod maintainers did not review this article or provide access, private data, payment or endorsement. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI, Anthropic, the MCP project, Node.js, npm or Zod. Publication-wide relationships are listed on the disclosures page.