One critical point when working with the MCP server -
It does request permission when suggesting its plans. Usually it is spot-on and has ideas that are more efficient than my requests.
**However it did make a request today to “write file to my dtBase2 folder"!
**
Clearly that could be a disaster. I replied no and created a strict rule in the project - which I will include in all future projects - to ONLY write to a DT database via the MCP server or via Applescript that I approve and never to add files directly to a Devonthink database. That should be Rule 1 for any AI workflow with Devonthink access.
I am assessing if I can modify the open source MCP server to preclude direct modification to a database file.
Claude suggests the issue may be at a more fundamental level with Cowork. Is this correct?
Is this something I can do or is it fundamentally something that is much better achieved with a Devontech-written MCP?
Interesting — the filesystem MCP is already restricted to only /Users/richardkaplan/Downloads. So it can’t directly reach the .dtBase2 files through that tool.
The violations are actually coming through other paths:
request_cowork_directory — which prompts you to grant folder access (that’s the dialog you’ve been seeing)
mcp__Control_your_Mac__osascript — running shell commands like cat or pdftotext against .dtBase2 internal paths
Bash tool in the sandbox
The filesystem MCP itself isn’t the problem. The real vectors are:
request_cowork_directory — this is a Cowork-level tool that can request access to any folder. There’s no way to add a deny-pattern to it that I’m aware of.
osascript do shell script — the sessions use AppleScript’s do shell script to run arbitrary commands, which can touch any path on disk.
A true MCP-level fix would mean either: (a) a custom wrapper around the DEVONthink MCP that intercepts and blocks any path containing .dtBase2, or (b) a Keyboard Maestro macro or filesystem permission that makes the .dtBase2 internal files unreadable to shell commands.
The most practical technical hardening would be a simple Keyboard Maestro macro that monitors for do shell script calls targeting .dtBase2 paths and blocks them. Want me to explore that?
Only Anthropic could confirm this. But LLMs are trained to deliver a result, therefore they return hallucinations instead of just saying they don‘t know. And likewise they try to bypass limitations (or to ignore user instructions). In the end all of this is neither deterministic nor 100% reliable - frequently it works but also fails miserably every then and now.
Is it possible somehow at the operating system level to restrict Applescript / JXA / Bash write access to Devonthink database files directly rather than by the accepted script functions?
The failures to achieve a task do not bother me - the success happens often enough to make it well worthwhile.
What is essential though is that a fail does not destroy my database by directly altering the database files.
Only option coming to my mind is to deny all automation requests, see System Settings > Privacy & Security > Automation > Claude.app. Or to use DEVONthink‘s chat assistant. But MCP is insecure by design, IMHO, and Claude Cowork is still a preview.
There are indeed options to make an MCP server more secure, e.g. by not returning paths by default or only for indexed items or only on demand using a dedicated tool which can be blocked or requires user confirmation. Of course Claude shouldn’t be allowed to automate DEVONthink too.
Unless I’m misreading you, I did exactly this a few weekends ago using the existing open source MCP. I fed it to CC and asked it do a security assessment and remove the write functions to DT.
It was fairly easy for CC to do, from what I could tell as it churned away, and it meant of course it only had read access. I played around with it a bit more, broke it, couldn’t get it work again (my fault, and I was losing patience with CC) and ended up deleting it. It was then I discovered the AI Document Assistants under Data → New from Template.
I had planned on revisiting it at some point, but not sure not after Christian’s tease earlier.
Claude does indeed have a configuration section where you can decide what tools the DT open source MCP server can use and whether permission is required for each use.
The concern I am raising is that Claude can alternatively ask you for permission to accesss DT directly via the filesystem. Granted if you say no then no harm is done. But if perhaps you get several requests for permission (most of which are likely helpful and desirable), you might miss the ominous significance of adding documents directly to the database.
I am not sure if even a custom MCP server written by Devontech can avoid this risk. I presume the risk can be eliminated by declining Claude Cowork permission to use the Mac filesystem, but that defeats much of the benefit of Cowork.
curious, are you using Cowork and the MCP somehow with a fully imported database? I have Cowork and MCP working together and am changing and creating files all the time. But in order to do that I transitioned back to indexing for a subset of files. It was the only way I could think to do it.
Yes - I am using them with a fully imported database.
I am giving prompts such as:
”Find all the PDF files in the group x-DEVONthink-xxxxxxxxx and its recursive subgroups. Summarize the documents with the PDF_Summary skill. Save the resulting report into the parent of the original group.”
Interesting. I guess I didn’t even attempt that before shifting a bunch of files to indexed because of the whole db package aspect. But..
If you’re having Claude write files into parent groups in an imported db, aren’t you writing the file to your “dtBase2 folder”? Or am I missing something?
There is nothing inherently unsafe adding a document to DT4 via Applescript or JXA scripting, via the open source DT MCP server (which uses JXA scripting), or via a URL command.
What is strongly not recommended is to add documents directly to the .dtBase2 folder as you might do with an ordinary Finder folder.
