OMP Tandem

Overview Schema Source Related Servers Discussions Admin

tandem_result

Retrieve a task's actual answer, work outcome, and next action by providing its task ID, with optional wait and detail settings for immediate or bounded results.

Instructions

Get the actual answer, work outcome and next_action. Questions return immediately.

wait_seconds: 0..1200, served in full by the server. A client may stop holding the call in the foreground first, and what it does then differs by client: if it answers that it moved the request to a background task, read that result instead of retrying; one measured Claude Code run handed off at 120 seconds and delivered every result. wait_mode="auto" also returns as soon as event delivery covers this task; "bounded" waits for the task itself, which costs one call instead of many when the client cannot use the waiting time. Either way the wait is finite and cancellable, and expiry is reported in wait, never as a task state. completed is turn completion, not proof of success. answer holds the requested text; summary only describes the work. When answer_truncated, read answer_artifact_id. details=true includes the full answer/report/contract/diagnostics.

Input Schema

TableJSON Schema

Name	Required	Default
`details`	No
`task_id`	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/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: wait limits, cancellation, expiry reporting via 'wait', completion versus success semantics, truncation handling, and details behavior. This is rich, specific, and directly actionable.

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 the dense paragraphs earn their length by explaining nuanced wait behavior, truncation, and completion semantics. The anecdotal 'measured Claude Code run' detail is slightly extraneous, and formatting is a wall of text, but nothing critical is missing.

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 need not be described. The description thoroughly covers wait behavior, cancellation, completion semantics, and artifact fallback. It lacks explicit error-condition guidance and sibling routing, but is otherwise complete enough to invoke correctly.

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 compensate. It explains wait_seconds range and server behavior, wait_mode auto vs bounded tradeoffs, and details=true inclusion. task_id is not explicitly explained, but it is the one required identifier and is obvious from context.

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 description states a specific verb ('Get') and resource ('actual answer, work outcome and next_action'), and clarifies that questions return immediately. It does not explicitly distinguish this from sibling result-related tools like tandem_receipt or tandem_wait, relying instead on behavioral detail.

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?

The description gives clear context for when results are immediate and how wait_mode auto vs bounded behave, including how to handle background task handoff. However, it never explicitly says when to use this tool instead of alternatives such as tandem_wait or tandem_receipt.

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