Plori

Official

by plori-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Accept Workspace changeset

accept_workspace_changeset

DestructiveIdempotent

Accept a changeset to publish a worker's changes as the Workspace's current files, creating a new revision. The expected current revision must match or the call is refused.

Instructions

Accept a changeset in phase review_ready: the worker's changes become the Workspace's current files, saved as a new revision. expected_current_revision must be the changeset's comparison_current_revision, and the Workspace's current revision must still be that revision; otherwise the call is refused with 409 current_revision_conflict, and submit_workspace_changeset submits the worker again against the new current revision. A changeset that is still being compared or has conflicts is refused with 409 workspace_changeset_unresolved; a Workspace with an active run or file operation is refused with 409 workspace_changeset_busy. For conflicts (needs_resolution), use reject_workspace_changeset then create_workspace_worker with an adjusted task on the current files. To keep both versions, read the worker's file with read_workspace_file from incoming_revision, use send_workspace_message to ask the Workspace's agent to write the combined file into the Workspace, wait for that run to complete, then use reject_workspace_changeset on the conflicted changeset. The save completes after the call returns: poll get_workspace_changeset until state is accepted and result_revision is set. Repeating the call with the same arguments returns the same result.

Input Schema

Name	Required	Description
`changeset_id`	Yes	The changeset_id from submit_workspace_changeset or list_workspace_changesets.
`workspace_id`	Yes	The Workspace UUID.
`validation_evidence`	Yes	1-32 statements of the checks you made on the changes before accepting them, such as the files you read or the tests the worker ran. They are stored with the changeset.
`expected_current_revision`	Yes	The changeset's comparison_current_revision from get_workspace_changeset.

Output Schema

Name	Required	Description
`phase`	Yes	The step the changeset is in: checkpointing, creating_integration and comparing while the comparison runs; review_ready when accept_workspace_changeset can accept it; needs_resolution when it has conflicts; saving_result after accept until result_revision is set; recompare_required when the Workspace changed after the comparison (submit the worker again); then accepted, rejected or failed.
`state`	Yes	submitted (being compared, or ready for review when phase is review_ready), conflicted (the worker and the Workspace changed the same paths; see accept_workspace_changeset for recovery), accepted, rejected or failed.
`changes`	No	The changed paths, at most 500. get_workspace_changeset returns them; list_workspace_changesets leaves them out.
`compared`	Yes	True when the comparison is complete and changes and conflicts are known.
`conflicts`	No	The paths that conflict, when state is conflicted.
`no_change`	No	True when the worker changed no files.
`created_at`	Yes	When the changeset was submitted.
`updated_at`	Yes	When the changeset last changed.
`auto_accept`	No	Set only for a changeset whose comparison was clean and changed files: pending (the platform may still accept it), accepted (the platform accepted it) or abandoned (the platform stopped and will not accept it).
`change_count`	Yes	The number of changed paths.
`changeset_id`	Yes	The changeset UUID.
`workspace_id`	Yes	The Workspace UUID.
`base_revision`	Yes	The revision the worker's copy started from.
`result_revision`	No	The new current revision of the Workspace once an accepted changeset is saved.
`terminal_reason`	No	Why a failed changeset failed.
`working_copy_id`	Yes	The worker's copy that the changes come from.
`changes_truncated`	No	True when there are more than 500 changed paths.
`incoming_revision`	Yes	The worker's saved revision. read_workspace_file reads its files.
`validation_evidence`	No	The evidence given when the changeset was accepted.
`comparison_current_revision`	No	The Workspace revision the changes were compared with. accept_workspace_changeset takes it as expected_current_revision.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.17.1Oct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive=true and idempotent=true, and the description adds substantial context beyond them: the specific 409 error codes and their triggers, the fact that the save is asynchronous and must be polled via get_workspace_changeset until state=accepted, and confirmation that repeated identical calls return the same result. This is exactly the extra operational detail annotations cannot carry.

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

Conciseness4/5

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

Front-loads the core action and effect in the first clause, then layers preconditions, error cases, and alternatives. The sentences are long and dense, but nearly every clause is operational information an agent needs; only minor tightening is possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, revision-guarded mutation with an output schema, the description covers preconditions, failure modes, async completion, and recovery paths, so nothing an agent needs to invoke it safely is missing. Return-value details are correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a real invariant beyond the schema text: expected_current_revision must equal the changeset's comparison_current_revision and the Workspace's live revision must still match or the call fails with 409. It adds no detail for validation_evidence, which the schema already covers fully.

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

Purpose5/5

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

States a specific verb (accept) and resource (changeset) plus the concrete effect: the worker's changes become the Workspace's current files as a new revision. This clearly separates it from reject_workspace_changeset and submit_workspace_changeset without needing to open their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the required precondition (changeset in phase review_ready, matching expected_current_revision) and explicit refusal conditions. It names alternatives and the conditions that select them: submit_workspace_changeset when the current revision moved, and reject_workspace_changeset + create_workspace_worker for conflicts, including a full recipe for preserving both versions.

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