WORK INWorkstream MCP
BRING
Brand access · Saved baseline · Representative cases
FINISH WITH
A verified saved version and evaluation evidence
Prerequisites
Connect to Workstream MCP with access to the intended brand. Have an authorized reviewer, representative cases, and the policy or evidence supporting the change. Evaluation may invoke models and consume resources even though it does not apply the candidate to the brand. If you have no existing workflow or real case yet, start with Your First Workflow Trial.1. Read the baseline
Discover the exposed tool schemas, then readget_brand_config and the relevant scorecard or
run evidence. These configuration tools use the argument brand; other operational tools may
use brand_id. Inspect the schema rather than assuming one name everywhere.
Retain the full deterministic_config, its config_version, the brand identity, and the
observed problem. Keep the baseline with the proposed change so a reviewer can compare them.
Use check_config_drift where available to identify divergence before editing.
Success: your proposal will be based on a known saved version and a specific failure case.
2. Propose a patch without saving
propose_config_patch accepts the brand and a list of operations. Its supported operations are
set, remove, append, and replace_text; it is not a generic implementation of every
JSON Patch operation. Use a path observed in the actual configuration and the operation’s
current schema.
Ask your assistant:
proposed_config, changes, validation, and
based_on_config_version. It does not save the candidate. Preserve that complete candidate;
do not reduce it to the changed fragment for the later apply call.
3. Validate the candidate you intend to apply
Callvalidate_config with the brand and the returned proposed_config as config.
Inspect valid, errors, and warnings.
Omitting config validates the brand’s currently saved configuration. That can succeed while
your proposed change remains invalid, so confirm which object was checked.
Validation checks configuration structure and binding rules. It does not prove answer quality,
provider readiness, or that the desired business outcome will occur.
Success: the exact candidate passes structural validation, and any warnings have been reviewed.
4. Compare behavior before applying
Useget_eval_cases or approved hand-written cases, then call evaluate_config with:
With
simulate_tools: true, recorded case context supplies reads and mutations are recorded
as proposed actions rather than executed. This is not a live connector test. Inspect missing
context and proposed actions as well as generated text before trusting the result.
Use evaluate_golden to check the candidate against the brand’s standing human-corrected cases.
An evaluation result informs the decision; do not mistake an earlier advisory evaluation for
the apply-time gate. If there are no usable cases, build and review the relevant evidence
before claiming that the change passed regression checks.
Keep Response’s evaluation records separate from Workstream golden cases. A Response
run_eval result does not automatically satisfy this brand’s workflow gate.
5. Apply the authorized candidate
After approval, callapply_config with these fields populated from the reviewed work:
A brand’s required golden gate still applies when the caller omits
require_golden_pass.
Omitting the flag is not a way to bypass policy. Resolve the reported prerequisite or failed
result rather than removing controls.
If the version conflicts, another change may have landed. Fetch the latest configuration,
review the difference, and rebuild/re-evaluate the proposal. Do not simply replace the expected
version number and send the old candidate, which could erase someone else’s work.
An authorized apply task can be explicit:
6. Verify persistence and subsequent behavior
Inspect the apply result, includingapplied, config_version, and config_fingerprint when
returned. Then read get_brand_config independently and compare the saved values. Use
list_config_versions and get_config_version for the version history and snapshots exposed
by your connection.
Watch relevant subsequent runs. Keep the new config version, run IDs, observed replies/actions,
and unresolved regressions with the change record. A successful apply proves persistence; it
does not itself prove better live outcomes or change the brand’s routing mode.
If a response was lost, read the saved state and version history before deciding whether to
repeat the write. Do not infer success solely from an HTTP connection or a tool invocation.
If the change needs to be reversed
Read the current state and the earlier snapshot. Treat restoring prior values as another reviewed, validated, evaluated change against the current version. An older snapshot is not automatically suitable if connectors or other policies have changed since it was captured. This process changes future configuration. It does not unsend replies, undo provider actions, or establish that in-flight runs now use the restored values. Inspect affected executions and handle their outcomes separately.Troubleshooting
Next steps
Measure the result
Compare subsequent outcomes with the baseline you saved.
Resolve a blocker
Diagnose access problems or a stalled workflow.