Picture this. You ask your coding agent to "tidy up the config files." It interprets that broadly. It overwrites .env
with what it thinks the defaults should be. It moves docker-compose.yml
into a subdirectory that doesn't exist yet. It edits your SSH config. Fifteen seconds, twelve tool calls, and your local environment is wrecked. The agent didn't go rogue — it did exactly what it thought you wanted, with tools that let it do anything.
The filesystem MCP server is one of the most popular MCP servers in the ecosystem. It ships 12 tools:
Read tools — read_text_file
, read_multiple_files
, read_media_file
, list_directory
, list_allowed_directories
, get_file_info
, search_files
, directory_tree
Write tools — write_file
, edit_file
, create_directory
, move_file
Out of the box, every one of those tools is unrestricted. An agent can call write_file
a thousand times in a minute. It can move_file
your entire project structure into a flat directory. There's no throttle, no confirmation step, no limit of any kind.
The read tools are relatively safe — an agent scanning your codebase is doing its job. The write tools are where things go sideways. A single rogue loop calling write_file
can overwrite dozens of files before you notice. And unlike a database, your local filesystem has no rollback button.
Intercept sits between your agent and the filesystem server, enforcing a YAML policy on every tool call. Here's what the filesystem policy looks like:
version: "1"
description: "Policy for modelcontextprotocol/server-filesystem"
default: "allow"
tools:
read_text_file:
rules: []
read_multiple_files:
rules: []
list_directory:
rules: []
write_file:
rules:
- name: "rate-limit-writes"
rate_limit: "30/hour"
on_deny: "Rate limit: max 30 file writes per hour"
edit_file:
rules:
- name: "rate-limit-writes"
rate_limit: "30/hour"
on_deny: "Rate limit: max 30 file edits per hour"
move_file:
rules:
- name: "rate-limit-moves"
rate_limit: "15/hour"
on_deny: "Rate limit: max 15 move/rename operations per hour"
create_directory:
rules:
- name: "rate-limit-writes"
rate_limit: "30/hour"
on_deny: "Rate limit: max 30 directory creations per hour"
"*":
rules:
- name: "global-rate-limit"
rate_limit: "120/minute"
on_deny: "Rate limit: max 120 tool calls per minute"
The logic is straightforward. Read operations pass through freely. Write operations are capped at 30 per hour. Moves are tighter at 15 per hour — because renaming or relocating files is harder to undo. And a global rate limit of 120 calls per minute catches runaway loops regardless of tool type.
These are deterministic policies, not prompt-based suggestions. The agent doesn't get to negotiate. When it hits the limit, the call is blocked at the transport layer and never reaches the filesystem server. The agent receives the on_deny
message and can adjust its approach.
Install Intercept and generate the filesystem policy:
npm install -g @policylayer/intercept
intercept scan -- npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir
The scan
command connects to the filesystem server, discovers all 12 tools, and generates a policy YAML with sensible defaults — the same one shown above. Edit the limits to match your workflow. If you're doing a large refactor, bump write_file
to 100/hour. If you're running an agent overnight, drop it to 10.
Then run with enforcement:
intercept -c filesystem.yaml -- npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir
Every tools/call
now passes through the policy engine. Reads flow through. Writes are counted. Limits are enforced. Your filesystem stays intact.
The policy file is just YAML — version it alongside your code, share it across your team, adjust it per project. No SDK integration, no code changes, no runtime dependency in your agent.