I found the earlier discussion requesting token/client-specific database access (“MCP – requests already (sorry)”). This request is related, but extends the idea from controlling which databases an MCP client can access to controlling what operations that client is technically authorized to perform within the accessible scope.
The current ability to exclude databases, groups, or records from Chat & MCP is useful for controlling what an AI can access. However, AI-assisted workflows also need a way to distinguish what an MCP client may read from what it may modify, and to constrain the types and locations of permitted modifications.
For example, I might want to give an AI:
- read/search access to an entire database;
- permission to create Markdown documents only in a designated Drafts group;
- permission to modify a few approved metadata fields;
- no permission to move or rename records;
- no permission to trash or delete anything.
A useful model might be an MCP client or service identity with permissions such as:
- allowed databases and groups;
- Read/Search;
- Create;
- Modify document content;
- Modify metadata;
- Tag;
- Move/Rename;
- Trash/Delete;
- optionally, specific writable metadata fields or permitted destination groups.
Ideally, these permissions would be enforced by DEVONthink itself using a default-deny model, so an MCP client could not bypass them regardless of the AI model, prompt, or client application being used.
One analogy is PostgreSQL/Supabase, where roles, object privileges, and row-level security allow the data system itself to enforce what a client is permitted to do rather than relying only on application behavior.
DEVONthink Server already has the related concept of users with different permissions. Extending a similar authorization model to MCP clients—preferably with group- and operation-level granularity—could make DEVONthink substantially safer for AI-assisted workflows.
An additional useful capability would be allowing an MCP authorization profile to expose only the MCP operations permitted for that identity. A read-mostly or constrained-write AI, for example, would never receive generic destructive tools at all.
This would make it possible to use AI for writing, organization, metadata maintenance, and automation without granting the AI the full mutation authority of the interactive DEVONthink user.
I’d be very interested to know whether anything along these lines is already planned for DEVONthink’s MCP implementation, or whether the existing work on client/database-specific access might eventually be extended in this direction.