Skip to main content
Glama
Sign In
devonthink3-mcp

devonthink3-mcp

by waylake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

dt3_selection

Read-onlyIdempotent

Read metadata for the current DEVONthink selection, filtered by access policy, to inspect selected documents without exposing restricted details.

Instructions

Read metadata for the current DEVONthink selection, filtered by access policy.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dt3_selection"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo

Output Schema

NameRequiredDescriptionDefault
kindNo
recordsYes
advisoryNo
snapshotYes
next_offsetYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • changedInput schema / properties / limit / maximum
      Previous value: -100New value: +200
  2. First observedv0.2.0

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description does add one genuinely non-obvious behavioral trait — results are filtered by access policy, so the agent should expect possibly incomplete results — but says nothing about pagination behavior, whether the selection can be empty, or how errors surface.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler and no repetition of the tool name. The 'filtered by access policy' qualifier is vague enough to be of marginal value, but the sentence is otherwise tight.

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?

An output schema exists and annotations are rich, so the description need not explain return values or safety. What remains missing is paging semantics and what 'current selection' means when nothing is selected, which is a real but modest gap for a two-parameter read tool.

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 0% and both parameters (limit with default 25/max 200, offset) are undocumented anywhere. The description never mentions paging, defaults, or that the selection may contain more items than one page, so it fails to compensate for the coverage gap.

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 gives a specific verb ('Read') and a specific resource ('metadata for the current DEVONthink selection'), which is meaningfully narrower than a by-ID lookup and distinguishes it in spirit from dt3_get_record/dt3_get_records. It stops short of naming any sibling explicitly, and the trailing clause 'filtered by access policy' slightly muddies rather than sharpens the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus dt3_get_record, dt3_get_records, or dt3_search, and no prerequisites or exclusions. The only implicit cue is that it applies to whatever is currently selected in the app, which an agent may not be able to verify or control.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools