Prometheor

What is running

list_tasks

Read-onlyIdempotent

Answers "what is running?" without a new message to any app: the owner's tasks, newest first, from every connected app, with title, state, which app and computer works on it, the folder, who handed it off (own: true for yours), the last progress line and whether it waits on a question or the owner. Open tasks only unless open_only is false. Read-only; details and results of tasks in this account come from task_status and task_result. With include_sessions, also lists recent native app chats to continue (title, folder, a short summary) and the owner's projects (a project is the folder its tasks and chats work in; each task shows its project). With session_query, describe the chat the owner means in their words (app, topic, project); the answer lists the best matching chats and session_match: "clear" when one fits, "ask_owner" when you should show the candidates and ask the owner once which one, "none" when no recent chat fits.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_tasks"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`query`	No	Optional. Finds a big task, ended ones included: its number ("#424") or the owner's words for its topic (title and brief, roughly). Every part, question and follow-up of a big task shares its label. task_match: "clear" when one big task fits, "ask_owner" when you should show the candidates and ask once, "none" when nothing fits.
`since`	No	Optional. Only tasks changed after this time, ended ones included, with their short result; pass the cursor of the last answer to see only what changed since.
`open_only`	No
`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.
`session_query`	No	Optional. The owner's description of a chat to continue, e.g. "the Prometheor website chat in Codex"; returns the best matching chats.
`include_sessions`	No	Include recent native app chats that can be continued, and projects: the folders the owner's recent tasks and chats work in, with the apps that worked there.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses ordering (newest first), the default open-only scope, returned fields, session/project expansion behavior, and the clear/ask_owner/none matching semantics. These details materially help the agent understand the tool's behavior.

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?

The purpose is front-loaded and nearly every sentence carries useful information, but the description is a dense, run-on paragraph. It could be easier to scan if split by parameter or behavior, though it is not padded.

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

Completeness5/5

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

For a 7-parameter read-only list tool with no output schema, the description explains the returned task fields, default filtering, session/project expansion, matching semantics, and where to get details/results. That is complete enough for an agent to call it correctly.

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

Parameters5/5

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

With 71% schema description coverage, the description adds substantial meaning for query, since, open_only, reply_session, session_query, and include_sessions, including cursor behavior and matching outcomes. Only limit is left to the schema, which is reasonable for a simple numeric bound.

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?

The description states a specific verb and resource: it lists the owner's tasks from every connected app, newest first, and names the fields returned. It also explicitly distinguishes this from task_status and task_result for details and results.

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?

It gives clear usage context: open tasks only unless open_only is false, and details/results come from task_status and task_result. It also explains include_sessions and session_query usage, but stops short of explicit when-not-to-use guidance or naming all alternative siblings.

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?