ExperimentalExperimentalExperimentalCreates a new task with the given creation parameters and original request. The implementation must generate a unique taskId and createdAt timestamp.
TTL Management:
The task creation parameters from the request (ttl, pollInterval)
The JSON-RPC request ID
The original request that triggered task creation
Optional_sessionId: stringThe created task object
ExperimentalGets the current status of a task.
The task identifier
Optional_sessionId: stringThe task object, or null if it does not exist
ExperimentalStores the result of a task and sets its final status.
The task identifier
The final status: 'completed' for success, 'failed' for errors
The result to store
Optional_meta?: {See MCP specification for notes on _meta usage.
OptionalprogressToken?: string | numberIf specified, the caller is requesting out-of-band progress notifications for this request (as represented by notifications/progress). The value of this parameter is an opaque token that will be attached to any subsequent notifications. The receiver is not obligated to provide these notifications.
Optionalio.modelcontextprotocol/related-task?: { taskId: string }If specified, this request is related to the provided task.
Optional_sessionId: stringExperimentalRetrieves the stored result of a task.
The task identifier
Optional_sessionId: stringThe stored result
ExperimentalUpdates a task's status (e.g., to 'cancelled', 'failed', 'completed').
The task identifier
The new status
OptionalstatusMessage: stringOptional diagnostic message for failed tasks or other status information
Optional_sessionId: stringExperimentalLists tasks, optionally starting from a pagination cursor.
Optionalcursor: stringOptional cursor for pagination
Optional_sessionId: stringAn object containing the tasks array and an optional nextCursor
ExperimentalCleanup all timers (useful for testing or graceful shutdown)
ExperimentalGet all tasks (useful for debugging)
A simple in-memory implementation of TaskStore for demonstration purposes.
This implementation stores all tasks in memory and provides automatic cleanup based on the ttl duration specified in the task creation parameters.
Note: This is not suitable for production use as all data is lost on restart. For production, consider implementing TaskStore with a database or distributed cache.