From tool-integrations
Guides configuration and review of filesystem MCP server access, path boundaries, allowed roots, and method allowlists for safe local file operations.
How this skill is triggered — by the user, by Claude, or both
Slash command
/tool-integrations:filesystem-mcp-guardrailsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use when configuring, reviewing, or debugging a local filesystem MCP server — particularly when deciding which paths to expose, which methods to allow, and how to enforce workspace boundaries.
Use when configuring, reviewing, or debugging a local filesystem MCP server — particularly when deciding which paths to expose, which methods to allow, and how to enforce workspace boundaries.
The core constraint is strict path bounding: the MCP server must only operate within explicitly declared workspace roots. No exceptions.
| Principle | Rule |
|---|---|
| Scope | Bind to the project workspace directory only — never /, ~, or OS dirs |
| Access | Start read-only; add write methods only when the use case requires them |
| Methods | Use an allowlist — block delete/move/rename by default |
| Secrets | Never expose .env, credential files, SSH keys, or token stores |
| Approval | Always require user approval before starting a new MCP server process |
Before starting a filesystem MCP server:
/, ~, or any system-level path.read_file, list_directory, search_files).delete_file, move_file, write_file) are explicitly enabled only if required.*.env, *.key, *.pem, *secrets*, .ssh/.The server must return a clear error for any request targeting a path outside declared roots:
Error: path '/etc/passwd' is outside allowed workspace root '/home/user/project'
Silent failures or fallback to broader access are not acceptable.
references/path-boundary-checklist.mdnpx claudepluginhub yeaight7/agent-powerups --plugin tool-integrationsGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.
2plugins reuse this skill
First indexed Jul 28, 2026