delega-mcp

get_task

Retrieve a task's details, ownership, handoff, links, and subtasks as bounded JSON. Follow cursors for large details; context is separate.

Instructions

Get a task's details, ownership, handoff, links and subtasks as bounded JSON. Context is retrieved separately through get_task_context. Follow text cursors with the same task ID for large details; do not treat a fragment as complete.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "get_task"
  }
}

Input Schema

Name	Required	Description
`cursor`	No	Next text cursor returned by a large read. Repeat identical selectors; changed content invalidates the cursor.
`task_id`	Yes	The task ID (use the ID from list_tasks, e.g. '3a7d...')
`max_chars`	No	Maximum response characters (default 6000); omitted data remains explicitly retrievable.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.19.0Sep 11, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "Next text cursor returned by a large read. Repeat identical selectors; changed content invalidates the cursor.",
+  "maxLength": 100,
+  "type": "string"
+}

addedInput schema / properties / max_chars

Added value: +{
+  "description": "Maximum response characters (default 6000); omitted data remains explicitly retrievable.",
+  "maximum": 16000,
+  "minimum": 1000,
+  "type": "integer"
+}

removedInput schema / properties / task_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / task_id / type
```
Added value: +[
+  "string",
+  "number"
+]
```

Changed4 schema fields changedv1.2.1May 1, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / task_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]

changedInput schema / properties / task_id / description

Previous value: -"The task ID"New value: +"The task ID (use the ID from list_tasks, e.g. '3a7d...')"

removedInput schema / properties / task_id / type
```
Removed value: -"integer"
```

First observedv1.0.3Mar 13, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose non-obvious behavior: output is 'bounded JSON', large reads paginate via text cursors, and a fragment must not be treated as complete. It omits auth/permission requirements and error behavior, but the pagination and bounded-output disclosures are genuinely useful beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each earning its place: the scope is front-loaded, the sibling routing follows, then the pagination caveat. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with no output schema and no annotations, the description enumerates the returned facets and explains the pagination/bounded-output model, which is enough to call it correctly. Only absent pieces are permission requirements and error semantics, which are minor here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already documents cursor, task_id and max_chars. The description reinforces the cursor rule ('same task ID', fragments incomplete) but adds little formal syntax or format detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) plus the exact resource and returned facets (details, ownership, handoff, links, subtasks), and explicitly carves out what it does NOT return ('Context is retrieved separately through get_task_context'). An agent can distinguish it from get_task_context and list_tasks without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly routes context-fetching to the named sibling get_task_context and gives pagination guidance ('Follow text cursors with the same task ID for large details; do not treat a fragment as complete'). It lacks an explicit negative condition (e.g. when to prefer list_tasks or get_task_chain), so it stops short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.