OMP Tandem

Overview Schema Source Related Servers Discussions Admin

tandem_wait

Waits for any selected task to finish or ask a question, returning ready IDs or questions so you can act on the first ready result instead of polling each task.

Instructions

Wait for ANY selected task to finish or ask a question, not for each in turn.

Like tandem_result, this defaults to a long bounded wait: the first task to finish or ask returns it. Pass wait_seconds=0 to peek at which tasks are already ready, and wait_mode="auto" when you have complementary work.

wait_seconds: 0..1200, served in full by the server; a client may stop holding the call in the foreground first; if it says it moved the request to a background task, read that result. wait_mode works as in tandem_result: "auto" also returns once event delivery covers every pending task, "bounded" waits for one of them to become ready. Returns ready IDs/questions, not full answers. Read ready terminal results with tandem_result and remove them from later wait sets; reply directly to a returned question. Does not acknowledge terminal events or rerun work. Await events only with a live independent watchdog.

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_ids": "<task_ids>"
    },
    "name": "tandem_wait"
  }
}

Input Schema

Name	Required	Default
`task_ids`	Yes
`wait_mode`	No	bounded
`wait_seconds`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.14.0Oct 29, 2026
- changedInput schema / properties / wait_mode / default
```
Previous value: -"auto"New value: +"bounded"
```
- changedInput schema / properties / wait_seconds / default
```
Previous value: -20New value: +1200
```

Changed2 schema fields changedv3.10.0Sep 17, 2026

addedInput schema / properties / wait_mode

Added value: +{
+  "default": "auto",
+  "enum": [
+    "auto",
+    "bounded"
+  ],
+  "type": "string"
+}

changedInput schema / properties / wait_seconds / maximum
```
Previous value: -25New value: +1200
```

First observedv3.0.1Sep 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so: server-side full wait_seconds service, the possibility that a client stops holding the call and moves it to a background task (read that result instead), that it returns ready IDs/questions rather than full answers, that it does not acknowledge terminal events or rerun work, and the watchdog caveat. These are exactly the non-obvious traits an agent needs before calling a long-blocking wait.

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 core distinction is front-loaded, which is good, but the prose is a dense run-on with awkward phrasing ("Wait for ANY selected task to finish or ask a question, not for each in turn") and a mild redundancy in first deferring to tandem_result for wait_mode semantics and then re-explaining them anyway. Most sentences earn their place, but the packing hurts scanability for an agent.

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?

An output schema exists, so return values needn't be fully specified, yet the description still usefully says it returns ready IDs/questions rather than answers. Behavioral coverage is strong for a no-annotation tool; the one real hole is the required task_ids input's origin and validity, which nothing else in the structured data supplies.

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 0%, so the description must explain parameters and it does well for two of three: wait_seconds is characterized (0..1200, served in full by the server, client may return earlier) and wait_mode's two enum values are given distinct meanings beyond the enum names. The required task_ids parameter is never characterized — no statement of where the IDs come from or what the 32-item cap implies — leaving the most important input undocumented.

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 first sentence states a specific verb (wait) and resource (a set of selected tasks) plus the key scope distinction: it returns on the FIRST task to finish or ask, "not for each in turn." It also names the sibling (tandem_result) it complements, so an agent can separate it from the per-task result readers without opening a 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?

It gives concrete usage triggers: wait_seconds=0 to peek at readiness, wait_mode="auto" when you have complementary work, and it routes follow-up actions (read terminal results with tandem_result, reply directly to a returned question). It never states an explicit when-NOT-to-use or a prerequisite for obtaining task_ids, which keeps it below 5.

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