Hi — I found your Python MCP Filesystem Server while looking at MCP projects where agent file operations may need evidence that survives outside the original local runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected agent actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace your server’s path validation, permission controls, logs, MCP responses, or normal filesystem state. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
Your repo seemed relevant because it allows AI clients to read, write, move, delete, search, and inspect files through MCP while enforcing allowed paths, file-type limits, validation, and local configuration.
A receipt could potentially bind selected high-impact operations like:
write_file;edit_file;move_file;delete_file;create_directory;- target project-relative path;
- pre-operation file hash if available;
- post-operation file hash if available;
- privacy-preserving argument/result digest;
- allowed-path/config policy hash;
- operation status;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when an AI-made file change, deletion, move, generated artifact, or filesystem operation result is handed to another person, reviewer, CI job, or external workflow, and they should not have to fully trust the original local MCP runtime.
BoundaryAttest would not prove the file operation was correct, safe, authorized, or desirable. It would only prove that a specific filesystem-operation claim was signed and has not been altered after the handoff.
Does that kind of portable signed receipt fit any workflow you imagine for this filesystem MCP server, or are normal MCP responses and local logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around MCP filesystem tools.
Hi — I found your Python MCP Filesystem Server while looking at MCP projects where agent file operations may need evidence that survives outside the original local runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected agent actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace your server’s path validation, permission controls, logs, MCP responses, or normal filesystem state. The receipt only proves a narrow claim:
Your repo seemed relevant because it allows AI clients to read, write, move, delete, search, and inspect files through MCP while enforcing allowed paths, file-type limits, validation, and local configuration.
A receipt could potentially bind selected high-impact operations like:
write_file;edit_file;move_file;delete_file;create_directory;The strongest use case would be when an AI-made file change, deletion, move, generated artifact, or filesystem operation result is handed to another person, reviewer, CI job, or external workflow, and they should not have to fully trust the original local MCP runtime.
BoundaryAttest would not prove the file operation was correct, safe, authorized, or desirable. It would only prove that a specific filesystem-operation claim was signed and has not been altered after the handoff.
Does that kind of portable signed receipt fit any workflow you imagine for this filesystem MCP server, or are normal MCP responses and local logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around MCP filesystem tools.