Preventing Accidental Writes in MCP: Confirmation Prompts That Work

Worried about assistants accidentally creating, updating, or deleting tasks? This safety playbook provides reusable prompt templates that force a preview and explicit confirmation token before any write tool is invoked. Learn patterns that prevent unintended changes while keeping workflows efficient.

Why Write Safety Matters

MCP tools can modify data (create, update, delete). Without proper safeguards, assistants might make unintended changes:

Risks of Unprotected Writes

• Creating duplicate tasks
• Updating wrong tasks
• Deleting important tasks
• Adding comments to wrong items
• Changing statuses unintentionally

Benefits of Write Safety

• Prevents accidental data loss
• Gives you control over changes
• Builds trust in automation
• Enables audit trails
• Reduces rollback needs

Core Safety Pattern: Preview + Confirmation

The most effective pattern combines two steps:

Two-Step Safety Pattern

1. Preview: Show what will be created/updated/deleted
2. Confirmation: Require explicit confirmation token before proceeding

Basic Template

"Before creating/updating/deleting anything:
1. Show me what you plan to do (preview)
2. Wait for my explicit confirmation
3. Only proceed if I say 'CONFIRM' or 'YES, CREATE TASK'"

This pattern forces the assistant to show you the plan first.

Confirmation Token Patterns

Use explicit confirmation tokens that are hard to trigger accidentally:

Strong Confirmation Tokens

Good Confirmation Tokens

• CONFIRM - Simple and clear
• YES, CREATE TASK - Action-specific
• PROCEED WITH UPDATE - Explicit intent
• APPROVE - Formal confirmation
• EXECUTE - Clear action signal

Weak Confirmation Tokens (Avoid)

Weak Tokens

• yes - Too short, easy to trigger accidentally
• ok - Too casual, ambiguous
• sure - Not explicit enough
• go - Too generic

Safety Patterns by Tool

1. create_task Safety Pattern

Safe Create Task Template

"I want to create a task. Before creating it:
1. Show me the task details you'll create (title, description, project, due date)
2. Wait for my confirmation
3. Only call create_task if I explicitly say 'CONFIRM' or 'YES, CREATE TASK'
4. If I don't confirm, don't create anything"

This ensures you see what will be created before it happens.

Example Workflow

1. User: "Create a task for implementing user authentication"
2. Assistant: Shows preview with title, description, project
3. User: Reviews preview
4. User: "CONFIRM"
5. Assistant: Calls create_task with the confirmed details

2. update_task Safety Pattern

Safe Update Task Template

"Before updating any task:
1. Read the current task details first (use get_task)
2. Show me what will change (before/after diff)
3. Wait for my explicit confirmation
4. Only call update_task if I say 'CONFIRM' or 'YES, UPDATE TASK'
5. If I don't confirm, don't update anything"

This shows you exactly what will change before updating.

Example: Status Update

Preview Format:

• Task: Implement user authentication (ID: 12345)
• Current Status: open
• New Status: in_progress
• Other Changes: None

Say 'CONFIRM' to proceed with this update.

3. delete_task Safety Pattern

Extra Caution for Deletes

"Before deleting any task:
1. Read the task details first (use get_task)
2. Show me the task title, description, and current status
3. Warn me that deletion is permanent
4. Wait for my explicit confirmation
5. Only call delete_task if I say 'YES, DELETE TASK' (exact phrase)
6. If I say anything else, don't delete"

Deletes are irreversible, so use the strongest confirmation.

4. add_task_comment Safety Pattern

Safe Add Comment Template

"Before adding a comment to any task:
1. Read the task details first (use get_task)
2. Show me the comment you'll add
3. Show me which task it will be added to (task ID and title)
4. Wait for my confirmation
5. Only call add_task_comment if I say 'CONFIRM' or 'YES, ADD COMMENT'"

Comments are less risky but still worth previewing.

Advanced Safety Patterns

Pattern 1: Read-First Workflow

