OMP Tandem

Overview Schema Source Related Servers Discussions Admin

tandem_result

Waits for an independent AI peer's answer or question with a bounded timeout, returning early on completion. Use it to collect task results, optionally with report metadata.

Instructions

Wait for the actual answer or a question, with a bounded response.

Default: one bounded wait up to 1200 seconds. Questions and completion return earlier. Use wait_seconds=0 for one observation, or wait_mode="auto" while doing complementary work. A client's background handoff is not a failed launch: retain that handle rather than starting another wait or worker. Completion is not acceptance. details=true adds bounded report metadata; follow readers/next_request for complete answer, report and contract.

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

Input Schema

Name	Required	Default
`details`	No
`task_id`	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: -0New 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

A3.6/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden and does well: it discloses the default and maximum wait duration, that questions and completion return earlier, and the non-obvious caveat that "completion is not acceptance" and that a background handoff is not a failed launch. It leaves error/timeout behavior and task_id validity unstated.

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?

Front-loaded with the core action and the default behavior, then branching options, then caveats. It is dense but nearly every sentence carries operational information; mild jargon ("contract", "readers/next_request", "background handoff") costs some clarity.

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 it correctly avoids explaining return values and instead points to readers/next_request inside the payload. For a polling tool with no annotations, the main remaining gaps are task_id semantics and what happens on timeout or invalid IDs.

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 description coverage is 0%, so the description must compensate and it partially does: wait_seconds=0 semantics, the 1200s default cap, wait_mode="auto", and details=true adding report metadata are all explained. The required task_id is never described, and the distinction between "bounded" and "auto" is only implied rather than defined.

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

Purpose3/5

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

The description identifies the operation as waiting on a task for its answer or a pending question, which is specific enough to act on. However, with siblings like tandem_read_result and tandem_wait present, it never states how this differs from them, so an agent cannot route between the three from the description alone.

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 branches: default is one bounded wait up to 1200s, use wait_seconds=0 for a single observation, use wait_mode="auto" while doing complementary work. It also warns against spawning another wait or worker when a client hands off in the background, which is a genuine when-not to act.

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