OMP Tandem
OMP Tandem is an MCP server that gives a coding agent an independent AI peer via Oh My Pi, supporting persistent conversations, shared tasks, and read-only reviews.
Start and manage tasks (
tandem_start,tandem_continue,tandem_result,tandem_reply,tandem_cancel,tandem_list): launch think/analyze/work tasks with structured contracts, continue conversations, get results, answer clarifications, and wait/cancel.Coordinate shared work (
tandem_work): create durable multi-step plans with owners, reviewers, acceptance criteria, dependencies, claims, submissions, accept/reject, blockers, and progress tracking.Review code (
tandem_review,tandem_review_run): capture immutable worktree/staged/commit snapshots, run independent read-only reviews with optional author-rationale comparison, and manage review runs.Track findings (
tandem_findings): log, confirm, reject, reopen, claim/verify fixes, and project correction sets against reviews.Share artifacts and context (
tandem_publish_artifact,tandem_read_artifact,tandem_project_context,tandem_export_context,tandem_import_context): publish immutable artifacts and versioned product rules/decisions with explicit cross-project transfers.Page context and inspect scope (
tandem_context_read,tandem_scope): read pinned snapshot data and inspect project boundaries, profiles, and capabilities.Audit evidence (
tandem_audit): optionally ask Jev about gaps between acceptance criteria and reported evidence, with previews and explicit approval controls.Wait efficiently (
tandem_wait): wait on multiple tasks at once, returning ready IDs and questions.Diagnose and monitor (
tandem_diagnose,tandem_channel): check project/OMP/model/delivery state and manage optional push-channel delivery with probes and acknowledgements.Gate result processing (
tandem_receipt): claim terminal results before applying them and complete with a token to avoid duplicate effects.
Integrates with Git for version-bound review bundles, staged/index snapshots, worktree comparisons, and shared task claims/submissions requiring a Git repository with an immutable HEAD commit.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@OMP TandemAsk OMP to independently challenge this design while I inspect the API constraints."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OMP Tandem
Give your coding agent an independent AI peer.
Consult, design, implement, and review together through Oh My Pi, with persistent conversations and project-isolated MCP tools.
Quick start · Jev assistance · Full guide · Releases · Contributing
Why OMP Tandem?
A second agent should do more than approve the first agent's work. OMP Tandem lets your coordinator ask for independent reasoning, explore alternatives, delegate a separate implementation slice, and compare findings against evidence.
Real OMP, your provider. Uses the official
omp_rpcclient andomp --mode rpc, not a substitute direct-API wrapper.Proportional planning. Independent assessment, one comparison, a concrete plan, then implementation and cross-checking—not a fresh whole-project audit for every local fix.
Persistent conversations. Continue a discussion while replacing the current goal and preserving its base constraints.
Scoped knowledge. Separate project histories, optional versioned product rules, and explicit cross-project sharing.
Honest results. Structured outcomes, questions with deadlines, and recoverable intermediate artifacts.
Version-bound reviews. Choose worktree or staged-only material, then use independent-first comparison, stale-result detection and finding history. Review workflow.
Bounded waiting and visible usage. Claude watchdog with polling fallback, explicit live diagnostics, and depth/budget settings separate from permissions. Profiles and usage.
Portable integration. Claude Code plugin, Agent Plugins package for Codex, and ordinary local stdio MCP for other hosts.
Optional Desktop QA handoff. Send UI tests to an already authorized desktop session; wait in server code and receive terminal events without model polling. Requires an external queue backend, not an autonomous GUI launcher. Setup and limits.
Optional Jev assistance. Report audits, candidate suggestions, shadow model routing and reversible context/tool/output focus. Explicit export approval; no automatic acceptance or model switching. Availability and setup.
No company-specific policies or hardcoded project paths are bundled.
Related MCP server: agentboost
Quick start
1. Install the prerequisites
Requires macOS/Linux, or WSL with Linux tools, plus uv and OMP on PATH.
With Homebrew:
brew install uv
brew install can1357/tap/omp
omp setupUse OMP's setup flow to authenticate your own supported provider and select a tool-capable model. The host agent has its own separate login. For Linux/standalone installation, API keys, OAuth, and local models, see the setup guide.
2. Install for your host
Claude Code
claude plugin marketplace add Flyozzzz/omp-tandem-public
claude plugin install omp-tandem@omp-tandemCodex CLI
codex plugin marketplace add Flyozzzz/omp-tandem-public
codex plugin add omp-tandem@omp-tandem --jsonStart a new session from your project's directory. Do not keep an old standalone registration enabled alongside the plugin. This repository is public; no invitation is required.
Python dependencies are prepared automatically in a private cache. OMP installation and provider authentication remain explicit user setup. Other clients can use the standard MCP configuration.
3. Check this project's setup
In Claude, run /omp-tandem:setup and ask for local diagnosis only. Confirm that Tandem is bound to your project, not the plugin/cache directory, and inspect runtime and delivery prerequisites. This does not call a model or prove provider authentication; a separate live diagnostic is optional and needs your approval.
4. Review your prepared commit
Stage the intended changes, then use /omp-tandem:tandem or ask in natural language:
Use OMP Tandem to review my prepared commit, using staged changes only. Use this task's requirements and acceptance criteria; ask me if they are missing. Do not edit files. Report correctness risks with evidence and identify missing context.
The agent uses tandem_review_run: a saved staged/index snapshot, one independent read-only assessment and at most one comparison with separately supplied author rationale. It does not edit files or run supplied test commands. Missing source context requires a fresh expanded snapshot, not live files added to an old review. Review details.
5. Give both agents one shared task
Use OMP Tandem to agree a shared task for this feature. Record the goal, constraints, acceptance criteria, module owners and distinct reviewers. Split independent modules, add a final integration step, and keep the checklist and blockers current. Do not launch unattended work until I grant its limits.
tandem_work exposes the same durable card to both participants, including a readable Markdown view. Work survives a conversation ending; a saved task is not a running agent. Existing-client work is manual; opt-in unattended execution uses a separate bounded controller, dedicated Claude/OMP attempts and isolated Git worktrees. Accepted results are not silently merged into your current branch. Shared-task workflow and operator commands.
Two entry paths
Staged review: independent assessment of a saved snapshot.
Shared development and operator grants: plan, ownership, exact submissions and distinct review. Claim/submit require the bound Git root with HEAD; task
cwdcannot repair that boundary. Unattended launches need explicit operator authorization. Shell is arbitrary execution, not a sandbox; reports are not acceptance.Migration and disabled helpers: no migration restarts work or retroactively makes a review independent.
Compact state and recovery
See compact views, runtime identity and recovery and operator blocker resolution. Hints and notifications grant no authority; resolving a blocker never resumes or authorizes work. Independent acceptance is separate from operator application and publication.
Latest published release: 3.12.0. Managed submission checks ownership before recording intent; current views distinguish intent from committed output. Explicitly authorized supervisor review checks use a prepared, immutable Linux Docker image and a separate exact-commit copy inside the existing product step, without reviewer shell tools. Network defaults to none; confirmed container removal is required, with no host fallback. Old grants are not upgraded. See the changelog. Updating the repository does not restart existing work or authorize new execution.
Team mode (unreleased)
Ask the coordinator to split development, research or review into a team. tandem_team
runs 2–16 planned steps, up to four concurrently, followed by a final integration step.
It queues file conflicts, preserves partial results and cancels pending and active work
without replaying uncertain execution. Work stays in the live project; this is not a sandbox.
Assigned workers no longer wait for unrelated model choices. Read-only research can
opt its final think step into dependency_policy="reported_evidence" to summarize
structured partial evidence while retaining an overall partial outcome. Development
dependencies remain success-only. Status replies are bounded, with lossless paged recovery.
The model pool is only OMP-available openai-codex subscription models.
OpenRouter, ordinary OpenAI API and other providers are excluded. With an
OPENROUTER_API_KEY, Jev automatically advises on roles and model assignments;
that key is for Jev, not a source of worker models. Each assignment includes the
model and its supported thinking level; explicit choices win.
Without Jev or a confident choice, the coordinator consults its OMP peer and
submits an agreed assignment from the same eligible pool.
Disable Jev globally with --jev off / OMP_TANDEM_JEV=off, or use
plan.model_selection="coordinator" for a team that sends no summaries to Jev.
Auto classification exports the declared goal/title summaries and public model
facts, not source files, contract context or histories. Protocol and examples.
Optional Jev assistance and shadow routing
Jev is a separate, optional structured-decision service—not the model that performs
the coding task. Recommendation, shadow-routing and focus are new in 3.12.0
and absent from 3.11.0 and earlier. Inspect the loaded
runtime's tandem_scope capabilities before using them.
Capability | Purpose | Availability |
| Flag gaps between acceptance criteria and reported evidence | 3.11.0 and later |
| Suggest one caller-supplied skill or review direction before task creation |
|
| Compare a task-start model suggestion with the unchanged execution model |
|
| Rank optional context, defer permitted native tool schemas and retrieve exact focused excerpts | This checkout, unreleased |
Audits and recommendations support exact keyless previews. A runtime OpenRouter
key automatically enables recommendations unless disabled; --jev-recommend
remains an explicit enable switch. Report audits still require --jev-audit.
Recommendation sends additionally require the approved preview's matching hash.
Advice and confidence are not verified correctness or permission.
For shadow model routing:
The operator provides two or three exact models in a policy file through
--jev-routing-policy PATHorOMP_TANDEM_JEV_ROUTING_POLICY.Both the policy and the task's
execution.routingmust explicitly approve export of a short summary. No summary is inferred from prompts, files or history.Code checks the catalog, capabilities, declared context/output estimates and optional estimated cost ceiling. An isolated metadata-only probe keeps catalog stalls separate from the execution process.
Jev may suggest an eligible model,
none, orunclear. The task still uses its original model;tandem_result.execution.routingrecords the proposal, reason, routing time and separate Jev usage.
Explicit model choices, continuations, snapshot reviews and managed work bypass
the router. It never changes thinking, tools, roles, grants or acceptance. An
ordinary routing failure preserves the original selection; uncertain sends are
not retried. Missing OPENROUTER_API_KEY produces an explicit bypass.
Context/tool/output focus requires --jev-focus-policy PATH, approved data
classes and explicit execution.focus export consent for the current task.
Required context and permissions stay fixed; omitted material remains recoverable.
Focused readers return exact, nonexhaustive excerpts—not generated summaries.
This does not compact native history or select arbitrary outside-host tools.
Local RPC/HTTP and pinned-OMP checks verify the exercised boundaries. Small live synthetic Jev runs succeeded; general accuracy, speedups and cost savings are not established. Deferred schemas can shrink the first request while increasing the complete interaction. See the audit guide, candidate recommendations, shadow routing and focus configuration and measurements.
Plan changes and repository handover
See plan transitions for stop evidence, saved checkpoints, capture-failure acknowledgments and fresh authorization; repository handover for boundary diagnostics and explicit closure/provenance commands.
Only the operator drives transitions and execution reconciliation. Supervisor teardown proves process stop, not absence of external effects. Never replay uncertain effects. Cross-scope links transfer no access, agreements, grants or acceptance; review the exact result in its own scope before explicit application.
How it works
flowchart LR
A[Coding agent] <-->|MCP stdio| T[OMP Tandem]
T <-->|official omp_rpc| O[Oh My Pi]
O <--> M[Your configured model]
T <--> D[(Project data)]Mode | Use it for | Project access |
| Consultation and reasoning over supplied context | No project/shell tools; collaboration tools remain available |
| Investigation and review | Read/search/web search; no edits or shell |
| Explicitly authorized implementation | Edit/write/shell and related tools; not a sandbox |
New tasks create independent conversations. Follow-ups retain native OMP history but replace the current objective. Questions and intermediate artifacts keep uncertainty visible instead of turning missing information into assumed success.
Evidence, not a promise
In our real review case, the first attempt was blocked by missing context (80.558 s wall time). An expanded review found a real deadline/cancellation bug, but its 300 s total budget ended in a timeout after 331.723 s wall time. A focused recheck completed in 186.127 s wall time and identified a distinct shared-SQLite publication-lock risk, not yet runtime-verified in that episode. Completion is not proof of bug-free code; the case preserves failures and remaining uncertainty.
The publication-lock risk was then reproduced and fixed before release; the case separates that passing runtime follow-up from the original static report.
Compatibility checks use an actual pinned OMP binary and RPC SDK with a deterministic localhost provider in CI—no paid account is needed. Evidence applies to the exact tested combination, not a broad version range or every provider. The benchmark document is a comparative protocol only: no comparative results or superiority claim.
Boundaries that matter
Project data is bound to trusted client workspace information, never a task's model-supplied
cwd. Foreign IDs do not open another project's history.The package does not sandbox processes with your OS permissions. Host shell sandbox settings do not automatically constrain an external OMP process.
Reports are claims, not independent acceptance.
completeddoes not provesuccess.Optional hooks diagnose prerequisites and provide a bounded Claude watchdog; they never install tools, read provider credentials, approve permissions, or replace polling when unavailable.
Polling works without Channels. Claude push/webhooks are optional and remain subject to client and organization policy.
Local storage is not offline inference: configured providers receive task context.
Read the security policy before reporting a vulnerability. Never include credentials, private conversations, or runtime databases in issues or pull requests.
Documentation
Topic | Reference |
Installation, providers, and clients | |
Start Claude and the webhook with one short command | |
Tasks, modes, results, questions, and artifacts | |
Product rules and decisions | |
Workspace isolation and explicit sharing | |
All MCP tools and limits | |
Jev audits, candidate advice and shadow model routing | |
Local data upgrades and migration | |
Claude Channels, webhook protocol, and managed setups | |
Development and contributions |
Full guides are also available in Russian and Simplified Chinese.
Development
uv sync --frozen --group dev
uv run pytest -q
uv run --frozen ruff check .
uv run --frozen ruff format --check .
uv build --wheelpytest is a declared development dependency; uv installs the project package and its omp_rpc dependency into the same environment. Tests use temporary stores and local fault peers, not provider credentials. CI runs pytest, Ruff, wheel building, and distribution checks on Linux and macOS.
This repository begins with a reviewed snapshot of earlier private development. The 3.x version series preserves that lineage without importing its Git history. “Legacy history” refers to local OMP conversation data, not hidden Git commits.
License
MIT, copyright (c) 2026 Flyozzzz. Commercial use, modification, and redistribution are allowed with the copyright and permission notice retained. The software is provided AS IS, without warranty. Dependencies keep their own licenses.
Available Tools
25 toolstandem_auditA
Explicitly ask Jev about gaps in a completed task's reported evidence.
preview=true shows the exact bounded export without a key, network call or reservation. Sending requires operator opt-in and an OpenRouter key. expected_input_sha256 refuses changed input before sending. The request includes selected criteria, goal, report prose and check descriptions. No source files, commands, task context, artifact bodies or history are read for export; report prose itself may still contain sensitive information. Advice is not verification, acceptance, a finding or permission to act. Ordinary results and waiting never call Jev. Exact repeated pages reuse the saved attempt, including failures; changed/overlapping pages may incur cost. No automatic retry after a timeout, cancellation or unresolved attempt.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| preview | No | ||
| task_id | Yes | ||
| expected_input_sha256 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: sending requires operator opt-in and an OpenRouter key, preview avoids network calls, expected_input_sha256 refuses changed input, repeated pages reuse saved attempts, and there is no automatic retry. It also warns about sensitive report prose and states that advice is not verification. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then groups cost, privacy, and caveat information into distinct, non-redundant sentences. It is long, but every sentence adds a meaningful behavioral fact, so the length is justified for a sensitive, externally-incurring tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and significant external side effects, the description covers prerequisites, preview behavior, request contents, privacy exclusions, cost/caching behavior, and retry policy. An output schema exists, so return-value details are not necessary. There is no meaningful missing information that would prevent an agent from invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does compensate for the two least obvious parameters: preview=true is explained as a bounded export without key/network/reservation, and expected_input_sha256 is explained as a guard against changed input. However, limit, offset, and task_id are left to inference from names and types, and the request-content sentence does not clearly map to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific action ('explicitly ask Jev'), the target (Jev), and the trigger (gaps in a completed task's reported evidence), so an agent can tell what the tool does. It does not explicitly contrast itself with sibling tools like tandem_review, tandem_findings, or tandem_diagnose, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to call it ('Explicitly ask Jev about gaps...') and provides an exclusion: 'Ordinary results and waiting never call Jev.' It also explains the preview path for inspecting without spending a key. However, it never names a specific alternative tool to use instead, so it lacks the explicit when-not/alternatives mapping of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_cancelA
Stop a task, including while it waits for clarification. Does not undo edits.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that cancellation does not undo edits and works during clarification waits, but it does not disclose whether cancellation is reversible, whether completed tasks can be cancelled, or any other state-change side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the core action, and each sentence adds value. The second sentence prevents a likely misinterpretation about undoing edits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is mostly complete: it states the action, a special case, and a key non-effect. It falls slightly short only by not addressing cancellation permanence or behavior on already-completed tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single task_id parameter with no description, and the tool description does not explain its format, origin, or usage. The parameter is self-explanatory by name, but the description adds no explicit parameter-level meaning despite low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Stop a task') and adds a meaningful nuance about stopping while waiting for clarification. This clearly distinguishes it from sibling tools like start, continue, wait, and result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to stop any task, including one waiting for clarification. It also notes a relevant limitation ('Does not undo edits'), but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_channelA
Manage optional Claude Code Channels push delivery; ordinary polling always remains available.
probe sends a receipt challenge only through the channel; ack with its probe_token confirms delivery. watchdog_token acknowledges an actual independent hook wake, never a tool-response assertion. ack with event_id acknowledges a webhook. pending lists unacknowledged events (include_previous explicitly includes earlier sessions). recover replays one event_id or a completed task_id; never changes task outcomes or reruns work. Token-file contents are secret.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| action | No | status | |
| task_id | No | ||
| event_id | No | ||
| probe_token | No | ||
| watchdog_token | No | ||
| include_previous | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it discloses that polling remains available, that watchdog_token must reflect an actual independent hook wake, that recover never changes task outcomes or reruns work, and that token-file contents are secret. It does not fully spell out state-changing effects like whether an ack consumes the event, leaving a small transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with an overview, then delivers one compact clause per action with caveats attached to the relevant operation. Every sentence earns its place, including the final security note about token-file contents. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most of the tool's complex behavior and an output schema exists, so return-value documentation is not required. But the 'status' action in the enum is never explained, and 'limit' is undocumented. For a 7-parameter, 5-action tool with no annotations, these are meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 successfully connects probe_token, watchdog_token, event_id, task_id, include_previous, and the action values to their behaviors. However, the 'limit' parameter is never mentioned, and the allowed ack combinations are implied rather than fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource: 'Manage optional Claude Code Channels push delivery' and contrasts it with 'ordinary polling.' It is clear and not tautological, but it does not name or distinguish any sibling tool, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete per-action conditions: probe is for a receipt challenge, ack confirms via probe_token/watchdog_token/event_id, pending lists unacknowledged events, and recover replays event_id or task_id. It does not explicitly name alternative tools or say when not to use this tool, but the action-level context is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_context_readB
Page omitted product data from this task's immutable pinned snapshot.
Follow capsule pointers rather than repeatedly loading the whole product. This does not select another context, read files, or grant execution rights. Independent review uses its pinned review reader instead. Focused view is optional, task-bound, nonexhaustive and export-consented; mixed/required context retains the raw view. Raw paging remains unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | raw | |
| pointer | No | ||
| task_id | Yes | ||
| max_bytes | No | ||
| offset_bytes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful traits: the snapshot is immutable and pinned, the call does not grant execution rights or read files, and mixed/required context 'retains the raw view'. These are valuable safety-adjacent facts. But the phrasing is dense and indirect ('export-consented', 'capsule pointers') and leaves the mutation/read-only nature of paging only implicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded, which is good, but the remaining lines are terse fragments rather than coherent clauses, and 'Independent review uses its pinned review reader instead' reads as tangential for the common case. The content is small but some of it does not clearly earn its place for an agent picking this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explained, and for a paging tool this description is roughly adequate. But given 5 parameters at 0% schema coverage and zero annotations, the description leaves gaps (byte-limit semantics, response shape consequences of view choice) that an agent would need to close by guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate. It does add semantics for 'pointer' (capsule pointers), 'view' (raw vs focused, with focused described as optional/task-bound/nonexhaustive/export-consented), and paging via 'Raw paging remains unchanged'. It never explains max_bytes, offset_bytes limits, or the required task_id binding, so coverage is partial rather than full.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Page omitted product data from this task's immutable pinned snapshot') but 'omitted product data' is opaque and the tool's actual purpose is only inferable from fragments about capsule pointers and raw/focused views. It hints at sibling separation ('Independent review uses its pinned review reader instead') without clearly naming which sibling this isn't, leaving the agent to guess among 24 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is implied guidance ('follow capsule pointers rather than repeatedly loading the whole product') and a negative scope statement ('does not select another context, read files, or grant execution rights'), which helps rule out misuse. However, no sibling tool is named as an alternative, and the conditions under which to choose raw vs focused are only vaguely stated as 'optional, task-bound, nonexhaustive and export-consented'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_continueB
Start a NEW current goal after completion; supply exactly one of prompt or turn contract.
History/base policy/mode/cwd persist, but old goals/acceptance do not. The product snapshot stays pinned unless explicitly changed to another revision of the same project. Question timeout is inherited unless explicitly set here. For waiting_input use tandem_reply. continuation=fresh requires an explicit handoff and starts a new context without replaying native history or transferring claims/grants. The source remains intact. Use preflight=true to inspect the same admission without a model or worker.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | ||
| handoff | No | ||
| contract | No | ||
| execution | No | ||
| preflight | No | ||
| review_id | No | ||
| continuation | No | resume | |
| review_stage | No | ||
| conversation_id | Yes | ||
| timeout_seconds | No | ||
| project_context_id | No | ||
| question_timeout_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses meaningful behavior: history/base policy/mode/cwd persist, old goals/acceptance do not, the product snapshot stays pinned, timeout inheritance, fresh continuation not replaying native history or transferring claims/grants, and source remaining intact. It still does not cover permissions or all side effects, but it is substantially transparent for a complex continuation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and the remaining sentences add constraints and modes without obvious filler. It is dense and somewhat cryptic, but appropriately structured for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers the main continuation modes and preflight behavior, but for a 12-parameter tool with no annotations, it does not fully explain parameter usage or sibling selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for 12 parameters. It explains only a few critical semantics, such as exactly one of prompt or contract, handoff for continuation=fresh, and preflight=true, while execution, review_id, review_stage, project_context_id, conversation_id, and timeout_seconds remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: start a NEW current goal after completion. It also distinguishes one sibling path by saying to use tandem_reply for waiting_input. It does not explicitly distinguish itself from tandem_start, so it is clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives some usage context: after completion, exactly one of prompt or contract, tandem_reply for waiting_input, and explicit handoff for continuation=fresh. However, it leaves the broader choice among tandem_start, tandem_work, and other continuations implicit, so the guidance is partial rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_desktopA
Hand off live UI tests to an already authorized desktop client.
The operator configures the external desktop-qa queue; the bound project selects its scope. This tool neither launches a model nor grants GUI access. Submit uses a stable request_id. An available native GUI worker calls next with worker_id, a fresh claim_id and exact eligible apps; wait_seconds=null holds the MCP call until work arrives without model polling. Only execute=true authorizes the returned claim, within the user's existing test permissions. Repeated/lost claims never authorize replay. Finish requires its claim_token and a real passed/failed/blocked report. Cancel requires job_id and a nonblank reason and only retires queued work before execution; running and completed tests cannot be cancelled. Cancelled is an administrative record, not a GUI result. Get waits for the result by default; wait_seconds=0 peeks. Claude Channels can announce terminal results when confirmed. Host tool timeouts still apply; keep the desktop session open, do not promise auto-wake.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden and does so well: it discloses the authorization gate, that repeated or lost claims never authorize replay, that cancel only retires queued work before execution, that cancelled is an administrative record rather than a GUI result, and that host tool timeouts still apply and the session must stay open. The one flaw is that the 'execute=true' authorization is never a documented parameter anywhere in the schema, so the central safety mechanism is uninvokable as described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded correctly, but the remainder is a single dense paragraph interleaving seven different action contracts (submit, next, finish, cancel, get, status, list) with no segmentation, bullets, or action labels. Every sentence is substantive, yet the lack of structure forces the agent to re-parse to find the rules for one action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-action, 18-parameter nested tool with no annotations, the lifecycle coverage (submit -> next -> finish, plus cancel/get) is substantial, and the output schema carries return shape. Gaps remain: the 'list' action is never described, 'status' is only implied, and the phantom 'execute' parameter leaves the authorization path under-specified for a tool gating GUI control.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 18 nested properties, so the prose does real work: it explains request_id stability, worker_id/claim_id on 'next', claim_token on finish, job_id plus nonblank reason on cancel, the passed/failed/blocked report shape, and wait_seconds semantics. But app vs apps, expected, scenario, build, limit, and launch_instructions go unexplained, and it references an 'execute' flag that does not exist in the schema — actively misleading for a caller building a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — 'Hand off live UI tests to an already authorized desktop client' — and adds a negative scope statement ('neither launches a model nor grants GUI access') that separates it from model-launching siblings like tandem_start. It does not, however, distinguish this tool from siblings that also offer cancel/list/wait semantics (tandem_cancel, tandem_list, tandem_wait), so an agent must guess which surface is canonical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: the operator owns the external desktop-qa queue, the bound project sets scope, wait_seconds=null blocks vs 0 peeks, and execute=true is required to authorize a claim. What is missing is explicit routing — nothing says when to prefer this tool over the sibling cancel/list/wait tools whose names collide with this tool's actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_diagnoseA
Diagnose this client session's project, OMP execution, actual model and delivery.
live=true starts one short provider request and may incur a charge: use only for a user-requested live check. Default checks local state without contacting a provider. If still running, inspect the returned task_id instead of starting another check. A separate CLI process cannot certify this session's push receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | ||
| task_id | No | ||
| wait_seconds | No | ||
| timeout_seconds | No | ||
| expected_project | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It discloses that live=true contacts a provider, may incur a charge, defaults to local state, returns a task_id when still running, and that a separate CLI process cannot certify the push receipt. This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main purpose in the first sentence and operational constraints in the next three. Every sentence adds necessary information; there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema presumably covers return values, and the description covers the core behavior and safety considerations. However, the missing semantics for three parameters and lack of routing among sibling tools leave the description incomplete for a tool with this many controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains live and task_id, but wait_seconds, timeout_seconds, and expected_project are left undocumented. An agent cannot fully understand how to set or interpret these parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Diagnose this client session's project, OMP execution, actual model and delivery,' which names a specific action and target. It is clear what the tool does, though it does not explicitly differentiate it from sibling tools like tandem_review or tandem_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use live=true versus the default local check, and instructs the agent to inspect an existing task_id instead of starting another check. It provides useful context but does not name alternative sibling tools or explicit when-not-to-use conditions beyond live checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_export_contextA
Explicitly offer this project's selected rules and referenced evidence to one recipient.
Use only when the user intends cross-project sharing. No tasks/history are shared. The returned transfer_id is a private capability, not a public link. The recipient must separately call tandem_import_context in its own coordinator session. This grants no permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| context_id | Yes | ||
| target_project_root | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations are absent, the description reveals important behavioral traits: the transfer_id is a private capability rather than a public link, the operation grants no permissions, and no tasks/history are shared. This is precisely the kind of context an agent needs beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose comes first, followed by usage constraints, privacy implications, and security caveats. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, security, return value semantics, and the follow-up action on the recipient side. The main gap is the lack of explicit parameter documentation; otherwise, an agent would have enough context to invoke the tool safely and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the two required parameters. 'context_id' and 'target_project_root' are somewhat inferable from their names and the surrounding text, but the description never states how to obtain context_id, what format target_project_root should take, or how they map to the described behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Explicitly offer') and a clear resource ('this project's selected rules and referenced evidence') directed at 'one recipient.' It also distinguishes itself from tandem_import_context and siblings by describing what it does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit usage condition: 'Use only when the user intends cross-project sharing.' It also clarifies that no tasks/history are shared and that the recipient must separately call tandem_import_context, which prevents misuse and clearly scopes the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_findingsA
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
tandem_import_contextA
Explicitly accept a product snapshot offered to this launch project.
Only recipient-bound exports can be imported; no foreign database is browsed. Creates fresh local context/evidence IDs, preserving source provenance, not granting approval. Existing product revisions require expected_revision. Retrying one transfer is idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| transfer_id | Yes | ||
| expected_revision | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that the operation creates fresh local IDs, preserves provenance, does not grant approval, is idempotent on retry, and cannot browse a foreign database.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences with no filler. The purpose is front-loaded, and the remaining sentences each add a distinct, useful constraint or behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and an output schema already present, the description covers all critical invocation details: import scope, provenance handling, revision expectations, idempotency, and the non-approval side effect. An agent has enough information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explicitly explains expected_revision ('Existing product revisions require expected_revision') and implies transfer_id from 'recipient-bound exports' and 'Retrying one transfer.' However, transfer_id is never named or formally defined, leaving a minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Explicitly accept a product snapshot offered to this launch project.' The description also distinguishes the tool from browsing or generic import by noting that only recipient-bound exports can be imported and no foreign database is browsed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about when the tool is appropriate: importing only recipient-bound exports, requiring expected_revision for existing revisions, and supporting idempotent retries. It does not explicitly name sibling alternatives or say 'use this instead of X,' but the constraints effectively delineate the correct use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_listA
List recent task/conversation IDs, statuses, outcomes and next actions without large bodies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It clearly discloses that the tool returns lightweight metadata fields and deliberately omits large bodies. It does not mention ordering, recency semantics, or side effects, but 'List' strongly signals a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every element—'recent', the listed fields, and 'without large bodies'—contributes directly to the tool's behavior and selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter list tool with an output schema, the description is mostly sufficient. However, it lacks explicit usage guidance, does not explain the 'limit' parameter, and relies on the tool name to convey read-only status because no annotations exist. These are real but non-fatal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the only parameter, 'limit', so it does not compensate for the missing schema field description. The parameter name and constraints supply some meaning, but the description adds no guidance on how limit affects the returned items.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and a precise resource: recent task/conversation IDs, statuses, outcomes, and next actions. The phrase 'without large bodies' clearly scopes it to metadata and distinguishes it from body-oriented siblings like tandem_read_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without large bodies' implies this is for overviews rather than full content, but it never names an alternative or states explicit when-to-use/when-not-to-use conditions. Siblings such as tandem_read_artifact likely cover the body-heavy case, but that routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_project_contextA
Coordinator-only product knowledge: source-backed rules, examples and settled decisions.
publish creates an immutable snapshot; updating a project requires its current expected_revision. get uses an exact context_id; list optionally filters project_id. Pass context_id to tandem_start/continue explicitly. Publishing never changes active tasks. Workers may propose changes in their answer but do not get this publishing tool. Do not approve invented rules.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| action | Yes | ||
| context | No | ||
| context_id | No | ||
| project_id | No | ||
| expected_revision | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses immutability of published snapshots, the expected_revision requirement, that publishing never changes active tasks, and that workers cannot access this publishing tool. This adds meaningful behavioral context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, action behavior, revision requirement, parameter routing, side-effect guarantee, and permission boundary. The most important information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the critical invariants and action-specific semantics. Minor omissions are the exact role of the context parameter and the limit parameter, but the schema provides enough defaults and names to make invocation feasible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It adds semantics for action, expected_revision, context_id, and project_id, and hints at content types through 'rules, examples and settled decisions.' It does not explain limit or the full context object relationship, but the schema names and defaults reduce the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as coordinator-only product knowledge for source-backed rules, examples, and settled decisions, and names the three actions (publish, get, list). It conveys the resource and its primary operations, though it does not explicitly contrast with siblings like tandem_scope or tandem_publish_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states coordinator-only usage, explains when expected_revision is needed, specifies that get requires an exact context_id, and that list filters by project_id. It also gives cross-tool guidance to pass context_id to tandem_start/continue. It does not name an alternative tool or provide an explicit when-not-to-use instruction, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_publish_artifactA
Publish immutable shared context; each same-name publication creates a new version.
Return artifact_id to the partner in a follow-up or contract.artifact_ids. Content max 4MiB UTF8. Logical names are not filesystem paths; no file is read or modified by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | Yes | ||
| media_type | No | text/plain | |
| conversation_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| sha256 | Yes | |
| created | Yes | |
| task_id | Yes | |
| version | Yes | |
| characters | Yes | |
| context_id | No | |
| media_type | Yes | |
| artifact_id | Yes | |
| conversation_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and succeeds: it discloses immutability, version-on-republish, a 4MiB UTF8 content limit, and that logical names are not filesystem paths. It also explicitly states 'no file is read or modified,' which prevents a common false assumption about artifact handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with the core operation and versioning behavior front-loaded, followed by return guidance and practical constraints. Every sentence earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a publication tool with an output schema, the description covers the essential operational facts: what is published, versioning semantics, how to use the returned artifact_id, content size/encoding limits, and the non-filesystem caveat. The main missing context is clearer guidance on when to use this versus reading or exporting artifacts, but that is a usage guideline gap rather than a completeness failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for two parameters: content is limited to 4MiB UTF8, and name is a logical, versioned identifier rather than a filesystem path. However, media_type and conversation_id are left unexplained in both the schema and the description, so the agent must infer their roles from the enum and parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and resource: 'Publish immutable shared context,' and immediately clarifies versioning behavior with 'each same-name publication creates a new version.' This clearly distinguishes it as a publication tool from siblings like tandem_read_artifact, tandem_list, or tandem_export_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: you publish a named artifact for a partner, then return artifact_id in a follow-up. However, it does not explicitly say when to prefer this tool over tandem_read_artifact, tandem_export_context, or other siblings, nor does it describe exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_read_artifactA
Read an immutable artifact version shared by the coordinator and OMP; page using next_offset.
Offsets count Unicode characters; limit 1..50000. IDs never resolve arbitrary local files.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| artifact_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses immutability, Unicode character-based offsets, the limit range, pagination via next_offset, and an important security property that IDs never resolve local files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states purpose and pagination, the second gives parameter semantics and a security caveat. Every sentence earns its place and key constraints are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required. The description covers purpose, pagination behavior, parameter semantics, and security. The only noticeable gap is a lack of explicit guidance on when to prefer this over other read/list siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies artifact_id as a coordinator/OMP-shared immutable artifact ID, limit as 1..50000, and offset as Unicode character count, though it leaves defaults to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read an immutable artifact version shared by the coordinator and OMP'. This distinguishes it from sibling writing/publishing tools like tandem_publish_artifact and from broader listing tools, so an agent can understand what it targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool reads immutable artifact versions and paginates with next_offset. It does not explicitly name alternatives or when-not-to-use conditions, but the shared-by-coordinator-and-OMP framing plus the 'never resolve arbitrary local files' caveat provides practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_receiptB
Gate result processing separately from reading/acknowledging notification events.
Claim before applying a terminal result; only an authorized fresh claim may proceed. Complete with its token after handling. Duplicate reads do not authorize repeated effects. A stranded claim is uncertain, never automatically released: reconcile external state. Claims grant no filesystem/external permissions. External effects still need their own idempotency/transaction boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| action | No | status | |
| task_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly carries the behavioral burden. It explicitly discloses that duplicate reads do not authorize repeated effects, stranded claims are never automatically released, claims grant no filesystem/external permissions, and external effects need their own idempotency/transaction boundary. This is substantial behavioral content, though it leaves definitions like 'terminal result' implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is terse and well-packaged: every sentence adds a distinct rule about claiming, completing, or safety boundaries, and the core for the central purpose is front-loaded. No filler or repetition is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, the description covers the lifecycle and several important corner cases. Yet it is cryptic about what a receipt represents in practice, does not define the reported status action, and relies heavily on domain-specific vocabulary without orienting an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does: 'claim' and 'complete' map to the action enum and 'token' is explained as the outcome of a claim. However, it never mentions the task_id parameter or describes the 'status' action, leaving part of the parameter surface under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates the tool coordinates result processing via claim, status, and complete, and says it is separate from reading/acknowledging events. However, the verb 'gate' is vague and the description never states plainly what the tool is or differentiates it from siblings like tandem_result or tandem_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is useful procedural guidance: claim before applying a terminal result, complete with the token after handling, and do not rely on duplicate claims. Still, it never explicitly says when to prefer this tool over alternatives or when not to use it, so the usage guidance is largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_recommendA
Suggest one skill or review direction from an explicit small candidate list.
Coordinator-only advisory operation, available before any task exists. No skill discovery, file/context/history reads, launches or permission changes. Preview is the default: exact bounded payload without a key or provider call. Sending needs separate recommendation enablement, an OpenRouter key, preview=false and the approved preview's matching expected_input_sha256. The hash binds input; it does not establish human approval. Supplied goal and candidate descriptions may contain secrets; this is not redaction. Send retains the exact request and result/failure in this project's journal. Exact duplicates reuse the attempt; uncertainty never authorizes replay. Candidate, none and unclear are distinct from provider/protocol failure. Advice and confidence never authorize execution or alter required checks. Do not inject this advice into an independent snapshot-review stage.
| Name | Required | Description | Default |
|---|---|---|---|
| preview | No | ||
| request | Yes | ||
| expected_input_sha256 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so: preview is the default with 'exact bounded payload without a key or provider call', while sending requires enablement, an OpenRouter key, preview=false and a matching expected_input_sha256 from the approved preview. It flags the important limits directly — 'The hash binds input; it does not establish human approval', 'Supplied goal and candidate descriptions may contain secrets; this is not redaction', 'Exact duplicates reuse the attempt; uncertainty never authorizes replay' — plus journal retention of request/result and the distinction between candidate/none/unclear and provider failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, default behavior, send gating and safety caveats are front-loaded in that order, and nearly every sentence introduces a distinct constraint rather than restating the schema. The telegraphic, one-clause-per-sentence style is dense and would scan faster as a short bulleted list, but there is no filler to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-schema tool with zero annotation and zero schema-description coverage, this is close to complete: it covers default vs send paths, credential and enablement prerequisites, hash provenance, side effects (journal retention), duplicate handling and failure taxonomy, and an output schema exists so return shape need not be restated. The remaining gap is the 'kind' parameter's two modes and any guidance on candidate count/id conventions, which the caller must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 two highest-risk parameters: preview's default/bounded behavior and expected_input_sha256's required matching provenance along with the warning that the hash is not approval. It also notes that goal and candidate descriptions carry potentially sensitive free text. It leaves 'kind' (skill vs review_direction) unexplained beyond the first sentence's phrasing and gives no size bounds, so it falls just short of complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Suggest one skill or review direction from an explicit small candidate list', which also bounds the operation to a caller-supplied list rather than open discovery. That scope ('explicit small candidate list', 'No skill discovery') distinguishes it from the discovery/context siblings in the namespace. An agent can decide between this and tandem_findings or tandem_scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the actor and timing ('Coordinator-only advisory operation, available before any task exists') and then enumerates what the tool does not do: 'No skill discovery, file/context/history reads, launches or permission changes.' It also names an explicit exclusion ('Do not inject this advice into an independent snapshot-review stage'), so both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_replyA
Answer exactly the pending clarification, resuming the same worker. Expired/stale IDs fail.
Duplicate identical answers are idempotent; different second answers are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | ||
| task_id | Yes | ||
| question_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose key stateful behavior: idempotency for identical duplicates, rejection of conflicting second answers, and failure on stale IDs. It does not detail unrelated side effects, but the output schema covers return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences put the core purpose first and then capture edge-case behavior with no filler or repeated schema details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-string tool with an output schema, the description covers the critical invocation context: pending clarifications, stale failures, and duplicate behavior. Minor gaps—how IDs are obtained and where this fits among the sibling tools—are not essential to making a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds contextual meaning: IDs must refer to a pending clarification and can go stale, and the 'answer' is the exact clarification response. It never names the parameters explicitly or describes formats, so it only partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Answer exactly the pending clarification') and identifies the resource: a clarification associated with a task and question. 'Resuming the same worker' adds useful context that separates it from generic start/list tools, though no sibling alternative is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates the tool is for replying to a pending clarification and notes edge cases where it should not be used ('Expired/stale IDs fail'; a different second answer is rejected). It does not explicitly enumerate alternatives among the tandem_* siblings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_resultA
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.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | ||
| task_id | Yes | ||
| wait_mode | No | auto | |
| wait_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
tandem_reviewA
Capture or read an immutable review bundle, or compare it with current selected files.
request.source selects base-to-worktree (default) or base-to-staged Git index material. Staged captures exclude unstaged/untracked content; source also governs applicability checks. Capture includes requirements, supplied checks and boundaries without executing tests. Bind review_id to a think task for snapshot-only review. Author rationale is withheld unless explicitly revealed in a comparison turn. Read pages by next_offset, not the live working directory. assess reports applicability at observation time, not whole-system correctness. prepare classifies the same request without saving anything: it reports every repairable selection conflict at once and proposes the corrected paths, which the caller decides whether to apply. It reserves nothing, so capture classifies the files again and a repaired request is a new request, not a retry.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| limit | No | ||
| action | Yes | ||
| offset | No | ||
| request | No | ||
| section | No | manifest | |
| review_id | No | ||
| reveal_author | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does substantial work: it discloses immutability ('immutable review bundle'), non-execution ('without executing tests'), author rationale withholding unless revealed, snapshot-vs-live semantics ('Read pages by next_offset, not the live working directory'), and the limited scope of assess ('applicability at observation time, not whole-system correctness'). Minor gaps remain around permissions and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense wall of prose with no paragraph breaks, bullets, or action-mode segmentation. While the first sentence front-loads the purpose, later sentences are convoluted ('It reserves nothing, so capture classifies the files again and a repaired request is a new request, not a retry'). The length is partly justified by complexity, but the structure makes it hard to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, four actions, an output schema), the description covers the most important semantics: actions, source selection, immutability, author gating, and prepare/assess distinctions. It leaves section/limit semantics implicit, but the presence of an output schema lowers the burden on describing return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the burden falls on the prose, and it adds real meaning for several parameters: request.source (worktree default, staged excludes untracked content), review_id (bind to a think task for snapshot-only review), reveal_author (rationale withheld unless revealed), and offset (paging via next_offset). However, path, limit, and especially section are left unexplained, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource ('Capture or read an immutable review bundle...') and the body clarifies the four action modes (create, prepare, read, assess). It does not explicitly differentiate from the sibling tandem_review_run, but the core purpose is distinguishable and concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives real when-to-use guidance for the action parameter: prepare 'reports every repairable selection conflict at once... without saving anything', while capture 'classifies the files again and a repaired request is a new request, not a retry'. It also explains source semantics (worktree vs staged) and read paging. It does not name sibling alternatives or exclusions, but internal action routing is well handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_review_runA
Run one read-only review scenario without manually coordinating its native turns.
start: supply ReviewRequest and a stable request_key for this logical request. Reusing the key returns the same run; a different payload conflicts. Code captures the snapshot, runs independent think review, then at most one comparison if author material was supplied and the independent report succeeded. Total budget defaults to 600 seconds, including startup, both stages and questions. It never edits files or runs supplied test commands. status/reply/cancel: use the returned run_id, never start again to wait. Replies require the current question_id. Full stage answers, findings, applicability and peer-only usage are assembled by code. Claims are not automatically accepted or applied. Missing context needs an explicit new capture (context_paths), not hidden live reads.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| answer | No | ||
| run_id | No | ||
| compare | No | ||
| request | No | ||
| execution | No | ||
| question_id | No | ||
| request_key | No | ||
| wait_seconds | No | ||
| budget_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: read-only, never edits files or runs supplied test commands, idempotent request_key semantics (same key returns same run, different payload conflicts), a two-stage pipeline with at most one comparison gated on author material and independent-report success, and the note that claims are not auto-applied. Gaps remain: it states a 600-second default total budget while the schema's profile descriptions imply 600/1800/3600 by profile, and it says nothing about permissions or concurrent-run behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in one sentence, then actions are grouped as 'start' and 'status/reply/cancel', which mirrors the enum and reads well. Some sentences pack multiple clauses (snapshot capture, think review, comparison gate, budget) and could be split, but there is little outright waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, and the description covers the core lifecycle and the read-only guarantee. For a ten-parameter, four-action orchestration tool it still leaves the polling/wait semantics, the compare flag, and the entire execution/profile surface unexplained, which an agent will need before calling correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema description coverage is 0%, so the description must compensate, and it partially does: it explains action dispatch, request_key idempotency/conflict, run_id reuse, and the question_id requirement for replies. It says nothing about wait_seconds, budget_seconds, compare, or the execution block (profile/thinking/timeout), leaving several of the ten parameters unexplained anywhere at the top level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource (run a read-only review scenario) and immediately scopes it as 'without manually coordinating its native turns', which tells the agent this is the orchestrated one-shot path. It never names the sibling tandem_review or explains how it differs, so differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description routes each action: start requires a ReviewRequest plus a stable request_key; status/reply/cancel reuse the returned run_id and explicitly warn 'never start again to wait'; replies require the current question_id. That is clear per-action guidance with an explicit prohibition, though it does not compare against the other review-family siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_scopeA
Inspect the immutable project boundary and available computation profile defaults.
Separate launch folders have separate data even with one user-wide MCP registration. Additional client-granted directories permit working there, not reading their MCP history. This is data isolation, not an OS filesystem sandbox. execution_profiles describes defaults, not effective/actual settings after overrides; deep means more time, not higher thinking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, and it does so well: it states the boundary is immutable, clarifies that data isolation is not an OS sandbox, and warns that execution_profiles reflects defaults rather than effective overrides. It does not explicitly say 'read-only', but 'inspect' plus 'immutable' conveys it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by three dense clarifications that each prevent a common misinterpretation. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introspection tool with an output schema, the description covers the essential semantics: what scope is, how folder boundaries work, what execution_profiles represents, and what it does not mean (effective settings, OS sandbox). This is sufficient for an agent to invoke it appropriately and interpret results without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description adds useful conceptual context about what 'scope' includes—project boundary, launch folders, and profile defaults—which helps the agent interpret any returned fields even without parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and object: 'Inspect the immutable project boundary and available computation profile defaults.' This clearly frames the tool as an inspection utility. It doesn't name sibling tools for contrast, but the term 'scope' plus the 'immutable' boundary and 'defaults' caveats make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no direct 'use this when' guidance or reference to alternatives. It does add context about what the tool reports (launch-folder isolation, client-granted directories, defaults vs effective settings), which helps an agent understand relevance, but the agent must infer when to call it relative to siblings like tandem_start or tandem_continue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_startA
Start a task with exactly one of prompt or structured contract. Returns immediately.
Base constraints/owned files stay fixed; each follow-up has a new goal and criteria. project_context_id pins product rules/decisions. Only the coordinator sets question timeout. Think: collaboration; analyze: read/search; work: edits/shell, NOT sandboxed. Use preflight=true to inspect admission without launching a worker. Structured requirements declare exact entry/boundary paths and shell/write needs; verification declares the agreed check ladder, never permission to execute it.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | ||
| mode | No | analyze | |
| prompt | No | ||
| contract | No | ||
| execution | No | ||
| preflight | No | ||
| review_id | No | ||
| review_stage | No | ||
| timeout_seconds | No | ||
| project_context_id | No | ||
| question_timeout_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose several non-obvious traits: the call returns immediately while a worker runs, 'work' mode edits/shell and is 'NOT sandboxed', preflight gives a dry-run admission check, and 'verification declares the agreed check ladder, never permission to execute it.' It still says nothing about concurrency limits, invalid-contract behavior, or cost, and its 'NOT sandboxed' note partly duplicates the scope field description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The most important fact (start a task with exactly one of prompt/contract, returns immediately) is front-loaded correctly. But the remainder is a dense run-on of fragment sentences in mixed registers ('project_context_id pins product rules/decisions. Only the coordinator sets question timeout.'), and 'Base constraints/owned files stay fixed; each follow-up has a new goal and criteria' describes follow-up behavior rather than this call, which dilutes focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no prose, and the description does cover the core launch semantics and the not-sandboxed risk. For an 11-parameter tool with a deeply nested contract and zero annotations, however, the complete silence on execution tuning (profile/thinking/timeout/routing) and review scoping leaves an agent guessing on roughly half the surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema description coverage is reported as 0%, so the prose must compensate, and it does explain the trickiest semantics: prompt-vs-contract exclusivity, project_context_id pinning, question_timeout being coordinator-only, preflight, and the requirements/verification sub-structures. It says nothing about the entire 'execution' group (profile, thinking, model, timeout_seconds, routing, focus), review_id/review_stage, or context_options, leaving several of the 11 parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource plus a hard constraint: 'Start a task with exactly one of prompt or structured contract. Returns immediately.' That tells an agent what the tool does and its fire-and-forget nature. It never names a sibling (tandem_continue, tandem_work, tandem_review_run), so the boundary with related launch/continue tools is only inferable from 'each follow-up has a new goal and criteria.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use preflight=true to inspect admission without launching a worker' is real when-to-use guidance, and the mode gloss ('Think: collaboration; analyze: read/search; work: edits/shell') helps pick a mode. But there is no explicit statement of when to choose this over tandem_continue or tandem_work, no prerequisites, and no exclusions beyond the prompt/contract either-or.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_teamA
Run a bounded team for development, research, analysis or review.
models reads only OMP-available openai-codex subscription models, excluding OpenRouter, ordinary OpenAI API and other providers, without a model turn. start requires a stable request_key and a complete plan with one final integration step. Independent steps run concurrently; declared file conflicts serialize. Work requires plan.allow_work; this is a live workspace, NOT an OS sandbox. The whole run owns one deadline and stops with its MCP owner, not detached. Auto selection uses Jev when configured, exporting goal/title summaries and public model facts only. Choose a model/thinking pair per step; explicit model and thinking choices win. Unassigned actionable steps are returned as pending_models, even while assigned workers run. Read selection for frozen eligible pairs, consult the OMP partner, compare once, then assign exactly every current pending step's model, thinking and reason. Never ask the user to route routine subtasks or invent model/reasoning availability. status observes the same run; never start again to wait. Worker questions use tandem_reply(task_id, question_id, answer). Cancel stops pending and active steps. Partial evidence unlocks only an explicitly opted-in read-only final synthesis. Completed reports are claims, not independent acceptance. Every response is bounded, including details. Follow readers for complete plan, selection, run errors, questions and structured results. read returns digest-bound UTF-8 byte pages; send next_request unchanged. models returns UTF-8 catalog pages from one immutable metadata observation; cursor pages never probe again. list has complete cursor continuation over run metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | ||
| limit | No | ||
| action | Yes | ||
| cursor | No | ||
| run_id | No | ||
| details | No | ||
| section | No | ||
| step_id | No | ||
| max_bytes | No | ||
| assignments | No | ||
| request_key | No | ||
| offset_bytes | No | ||
| wait_seconds | No | ||
| expected_sha256 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses concurrency and file-conflict serialization, the live-workspace-not-sandbox constraint, deadline ownership tied to the MCP owner, model-provider exclusions, Jev export behavior, pending_models while workers run, cancellation semantics, partial-evidence synthesis limits, and bounded paged responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and contains many valuable behavioral details, but it is a dense, roughly 300-word block with compressed clauses and some awkward fragments such as 'models reads only...' and 'Read selection for frozen eligible pairs...'. It is appropriately sized for a complex orchestration tool but could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values, and it does cover the run lifecycle, concurrency, model selection, cancellation, paging, and safety constraints. The remaining gaps are mainly detailed action-to-parameter mapping and explicit boundaries against overlapping sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level parameters, so the description must compensate for 14 parameters. It adds meaning for request_key, plan completeness, allow_work, model/thinking/assignments, and cursor-based paging, but it leaves several parameters such as limit, run_id, details, section, step_id, wait_seconds, expected_sha256, offset_bytes, and project_context_id implicit or unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a clear verb and resource: run a bounded team for development, research, analysis, or review. The description also explains the multi-action surface, but it does not distinguish tandem_team's start/cancel/list actions from the similarly named sibling tools tandem_start, tandem_cancel, and tandem_list, leaving some overlap for an agent to resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit prerequisites and alternatives for key actions: start requires a stable request_key and complete plan, work requires plan.allow_work, status is used to observe an existing run rather than starting again to wait, worker questions use tandem_reply, and cancel stops pending and active steps. It is less explicit about when to use list versus status or read, and it does not fully address sibling tools such as tandem_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tandem_waitA
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.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | ||
| wait_mode | No | auto | |
| wait_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
tandem_workA
Maintain one durable shared task and its role-bound checklist.
To create, send action="create", expected_revision=0, a unique operation_id, and plan; omit work_id. The plan must have one final integration step that depends directly or transitively on every other step, including investigations. For later mutations, get the card first and use its current revision as expected_revision. Use a new operation_id for a new or corrected request; reuse an ID only for an exact retry. list/get/history need no operation_id. Plan agreement, worker submission and independent acceptance are separate. Progress defaults to a bounded summary. Follow returned section/cursor pointers for omitted material; choose plan/step/full only when needed. Waiting observes committed changes, not permission to start an agent. Give after_revision the revision you last read: a card already past it returns at once instead of waiting for the next change. It is an observation baseline, never expected_revision, a claim, or permission to replay work. Autonomous grants and uncertain-attempt reconciliation are operator CLI actions.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | summary | |
| limit | No | ||
| cursor | No | ||
| format | No | json | |
| request | Yes | Shared-task command. create requires plan, expected_revision=0, a stable operation_id, and no work_id. All other mutations require the current revision from get and a stable operation_id. list/get/history need no operation_id. | |
| section | No | ||
| wait_seconds | No | ||
| after_revision | No | ||
| include_snapshots | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it does substantial work: it clarifies after_revision is 'an observation baseline, never expected_revision, a claim, or permission to replay work,' explains that waiting observes committed changes rather than granting permission, and notes plan structure requirements (final integration step depending transitively on all others). It also flags that 'autonomous grants and uncertain-attempt reconciliation are operator CLI actions.' It could go further on error/conflict behaviors and the response format, but given zero annotation coverage, this is a strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but every sentence earns its place — there is no filler. The core purpose is front-loaded, and each clause addresses a distinct operational concern (creation requirements, mutation semantics, idempotency, waiting behavior, revision semantics). It runs longer than typical descriptions, but the complexity (18 actions, nested plan/verification objects) justifies the length. Some tightening would help, but it is substantive throughout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 distinct actions and deeply nested plan/verification schemas), the description covers the core flows well — create, mutation revision handling, operation_id rules, waiting semantics. However, most of the 18 actions (propose, agree, claim, heartbeat, block, unblock, submit, accept, reject, report, compare, pause, resume, reconcile, recover) receive no individual explanation; an agent must infer their semantics from names and schema alone. The output schema exists and mitigates return-value concerns, but action-specific guidance is a notable gap for such a wide action surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description must compensate — and it does. It adds meaning beyond the schema for expected_revision ('exactly 0 for create; otherwise the current card revision from get'), operation_id (unique per request, reuse only for exact retry), and after_revision (observation baseline distinct from expected_revision). It also explains the plan requirement that others only hint at in the schema. The description meaningfully enriches parameter understanding despite the sparse schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Maintain one durable shared task and its role-bound checklist.' This clearly conveys the tool's core function of creating and managing a shared task with a plan/checklist structure. It doesn't explicitly name sibling tools for differentiation, but the scope (durable task with role-bound checklist) is distinct enough from siblings like tandem_review or tandem_channel, and the many action verbs (create/get/submit/accept) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong operational guidance: how to create (action=create, expected_revision=0, unique operation_id, omit work_id), how to mutate (get card first, use current revision), and when no operation_id is needed (list/get/history). It clearly distinguishes waiting semantics ('observes committed changes, not permission to start an agent') and explains that autonomous grants are operator CLI actions. It doesn't explicitly name sibling alternatives for when not to use this tool, but the action-level guidance is detailed and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v3.12.0- Changed
tandem_context_read1 field changed- added
Input schema / properties / viewAdded value: +{ + "default": "raw", + "enum": [ + "raw", + "focused" + ], + "type": "string" +}
- Changed
tandem_continue1 field changed- changed
Input schema / properties / execution / anyOfPrevious value: -[ - { - "properties": { - "model": { - "anyOf": [ - { - "minLength": 1, - "pattern": "\\S", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "profile": { - "default": "balanced", - "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", - "enum": [ - "quick", - "balanced", - "deep" - ], - "type": "string" - }, - "thinking": { - "anyOf": [ - { - "enum": [ - "off", - "minimal", - "low", - "medium", - "high", - "xhigh", - "max" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "timeout_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "focus": { + "anyOf": [ + { + "properties": { + "allow_external": { + "default": false, + "type": "boolean" + }, + "goal": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + }, + "surfaces": { + "items": { + "enum": [ + "context", + "tools", + "outputs" + ], + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit goal and export consent for optional context, tool presentation and focused readers; never inherited." + }, + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "routing": { + "anyOf": [ + { + "properties": { + "allow_external_summary": { + "default": false, + "type": "boolean" + }, + "input_modalities": { + "items": { + "enum": [ + "text", + "image" + ], + "type": "string" + }, + "maxItems": 2, + "minItems": 1, + "type": "array" + }, + "input_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "max_candidate_cost_usd": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "output_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "summary": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "summary", + "input_token_estimate", + "output_token_estimate" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit export-approved input for optional shadow routing; never inherited or applied to execution." + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Added
tandem_desktop - Added
tandem_recommend - Changed
tandem_review_run1 field changed- changed
Input schema / properties / execution / anyOfPrevious value: -[ - { - "properties": { - "model": { - "anyOf": [ - { - "minLength": 1, - "pattern": "\\S", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "profile": { - "default": "balanced", - "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", - "enum": [ - "quick", - "balanced", - "deep" - ], - "type": "string" - }, - "thinking": { - "anyOf": [ - { - "enum": [ - "off", - "minimal", - "low", - "medium", - "high", - "xhigh", - "max" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "timeout_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "focus": { + "anyOf": [ + { + "properties": { + "allow_external": { + "default": false, + "type": "boolean" + }, + "goal": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + }, + "surfaces": { + "items": { + "enum": [ + "context", + "tools", + "outputs" + ], + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit goal and export consent for optional context, tool presentation and focused readers; never inherited." + }, + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "routing": { + "anyOf": [ + { + "properties": { + "allow_external_summary": { + "default": false, + "type": "boolean" + }, + "input_modalities": { + "items": { + "enum": [ + "text", + "image" + ], + "type": "string" + }, + "maxItems": 2, + "minItems": 1, + "type": "array" + }, + "input_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "max_candidate_cost_usd": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "output_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "summary": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "summary", + "input_token_estimate", + "output_token_estimate" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit export-approved input for optional shadow routing; never inherited or applied to execution." + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_start1 field changed- changed
Input schema / properties / execution / anyOfPrevious value: -[ - { - "properties": { - "model": { - "anyOf": [ - { - "minLength": 1, - "pattern": "\\S", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "profile": { - "default": "balanced", - "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", - "enum": [ - "quick", - "balanced", - "deep" - ], - "type": "string" - }, - "thinking": { - "anyOf": [ - { - "enum": [ - "off", - "minimal", - "low", - "medium", - "high", - "xhigh", - "max" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "timeout_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "focus": { + "anyOf": [ + { + "properties": { + "allow_external": { + "default": false, + "type": "boolean" + }, + "goal": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + }, + "surfaces": { + "items": { + "enum": [ + "context", + "tools", + "outputs" + ], + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit goal and export consent for optional context, tool presentation and focused readers; never inherited." + }, + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "routing": { + "anyOf": [ + { + "properties": { + "allow_external_summary": { + "default": false, + "type": "boolean" + }, + "input_modalities": { + "items": { + "enum": [ + "text", + "image" + ], + "type": "string" + }, + "maxItems": 2, + "minItems": 1, + "type": "array" + }, + "input_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "max_candidate_cost_usd": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "output_token_estimate": { + "maximum": 2000000, + "minimum": 1, + "type": "integer" + }, + "summary": { + "maxLength": 4000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "summary", + "input_token_estimate", + "output_token_estimate" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit export-approved input for optional shadow routing; never inherited or applied to execution." + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Added
tandem_team
1 tool update
v3.11.0- Added
tandem_audit
8 tool updates
v3.10.0- Changed
tandem_continue1 field changed- changed
Input schema / properties / contract / anyOfPrevious value: -[ - { - "description": "A new turn's goal and criteria, without permission or ownership changes.", - "properties": { - "acceptance": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "artifact_ids": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 60000, - "type": "string" - }, - "context_options": { - "description": "Presentation of pinned product data, never a reduction of required policy.", - "properties": { - "advisory_rule_ids": { - "items": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "decision_ids": { - "items": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "delivery": { - "default": "capsule", - "enum": [ - "capsule", - "full" - ], - "type": "string" - } - }, - "type": "object" - }, - "goal": { - "maxLength": 8000, - "pattern": "\\S", - "type": "string" - }, - "requirements": { - "description": "Declared execution needs; a live-path claim remains attributed evidence.", - "properties": { - "boundary_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "entry_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "live_path_evidence": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "requires_write": { - "default": false, - "type": "boolean" - } - }, - "type": "object" - }, - "verification": { - "anyOf": [ - { - "description": "Explicit check ladder; later phases include earlier required checks.", - "properties": { - "checks": { - "items": { - "properties": { - "command": { - "anyOf": [ - { - "maxLength": 2000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "criterion": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "estimated_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "id": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "phase": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "scope": { - "anyOf": [ - { - "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", - "properties": { - "boundaries": { - "description": "What the run did not exercise (external services, other platforms, unselected files).", - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "digest": { - "pattern": "^[0-9a-f]{7,128}$", - "type": "string" - }, - "kind": { - "enum": [ - "tree", - "commit", - "archive", - "content" - ], - "type": "string" - } - }, - "required": [ - "kind", - "digest" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." - } - }, - "required": [ - "id", - "criterion" - ], - "type": "object" - }, - "maxItems": 50, - "type": "array" - }, - "preparation_seconds": { - "default": 0, - "maximum": 7200, - "minimum": 0, - "type": "integer" - }, - "stage": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "required": [ - "goal" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "description": "A new turn's goal and criteria, without permission or ownership changes.", + "properties": { + "acceptance": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "acceptance_set": { + "anyOf": [ + { + "description": "The declared denominator. Its revision is its content, not a version number.", + "properties": { + "items": { + "items": { + "properties": { + "id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligations": { + "description": "Declared clauses. Naming none keeps the criterion one undecomposed unit; naming some means a mapping of the parent covers none of them.", + "items": { + "description": "One clause of a criterion, with the exact environment it is owed in.", + "properties": { + "environment": { + "patternProperties": { + "\\S": { + "maxLength": 200, + "type": "string" + } + }, + "propertyNames": { + "maxLength": 60 + }, + "type": "object" + }, + "id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "text": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "id", + "text" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "text": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "id", + "text" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "schema_version": { + "const": 1, + "default": 1, + "type": "integer" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional structured form of the same acceptance list: its texts must repeat acceptance exactly, so there is never a second source of truth." + }, + "artifact_ids": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 60000, + "type": "string" + }, + "context_options": { + "description": "Presentation of pinned product data, never a reduction of required policy.", + "properties": { + "advisory_rule_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "decision_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "delivery": { + "default": "capsule", + "enum": [ + "capsule", + "full" + ], + "type": "string" + } + }, + "type": "object" + }, + "goal": { + "maxLength": 8000, + "pattern": "\\S", + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "acceptance_coverage": { + "default": "report_only", + "description": "report_only surfaces gaps and refuses nothing. require_current_evidence additionally refuses a success report while a declared evidence unit lacks applicable current passing evidence.", + "enum": [ + "report_only", + "require_current_evidence" + ], + "type": "string" + }, + "checks": { + "items": { + "properties": { + "acceptance_refs": { + "description": "Which declared criteria or obligations this check is intended to exercise. An assertion of intent, never of execution or sufficiency.", + "items": { + "description": "Points at one criterion or one of its obligations, at an exact revision.", + "properties": { + "criterion_id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligation_id": { + "anyOf": [ + { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision", + "criterion_id" + ], + "type": "object" + }, + "maxItems": 200, + "type": "array" + }, + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "coverage_scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "The output bytes this coverage assessment is about. A declaration, not an observation of the filesystem." + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_findings3 fields changed- changed
Input schema / properties / action / enumPrevious value: -[ - "create", - "update", - "get", - "list" -]New value: +[ + "create", + "update", + "get", + "list", + "pin", + "project" +] - added
Input schema / properties / finding_idsAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / set_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +}
- Changed
tandem_result2 fields changed- added
Input schema / properties / wait_modeAdded value: +{ + "default": "auto", + "enum": [ + "auto", + "bounded" + ], + "type": "string" +} - changed
Input schema / properties / wait_seconds / maximumPrevious value: -25New value: +1200
- Changed
tandem_review2 fields changed- changed
Input schema / properties / action / enumPrevious value: -[ - "create", - "read", - "assess" -]New value: +[ + "create", + "prepare", + "read", + "assess" +] - changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "commit": { - "anyOf": [ - { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Required with source=commit: the exact committed snapshot to review against base." - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "corrective": { - "anyOf": [ - { - "description": "Explicit prior exposure, never permission to reuse a prior verdict.", - "properties": { - "open_findings": { - "items": { - "properties": { - "expected_revision": { - "minimum": 1, - "type": "integer" - }, - "finding_id": { - "type": "string" - } - }, - "required": [ - "finding_id", - "expected_revision" - ], - "type": "object" - }, - "maxItems": 100, - "type": "array" - }, - "previous_code_fingerprint": { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - "previous_review_id": { - "type": "string" - } - }, - "required": [ - "previous_review_id", - "previous_code_fingerprint" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", - "enum": [ - "worktree", - "staged", - "commit" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "corrective": { + "anyOf": [ + { + "description": "Explicit prior exposure, never permission to reuse a prior verdict.", + "properties": { + "open_findings": { + "items": { + "properties": { + "expected_revision": { + "minimum": 1, + "type": "integer" + }, + "finding_id": { + "type": "string" + } + }, + "required": [ + "finding_id", + "expected_revision" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "previous_code_fingerprint": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "previous_review_id": { + "type": "string" + } + }, + "required": [ + "previous_review_id", + "previous_code_fingerprint" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "review_directory": { + "default": "", + "description": "Directory inside the launch project whose Git state is reviewed, relative to the project root. Use it when the work lives in a nested repository or a subtree with its own history. Selected and context paths stay relative to the project root regardless. Empty means the project root itself.", + "maxLength": 4096, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_review_run2 fields changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "commit": { - "anyOf": [ - { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Required with source=commit: the exact committed snapshot to review against base." - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "corrective": { - "anyOf": [ - { - "description": "Explicit prior exposure, never permission to reuse a prior verdict.", - "properties": { - "open_findings": { - "items": { - "properties": { - "expected_revision": { - "minimum": 1, - "type": "integer" - }, - "finding_id": { - "type": "string" - } - }, - "required": [ - "finding_id", - "expected_revision" - ], - "type": "object" - }, - "maxItems": 100, - "type": "array" - }, - "previous_code_fingerprint": { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - "previous_review_id": { - "type": "string" - } - }, - "required": [ - "previous_review_id", - "previous_code_fingerprint" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", - "enum": [ - "worktree", - "staged", - "commit" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "corrective": { + "anyOf": [ + { + "description": "Explicit prior exposure, never permission to reuse a prior verdict.", + "properties": { + "open_findings": { + "items": { + "properties": { + "expected_revision": { + "minimum": 1, + "type": "integer" + }, + "finding_id": { + "type": "string" + } + }, + "required": [ + "finding_id", + "expected_revision" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "previous_code_fingerprint": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "previous_review_id": { + "type": "string" + } + }, + "required": [ + "previous_review_id", + "previous_code_fingerprint" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "review_directory": { + "default": "", + "description": "Directory inside the launch project whose Git state is reviewed, relative to the project root. Use it when the work lives in a nested repository or a subtree with its own history. Selected and context paths stay relative to the project root regardless. Empty means the project root itself.", + "maxLength": 4096, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Input schema / properties / wait_seconds / maximumPrevious value: -25New value: +1200
- Changed
tandem_start1 field changed- changed
Input schema / properties / contract / anyOfPrevious value: -[ - { - "properties": { - "acceptance": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "artifact_ids": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 60000, - "type": "string" - }, - "context_options": { - "description": "Presentation of pinned product data, never a reduction of required policy.", - "properties": { - "advisory_rule_ids": { - "items": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "decision_ids": { - "items": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "delivery": { - "default": "capsule", - "enum": [ - "capsule", - "full" - ], - "type": "string" - } - }, - "type": "object" - }, - "goal": { - "maxLength": 8000, - "pattern": "\\S", - "type": "string" - }, - "requirements": { - "description": "Declared execution needs; a live-path claim remains attributed evidence.", - "properties": { - "boundary_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "entry_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "live_path_evidence": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "requires_write": { - "default": false, - "type": "boolean" - } - }, - "type": "object" - }, - "scope": { - "description": "Declared file ownership for coordination; NOT a filesystem sandbox.", - "properties": { - "owned_files": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - } - }, - "type": "object" - }, - "verification": { - "anyOf": [ - { - "description": "Explicit check ladder; later phases include earlier required checks.", - "properties": { - "checks": { - "items": { - "properties": { - "command": { - "anyOf": [ - { - "maxLength": 2000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "criterion": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "estimated_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "id": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "phase": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "scope": { - "anyOf": [ - { - "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", - "properties": { - "boundaries": { - "description": "What the run did not exercise (external services, other platforms, unselected files).", - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "digest": { - "pattern": "^[0-9a-f]{7,128}$", - "type": "string" - }, - "kind": { - "enum": [ - "tree", - "commit", - "archive", - "content" - ], - "type": "string" - } - }, - "required": [ - "kind", - "digest" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." - } - }, - "required": [ - "id", - "criterion" - ], - "type": "object" - }, - "maxItems": 50, - "type": "array" - }, - "preparation_seconds": { - "default": 0, - "maximum": 7200, - "minimum": 0, - "type": "integer" - }, - "stage": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "required": [ - "goal" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "acceptance": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "acceptance_set": { + "anyOf": [ + { + "description": "The declared denominator. Its revision is its content, not a version number.", + "properties": { + "items": { + "items": { + "properties": { + "id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligations": { + "description": "Declared clauses. Naming none keeps the criterion one undecomposed unit; naming some means a mapping of the parent covers none of them.", + "items": { + "description": "One clause of a criterion, with the exact environment it is owed in.", + "properties": { + "environment": { + "patternProperties": { + "\\S": { + "maxLength": 200, + "type": "string" + } + }, + "propertyNames": { + "maxLength": 60 + }, + "type": "object" + }, + "id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "text": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "id", + "text" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "text": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "id", + "text" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "schema_version": { + "const": 1, + "default": 1, + "type": "integer" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional structured form of the same acceptance list: its texts must repeat acceptance exactly, so there is never a second source of truth." + }, + "artifact_ids": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 60000, + "type": "string" + }, + "context_options": { + "description": "Presentation of pinned product data, never a reduction of required policy.", + "properties": { + "advisory_rule_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "decision_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "delivery": { + "default": "capsule", + "enum": [ + "capsule", + "full" + ], + "type": "string" + } + }, + "type": "object" + }, + "goal": { + "maxLength": 8000, + "pattern": "\\S", + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "scope": { + "description": "Declared file ownership for coordination; NOT a filesystem sandbox.", + "properties": { + "owned_files": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + } + }, + "type": "object" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "acceptance_coverage": { + "default": "report_only", + "description": "report_only surfaces gaps and refuses nothing. require_current_evidence additionally refuses a success report while a declared evidence unit lacks applicable current passing evidence.", + "enum": [ + "report_only", + "require_current_evidence" + ], + "type": "string" + }, + "checks": { + "items": { + "properties": { + "acceptance_refs": { + "description": "Which declared criteria or obligations this check is intended to exercise. An assertion of intent, never of execution or sufficiency.", + "items": { + "description": "Points at one criterion or one of its obligations, at an exact revision.", + "properties": { + "criterion_id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligation_id": { + "anyOf": [ + { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision", + "criterion_id" + ], + "type": "object" + }, + "maxItems": 200, + "type": "array" + }, + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "coverage_scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "The output bytes this coverage assessment is about. A declaration, not an observation of the filesystem." + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_wait2 fields changed- added
Input schema / properties / wait_modeAdded value: +{ + "default": "auto", + "enum": [ + "auto", + "bounded" + ], + "type": "string" +} - changed
Input schema / properties / wait_seconds / maximumPrevious value: -25New value: +1200
- Changed
tandem_work3 fields changed- added
Input schema / properties / after_revisionAdded value: +{ + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null +} - changed
Input schema / properties / request / properties / plan / anyOfPrevious value: -[ - { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 64000, - "type": "string" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "steps": { - "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", - "items": { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "depends_on": { - "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", - "items": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "maxItems": 200, - "type": "array" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "id": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "owned_files": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 500, - "type": "array" - }, - "owner": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "requirements": { - "description": "Declared execution needs; a live-path claim remains attributed evidence.", - "properties": { - "boundary_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "entry_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "live_path_evidence": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "requires_write": { - "default": false, - "type": "boolean" - } - }, - "type": "object" - }, - "review_context_paths": { - "description": "Exact additional read-only review paths from the submitted commit. Does not expand owned_files; new context requires a new agreed snapshot.", - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "review_requirements": { - "description": "Declared execution needs; a live-path claim remains attributed evidence.", - "properties": { - "boundary_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "entry_paths": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "live_path_evidence": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "requires_write": { - "default": false, - "type": "boolean" - } - }, - "type": "object" - }, - "review_verification": { - "anyOf": [ - { - "description": "Explicit check ladder; later phases include earlier required checks.", - "properties": { - "checks": { - "items": { - "properties": { - "command": { - "anyOf": [ - { - "maxLength": 2000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "criterion": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "estimated_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "id": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "phase": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "scope": { - "anyOf": [ - { - "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", - "properties": { - "boundaries": { - "description": "What the run did not exercise (external services, other platforms, unselected files).", - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "digest": { - "pattern": "^[0-9a-f]{7,128}$", - "type": "string" - }, - "kind": { - "enum": [ - "tree", - "commit", - "archive", - "content" - ], - "type": "string" - } - }, - "required": [ - "kind", - "digest" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." - } - }, - "required": [ - "id", - "criterion" - ], - "type": "object" - }, - "maxItems": 50, - "type": "array" - }, - "preparation_seconds": { - "default": 0, - "maximum": 7200, - "minimum": 0, - "type": "integer" - }, - "stage": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "reviewer": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "verification": { - "anyOf": [ - { - "description": "Explicit check ladder; later phases include earlier required checks.", - "properties": { - "checks": { - "items": { - "properties": { - "command": { - "anyOf": [ - { - "maxLength": 2000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "criterion": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "estimated_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "id": { - "maxLength": 100, - "pattern": "\\S", - "type": "string" - }, - "phase": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - }, - "requires_shell": { - "default": false, - "type": "boolean" - }, - "scope": { - "anyOf": [ - { - "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", - "properties": { - "boundaries": { - "description": "What the run did not exercise (external services, other platforms, unselected files).", - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "digest": { - "pattern": "^[0-9a-f]{7,128}$", - "type": "string" - }, - "kind": { - "enum": [ - "tree", - "commit", - "archive", - "content" - ], - "type": "string" - } - }, - "required": [ - "kind", - "digest" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." - } - }, - "required": [ - "id", - "criterion" - ], - "type": "object" - }, - "maxItems": 50, - "type": "array" - }, - "preparation_seconds": { - "default": 0, - "maximum": 7200, - "minimum": 0, - "type": "integer" - }, - "stage": { - "default": "targeted", - "enum": [ - "targeted", - "candidate", - "integration" - ], - "type": "string" - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "required": [ - "id", - "title", - "goal", - "owner", - "reviewer", - "acceptance" - ], - "type": "object" - }, - "maxItems": 200, - "minItems": 1, - "type": "array" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "title", - "goal", - "acceptance", - "steps" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 64000, + "type": "string" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "steps": { + "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", + "items": { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "depends_on": { + "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", + "items": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "maxItems": 200, + "type": "array" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "id": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "owned_files": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 500, + "type": "array" + }, + "owner": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "review_context_paths": { + "description": "Exact additional read-only review paths from the submitted commit. Does not expand owned_files; new context requires a new agreed snapshot.", + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "review_requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "review_verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "acceptance_coverage": { + "default": "report_only", + "description": "report_only surfaces gaps and refuses nothing. require_current_evidence additionally refuses a success report while a declared evidence unit lacks applicable current passing evidence.", + "enum": [ + "report_only", + "require_current_evidence" + ], + "type": "string" + }, + "checks": { + "items": { + "properties": { + "acceptance_refs": { + "description": "Which declared criteria or obligations this check is intended to exercise. An assertion of intent, never of execution or sufficiency.", + "items": { + "description": "Points at one criterion or one of its obligations, at an exact revision.", + "properties": { + "criterion_id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligation_id": { + "anyOf": [ + { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision", + "criterion_id" + ], + "type": "object" + }, + "maxItems": 200, + "type": "array" + }, + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "coverage_scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "The output bytes this coverage assessment is about. A declaration, not an observation of the filesystem." + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "reviewer": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "acceptance_coverage": { + "default": "report_only", + "description": "report_only surfaces gaps and refuses nothing. require_current_evidence additionally refuses a success report while a declared evidence unit lacks applicable current passing evidence.", + "enum": [ + "report_only", + "require_current_evidence" + ], + "type": "string" + }, + "checks": { + "items": { + "properties": { + "acceptance_refs": { + "description": "Which declared criteria or obligations this check is intended to exercise. An assertion of intent, never of execution or sufficiency.", + "items": { + "description": "Points at one criterion or one of its obligations, at an exact revision.", + "properties": { + "criterion_id": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + "obligation_id": { + "anyOf": [ + { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._\\-]{0,99}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "revision": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "set_id": { + "type": "string" + } + }, + "required": [ + "set_id", + "revision", + "criterion_id" + ], + "type": "object" + }, + "maxItems": 200, + "type": "array" + }, + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "coverage_scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "The output bytes this coverage assessment is about. A declaration, not an observation of the filesystem." + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "title", + "goal", + "owner", + "reviewer", + "acceptance" + ], + "type": "object" + }, + "maxItems": 200, + "minItems": 1, + "type": "array" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "title", + "goal", + "acceptance", + "steps" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Input schema / properties / wait_seconds / maximumPrevious value: -25New value: +1200
6 tool updates
v3.8.0- Added
tandem_context_read - Changed
tandem_continue4 fields changed- added
Input schema / properties / continuationAdded value: +{ + "default": "resume", + "enum": [ + "resume", + "fresh" + ], + "type": "string" +} - changed
Input schema / properties / contract / anyOfPrevious value: -[ - { - "description": "A new turn's goal and criteria, without permission or ownership changes.", - "properties": { - "acceptance": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "artifact_ids": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 60000, - "type": "string" - }, - "goal": { - "maxLength": 8000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "goal" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "description": "A new turn's goal and criteria, without permission or ownership changes.", + "properties": { + "acceptance": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "artifact_ids": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 60000, + "type": "string" + }, + "context_options": { + "description": "Presentation of pinned product data, never a reduction of required policy.", + "properties": { + "advisory_rule_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "decision_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "delivery": { + "default": "capsule", + "enum": [ + "capsule", + "full" + ], + "type": "string" + } + }, + "type": "object" + }, + "goal": { + "maxLength": 8000, + "pattern": "\\S", + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "checks": { + "items": { + "properties": { + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Input schema / properties / handoffAdded value: +{ + "anyOf": [ + { + "description": "Explicit data for a fresh conversation; no execution capability is transferred.", + "properties": { + "evidence_artifact_ids": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "invalidated_assumptions": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "reason": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "remaining_goals": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "summary": { + "maxLength": 8000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "reason", + "summary" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / preflightAdded value: +{ + "default": false, + "type": "boolean" +}
- Changed
tandem_review1 field changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "commit": { - "anyOf": [ - { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Required with source=commit: the exact committed snapshot to review against base." - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", - "enum": [ - "worktree", - "staged", - "commit" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "corrective": { + "anyOf": [ + { + "description": "Explicit prior exposure, never permission to reuse a prior verdict.", + "properties": { + "open_findings": { + "items": { + "properties": { + "expected_revision": { + "minimum": 1, + "type": "integer" + }, + "finding_id": { + "type": "string" + } + }, + "required": [ + "finding_id", + "expected_revision" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "previous_code_fingerprint": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "previous_review_id": { + "type": "string" + } + }, + "required": [ + "previous_review_id", + "previous_code_fingerprint" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_review_run1 field changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "commit": { - "anyOf": [ - { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Required with source=commit: the exact committed snapshot to review against base." - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", - "enum": [ - "worktree", - "staged", - "commit" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "corrective": { + "anyOf": [ + { + "description": "Explicit prior exposure, never permission to reuse a prior verdict.", + "properties": { + "open_findings": { + "items": { + "properties": { + "expected_revision": { + "minimum": 1, + "type": "integer" + }, + "finding_id": { + "type": "string" + } + }, + "required": [ + "finding_id", + "expected_revision" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "previous_code_fingerprint": { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + "previous_review_id": { + "type": "string" + } + }, + "required": [ + "previous_review_id", + "previous_code_fingerprint" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_start2 fields changed- changed
Input schema / properties / contract / anyOfPrevious value: -[ - { - "properties": { - "acceptance": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "artifact_ids": { - "items": { - "type": "string" - }, - "maxItems": 32, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 2000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 60000, - "type": "string" - }, - "goal": { - "maxLength": 8000, - "pattern": "\\S", - "type": "string" - }, - "scope": { - "description": "Declared file ownership for coordination; NOT a filesystem sandbox.", - "properties": { - "owned_files": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - } - }, - "type": "object" - } - }, - "required": [ - "goal" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "acceptance": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "artifact_ids": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 60000, + "type": "string" + }, + "context_options": { + "description": "Presentation of pinned product data, never a reduction of required policy.", + "properties": { + "advisory_rule_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "decision_ids": { + "items": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "delivery": { + "default": "capsule", + "enum": [ + "capsule", + "full" + ], + "type": "string" + } + }, + "type": "object" + }, + "goal": { + "maxLength": 8000, + "pattern": "\\S", + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "scope": { + "description": "Declared file ownership for coordination; NOT a filesystem sandbox.", + "properties": { + "owned_files": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + } + }, + "type": "object" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "checks": { + "items": { + "properties": { + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "goal" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Input schema / properties / preflightAdded value: +{ + "default": false, + "type": "boolean" +}
- Changed
tandem_work2 fields changed- changed
Input schema / properties / request / properties / plan / anyOfPrevious value: -[ - { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 64000, - "type": "string" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "steps": { - "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", - "items": { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "depends_on": { - "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", - "items": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "maxItems": 200, - "type": "array" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "id": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "owned_files": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 500, - "type": "array" - }, - "owner": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "review_context_paths": { - "description": "Exact additional read-only review paths from the submitted commit. Does not expand owned_files; new context requires a new agreed snapshot.", - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "reviewer": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "id", - "title", - "goal", - "owner", - "reviewer", - "acceptance" - ], - "type": "object" - }, - "maxItems": 200, - "minItems": 1, - "type": "array" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "title", - "goal", - "acceptance", - "steps" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 64000, + "type": "string" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "steps": { + "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", + "items": { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "depends_on": { + "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", + "items": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "maxItems": 200, + "type": "array" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "id": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "owned_files": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 500, + "type": "array" + }, + "owner": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "review_context_paths": { + "description": "Exact additional read-only review paths from the submitted commit. Does not expand owned_files; new context requires a new agreed snapshot.", + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "review_requirements": { + "description": "Declared execution needs; a live-path claim remains attributed evidence.", + "properties": { + "boundary_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "entry_paths": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "live_path_evidence": { + "items": { + "type": "string" + }, + "maxItems": 32, + "type": "array" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "requires_write": { + "default": false, + "type": "boolean" + } + }, + "type": "object" + }, + "review_verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "checks": { + "items": { + "properties": { + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "reviewer": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "verification": { + "anyOf": [ + { + "description": "Explicit check ladder; later phases include earlier required checks.", + "properties": { + "checks": { + "items": { + "properties": { + "command": { + "anyOf": [ + { + "maxLength": 2000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "criterion": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "estimated_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "maxLength": 100, + "pattern": "\\S", + "type": "string" + }, + "phase": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + }, + "requires_shell": { + "default": false, + "type": "boolean" + }, + "scope": { + "anyOf": [ + { + "description": "Which bytes a run observed. Equal digests of the same kind are the same bytes.", + "properties": { + "boundaries": { + "description": "What the run did not exercise (external services, other platforms, unselected files).", + "items": { + "maxLength": 2000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "digest": { + "pattern": "^[0-9a-f]{7,128}$", + "type": "string" + }, + "kind": { + "enum": [ + "tree", + "commit", + "archive", + "content" + ], + "type": "string" + } + }, + "required": [ + "kind", + "digest" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Explicit current input identity. History from other bytes remains recorded but is not a current result; omitted scope keeps ambiguous failures unresolved." + } + }, + "required": [ + "id", + "criterion" + ], + "type": "object" + }, + "maxItems": 50, + "type": "array" + }, + "preparation_seconds": { + "default": 0, + "maximum": 7200, + "minimum": 0, + "type": "integer" + }, + "stage": { + "default": "targeted", + "enum": [ + "targeted", + "candidate", + "integration" + ], + "type": "string" + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "title", + "goal", + "owner", + "reviewer", + "acceptance" + ], + "type": "object" + }, + "maxItems": 200, + "minItems": 1, + "type": "array" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "title", + "goal", + "acceptance", + "steps" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Input schema / properties / sectionAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +}
1 tool update
v3.7.1- Changed
tandem_work7 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / formatAdded value: +{ + "default": "json", + "enum": [ + "json", + "markdown" + ], + "type": "string" +} - added
Input schema / properties / include_snapshotsAdded value: +{ + "default": false, + "type": "boolean" +} - added
Input schema / properties / limitAdded value: +{ + "default": 50, + "maximum": 200, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / request / properties / action / enumPrevious value: -[ - "create", - "get", - "list", - "history", - "propose", - "agree", - "claim", - "heartbeat", - "block", - "unblock", - "submit", - "accept", - "reject", - "report", - "compare", - "pause", - "resume", - "reconcile" -]New value: +[ + "create", + "get", + "list", + "history", + "propose", + "agree", + "claim", + "heartbeat", + "block", + "unblock", + "submit", + "accept", + "reject", + "report", + "compare", + "pause", + "resume", + "reconcile", + "recover" +] - changed
Input schema / properties / request / properties / plan / anyOfPrevious value: -[ - { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "constraints": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "context": { - "default": "", - "maxLength": 64000, - "type": "string" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "steps": { - "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", - "items": { - "properties": { - "acceptance": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - }, - "depends_on": { - "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", - "items": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "maxItems": 200, - "type": "array" - }, - "goal": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "id": { - "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", - "type": "string" - }, - "owned_files": { - "items": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - }, - "maxItems": 500, - "type": "array" - }, - "owner": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "reviewer": { - "enum": [ - "claude", - "omp" - ], - "type": "string" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "id", - "title", - "goal", - "owner", - "reviewer", - "acceptance" - ], - "type": "object" - }, - "maxItems": 200, - "minItems": 1, - "type": "array" - }, - "title": { - "maxLength": 16000, - "pattern": "\\S", - "type": "string" - } - }, - "required": [ - "title", - "goal", - "acceptance", - "steps" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "constraints": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "context": { + "default": "", + "maxLength": 64000, + "type": "string" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "steps": { + "description": "Acyclic checklist with exactly one final integration step that depends transitively on all other steps. A one-step plan is valid.", + "items": { + "properties": { + "acceptance": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + }, + "depends_on": { + "description": "Prerequisite step IDs. One final integration step must depend, directly or transitively, on every other step, including investigation and verification steps.", + "items": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "maxItems": 200, + "type": "array" + }, + "goal": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "id": { + "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_-]{0,99}$", + "type": "string" + }, + "owned_files": { + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 500, + "type": "array" + }, + "owner": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "review_context_paths": { + "description": "Exact additional read-only review paths from the submitted commit. Does not expand owned_files; new context requires a new agreed snapshot.", + "items": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "reviewer": { + "enum": [ + "claude", + "omp" + ], + "type": "string" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "id", + "title", + "goal", + "owner", + "reviewer", + "acceptance" + ], + "type": "object" + }, + "maxItems": 200, + "minItems": 1, + "type": "array" + }, + "title": { + "maxLength": 16000, + "pattern": "\\S", + "type": "string" + } + }, + "required": [ + "title", + "goal", + "acceptance", + "steps" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Input schema / properties / viewAdded value: +{ + "default": "summary", + "enum": [ + "summary", + "plan", + "step", + "full" + ], + "type": "string" +}
3 tool updates
v3.5.0- Changed
tandem_review1 field changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes or Git index bytes compared with base. Staged capture never reads live files.", - "enum": [ - "worktree", - "staged" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_review_run1 field changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "context_paths": { - "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", - "items": { - "type": "string" - }, - "maxItems": 256, - "type": "array" - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "source": { - "default": "worktree", - "description": "Select worktree bytes or Git index bytes compared with base. Staged capture never reads live files.", - "enum": [ - "worktree", - "staged" - ], - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "commit": { + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Required with source=commit: the exact committed snapshot to review against base." + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes, Git index bytes, or the tree of an existing commit compared with base. Staged and commit captures never read live files.", + "enum": [ + "worktree", + "staged", + "commit" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Added
tandem_work
4 tool updates
v3.3.0- Changed
tandem_continue1 field changed- changed
Input schema / properties / execution / anyOfPrevious value: -[ - { - "properties": { - "model": { - "anyOf": [ - { - "minLength": 1, - "pattern": "\\S", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "profile": { - "default": "balanced", - "enum": [ - "quick", - "balanced", - "deep" - ], - "type": "string" - }, - "thinking": { - "anyOf": [ - { - "enum": [ - "off", - "minimal", - "low", - "medium", - "high", - "xhigh", - "max" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "timeout_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Changed
tandem_review1 field changed- changed
Input schema / properties / request / anyOfPrevious value: -[ - { - "properties": { - "author_proposal": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "author_rationale": { - "default": "", - "maxLength": 200000, - "type": "string" - }, - "base": { - "default": "HEAD", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "checks": { - "items": { - "properties": { - "code_fingerprint": { - "anyOf": [ - { - "pattern": "^[0-9a-f]{64}$", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "command": { - "anyOf": [ - { - "maxLength": 4000, - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "output": { - "maxLength": 1048576, - "type": "string" - }, - "source": { - "default": "coordinator supplied", - "maxLength": 1000, - "type": "string" - } - }, - "required": [ - "name", - "output" - ], - "type": "object" - }, - "maxItems": 32, - "type": "array" - }, - "criteria": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "external_boundaries": { - "items": { - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "paths": { - "anyOf": [ - { - "items": { - "type": "string" - }, - "maxItems": 256, - "minItems": 1, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "requirements": { - "maxLength": 200000, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "requirements" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "author_proposal": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "author_rationale": { + "default": "", + "maxLength": 200000, + "type": "string" + }, + "base": { + "default": "HEAD", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "checks": { + "items": { + "properties": { + "code_fingerprint": { + "anyOf": [ + { + "pattern": "^[0-9a-f]{64}$", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "command": { + "anyOf": [ + { + "maxLength": 4000, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "output": { + "maxLength": 1048576, + "type": "string" + }, + "source": { + "default": "coordinator supplied", + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "name", + "output" + ], + "type": "object" + }, + "maxItems": 32, + "type": "array" + }, + "context_paths": { + "description": "Explicit additional saved context; staged reviews use index bytes, never live files.", + "items": { + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + "criteria": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "external_boundaries": { + "items": { + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "paths": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "maxItems": 256, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "requirements": { + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "source": { + "default": "worktree", + "description": "Select worktree bytes or Git index bytes compared with base. Staged capture never reads live files.", + "enum": [ + "worktree", + "staged" + ], + "type": "string" + } + }, + "required": [ + "requirements" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Added
tandem_review_run - Changed
tandem_start1 field changed- changed
Input schema / properties / execution / anyOfPrevious value: -[ - { - "properties": { - "model": { - "anyOf": [ - { - "minLength": 1, - "pattern": "\\S", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "profile": { - "default": "balanced", - "enum": [ - "quick", - "balanced", - "deep" - ], - "type": "string" - }, - "thinking": { - "anyOf": [ - { - "enum": [ - "off", - "minimal", - "low", - "medium", - "high", - "xhigh", - "max" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "timeout_seconds": { - "anyOf": [ - { - "maximum": 7200, - "minimum": 1, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "description": "Profile defaults: quick: Defaults to low thinking with a 600-second deadline. balanced: Defaults to high thinking with a 1800-second deadline. deep: Defaults to high thinking with a 3600-second deadline. Uses the same thinking level as balanced with a longer deadline, not higher reasoning. These are default choices; overrides, effective settings, and actual settings are reported separately.", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } +]
7 tool updates
v3.1.0- Changed
tandem_channel1 field changed- added
Input schema / properties / watchdog_tokenAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +}
- Changed
tandem_continue8 fields changed- added
Input schema / properties / executionAdded value: +{ + "anyOf": [ + { + "properties": { + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / review_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / review_stageAdded value: +{ + "anyOf": [ + { + "enum": [ + "independent", + "comparison" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / timeout_seconds / anyOfAdded value: +[ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } +] - changed
Input schema / properties / timeout_seconds / defaultPrevious value: -1800New value: +null - removed
Input schema / properties / timeout_seconds / maximumRemoved value: -7200 - removed
Input schema / properties / timeout_seconds / minimumRemoved value: -1 - removed
Input schema / properties / timeout_seconds / typeRemoved value: -"integer"
- Added
tandem_diagnose - Added
tandem_findings - Added
tandem_receipt - Added
tandem_review - Changed
tandem_start8 fields changed- added
Input schema / properties / executionAdded value: +{ + "anyOf": [ + { + "properties": { + "model": { + "anyOf": [ + { + "minLength": 1, + "pattern": "\\S", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile": { + "default": "balanced", + "enum": [ + "quick", + "balanced", + "deep" + ], + "type": "string" + }, + "thinking": { + "anyOf": [ + { + "enum": [ + "off", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "timeout_seconds": { + "anyOf": [ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / review_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / review_stageAdded value: +{ + "anyOf": [ + { + "enum": [ + "independent", + "comparison" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null +} - added
Input schema / properties / timeout_seconds / anyOfAdded value: +[ + { + "maximum": 7200, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } +] - changed
Input schema / properties / timeout_seconds / defaultPrevious value: -1800New value: +null - removed
Input schema / properties / timeout_seconds / maximumRemoved value: -7200 - removed
Input schema / properties / timeout_seconds / minimumRemoved value: -1 - removed
Input schema / properties / timeout_seconds / typeRemoved value: -"integer"
14 tool updates
v3.0.1- First observed
tandem_cancel - First observed
tandem_channel - First observed
tandem_continue - First observed
tandem_export_context - First observed
tandem_import_context - First observed
tandem_list - First observed
tandem_project_context - First observed
tandem_publish_artifact - First observed
tandem_read_artifact - First observed
tandem_reply - First observed
tandem_result - First observed
tandem_scope - First observed
tandem_start - First observed
tandem_wait
TDQS
Scored across 25 tools
Most tools target distinct resources (start/continue/reply/cancel/wait/result are clearly separable lifecycle ops), but several pairs have murky boundaries: tandem_review vs tandem_review_run, tandem_result vs tandem_wait, tandem_audit vs tandem_recommend (both share preview/hash/opt-in OpenRouter semantics), and tandem_project_context vs tandem_publish_artifact/read_artifact all move immutable shared data. Descriptions work hard to disambiguate, but the overlaps mean an agent can plausibly misselect.
All names use a consistent 'tandem_' prefix and snake_case, which is uniform and readable. There is a minor deviation between verb-first names (start, continue, cancel, list, wait, reply) and noun-first names (scope, team, result, channel, review, findings), but the pattern is predictable within categories and rarely ambiguous.
25 tools sits at the upper/heavy boundary. For a multi-stage orchestration system (tasks, teams, reviews, context exchange, delivery) many tools earn their place, but the surface is sprawling and includes peripheral operations (diagnose, channel, receipt, export/import) that push it toward overload.
Coverage is broad and thoughtful: task lifecycle (start/continue/wait/result/reply/cancel/list), context/artifact exchange (project_context, publish/read, export/import), review capture/run/findings, team, desktop, and delivery all have tools. The surface has few obvious dead ends; remaining gaps are edge operations rather than core workflow holes.
Maintenance
Related MCP Connectors
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Coordinate coding agents through MCP using existing AI plans, saved work, and independent checks.
The project brain for AI coding agents — memory, decisions, sprints, knowledge base via MCP.
StremAI MCP: shared memory for AI coding agents. Connected agents can recall. OAuth + local stdio.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides MCP tools for AI-powered code review, research, and book writing via a fleet of coding agents.Apache 2.0
- AlicenseNot gradedqualityCmaintenanceProvides coding agents with structured planning, persistent project memory, automated verification, and safety permission controls through MCP tools, enabling better planning, context retention, self-checking, and guarded execution.7 npmMIT
- AlicenseNot gradedqualityAmaintenanceEnables multi-agent AI collaboration by connecting Claude Code, OpenAI Codex, and Google Antigravity, providing cross-model code reviews, independent second opinions, and autonomous validation through MCP tools.1MIT
- FlicenseAqualityBmaintenanceEnables coding agents to build and query a verified project memory through the MCP protocol, so skills, facts, and user preferences are captured as experience and adopted only after passing independent checks. It also briefs agents at each request, flags known pitfalls live, and runs an executable review before changes are finalized.4-