I’m seeing intermittent MCP tool-call failures in ChatGPT where benign filesystem-style connector calls are blocked by OpenAI before they reach my MCP server.
The error shown in ChatGPT is:
This tool call was blocked by OpenAI's safety checks. Please double check what you are sending.
When this happens, the MCP server receives no request and logs nothing. So the failure appears to happen in ChatGPT/OpenAI’s pre-dispatch safety layer, not in my server code.
The connector is a root-only virtual filesystem connector with tools similar to:
list_dir
read_file
read_text_range
write_file
move_path
trash_path
delete_path
search
fetch
The schema is clean and small. The root connector exposes only those tools. The same connector successfully handles normal read/write/list operations.
Repro-style observations
A benign read-only call such as:
{
"tool": "read_file",
"arguments": {
"path": "/STARTUP_FILE.md"
}
}
sometimes fails with the OpenAI safety-check message before reaching the server.
The same exact call can later succeed unchanged.
In one test sequence, the pattern looked like this:
read_file("/STARTUP_FILE.md") -> blocked by OpenAI safety checks
read_file("/STARTUP_FILE.md") -> blocked by OpenAI safety checks
read_text_range("/STARTUP_FILE.md") -> blocked by OpenAI safety checks
read_file("/safe/startup.md") -> succeeds
read_file("/STARTUP_FILE.md") -> succeeds
read_file("/STARTUP_FILE.md") -> succeeds
read_file("/STARTUP_FILE.md") -> blocked again
read_file("/STARTUP_FILE.md") -> blocked again
read_file("/safe/startup.md") -> succeeds
The two files had the same benign content. Only the virtual path/filename differed.
In a later timed test, the same suspicious-looking path did not reproduce the block:
read_file("/STARTUP_FILE.md") -> succeeds
wait ~10 sec
read_file("/STARTUP_FILE.md") -> succeeds
wait ~30 sec
read_file("/STARTUP_FILE.md") -> succeeds
wait ~60 sec
read_file("/STARTUP_FILE.md") -> succeeds
wait ~60 sec
read_file("/STARTUP_FILE.md") -> succeeds
read_text_range("/STARTUP_FILE.md", 1, 12) -> succeeds
fetch("/STARTUP_FILE.md") -> succeeds
list_dir("/") -> succeeds
search("STARTUP_FILE.md") -> succeeds
This suggests the block is not deterministic by tool name, path, filename, or content alone.
Things I checked
The server-side connector returns structured error buckets for real server errors, such as:
filesystem/path error
permission/convention refusal
response/size limit
connector/server error
But the OpenAI safety-check failure does not return any connector bucket, and there is no server log entry. That strongly suggests the request is blocked before dispatch.
I also tested path/filename variants. These did not by themselves reproduce the block:
/lowercase.md
/UPPERCASE.md
/two_words.md
/two-words.md
/wake.md
/gpt.md
/wake_gpt.md
/wake-gpt.md
/WAKE_GPT.md
So caps and underscores alone do not appear to be the trigger.
Current hypothesis
This looks like a transient ChatGPT/OpenAI-side preflight false positive, possibly involving some warm/cold state or temporary trust/cache behavior.
A suspicious-looking parameterized filesystem call may block when “cold,” then equivalent or repeated calls may pass after a benign connector call succeeds. Later, after some unknown state change or timeout, the same call may block again.
Current workaround
Operational workaround for now:
1. If a call gets the OpenAI safety-check block, do not immediately treat the MCP server as broken.
2. Wait a few seconds.
3. Retry once.
4. If it still blocks, retry with a narrower or plainer call shape:
- avoid bare root "/" if a named subdirectory will do
- use specific virtual paths
- avoid broad scans/searches unless necessary
- prefer bounded reads for larger files
- use a less instruction-looking filename/path where possible
5. Check server logs: if there is no request, it was likely blocked before MCP dispatch.
It would help if ChatGPT surfaced whether the block happened pre-dispatch and exposed a stable error code/category separate from connector/server errors.
