Skip to main content
Glama
BrightbeamAI

@brightbeamai/chap-coordinator-mcp

Official
by BrightbeamAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Override with a correction

chap.decide.override

Correct a reviewed artefact by applying an RFC 6902 JSON Patch, then accept it while recording the patch, rationale and tags in the audit log.

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

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so safety is covered. The description adds a real behavioral trait beyond that: the patch, rationale and tags are co-recorded so the audit log captures what changed and why, which explains the non-idempotent nature. It stops short of describing refusal conditions or what the caller receives back.

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?

Two sentences, front-loaded with the action and mechanism (RFC 6902 JSON Patch) before the audit rationale. The trailing clause 'rather than only that the work was not accepted as written' is slightly wordy but justifies why the tool exists alongside reject.

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

Completeness4/5

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

For a 10-parameter mutation tool, the description covers the core semantics (patch is applied, result is accepted, audit captures patch plus rationale) while the schema carries parameter detail and error codes (-32012, -32074) and annotations carry the safety profile. Only the return shape and idempotency implications are unaddressed.

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 ten parameters including diff, rationale, tags, policy_refs and approved_artefact_digest are already documented, and the description only echoes the patch/rationale/tags trio. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose4/5

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

The description states a specific verb (correct/override) and resource (the artefact under review), and 'accept the result' makes clear this is a terminal decision rather than a comment. It implicitly differs from chap.decide.approve/reject by modifying content rather than just accepting or refusing it, but it never names those siblings to make the distinction explicit.

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

Usage Guidelines2/5

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

There is no explicit statement of when to choose this over chap.decide.approve or chap.decide.reject, which are the obvious alternatives in a 39-tool sibling set. The reader must infer from 'override with a correction' that this is the path when the draft is nearly right but needs edits.

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

Deploy Server

Other Tools