The most useful question in an MCP review is often a simple one: what can happen if this tool is called?
Reading is a real disclosure
A read-only message server cannot contact a recipient through that interface. It can still return private text, participants and attachments to the client. Restrict the date range and conversation scope to what the task needs.
Local execution is only one part of the data journey. A cloud-connected assistant may include tool results in a model request; review that path as well as the local server.
Sending can exist without history
The send-only project in this edition uses macOS automation without reading chat.db. This narrows the database permission requirement, but it also means the assistant cannot obtain the conversation through that tool.
Provide verified context separately and show the destination and final text before executing a send. A narrow interface does not prevent an application from choosing the wrong recipient.
Check optional actions independently
Some local projects expose reactions, deletion, edits or unsend actions through additional flags. Their confirmation behavior can differ by operation. Never assume a batch preview protects a separate individual-delete tool.
The tszaks repository describes experimental UI actions and optional mutation features. Read the current flag documentation and leave unnecessary powers disabled during the first evaluation.
Enforce approval outside a sentence
A tool description asking an assistant to confirm is an instruction. An approval token or client-side permission gate is a different control. Identify which mechanism the actual workflow relies on.
For a consequential send, preserve the approved recipient and message as concrete data and reject changes after approval. The application should own that rule rather than trying to infer approval from conversational tone.