First implementation of the Tasks extension (SEP-2663) — feedback on the status mapping? #3189
Replies: 1 comment
|
I checked these choices against the final SEP and the current implementation. Your three interpretations are correct, with one important security/conformance issue worth fixing.
The issue I would change before calling it fully conformant is the task identifier. job_id = uuid.uuid4().hex[:8]That exposes only 32 random bits. The Tasks security requirements say task IDs must have enough entropy to be unguessable and that every task request must be authenticated/authorized for that task. Capability negotiation is not authorization. I would use at least the full UUID ( Relevant final-spec sections: Task Status, Error Handling, and Security Implications. |
Uh oh!
There was an error while loading. Please reload this page.
I just shipped backburner 1.0, an open-source (MIT) MCP server that implements the Tasks extension (io.modelcontextprotocol/tasks) against the final 2026-07-28 spec. It runs shell commands as durable, on-disk background jobs, so a task started in one session is still retrievable in a completely separate one.
Since there don't seem to be many Tasks implementations out there yet, I wanted to share the design decisions I had to make and check them with the people who wrote the spec:
Status mapping for tool-level vs protocol failures. I map a job's non-zero exit code and timeouts to task status completed with isError: true (the tool ran, it just failed), and reserve failed for actual JSON-RPC protocol faults — e.g. my server process dying mid-task surfaces as failed with an INTERNAL_ERROR. Is that the intended reading of completed vs failed, or should a killed-by-timeout task be failed?
Capability gating. I read the client's declared extensions off client_capabilities and reject any tasks/* call from a client that didn't declare the extension with -32021. Unknown/expired taskId → -32602. Does that match expectations?
ttlMs: null. I use null to mean "no expiry" for tasks that persist on disk indefinitely. Is that the right convention?
Happy to write up fuller implementation notes if useful, and I'd love to compare with anyone else building Tasks support — especially on the client side, since I haven't been able to round-trip against a real Tasks-capable client yet.
All reactions