Loading ToolBench
Durable, resumable operations for MCP servers: long-running tasks and chunked file transfers that survive timeouts, disconnects, and client restarts — on every client, no Tasks-extension support required.
mcp-longjobs demonstrates solid patterns for durable task and file-transfer operations with clear naming (verb_noun convention) and structured schemas. However, descriptions are inconsistent in depth and some parameter documentation lacks actionable constraints. Tool names are clear and follow verb-first convention (generate-report, durable_task_get, file_transfer_*). Schemas are present and typed for all tools. Main gaps: parameter descriptions lack format/range guidance (e.g., 'path' parameter has no validation rules), error handling descriptions are generic, and output schemas are not formally documented. The e2e-demo.mjs shows the tools work end-to-end, but production-grade descriptions would benefit from explicit constraint documentation and recovery guidance.
Cooperatively cancel a running task. The task stops at its next checkpoint.
Poll a long-running task created by this server. Repeat until status is "completed" or "failed".
Deliver input that a paused task (status input_required) asked for.
Verify size and sha256, move the staged file into place.
Open a chunked upload or download session. Upload: send chunks with file_transfer_write starting at offset 0, then file_transfer_commit. Download: fetch chunks with file_transfer_read until eof. Sessions survive server restarts — resume at the reported nextOffset.
Fetch a byte range as base64. Repeat with nextOffset until eof; the final response carries the whole-file sha256.
Parameter descriptions lack actionable constraints. 'path' parameter in file_transfer_open has no validation rules (e.g., allowed characters, max length, directory traversal protection). 'data' in file_transfer_write says '(<= the session's chunkSize)' but does not specify what chunkSize is or how to determine it.
Output schemas are not formally documented. Tools return structured JSON (taskId, status, progress, result, etc.) but the response schema is inferred from e2e-demo.mjs rather than declared in tool definitions. LLMs cannot plan downstream calls without explicit output documentation.
Error handling descriptions are generic. 'durable_task_respond' says 'Deliver input that a paused task asked for' but does not explain what happens if the response is invalid, what error codes are possible, or how to recover. No guidance for retryable vs. fatal errors.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Inspect a transfer session (survives server restarts with a durable store).
Append a base64 chunk at the session's expected offset. A wrong offset returns a repairable error with the correct cursor instead of failing the transfer.
Simulates a slow job (~2s per section). Demonstrates background execution, progress polling, restart-safe state, and cooperative cancellation.
Parameter 'response' in durable_task_respond lacks type and format guidance. Is it a string, JSON, or binary? What encoding? What length limits? Description says 'Deliver input' but does not specify the expected structure.
file_transfer_status description is minimal (18 chars: 'Inspect a transfer session'). Does not explain what fields are returned, when to call it, or what state transitions are possible. Below the 34-char p10 baseline for tool descriptions.