devonthink3-mcp

by waylake

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness3/5
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.
Average 4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on September 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: results are permission-filtered, suggestions are advisory, and duplicate detection follows DEVONthink's logic rather than a fresh disk hash. This complements the readOnly and idempotent hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three focused sentences: one for purpose, one for permission filtering, and one for behavioral caveats. It is well-structured with no redundant or vague content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is available, the description does not need to explain return values. It provides enough context about the kinds of related items and key behavioral caveats to enable correct usage, though it could have included a brief example or parameter-relationship mapping for extra clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The uuid parameter is well described (accepts UUID or x-devonthink-item:// link, and notes ignored parameters), and the kind enum values are self-explanatory. However, limit and offset lack descriptions, and the relationship kinds are not further elaborated. Since schema coverage is only 25%, the description only partially compensates for the missing parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb ('Find') and a distinct resource scope: native similar documents, classification suggestions, duplicate files, and incoming/outgoing references. This makes it readily distinguishable from sibling tools like search or list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by specifying the types of relationships it retrieves (similar, classify, duplicates, incoming, outgoing) and includes useful caveats about permission filtering and the advisory nature of suggestions. It stops short of explicitly contrasting with sibling tools, but the scope is clear enough for practical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

devonthink3-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![devonthink3-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/waylake/devonthink3-mcp/badges/card.svg)](https://glama.ai/mcp/servers/waylake/devonthink3-mcp)

Score Badge

Copy to your README.md:

[![devonthink3-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/waylake/devonthink3-mcp/badges/score.svg)](https://glama.ai/mcp/servers/waylake/devonthink3-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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