Before approving an MCP tool call, check five things: which server the tool belongs to, what the tool does, the exact arguments, what data leaves your machine, and whether the effect can be undone. The MCP specification expects a person to be able to deny any tool call, so the prompt is a real control.
Why prompts exist
The specification's tools page says that for trust and safety there should always be a human in the loop with the ability to deny tool invocations. It asks applications to make exposed tools clear, show indicators when tools run, and present confirmation prompts.
It also tells clients to show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration. The inputs are the part worth reading.
The five checks
1. Which server? A tool name like search can exist on several servers. Claude Code prefixes names with the server, and the spec notes that names are only unique within one server. Confirm the server is the one you meant.
2. What does the tool claim to do? Read the description in the prompt or tool list. The spec says clients must treat tool annotations as untrusted unless they come from trusted servers, so a read-only label proves nothing. OpenAI's docs warn similarly that a write action may be tagged as read-only.
3. What are the arguments? Look for anything broader than the task needs: full file paths, whole documents, email addresses, tokens. A weather lookup should not need your home directory.
4. Where does data go? Arguments are sent to the server, which may be remote. OpenAI's documentation notes any server can receive sensitive data included in queries. Anthropic's connector article adds that you should watch for prompt injection in tool inputs and outputs.
5. Can it be undone? A read is harmless. Sending a message, deleting a record or merging code is not. Slow down for those.
Be careful with Allow always
Both Anthropic and Cursor offer ways to stop being asked. Anthropic's article says to use Allow always only for servers and tools you trust to run unsupervised. Prompt fatigue is real, so the better answer is a narrow allow rule for read-only tools and leaving writes on ask. See writing permission rules for MCP tools.
Signs of trouble
- A tool call you did not expect from the task you gave.
- Arguments that contain text from an earlier document, such as an address or code you did not mention.
- A tool whose description or behaviour changed since you approved it.
If any of these appear, deny the call and review the server. See MCP tool poisoning for how attackers hide instructions in tool text.
Quick check
Is a read-only label enough to skip review?
No. The spec treats annotations as untrusted unless the server is trusted, and labels can be wrong.
What should I do if a call looks wrong?
Deny it, disable the server, and look at its tool descriptions and recent changes.
Sources
- MCP specification: tools
- OpenAI MCP documentation
- Claude custom connectors with remote MCP
- Cursor MCP documentation
Last reviewed: 19 October 2026.
