Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@devonthink3-mcp @devonthink3-mcp search my database for project notes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local, scoped MCP access to DEVONthink 3 on macOS. Search your archive, read cited text, follow references, and preview document organization from an AI assistant.
Tested on DEVONthink 3.9.18. Uses the official MCP TypeScript SDK 2.0.0 with the 2026-07-28 protocol and compatibility for 2025 clients. JavaScript source runs directly on Node.js; no build step, web server, API key, or second search index.
한국어 안내 · Design and research · Validation · Security boundaries
Already using DEVONthink 4? Its built-in MCP server is the simpler starting point. This project is for people staying on version 3. It is independent of DEVONtechnologies.
Requires macOS, Node.js 22 or later, and a running, scriptable DEVONthink 3 installation. Open the databases you want to use. Allow the launching terminal or AI application to control DEVONthink in System Settings → Privacy & Security → Automation when macOS prompts.
Choose and register a client without cloning the repository:
npx -y @waylake/devonthink3-mcp@0.2.0 setup --client codexFor Pi:
npx -y @waylake/devonthink3-mcp@0.2.0 setup --client piFor both, use --client both. Setup lists open databases by name, asks you to select their numbers or explicitly follow all open databases, and asks whether to enable writes. It saves local settings, then calls the client's own installer. Codex CLI or Pi must already be on PATH. --client pi installs pi-mcp-adapter@2.32.1 and this package through pi install; no separate MCP JSON editing is required.
Setup stores settings in ~/.config/devonthink3-mcp/config.json with owner-only permissions and preserves the previous file as config.json.bak. Existing unrelated MCP servers and Pi packages are retained. If client registration fails after settings were saved, fix the client installation and rerun setup. Keep setup output and configuration private.
Reconnect Codex or restart Pi after installation. In Pi, /reload and /mcp refresh and inspect available servers. The adapter discovers the package's pi.mcp manifest and connects lazily when needed. The package entry is named waylake_devonthink3-mcp__devonthink3 in the adapter. Pi package documentation, adapter documentation.
This grants reads and writes to every database currently open and every database opened later:
npx -y @waylake/devonthink3-mcp@0.2.0 setup --client both --database-mode open --enable-writesRestrict access to selected UUIDs instead:
npx -y @waylake/devonthink3-mcp@0.2.0 --doctor
npx -y @waylake/devonthink3-mcp@0.2.0 setup --database-uuids FIRST_UUID,SECOND_UUID --read-onlyWithout --client, setup saves settings only. Replace example UUIDs with values from the local doctor output. --exclude-databases UUID,UUID adds an exclusion list that overrides either scope mode; passing an empty string clears that list. Setup preserves other saved settings, including import roots. Settings changes require a client reconnect. Opening or closing databases does not require a reconnect.
If you prefer the client's native commands, first run npx -y @waylake/devonthink3-mcp@0.2.0 setup to choose scope, then:
# Codex
codex mcp add devonthink3 -- npx -y @waylake/devonthink3-mcp@0.2.0
# Pi
pi install npm:pi-mcp-adapter@2.32.1
pi install npm:@waylake/devonthink3-mcp@0.2.0The setup helper registers absolute Node and npm CLI paths for Codex so GUI launches do not depend on finding Node through a shell. The manual npx form requires Node/npm on the client's PATH. Official Codex MCP documentation.
For another local stdio MCP client:
{
"mcpServers": {
"devonthink3": {
"command": "npx",
"args": ["-y", "@waylake/devonthink3-mcp@0.2.0"]
}
}
}Version pins keep the chosen server version stable. To upgrade, review the release and rerun setup from the new version. The Pi manifest intentionally executes the matching npm version through npx; the first connection may download that version into npm's cache. Subsequent connections reuse it. No repository checkout is required. Web-only remote clients need a separate local bridge; none is included.
Related MCP server: DEVONthink MCP Server
Eight read tools are available by default. Five write tools appear when writes are enabled in setup or with DT3_ENABLE_WRITES=1.
Tool | Purpose |
| App readiness, version and configured scope |
| Permitted open databases and their root UUIDs |
| Permitted records in the current selection |
| Native full-text/query search in one database or group |
| Direct children, including records with no indexed text |
| Metadata, optional custom metadata, and edit revision |
| Bounded indexed text, extraction status and source link |
| Similarity, classification, duplicates, incoming/outgoing item references |
| Preview/create Markdown, plain text or a group |
| Preview/edit name, tags, comment, rating, flags, or plain/Markdown text |
| Move one document instance; preserve other replicants |
| Add a shared document instance within the same database |
| Import one permitted local file; retain its original |
Each successful tool response has an output schema, structured data and a text rendering. Record identifiers accept UUIDs or x-devonthink-item:// links. Tool results include item_url for citations and resource_uri for MCP clients. devonthink3://record/{uuid} reads the first text chunk; devonthink3://guide describes the workflow. The research and organize prompts provide starting workflows.
Call dt3_databases; choose relevant databases. Search each explicitly and combine evidence with database UUIDs and item links.
Call dt3_search with native syntax such as name:report or tag:review.
Inspect metadata; call dt3_read_text only for relevant records.
Continue with next_offset until null, comparing revisions if the source changes.
Cite the returned item link in the synthesis. Keep originals in DEVONthink and small, source-linked knowledge pages in Git.
List pages default to 25 records, capped at 100. Text chunks default to 8,000 UTF-16 code units, capped at 16,000; surrogate pairs are preserved. Search/browse order is native and not a snapshot. Concurrent imports or edits may change page membership; deduplicate by UUID when gathering an inventory.
Enable writes through setup or an environment override and reconnect. The server still defaults every mutation to a preview:
{
"uuid": "RECORD_UUID",
"expected_revision": "REVISION_FROM_GET_RECORD",
"request_id": "rename-project-note-001",
"name": "Project note",
"dry_run": true
}Review before, destination and changes. For an authorized change, call the same tool with dry_run: false. A text preview shows its first 1,000 code units and total length. Tags replace the complete tag list. Moving requires both from_uuid and destination_uuid and operates on one document instance, within one database.
To preserve existing tags, read them first and include them in the replacement array.
A changed revision rejects the edit. The app is not transactional: multiple property updates can partially complete if an Apple Event fails. Inspect current state after any uncertain result. A timeout or cancellation stops the subprocess but cannot roll back an Apple Event already delivered.
Mutation receipts prevent exact retries from repeating a write within one server process. Reuse the same request_id only with identical arguments. Receipts are held for up to 256 writes without eviction; subsequent new writes return RECEIPT_LIMIT. Reconcile results before restarting. Receipts do not survive a restart and are not an audit log. Replays recheck access permissions.
Without settings or environment overrides, access is denied and writes are off. Settings are read once at startup. Environment values override saved settings. An explicit DT3_DATABASE_UUIDS, including an empty value, also selects selected mode unless DT3_DATABASE_MODE is explicitly provided. The Pi package uses the default settings file and does not inherit custom DT3 environment overrides; use setup or a custom MCP entry for a separate Pi profile.
Variable | Default | Meaning |
|
| Absolute settings-file path; an explicitly named missing file is an error |
|
|
|
| empty | Comma-separated permitted database UUIDs in selected mode; no wildcard |
| empty | Comma-separated denied database UUIDs, in both modes |
|
|
|
| empty | Extra excluded tags, comma-separated; |
|
| JSON array of absolute directories permitted for single-file imports |
|
| Per JXA subprocess timeout, 1,000–120,000 ms |
Example import root: DT3_IMPORT_ROOTS='["/Users/you/Documents/MCP Import"]'. Imports follow real paths, reject symlink escapes, directories, and files over 100 MiB. Use DEVONthink itself for large folder imports.
Tag a document or group mcp-private to exclude it. The server checks every parent: a replicant in a private group is denied even if another instance is in a public group. Trash is excluded. Metadata, search results, direct reads, resources and writes share the same scope check.
The server has no network listener or telemetry. The connected AI host may send returned content to its model provider. There is no automatic sensitive-text redaction; this is separate from DEVONthink 4's built-in privacy controls.
no_text means DEVONthink returned no plain text. It does not prove the source is empty. OCR, media transcription, archive expansion, spreadsheet formula evaluation and password recovery are outside this server.
Metadata-only search is separate from text reading. PDF text comes from DEVONthink's index; page count is provided, but returned chunks do not claim page-level alignment.
Text reads reject indexed text over five million characters. Native APIs may materialize full text or search results internally before pagination. A call scans at most 5,000 result candidates; follow next_offset, including on an empty filtered page.
Writes to locked or indexed records, group relocation, cross-database moves, trash operations and permanent deletion are excluded. Edit original indexed files through their source application.
NOT_RUNNING: open DEVONthink 3. ACCESS_DENIED: check UUID configuration and open databases. NOT_FOUND_OR_DENIED: check tags and ancestors. AUTOMATION_DENIED/AUTOMATION_FAILED: inspect macOS Automation permissions and app dialogs. CONFLICT: re-read and preview again.
Configured databases must remain open in the app; the server does not mount closed database packages. A permission granted to Terminal does not automatically grant it to a GUI AI host. Open that host interactively and check its own Automation entry.
Apple Events are serialized within one process; at most 16 calls queue. Use one server process for a given workflow. Multiple clients/processes and manual app edits are not protected by a distributed lock.
npm ci --ignore-scripts
npm run check
DT3_LIVE_TEST=1 npm run test:livePortable tests cover policy, schemas, replay, imports, queueing and both protocol eras. The opt-in live test creates a temporary synthetic database, exercises actual app operations, closes it, and removes its temporary files. It requires DEVONthink 3 and Automation permission; do not run it while relying on the current selection for another workflow.
For a durable archive structure and agent review workflow, read the knowledge organization guide.
MIT license. See design and research for upstream references and reuse decisions.
List permitted currently open databases and their root UUIDs. Refresh as databases open/close. Run the local setup CLI to change access policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| databases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile. The description reinforces this with 'List' and 'Refresh as databases open/close' which imply no state changes. Adds the 'permitted' access qualifier without conflicting with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first states the purpose, the second adds operational context (refresh timing and policy change alternative). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple no-parameter tool. The description includes the output hint ('root UUIDs'), the access scope ('permitted'), and the non-goal (policy changes). It doesn't list the exact output structure, but that is not essential given the trivial signature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the schema covers 100% of them. The description adds no parameter details (unnecessary), but the empty schema is self-explanatory. A score of 4 reflects that no parameters are present, making this dimension trivially satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (List), resource (databases), and qualifiers (permitted, currently open, with root UUIDs). The verb is specific and unambiguous, and the description differentiates from sibling tools like 'status' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance: 'Refresh as databases open/close' indicates when to call this tool, and 'Run the local setup CLI to change access policy' tells the user what to use instead for policy changes. Lacks a direct 'use this when...' phrase but is sufficiently helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read document metadata and a revision for safe editing. Optionally include custom metadata (16,000-character limit). Original paths and binary bytes are not exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Record UUID or x-devonthink-item:// link. Link page/search parameters are ignored. | |
| include_custom_metadata | No |
| Name | Required | Description |
|---|---|---|
| record | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly and idempotent behavior, and the description adds that original paths and binary bytes are not exposed, which is extra context. This transparency helps set expectations without contradicting the annotations. A perfect score would require more detail on side effects (e.g., whether it marks anything), but it's already strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey the core function, optional behavior, and constraints. No redundant words or vague phrasing. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, so return values are defined elsewhere; the description focuses on constraints like the 16,000-character limit and non-exposure of paths/bytes. This provides sufficient context for an agent to decide whether to invoke the tool. It lacks a few details like whether the revision is the latest, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The uuid parameter is well described in the schema, including the format (UUID or x-devonthink-item link) and that page/search parameters are ignored. The include_custom_metadata parameter lacks a schema description, but the tool description explains it with a character limit. Combined, both parameters are semantically clear, though the schema could be more complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads document metadata and a revision for safe editing, which is a specific and unambiguous purpose. It also mentions what is not exposed (original paths and binary bytes), further clarifying the tool's scope. This distinguishes it sufficiently from sibling tools like dt3_read_text that likely handle content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('for safe editing') but does not explicitly state when to use this tool over alternatives. While the purpose is clear, there is no direct comparison to sibling tools like dt3_read_text or dt3_search. Providing a hint about when to choose this tool would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse direct children, including empty groups and records without indexed text. Follow next_offset to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Record UUID or x-devonthink-item:// link. Link page/search parameters are ignored. | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| records | Yes | |
| advisory | No | |
| snapshot | Yes | |
| next_offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and destructive=false, so the description does not need to restate those. It adds behavioral clarity by explaining that the tool includes empty groups and unindexed records, and that pagination is handled via next_offset. This is exactly the type of context that goes beyond basic annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences and every part contributes value: the action, the inclusions, and the pagination hint. There is no redundancy or fluff, and it is well-structured with the main purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for the tool's core behavior — listing direct children. Since an output schema is present, return values do not need to be fully described. The mention of next_offset hints at pagination, which is important. It is slightly lacking in that it does not describe what a 'group' is, but given the tool name and sibling context, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — only 'uuid' has a description, while 'limit' and 'offset' lack any explanatory text. The tool description does not compensate for this by clarifying the meaning or behavior of limit and offset. With low schema coverage and no additional parameter details, the semantics are significantly under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Browse direct children') and the specific resource, making the tool's purpose obvious. It adds useful detail about including empty groups and unindexed records, but it does not explicitly contrast with sibling tools like dt3_search or dt3_get_record. Given the name and context, the purpose is sufficiently clear without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage instruction: 'Follow next_offset to continue,' which helps with pagination. However, it does not explicitly state when to prefer this tool over alternatives such as dt3_search or dt3_get_record. The absence of when-to-use guidance leaves some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a bounded chunk of DEVONthink indexed plain text with citation and extraction status. No OCR, transcription, or spreadsheet recalculation is performed.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Record UUID or x-devonthink-item:// link. Link page/search parameters are ignored. | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| offset | Yes | |
| record | Yes | |
| source | Yes | |
| untrusted | Yes | |
| next_offset | Yes | |
| text_status | Yes | |
| total_characters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/destructive hints, but the description adds extra context about what operations it does not perform, which is useful for setting expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant phrasing. Every word adds value, and the key purpose and limitations are stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be explained. The description covers purpose and limitations but lacks sufficient context on parameter semantics and when to prefer this tool over siblings, leaving some gaps for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only uuid has a description). The description mentions 'bounded chunk' but does not explain the limit and offset parameters, leaving them ambiguous without additional schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'read' with specific resource (DEVONthink indexed plain text) and additional details about citation and extraction status. Distinguishes from sibling tools like search, list_group, and get_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States limitations (no OCR, transcription, spreadsheet recalculation) but does not explicitly name when to use this tool versus alternatives. The 'bounded chunk' hint implies partial reads, but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search one permitted database with native DEVONthink query syntax, e.g. name:report or tag:review. Metadata only; use read_text for content. Live pagination follows native result order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| offset | No | ||
| recursive | No | ||
| group_uuid | No | Record UUID or x-devonthink-item:// link. Link page/search parameters are ignored. | |
| database_uuid | Yes |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| records | Yes | |
| advisory | No | |
| snapshot | Yes | |
| next_offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly and idempotent hints. The description adds that it returns metadata only and that pagination follows native result order, which are useful behavioral details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with no redundant words. It packs essential information—query syntax example, metadata-only scope, and pagination behavior—into a single sentence, ensuring quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and an output schema, the description provides little context for most parameters and does not clarify expected input formats or edge cases. The presence of an output schema reduces the need to describe return values, but the lack of parameter guidance makes the tool hard to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (only group_uuid is described) and the description does not explain limit, offset, recursive, or database_uuid. While query syntax is mentioned with examples, the meaning and interplay of the pagination and scoping parameters remain unclear, leaving users to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) on a specific resource (one permitted database) using native DEVONthink query syntax. It provides concrete examples and distinguishes from content retrieval by saying metadata only, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to use read_text for content, indicating when not to use this tool. It also mentions pagination behavior, which helps with paginated queries. However, it does not contrast with other search/list tools like dt3_list_group or dt3_get_record, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read metadata for the current DEVONthink selection, filtered by access policy.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| records | Yes | |
| advisory | No | |
| snapshot | Yes | |
| next_offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the detail of filtering by access policy, which is a behavioral nuance not present in the annotations. This extra information enhances transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core functionality without unnecessary detail. It is well-structured and directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys that the tool returns metadata for the current selection, filtered by access policy. It does not elaborate on the output format, but given the existence of an output schema and the simplicity of the operation, it is reasonably complete. Slight improvement could clarify pagination behavior, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes limit and offset with defaults and bounds but no descriptions. The tool description does not explain these parameters or their purpose. As schema coverage is 0%, the description fails to compensate, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads metadata for the current DEVONthink selection, with a specific filtering criterion (access policy). This distinguishes it from sibling tools like dt3_search or dt3_get_record, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving metadata of the currently selected items, but it does not explicitly contrast with alternatives such as dt3_get_record or dt3_search, nor does it state when not to use it. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check DEVONthink 3 readiness and scope configuration. Does not launch the app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| running | Yes | |
| version | Yes | |
| text_source | Yes | |
| database_mode | Yes | |
| writes_enabled | Yes | |
| configured_databases | Yes | |
| permitted_open_databases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, so the bar is lower. The description adds a useful side-effect clarification ('Does not launch the app') that goes beyond the annotations, but does not detail other behavioral aspects like error handling or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey purpose and a key limitation without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the core purpose and a critical non-behavior, but leaves terms like 'readiness' and 'scope configuration' undefined. Given the tool's simplicity and the presence of an output schema (not shown), the description is mostly sufficient but lacks a bit of contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters to describe, so schema coverage is effectively 100%. The description does not add parameter-related detail, but none is needed, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the target ('DEVONthink 3 readiness and scope configuration'), and explicitly notes a key non-behavior ('Does not launch the app'), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a negative constraint ('Does not launch the app') but provides no explicit guidance on when to use this tool versus alternatives like dt3_databases or dt3_search. The intended use case is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0dt3_databasesdt3_get_recorddt3_list_groupdt3_read_textdt3_relateddt3_searchdt3_selectiondt3_statusEach tool targets a distinct operation: status, database enumeration, selection metadata, search, group browsing, record metadata retrieval, content extraction, and related-item discovery. Even the overlapping get_record and read_text are clearly differentiated by returning metadata vs. content, leaving no ambiguity.
All tools share the dt3_ prefix and use a consistent snake_case convention with descriptive verbs (list, get, read) or clear nouns (status, databases, selection). The pattern is uniform and predictable, making tool selection straightforward.
8 tools is well-scoped for a DEVONthink integration, covering the core read-side workflow (status, databases, selection, search, navigation, retrieval, content access, and related items) without being overly sparse or bloated.
The surface is strong for read and browse operations, but lacks any create, update, or delete tools. While the get_record description hints at editing via external workflows, the MCP server itself does not provide write capabilities, leaving a notable gap in lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/waylake/devonthink3-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
