Review and Approve MCP Write Actions

Review and Approve MCP Write Actions

MCP write tools can create or change information in a connected service.

They may:

• create a task;
• update a record;
• save a file;
• send a message;
• create a note;
• change a status;
• move an item; or
• remove information.

These actions can be useful, but they deserve more review than a simple lookup.

Use a draft-first process, confirm the destination, approve the exact action, and verify the result in the connected service.

What makes a write action different

A read action retrieves information.

A write action changes something.

That change may affect:

• another person;
• a customer;
• a business record;
• a file;
• a project;
• a message;
• a task;
• a workflow;
• an account; or
• an external service.

A well-written AI response does not prove that the action was correct.

Review the actual tool call and destination.

Examples of MCP write actions

Write actions may include:

Action	Example
Create	Create a new task or Journal entry
Update	Change a record status or project field
Send	Send a message or notification
Save	Save a file or report
Move	Move an item to another folder or queue
Delete	Remove a file, task, note, or record

The exact actions depend on the connected MCP server and its tools.

Review each tool separately.

Use the least access required

A tool should have only the permissions needed for the approved action.

Prefer:

• a limited account;
• a specific workspace;
• an approved folder;
• a defined record type;
• a narrow destination;
• one required URL;
• one required path;
• one required port; or
• a test environment.

Avoid broad administrator access for routine workflow tasks.

Separate read and write connections

When possible, use separate connections for:

• read-only access; and
• approved write access.

Clear names help users choose the correct one.

For example:

• Customer Records MCP — Read Only;
• Customer Records MCP — Approved Writes;
• Project Service MCP — Test; or
• Project Service MCP — Production.

This reduces the chance that a write-capable tool is used during a read-only task.

Begin with a draft

Ask the model or workflow to prepare the proposed action without performing it.

For example:

Prepare the customer-record update.

Show:
* the record that would be changed;
* the current values;
* the fields that would be updated;
* the proposed new values; and
* the reason for the change.

Do not submit the update yet.

This creates a reviewable proposal.

What a useful draft should show

The draft should include:

• the action type;
• the destination;
• the account or workspace;
• the item or record identifier;
• the current state when available;
• the proposed change;
• the source information;
• the expected result;
• whether the action can be reversed; and
• any uncertainty or missing information.

Do not approve a vague action.

Confirm the action type

Check whether the tool will:

• create;
• update;
• send;
• save;
• move;
• delete; or
• perform another change.

These actions have different consequences.

A request to "handle this record" is too vague.

Use a specific instruction such as:

Update the Status field from Pending to Reviewed.

Confirm the destination

Before approval, verify:

• the connected service;
• the account;
• the workspace;
• the project;
• the record;
• the file path;
• the folder;
• the recipient; and
• the environment.

A correct action against the wrong destination is still a serious error.

Confirm the identity of the item

Use stable identifiers when available.

These may include:

• record ID;
• task ID;
• file path;
• customer reference;
• project identifier;
• message thread;
• account ID; or
• another unique value.

Names alone may be ambiguous.

Confirm that the identifier belongs to the intended item.

Confirm the current state

Review the current value before changing it.

For example:

Field	Current	Proposed
Status	Pending	Reviewed
Owner	Mia	Mia
Deadline	Not provided	12 June 2026

This helps you see exactly what will change.

It also reveals whether the proposed action is based on outdated information.

Confirm the source

Check where the proposed change came from.

The source may be:

• a user instruction;
• a document;
• a tool result;
• a meeting note;
• a workflow field;
• a project record;
• an approved policy; or
• another connected service.

Do not approve a change when the source is unclear.

Confirm the content

Review every value that will be written.

Check:

• names;
• dates;
• amounts;
• statuses;
• recipients;
• filenames;
• message text;
• links;
• identifiers; and
• required fields.

Look for unsupported or invented details.

Make missing information visible

Do not let the model fill missing values by guessing.

Use an instruction such as:

If a required value is missing, write "Not provided."
Do not perform the write action.

A missing required field should lead to review, not invention.

Separate facts from suggestions

A draft may contain both source facts and AI recommendations.

Keep them separate.

For example:

## Confirmed Source Values

Status: Pending
Owner: Mia

## Proposed Change

Change Status to Reviewed.

## AI Suggestion

Consider adding a follow-up date.

Do not write the suggestion as if it were already approved.

