Server-side implementation of the MCP Tasks extension (SEP-2663). Not a to-do manager.
Single tool 'index_corpus' has a minimal description (58 chars) and empty input schema ({}). The description lacks WHAT the tool does beyond vague 'indexes a corpus', WHEN to use it, or what it returns. No parameter descriptions exist because the schema is empty. The tool is registered in code but lacks the structured definition quality expected for production. This server appears to be a library/framework for durable task management rather than a functional MCP server with well-defined tools.
Indexes a corpus. Takes long enough to outlive a crash.
Empty input schema: tool 'index_corpus' has inputSchema: {} with no parameters defined.
Minimal description (58 chars): 'Indexes a corpus. Takes long enough to outlive a crash.' lacks WHAT the tool does (what is indexed?), WHEN to use it, and what it returns. Does not meet 10-1024 char guideline for actionable LLM selection.
No output schema documented: tool returns a task object (created.taskId, etc.) but the response structure is not formally documented. LLMs cannot plan downstream calls without knowing return fields.
No error handling guidance: tool can fail (e.g., task creation fails, indexing crashes) but no error messages guide the LLM on recovery steps or retry logic.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Tool name 'index_corpus' is vague: does not clearly convey that this creates a long-running task. A name like 'create_indexing_task' or 'start_corpus_index' would better signal intent and distinguish from synchronous indexing.