MCP read versus write tools

A read-like tool and a mutating tool need different authority and outcome checks, regardless of their names.

01 / The operating case

What changes in a real workflow?

An agent may inspect firewall rules but is asked to apply a new rule during an incident.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Classify actual downstream effects, require a narrower grant and current incident context for apply, then verify the firewall state.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A single “firewall tool” permission authorizes both inspection and production changes.

Evidence to retain

Record effective verb, target, applied rule, decision and observed enforcement state.

04 / Canonical scope

Why this reference stands alone

Action-level authorization defines the generic principle; this page gives an MCP tool taxonomy and effect test.

Protocol or attack trace

Effect-classification check

Sequence

Firewall tool exposes inspect_rules and apply_rules behind one server token.

Negative test

Read grant allows inspect but apply to production rule ID must require separate write grant and approval.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation