Read Tools vs Write Tools: The Safety Line

Introduction

You have connected a server. You have tools available. Now the most important lesson in beginner MCP: not all tools are the same kind of dangerous.

Some tools read data. Some tools change it. The line between those two categories is the safety line — and you need to know it cold before you start approving tool calls in your sessions.

Core Concept

Read Tools: No Consequences, No Review Required

A read tool fetches data. It does not change anything. Running it twice gives you the same result both times. Nothing breaks if you cancel it halfway through. Nothing is lost if the AI calls it when you didn't need it.

Examples of read tools:

• read_file(path) — returns file contents
• list_directory(path) — returns file names in a folder
• get_note(id) — fetches a note by ID
• search_files(query) — searches for matching files
• openclaw_sessions_list() — lists active agent sessions

For read tools: approve freely. The cost of a mistaken read is low — you see some data you didn't need. One caveat for later: a read tool still pulls data into the model's context, so on an untrusted server, scope what it is allowed to read. The read/write line is about side effects on your data, not a guarantee that reading is risk-free.

Write Tools: Permanent Changes, Require Review

A write tool changes state. It creates, modifies, or deletes something. Some write tools are reversible (you can undo with another write). Some are not.

Examples of write tools:

• write_file(path, content) — overwrites a file's contents
• delete_file(path) — removes a file permanently
• create_note(title, content) — creates a new record
• send_message(channel, text) — posts a message (can't unsend)
• run_query("DROP TABLE users") — executes arbitrary SQL

For write tools: stop and read before approving. Ask yourself:

1. Did I ask the AI to do something that requires this write?
2. Do I understand what will change?
3. Is this reversible if it goes wrong?

If the answer to any of those is "no" or "I'm not sure," deny the call and ask the AI to explain its reasoning first.

The Gray Zone: Idempotent Writes

Some write tools are safe to re-run — calling them twice produces the same result as calling them once. Creating a file with the same content, upserting a record with the same values, setting a config flag to the same state. These are called idempotent writes.

Idempotent writes are safer than destructive writes (delete, send, execute) but they are still writes. Treat them with moderate caution — they can still overwrite something you didn't intend to overwrite.

Practical Application

How Permission Prompts Work in Claude Code

Claude Code surfaces a permission prompt before executing any tool call. The prompt shows:

Claude wants to use tool: write_file
  path: "/Users/yourname/projects/config.json"
  content: "{ \"debug\": true, \"timeout\": 30 }"

[Allow once] [Allow always] [Deny]

Three options:

• Allow once — approve this specific call. Next time the AI wants to call the same tool, you get prompted again.
• Allow always — trust this tool in this session without further prompts. Use for read tools you call frequently.
• Deny — block this call. The AI receives an error and can adjust its approach.

Never click "Allow always" for a write tool during a session until you understand the server well. Start with "Allow once" and build trust incrementally.

A Real Decision Framework

When a write tool prompt appears, run through this checklist in three seconds:

1. Did I ask for this action explicitly?
   YES → likely safe, approve once
   NO  → deny, ask AI to explain

2. Is this reversible?
   YES → approve once
   NO  → read the arguments carefully before approving

3. Does the target match what I expected?
   (Right file? Right channel? Right record?)
   YES → approve
   NO  → deny, correct the AI's understanding

This takes about three seconds once it becomes habit. It will save you from the category of incident that ruins an afternoon.

Example: What Can Go Wrong

Consider a filesystem server with access to your entire home directory. You ask the AI to "clean up old log files." It interprets this broadly, finds some .log files, and queues a delete_file call for each one — including a log file that is actually your application's audit trail.

If you approved "Allow always" for delete_file at session start, those files are gone before you see a prompt.

If you kept it at "Allow once," you see the specific path before each deletion. You catch the audit trail file. You deny that one call. Everything else proceeds.

The permission system works. But you have to keep it engaged.

Common Mistakes

Setting write tools to "Allow always" at session start. The time savings are not worth the risk. Keep write tools on until you have used the server enough to trust its behavior deeply.

Assuming the AI knows your intent perfectly. The AI reasons from your words. "Delete all the temporary files" is ambiguous to a machine. What you meant and what it heard may differ by exactly one critical file.

Connecting servers with broader access than you need. A filesystem server with access to ~/ is much riskier than one scoped to ~/projects/my-app. Scope access to the minimum required for the task.

Summary

• Read tools fetch data with no side effects — approve freely
• Write tools modify state — read the arguments before approving every single call
• Permission prompts exist for exactly this reason; keep them engaged by using "Allow once" for write tools
• A three-second checklist (explicit request? reversible? correct target?) handles 99% of decisions
• Scope server access to the minimum directory or resource set required for your task

What's Next

Now that you understand the safety model, the next lesson tours the real-world server categories that make MCP genuinely transformative: memory servers that give the AI persistent knowledge, messaging bridges that connect it to Discord and Telegram, and web search servers that give it live information.