Prometheor

Task status

task_status

Read-onlyIdempotent

Read-only. Returns the state, times, last progress line, live activity while it runs (current_step such as "3 of 7: ...", the app's latest message and last 5 steps) and open question of a task in the owner's account; own says whether your app created it. A verified result is included in the same form as task_result (summary, evidence, files, delivered: true). status_line is a short status line for the time while the task runs; chat_line (once the task ended, asks or waits for review) names the task, the app and the time it took. Both are for your information in the brief's language: never paste them, tell the owner in your own sentences. open_link opens the task's own chat in its app (codex:// or claude://, on the Mac and the phone): put it next to the result so the owner can go on there. wait_seconds waits while the task is queued or running and returns at a result, question or end.

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

Input Schema

Name	Required	Description
`detail`	No	Optional. true returns the longer recent history and the app's full task list instead of the last 5 steps.
`task_id`	Yes
`wait_seconds`	No	Optional. Wait up to this many seconds (at most 20) while the task is still queued or running.
`reply_session`	No	Only for a Claude Code web session or Claude project chat, and then on every call: your session id or claude.ai/code link (as reply_session in delegate). Only this chat's tasks then count as own; without it you also get other chats' tasks, questions and updates.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real behavior: what fields appear at each lifecycle stage, that wait_seconds blocks until a result, question or end, and that open_link only resolves to codex:// or claude:// on Mac and phone. The instruction to paraphrase status_line/chat_line rather than paste them is useful behavioral guidance. The only gap is that wait_seconds' interaction with detail (what you get back when the wait times out) is not spelled out.

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

Conciseness3/5

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

The first sentence front-loads the core purpose, but the remainder is one dense run-on paragraph of parentheticals mixing return-field documentation with usage advice, and 'status_line is a short status line' is near-circular. It is information-dense rather than padded, but a structure of separate clauses for returns, fields and parameters would read far better.

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?

There is no output schema, so the description carries the full burden of describing return values, and it does cover the live fields, open question, verified result and the two status lines. For a polling tool with blocking wait, ownership scoping and a deep-link field, this is close to complete; only timeout behavior and interaction between detail and wait_seconds are ambiguous.

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 75%, and the description adds meaning the schema lacks for the most consequential parameter, explaining that wait_seconds returns at a result, question or end rather than simply elapsing. It is silent on detail and reply_session, but reply_session is already well documented in the schema and detail is covered there too, so little is lost.

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

Purpose4/5

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

The description states a specific verb and resource: it returns the state, times, live activity, open question and verified result of a task. It implicitly separates itself from list_tasks and task_result by noting the result arrives 'in the same form as task_result', but it never names those siblings explicitly as alternatives.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: 'live activity while it runs' and 'wait_seconds waits while the task is queued or running' tell an agent this is the polling tool, and the overlap with task_result is hinted at. There is no explicit 'use this instead of X when Y' routing, so the agent must infer when to poll versus call task_result or read_chat.

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

All Prometheor 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?