OMP Tandem

Overview Schema Source Related Servers Discussions Admin

tandem_wait

Wait for any selected task to finish or ask a question, returning ready IDs or questions instead of full answers. Use tandem_result for terminal results and to remove tasks from later waits.

Instructions

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

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.6/5.0

Behavior5/5

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

With no annotations, the description carries full burden and covers substantial behavior: wait_seconds served in full, background-task handoff, wait_mode semantics ('auto' vs 'bounded'), return of ready IDs/questions rather than full answers, no acknowledgment/rerun, and watchdog caveat. This goes well beyond the schema.

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?

Purpose is front-loaded in the first sentence, and parameter/behavior details follow in tight paragraphs. Dense but every sentence adds information; slight redundancy/complexity for the background-task handoff prevents a 5.

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?

Given no annotations and a complex asynchronous wait tool, the description covers parameter behavior, return semantics, follow-up workflow, side-effect boundaries, and safety caveats. The presence of an output schema means return-value details do not need to be spelled out.

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 description coverage is 0%, but the description compensates for wait_seconds (range and server semantics) and wait_mode (auto/bounded meanings). task_ids is not explicitly described beyond 'selected task', though it is clear from the required schema field and tool name.

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 opening sentence names the specific operation: wait for any selected task to finish or ask a question, and explicitly contrasts with waiting for each in turn. Later it directs to tandem_result for reading results, which differentiates this tool from that sibling.

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 a workflow: use return IDs/questions to read ready terminal results via tandem_result and remove them from later wait sets, or reply to questions. It also states limitations—does not acknowledge terminal events or rerun work, and async background cases—but does not crisply enumerate 'use when X instead of Y' as a decision rule.

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