Retrieve a canonical task by its typed task_id through Core to inspect persistent multi-agent work records and support file-based coordination workflows.
Read a canonical TASK by its typed identity through Core.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Changes observed during successful MCP inspections.
v4.0.5Input schema / properties / filenameRemoved value: -{
- "description": "Task filename (e.g. ``TASK-20260423-001-PM-to-DEV.md``)\nor plain task ID (e.g. ``TASK-20260423-001``). Both open\nand archived tasks are searched.",
- "type": "string"
-}Input schema / properties / task_idAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "filename"
-]New value: +[
+ "task_id"
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullv3.2.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about what happens when the task_id is unknown, whether the result is a snapshot or live state, or permission requirements. "Canonical" weakly hints that the returned record is authoritative but is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb first and no filler sentences. It is efficient, though the brevity comes at the cost of the missing guidance noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an undocumented parameter, the description leaves too much unsaid for an agent to call this correctly. It omits both the identifier format and the shape of the returned task record.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter with 0% schema description coverage, so the description must compensate. "Typed identity" gestures at the meaning of task_id but gives no format, source, or example of what a typed task identity looks like versus other identifiers used by sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+resource pair ("read a canonical TASK") is clear enough, but the qualifiers "typed identity" and "through Core" are internal jargon that add no discriminating information. It also fails to distinguish itself from the sibling inspect_task, which plausibly does the same thing, so an agent cannot choose between them from the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus inspect_task or list_tasks, and no prerequisites or error conditions. The description only implies usage through the word "Read".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.