OMP Tandem

Overview Schema Source Related Servers Discussions Admin

tandem_findings

Track coding-review findings across versions, preserving history and separating validity from resolution. Pin correction sets for later closure checks or project dispositions against a target review.

Instructions

Track version-bound review findings without rewriting their history.

Validity and resolution are separate. A claimed fix is not verified; verify_fixed needs evidence and a completed verification task for its snapshot. Update requires the current expected_revision. Get by stable finding_id or conversation_id plus human number. pin fixes the membership of a correction set for review_id once, so closure can be answered later; a live list cannot, because closing a finding removes it from the list. project reads what became of every pinned member of set_id, optionally against a target review. It records dispositions and decides nothing: a claimed fix is still unverified, and an accounted-for member is not a fix that holds.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`action`	Yes
`change`	No
`number`	No
`offset`	No
`set_id`	No
`finding`	No
`task_id`	No
`review_id`	No
`finding_id`	No
`finding_ids`	No
`conversation_id`	No
`expected_revision`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.10.0Sep 17, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "create",
-  "update",
-  "get",
-  "list"
-]New value: +[
+  "create",
+  "update",
+  "get",
+  "list",
+  "pin",
+  "project"
+]

addedInput schema / properties / finding_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 100,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / set_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Addedv3.1.0Sep 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and delivers: findings are immutable/history-preserving, validity and resolution are separate, a claimed fix is unverified until verify_fixed, updates are concurrency-guarded by expected_revision, pin is one-time and permanent, and project 'records dispositions and decides nothing.' For a stateful tool with zero annotation coverage, this is exemplary behavioral disclosure that an agent could not infer from the schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly 150 words across four dense paragraphs, front-loaded with the central invariant ('without rewriting their history') followed by action-specific semantics. Every sentence carries non-redundant information that cannot be derived from the schema, and for a 6-action tool with zero parameter descriptions the length is earned rather than padded.

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?

For a 13-parameter, 6-action tool with 0% schema coverage and no annotations, the description covers the behaviorally tricky operations (verify, pin, project, update concurrency) well, and the existing output schema removes the need to describe return values. The gaps are the unaddressed change sub-actions (note/confirm/reject/reopen) and the create action, which get no behavioral explanation despite being core to the tool.

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%, so the description must compensate, and it does for the high-semantic parameters: expected_revision (concurrency requirement), finding_id/conversation_id/number (get addressing), set_id (project membership), review_id (pin binding), and evidence/verification_task_id (verify_fixed prerequisites). However, several parameters remain unexplained, notably the entire finding object structure (title, description, location, reproduction_conditions) and the change object's other sub-actions (note/confirm/reject/reopen), which are schema-required but behaviorally unspecified.

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 line 'Track version-bound review findings without rewriting their history' states a specific verb+resource and a distinguishing design property. The multi-action nature (create/update/get/list/pin/project) is clear from the schema enum, and the description makes it obvious this tool is the findings manager among the tandem_* siblings, none of which overlap. A crisp single-sentence purpose statement, though it doesn't enumerate all six actions in the prose.

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?

Gives explicit action-level guidance: verify_fixed needs evidence plus a completed verification task, update requires the current expected_revision, get works by finding_id or conversation_id plus number, and pin is chosen over a live list because closing a finding removes it. The pin-vs-list distinction is a genuine when-to-use-which explanation. No explicit sibling comparisons, but none of the siblings compete with this tool's domain, so that omission is acceptable.

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