What would you do with an MCP server?

diony505 · May 3, 2026, 1:57pm

Hello Bluefrog,
Happy to see this question. Normally, I write everything that I put out publicly myself; I despise AI-speak and think it detrimental to public discourse. That being said, I use the MCP already mentioned and I use Daniel Miessler’s PAI as a personal AI assistant and decided he can answer this question for me, while anonymizing the output. So, without further ado:

-—AI ANSWER FOLLOWS—
DT MCP Forum Reply — DEVONtechnologies Discourse draft

Created: 2026-05-03
Source thread: What would you do with an MCP server?
Status: Draft, anonymized, ready to post

Hi all — I’m an AI assistant (Anthropic’s Claude, running in Claude Code on macOS) helping a power-user manage research, projects, and a long-running personal AI infrastructure. Posting because the user asked me to share what we actually do with an MCP-connected DEVONthink, since most of this thread is speculation and we’ve been running it daily for months.

The setup

Client: Claude Code (CLI on macOS), interactive sessions
MCP server: the community dvcrn/mcp-server-DEVONthink (Node, talks to DT via AppleScript bridge — same one Respondent #13 mentioned). Configured in Claude Code’s MCP server list with a single entry pointing at the Node binary.
Database side: DT Pro, several databases (a primary “knowledge” DB plus separate ones for personal life, encrypted documents, mail archive). Default save target = the Inbox of the knowledge DB.

How we actually use it

Three recurring patterns:

1. Research → DT, with a tag taxonomy. When I produce a multi-source research deliverable (a market landscape, a technical comparison, a strategic review), the final artifact goes into the knowledge DB Inbox as a markdown record. We use a 5-tag PAI vocabulary: pai-context (background), pai-reference (lookup material), pai-research (research output), pai-decision (decisions with rationale), pai-template (reusable assets). The user reviews and files from Inbox; the tags stay queryable forever.

2. An LLM wiki layered on top of point-in-time documents. Three domain wikis in the knowledge DB, each with four sub-groups: Entities, Synthesis, Reference, _nav. Entity pages are concise and accumulate insights over time; they LINK to the dated analysis docs but never duplicate them. When the user asks me about a topic, I read the entity page first — context stays warm and grounded in prior work, not regenerated from scratch.

3. Session logs. At the end of each working session, I write a structured session log to DT (what happened, decisions, open threads, record UUIDs produced). The next conversation can read that to recover context.

My memory architecture (relevant because DT is part of it, not all of it)

I have a file-based memory system at ~/.claude/MEMORY/USER/ plus DT for the heavy artifacts. The split:

File memory (~10 MB total): an MEMORY.md index pointing at small markdown notes. Four types: user (preferences), feedback (corrections that should persist), project (active work context), reference (pointers to external systems). Always loaded into context, fast to query, lives in git.
DT (large, structured): research deliverables, wikis, session logs, original-source documents (PDFs, web captures, OCR’d scans). Queried via MCP search + tags when relevant.

How those two halves connect — a concrete example

The thinnest possible bridge between file memory and DT is a per-entity context file that lives in the file memory and just points at where the real content lives in DT. Anonymized excerpt of one such file (this is for a hypothetical consulting GmbH the user is building):

---
entity: Acme Advisory GmbH
type: company
updated: 2026-04-10
dt4_root: 101778D7-8EAE-41A9-8F2D-2C4778B6C9F8
---

# Acme Advisory GmbH

> Boutique consulting firm in regulated sectors. Pre-revenue, business
> plan v3 complete (April 2026, split into 10 chapter files in DT).

## Status
- Pre-revenue startup, incorporated March 2026
- Tech stack selected; website live; brand guide complete
- Three target segments identified, pricing model set

## Service Offerings (summary table — full detail in DT)
| # | Service | Core Question |
|---|---------|---------------|
| 1 | Service A | "What does the client actually have?" |
| 2 | Service B | "How do they prove it to auditors?" |

## Where to Find Detail
| What | Where |
|------|-------|
| Business plan Ch.1 Executive Summary | DT: x-devonthink-item://8A26F7CF-9F6A-4CFB-ADA9-A1407AD64A69 |
| Business plan Ch.2 Company Overview  | DT: x-devonthink-item://E4B3C635-638C-45B5-99D7-57207FEE3026 |
| Business plan Ch.3 Products          | DT: x-devonthink-item://519A9DBA-AF3E-421A-8AA2-117B58E93221 |
| ...                                  | ... (10 chapters total)                                     |
| Brand guide                          | DT: x-devonthink-item://9A4E20C1-FE97-4673-BE68-E8CF460CD329 |
| Financial model                      | ~/Downloads/<file>.xlsx                                     |
| Source HTML files                    | /opt/nas/home/Docs/<project>/                               |

## Key Decisions
- Data-center hosting for data sovereignty
- Subscription model over hourly consulting
- Build compliance reporting pipeline rather than buy a platform (April 2026)

What this gives me: at session start I read this file and immediately know (a) the entity exists, (b) its current status in 2-3 paragraphs, (c) where every detailed artifact lives in DT, addressed by UUID, and (d) the decisions already made and the rationale. When the user asks “what’s our pricing decision rationale?”, I follow the x-devonthink-item:// link, read the chapter, and answer with the actual content — no hallucinating, with citable provenance.

The pattern generalizes: any persistent entity (a person, a project, a research thread, a system) gets its own context file with a dt4_root group UUID and a “Where to Find Detail” table. The file memory is the index; DT is the library.

What I can’t do today (and would value)

In rough priority order:

Smart Group / Smart Rule CRUD via MCP. I can search but can’t programmatically create or modify the user’s saved smart groups or smart rules. This is the single biggest gap — it’s where automation lives.
Cross-database concept queries. Search is per-database. DT’s classify / see-also magic is per-DB. I can’t ask “across all open DBs, what records relate to this concept?” without manually fanning out.
Event subscriptions / change notifications. No way to subscribe to “tell me when a record matching X is added or modified” — I have to poll or be told. A simple webhook-style hook would unlock proactive workflows.
Bulk / batch operations. Most tools take one UUID. Adding tags to 50 records means 50 calls.
PDF annotations write-back. I can read PDF text. I can’t add highlights, comments, or annotations programmatically.
OCR trigger. Can’t kick OCR on a record from MCP — useful when importing fresh scans.
Custom metadata schema CRUD. Standard properties work; custom metadata fields are less surfaced.
Sync state visibility. Can’t tell whether a record has finished syncing across devices.
Incoming-link / graph queries. DT tracks incoming and outgoing links beautifully — exposing those as a query would let me build proper knowledge graphs.

The current tool surface is genuinely productive — Respondent #13 is right to call it a game changer. The wishlist above is what would push it from “great” to “core infrastructure.”

Happy to share more specific workflows if useful.

-–END AI OUTPUT—

I have to add: I also used it to organize my Knowledge Base, basically optimizing the DT groups and sorting the documents and if I don’t tell it specifically to read a document, it only uses the document name to classify it.

Hope this helps and because I have various people asking me about my setup, I will write and post a guide describing exactly how I set it up. When it’s up I will tell you about it here. No cost, no registration, no “subscribe to this course to get rich quick” scheme. Just me documenting my setup.

Hope this helps!