Skip to main content
Glama
Sign In
subtask

subtask

by tedin7
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

wait

Block until background jobs or groups finish, then return their summaries; choose all, any, or first-success completion and get early results when a job stalls.

Instructions

Block until jobs or groups end and return their summaries. mode: all | any (first to end) | first_success (first done and verified; the rest are stopped). Returns early on a stalled job. since: cursor for clients without progress; with it, timeout is capped at 60 s. For Codex: wait(ids, mode='any', timeout=60, since=''), drop ended ids and pass back cursor=. An idle Codex 0.164.0 is not woken by ordinary local MCP progress or log notifications. Includes the automatic Jev delivery/evidence/risk advice, raw provider choice, wrapper assessment and next action: read it before a manual review and do not resubmit the same work.

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": {
      "ids": "<ids>"
    },
    "name": "wait"
  }
}

Input Schema

NameRequiredDescriptionDefault
anyNo
idsYes
modeNo
sinceNo
timeoutNo
stall_timeoutNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does add real behavioral detail: early return on a stalled job, the 60 s timeout cap when a cursor is supplied, which jobs get stopped under first_success, and the caveat that an idle client is not woken by ordinary MCP progress or log notifications. Gaps remain on what happens when timeout expires without completion and on error behavior, but the disclosure is well above the norm for an unannotated tool.

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 lead sentence is well front-loaded and every sentence does carry information, but the body is a dense run-on that interleaves general behavior with a client-specific workaround and internal jargon ('Jev delivery/evidence/risk advice', 'raw provider choice, wrapper assessment') an agent may not be able to parse.

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

Completeness3/5

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

For a six-parameter, unannotated, output-schema-less tool the description covers the core behavior and the return of job summaries, but it leaves two parameters unexplained and gives no sense of what a 'summary' contains or how partial timeouts are reported. It is close to sufficient for calling the tool, not for interpreting the result.

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 0%, so the description must compensate for all six parameters, and it only partly does: mode values are fully explained and since/cursor semantics are described, but the 'any' boolean (which appears redundant with mode) and 'stall_timeout' are never mentioned, and the default 300 s timeout is not discussed. Roughly half the parameters get meaning added, which is helpful but leaves the schema under-documented.

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 opening sentence gives a concrete verb and resource: block until jobs or groups end and return their summaries. That is clearly distinct from a fire-and-forget 'start' or a 'status' poll, but the description never names a sibling or says why an agent would pick 'wait' over 'status'/'result' when it wants job output.

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?

Mode semantics (all | any | first_success) are spelled out and there is a concrete recommended call pattern for one client, plus the instruction to read the returned advice before a manual review and not resubmit the same work. However, there is no explicit when-not-to-use guidance or routing to alternatives such as polling status or fetching a result directly, so the usage context is implied rather than stated.

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

Deploy Server

Other Tools