Plori

Official

by plori-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Reject Workspace changeset

reject_workspace_changeset

DestructiveIdempotent

Reject a submitted changeset to leave Workspace files unchanged while keeping the worker's copy and saved revision. Use when changes should not be merged.

Instructions

Reject a changeset: the Workspace's files stay as they are, and the worker's copy and saved revision are kept. A rejected or accepted changeset cannot change again. Repeating the call returns the same result.

Input Schema

Name	Required	Description	Default
`changeset_id`	Yes	The changeset_id from submit_workspace_changeset or list_workspace_changesets.
`workspace_id`	Yes	The Workspace UUID.

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.5/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new context: what is and isn't affected (Workspace files unchanged, worker copy and saved revision kept), that the changeset enters a terminal state after accept or reject, and that repeated calls return the same result. This clarifies the scope of the "destructive" annotation rather than repeating it.

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

Conciseness5/5

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

Two compact sentences with zero filler. The primary effect (files stay, copy kept) is front-loaded, and the terminal-state/idempotency note follows as secondary but relevant detail.

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?

An output schema exists, so return values need no explanation. For a two-parameter, fully-described mutation tool, the description covers the state semantics, the terminal behavior, and idempotency — everything an agent needs to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (changeset_id, workspace_id) are already fully documented in the schema, including where changeset_id comes from. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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 and resource ("Reject a changeset") and immediately explains the resulting state, which makes it unambiguous against its sibling accept_workspace_changeset. An agent can distinguish the two without opening either schema.

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

Usage Guidelines4/5

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

The description conveys the selecting condition implicitly and clearly: rejecting keeps the Workspace's files and the worker's copy/revision, which is the semantic opposite of accepting. It does not explicitly name accept_workspace_changeset as the alternative or state when-not to use this tool, so it falls short of a full 5.

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