Read Before Write

"Always read the current state before making changes:
1. Use get_task to read task details
2. Use list_tasks to verify task exists
3. Show me what you found
4. Then propose changes
5. Wait for confirmation before writing"

This prevents acting on wrong or outdated information.

Pattern 2: Diff Preview

Show Before/After

"Before updating, show me a diff:
- Title: 'Old Title' → 'New Title'
- Status: 'open' → 'in_progress'
- Description: [unchanged]

Say 'CONFIRM' to apply these changes."

Visual diffs make changes clear and reviewable.

Pattern 3: Batch Confirmation

Multiple Changes

"If making multiple changes:
1. Show me all changes in a list
2. Number each change
3. Ask me to confirm all at once: 'Say CONFIRM ALL to proceed with all changes'
4. Or let me approve individually: 'Say CONFIRM 1, 2, 3 to approve specific changes'"

Batch operations need clear confirmation of scope.

Reusable Prompt Templates

Template 1: Universal Write Safety

"IMPORTANT: Before calling any write tool (create_task, update_task, delete_task, add_task_comment):
1. Show me a preview of what will happen
2. Wait for my explicit confirmation
3. Only proceed if I say 'CONFIRM' or a similar explicit confirmation token
4. If I don't confirm, don't call the write tool"

Add this to the start of any workflow that might write data.

Template 2: Task Creation Safety

"When creating tasks:
1. Show me the task details (title, description, project, due date, status)
2. Ask: 'Review the task above. Say CONFIRM to create it, or tell me what to change.'
3. Only call create_task after I say 'CONFIRM'
4. If I request changes, update the preview and ask again"

Template 3: Task Update Safety

"When updating tasks:
1. First, read the current task (use get_task with task_id)
2. Show me what will change in a before/after format
3. Ask: 'Review the changes above. Say CONFIRM to apply them, or tell me what to change.'
4. Only call update_task after I say 'CONFIRM'
5. If I request changes, update the preview and ask again"

Template 4: Delete Safety (Extra Strong)

"When deleting tasks:
1. First, read the task (use get_task with task_id)
2. Show me: task title, description, current status, and creation date
3. Warn: '⚠️ This will permanently delete the task. This action cannot be undone.'
4. Ask: 'Type YES, DELETE TASK (exact phrase) to confirm deletion.'
5. Only call delete_task if I type the exact phrase 'YES, DELETE TASK'
6. If I say anything else, do not delete"

Best Practices

1. Always Preview First

Never call write tools without showing a preview first. Users need to see what will happen.

2. Use Strong Confirmation Tokens

Require explicit, action-specific tokens like "CONFIRM" or "YES, CREATE TASK". Avoid weak tokens like "yes" or "ok".

3. Read Before Write

Always read the current state (get_task, list_tasks) before making changes. This prevents acting on wrong data.

4. Show Context

Include task IDs, titles, and current values in previews. Context helps users make informed decisions.

5. Use Stronger Tokens for Destructive Actions

Deletes require the strongest confirmation (exact phrase match). Updates can use simpler tokens.

6. Allow Changes Before Confirmation

If the user wants to modify the preview, update it and ask for confirmation again. Don't force them to confirm as-is.

Quick Safety Checklist

Before Using Write Tools

• ✅ Added preview step before any write operation
• ✅ Required explicit confirmation token (CONFIRM, YES, CREATE TASK, etc.)
• ✅ Read current state before updating (get_task, list_tasks)
• ✅ Showed context (task IDs, titles, current values)
• ✅ Used stronger tokens for destructive actions (deletes)
• ✅ Allowed user to modify preview before confirming
• ✅ Tested the workflow to ensure confirmation is required

Related Resources

• Least-Privilege Workflows - Learn more about safe write patterns
• API Keys & Security - Secure your MCP integration with proper API key management
• MCP Quickstart - Learn effective prompting and setup patterns for MCP tools
• Troubleshooting Index - Browse all troubleshooting guides