Skip to main content
Glama
BrightbeamAI

@brightbeamai/chap-coordinator-mcp

Official
by BrightbeamAI
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

chap.decide.override

chap.decide.override

Apply an RFC 6902 JSON Patch to correct an artefact under review, recording the rationale and tags for an auditable decision trail.

Instructions

Correct the artefact under review with an RFC 6902 JSON Patch and accept the result. The patch, the rationale and any tags are recorded together, so the audit log holds what was changed and why, rather than only that the work was not accepted as written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffYesRFC 6902 JSON Patch operations applied to the artefact under review. The patched artefact becomes the task output; a patch that does not apply is refused with -32012.
fromYesParticipant URI, e.g. 'human:alice@example.org' or 'agent:bot@local'.
tagsNoWorkspace-defined labels for this decision, e.g. ['tone', 'unsupported-claim']. Recorded in the audit entry. chap.audit.read does not filter on tags, so grouping by tag is done by the reader.
task_idYesTask identifier returned by chap.task.create.
rationaleYesWhy the correction was made. Required on every override and recorded in the audit entry, since the diff shows what changed but not why.
workspaceYesWorkspace identifier, e.g. 'wsp_techcorp_support'.
logical_idNoCaller-chosen identifier for the item being decided, stable across revisions and overrides of the same underlying content. Recorded in the audit entry.
policy_refsNoIdentifiers of the policies or guidelines this correction applies, e.g. ['policy:no-delivery-promises']. Recorded in the audit entry.
intent_preservedNoTrue when the edit refines the decision the draft was making, false when it substitutes a different one. Recorded in the audit entry.
approved_artefact_digestNoOptional. SHA-256 over the JCS canonicalisation of the artefact under review, in the form `sha256:<hex>`. When present it binds the decision to the exact content reviewed, and a mismatch is refused with -32074.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.13

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the patch, rationale, and tags are recorded together in the audit log, and that the action accepts the result. However, it does not mention permission requirements, reversibility, or other side effects beyond audit logging.

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?

The description is two focused sentences with no filler. The core action is front-loaded, and the audit rationale is explained efficiently in the second sentence.

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

Completeness4/5

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

The rich parameter schema covers operation semantics, error behavior, and audit recording, while the description adds the cross-cutting audit rationale. The lack of an output schema is not a major gap because success semantics are largely inferable from the schema and description.

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 all 10 parameters already have descriptive meaning. The description adds little beyond the schema; it reinforces that rationale and tags are auditable but does not provide new parameter-level information.

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?

The description states a specific verb ('Correct'), a resource ('the artefact under review'), and the mechanism ('RFC 6902 JSON Patch'), and clarifies that the result is accepted. This clearly distinguishes the tool from sibling decision tools like chap.decide.approve and chap.decide.reject.

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 when to use the tool: when the artefact needs correction rather than outright rejection. The phrase 'rather than only that the work was not accepted as written' contrasts with reject-style decisions, giving useful context even though it does not name sibling tools explicitly.

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

Install Server

Other Tools