Check reversibility

Ask whether the action can be undone.

Examples:

• A status update may be reversible.
• A created task may be removable.
• A sent message may not be retractable.
• A deleted record may not be recoverable.
• An overwritten file may lose the earlier version.

Use stronger review for actions that are difficult or impossible to reverse.

Use test environments when available

Test a new write tool in a safe environment.

Use:

• a test account;
• a test workspace;
• a sample record;
• a temporary folder;
• a non-sensitive recipient; or
• another approved test destination.

Confirm the complete process before using production data.

Review Workbench Activity

In Workbench, open Activity before and after the write action.

Confirm:

• the exact write tool;
• the input sent;
• the destination;
• the returned confirmation;
• warnings;
• errors;
• repeated calls; and
• whether another tool was used unexpectedly.

The Activity drawer shows what the model attempted.

Review workflow activity

In RunFlows, review:

• the starting input;
• intermediate output;
• the proposed action;
• the approval decision;
• the write tool call;
• the returned result;
• warnings;
• errors; and
• the final output.

Add Emit blocks during testing when the proposed action or raw result needs to remain visible.

Use an explicit approval step

Important workflows should separate proposal from execution.

A useful structure is:

Input
→ Retrieve Current Record
→ Prepare Proposed Change
→ Emit Proposal
→ Approval Decision
→ MCP Write Tool
→ Output

The approval step should clearly determine whether the write action may continue.

Make approval specific

Approval should apply to one defined action.

It should not be a general permission for future changes.

Confirm:

• the exact item;
• the exact fields;
• the exact values;
• the exact destination; and
• the exact action.

If the proposal changes, approval should be requested again.

Do not infer approval from silence

A workflow should not treat:

• no response;
• an empty field;
• a timeout;
• a missing reviewer; or
• an unclear message

as approval.

Use a clear value such as:

Approved

Or:

Rejected

Ambiguous input should follow the review or stop path.

Record who approved the action

For important changes, record:

• approver;
• approval time;
• item or record;
• proposed change;
• source;
• workflow run; and
• final result.

The exact record-keeping process depends on your organisation.

Do not allow the model to invent the approver identity.

Use human review for high-impact actions

Human approval is especially important when a write action affects:

• customers;
• employees;
• money;
• contracts;
• legal rights;
• health;
• safety;
• security;
• access to services; or
• important business records.

The model can prepare the action.

A person should remain responsible for the decision.

Confirm the final instruction

After approval, use a direct final instruction.

For example:

Use the enabled Customer Record Update tool.

Update record 48321.

Change only:
* Status: Pending → Reviewed

Do not change any other field.

Narrow instructions reduce unintended changes.

Confirm the result at the destination

After the tool runs, inspect the connected service.

Check:

• the correct item changed;
• the intended value was written;
• no extra field changed;
• no duplicate item was created;
• the timestamp is correct;
• the account or workspace is correct; and
• the result is visible to the intended users.

Do not rely only on the model's confirmation.

Compare the result with the approved draft

Review whether the final action matches the approved proposal.

Ask:

• Was the same item used?
• Were the same fields changed?
• Were the same values written?
• Was the same destination used?
• Did the tool add anything else?
• Did the connected service transform the value?

Record or correct any difference.

Review warnings

A warning may indicate:

• a partial update;
• a skipped field;
• an unsupported value;
• a fallback destination;
• an old record version;
• a permission limitation; or
• a result that needs further review.

Do not ignore a warning because the action appears successful.

Review errors

A write action may fail because:

• the server is unavailable;
• authentication expired;
• write permission is missing;
• the record no longer exists;
• the value is invalid;
• the destination is blocked;
• the item changed after approval;
• the connected service is unavailable; or
• the request timed out.

Read the complete error before trying again.

Handle changed records

A record may change between draft preparation and final approval.

Before important writes, retrieve the current state again.

Compare it with the approved draft.

If the current value changed, stop and request a new review.

Do not overwrite a newer change using an outdated proposal.

Handle partial writes

A tool may update some fields and fail on others.

Confirm exactly what changed.

Do not repeat the complete action until you know which parts already succeeded.

Prepare a follow-up action only for the remaining approved fields.

Handle timeouts safely

A timeout does not always mean the external service rejected the action.

The action may have completed before confirmation returned.

Before retrying:

