MCP Feature Request, maybe?

DEVONthink Artificial Intelligence
1

I’ve been using the MCP with Claude Cowork, and it’s been running very well. In general, I’ve set the harness so that any document the AI creates for my use goes into DTP (and anything the LLM uses stays in the filesystem), and the AI knows to look in DTP for certain documents. This all works pretty well.

However, because the AI needs to be aware of what’s changed in DTP, when I start a session, the harness has the model scan the open databases for changes.

Claude and I worked on this process for quite a bit until we got it running well, but the friction in the system is that there is nothing in the MCP (or at least none we’ve found) that feeds back to the LLM what’s changed.

At session start, the DTP sequence is (this is from Claude, as it’s more concise than what I’d write):

  1. get_databases (one call) - confirm DT is running, list open databases + UUIDs, read each DB’s versioning flag.
  2. search_records per tracked database (filtered by modificationDate >= last session) -pull the set of records that changed since the prior session.
  3. search_records item:replicated + get_record_parents - when records changed, re-resolve replicant locations.
  4. get_record_children on each database’s Trash group - detect deletions (trashing doesn’t bump modificationDate and search can’t see into Trash, so this has to be enumerated directly).
  5. Local diff + reconcile - feed all the above into a local SQLite index and compute the delta: adds, edits, moves, renames, replications, deletions.

Steps 2 through 5 exist because there’s no change log for the AI to use. It doesn’t take all that long, but it does lengthen the entire start-up process (this is only one of several things I have it do at session start). Because file renames and record-level moves don’t update the modification date, they’re entirely invisible to the incremental pull; catching them requires a periodic full-name pull of the whole database and a name-by-name comparison. Which, IIRC, is a weekly task I have set up to catch these things. Claude tells me that “a simple MCP-provided “what changed since timestamp X” endpoint (ideally one that captures renames/moves/trashing, not just content edits) would collapse all of that into a single call.”

Or… if there is a more efficient way for the AI to poll changes from DTP since the last time it spun up, I’d be interested in knowing how to run this better.

2 Likes
2

Thank you for the suggestion! This sounds like an extension of the search syntax actually, something like e.g. attributesModificationDate: or attributesModified:.

5 Likes