EasyTerritory MCP

Get Task Result

tasks_result

Read-onlyIdempotent

Tool equivalent of the native MCP tasks/result, listed for clients without the Tasks capability. Returns the originating tool's terminal result once the task status is completed (consume_result): ts_handle, counts, timings, and map binding, never an inline Territory Solution. A build's ts_handle or task_id (as job_id) is the input analyze takes.

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": "tasks_result"
  }
}

Input Schema

Name	Required	Description	Default
`task_id`	Yes	task_id whose status next_action is consume_result.

Output Schema

Name	Required	Description
`ok`	Yes
`error`	No	Present when ok is false.
`result`	No	Present when ok is true. A submission returns the task reference (task_id, next_action, sleep_ms); the completed task result carries the remaining fields.
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026

addedInput schema / properties / task_id / description

Added value: +"task_id whose status next_action is consume_result."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "error": {
+    "description": "Present when ok is false.",
+    "properties": {
+      "ask_user": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "code": {
+        "type": "string"
+      },
+      "details": {
+        "type": "object"
+      },
+      "do_this_next": {
+        "type": "object"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "ok": {
+    "type": "boolean"
+  },
+  "result": {
+    "description": "Present when ok is true. A submission returns the task reference (task_id, next_action, sleep_ms); the completed task result carries the remaining fields.",
+    "properties": {
+      "do_this_next": {
+        "type": "object"
+      },
+      "job_id": {
+        "type": "string"
+      },
+      "next_action": {
+        "type": "string"
+      },
+      "sleep_ms": {
+        "type": "integer"
+      },
+      "status": {
+        "type": "string"
+      },
+      "task_id": {
+        "type": "string"
+      },
+      "terminal": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "warnings": {
+    "items": {
+      "properties": {
+        "code": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "ok"
+]
```

removedOutput schema / title

Removed value: -"tasks_resultDictOutput"

First observedSep 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, so the safety profile is covered; the description adds real extra context by disclosing the gating condition and the important output caveat 'never an inline Territory Solution'. It does not discuss failure modes (e.g., what happens when status is not yet completed).

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

Conciseness4/5

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

Three sentences, front-loaded with the essential equivalence and precondition, with zero filler. Density is high and mildly jargon-heavy ('consume_result', 'map binding'), but nothing is redundant.

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?

With an output schema and full annotations present, the description supplies the remaining decision-critical information: when the call is valid and what downstream tool consumes the result. Minor gaps are around error behavior when the task is not yet complete, which an agent would likely need.

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

Parameters4/5

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

Schema coverage is 100% and the single required task_id is documented there as needing next_action = consume_result. The description goes beyond the schema by explaining that a build's task_id may arrive as job_id and that the returned ts_handle is what analyze consumes, which clarifies the value's lifecycle.

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 and resource ('Returns the originating tool's terminal result') and frames it against the native MCP tasks/result counterpart, so the agent knows exactly what this is. The enumerated payload (ts_handle, counts, timings, map binding) further pins down the purpose beyond the name.

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?

Gives a clear precondition — call only once the task's next_action is consume_result/completed — and names the audience constraint (clients without the Tasks capability), which implicitly routes native-capable clients elsewhere. It also hands off the result to analyze, though it does not explicitly contrast with tasks_get, which is the nearest confusing sibling.

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

All EasyTerritory MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?