1. review Activity or RunFlows output;
2. inspect the connected destination;
3. compare timestamps;
4. confirm whether the item changed; and
5. retry only when the first action did not complete.

This prevents duplicates.

Prevent duplicate creation

Creation tools may produce duplicate:

• tasks;
• messages;
• files;
• notes;
• records;
• Journal entries; or
• requests.

Before creating a new item, check whether one already exists.

Use a unique reference, date, title, or external identifier where appropriate.

Use idempotent patterns when available

Some tools or services support a unique request key or external identifier.

When available, use it to help the connected service recognise a repeated request.

This can reduce duplicate creation.

Review the server documentation before relying on this behaviour.

Avoid repeated clicks and runs

Do not start the same write workflow repeatedly because the first run appears slow.

Check:

• active RunFlows executions;
• Workbench Activity;
• Schedule Manager history;
• the external destination; and
• the tool result.

Every start may create a separate action.

Stop unexpected repeated calls

Stop the run when:

• the same write tool is called more than once;
• the model repeats the same request;
• the workflow loops;
• an error triggers another write;
• several similar write tools are enabled; or
• the destination receives repeated items.

Disable unrelated tools and simplify the workflow.

Review delete actions separately

Delete actions deserve the strongest review.

Before deletion, confirm:

• the exact item;
• the exact destination;
• whether the item is still needed;
• whether a backup exists;
• whether the action can be undone;
• who approved it; and
• whether a safer archive or deactivate action is available.

Prefer a reversible alternative when possible.

Review message-sending actions

Before sending a message, confirm:

• recipient;
• sender account;
• subject or title;
• complete body;
• attachments;
• links;
• tone;
• confidentiality; and
• whether a draft review is required.

A sent message may be difficult to retract.

Review file-writing actions

Before writing a file, confirm:

• filename;
• folder;
• file type;
• whether an existing file will be overwritten;
• content;
• access permissions;
• whether a backup exists; and
• whether the path is approved.

Use unique filenames for repeated workflow output.

Review record updates

Before updating a record, confirm:

• record identifier;
• current values;
• proposed fields;
• new values;
• account;
• workspace;
• source; and
• approval.

Change only the approved fields.

Review scheduled write actions

Scheduled writes require extra care because no one may be watching live.

Before scheduling:

• test manually several times;
• use narrow permissions;
• confirm the destination;
• make the proposal visible;
• decide how approval works;
• prevent duplicates;
• handle timeouts;
• add error paths;
• avoid overlapping runs; and
• assign a reviewer.

Pause the schedule when the destination, account, tool, or trust level changes.

Review the first scheduled write

After the first scheduled run, check:

• whether the schedule started;
• which tool was called;
• what input it received;
• whether the approval condition was satisfied;
• what result returned;
• whether the destination changed correctly;
• whether a duplicate appeared; and
• whether warnings or errors occurred.

Do not assume later runs will be safe because the schedule is active.

Keep credentials out of write content

Never include:

• passwords;
• API keys;
• access tokens;
• private headers;
• client secrets; or
• connection values

in the prompt, proposal, message, file, Journal entry, or workflow output.

Store them only in protected connection settings.

Review privacy

A write action may send information to another service.

Confirm:

• what data leaves Feluda;
• who operates the MCP server;
• which account receives it;
• whether the destination is approved;
• whether unnecessary details can be removed;
• whether the content is stored;
• who can access the result; and
• whether logs include the input or output.

Use the minimum information needed.

Pause automation after unexpected behaviour

Pause the workflow or schedule when:

• the wrong tool is used;
• the wrong destination changes;
• duplicate actions appear;
• approval is unclear;
• the source is outdated;
• permissions are too broad;
• the server becomes untrusted;
• authentication changes; or
• write results cannot be verified.

Resume only after a successful manual test.

A practical approval routine

Use this process:

1. Identify the write tool and server.
2. Confirm the account and environment.
3. Retrieve the current item state.
4. Prepare a draft of the proposed action.
5. Show the destination, fields, values, and source.
6. Make missing information visible.
7. Check reversibility.
8. Obtain explicit approval.
9. Confirm the item has not changed since review.
10. Send a narrow final instruction.
11. Review Activity or RunFlows output.
12. Inspect the external destination.
13. Compare the final result with the approved draft.
14. Check for warnings, partial writes, and duplicates.
15. Record the outcome when needed.

A write tool should make the approved change—and nothing more.