Devon

by mnott

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v3.0.1
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, such as 'convert_record' and 'duplicate_record' both creating new records, and 'get_record_properties' vs. 'get_record_content' potentially causing confusion. Descriptions help clarify, but careful reading is needed to differentiate.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern throughout, such as 'create_record', 'delete_record', and 'list_smart_groups'. This predictability makes the set easy to navigate and understand.
Tool Count3/5
With 33 tools, the count feels heavy for a document management server, potentially overwhelming for agents. While the domain is broad, many tools could be consolidated or omitted without losing core functionality.
Completeness5/5
The toolset provides comprehensive coverage for DEVONthink operations, including CRUD for records, AI integration, metadata management, search, and specialized functions like smart groups and email parsing. No obvious gaps are present.
Average 3.7/5 across 33 of 33 tools scored. Lowest: 2.5/5.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails to indicate if the operation is read-only, what format results are returned in, or the significance of omitting the compareWithUuid parameter (which triggers a 'find similar' mode rather than a direct comparison).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is not verbose, but for a tool with four parameters and dual operating modes, it is undersized. It front-loads the verb and resource, yet the extreme brevity constitutes under-specification rather than efficient conciseness given the tool's complexity.
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 lack of annotations and output schema, the description should disclose safety properties (read-only status), return value structure, and behavioral nuances. It omits all of these, leaving significant gaps in contextual information needed for proper tool invocation.
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?
Schema description coverage is 100%, with all four parameters (recordUuid, compareWithUuid, databaseName, comparison) fully documented in the schema including enum explanations. The description adds no supplementary parameter guidance, meeting the baseline expectation when the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (compare records for similarities) and resource (DEVONthink records), but remains vague about the comparison scope. It fails to distinguish from sibling tools like 'search' or 'classify' that also find similar items, and omits the tool's dual behavior (comparing two specific records vs. finding records similar to one).
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?
No guidance provided on when to use this tool versus alternatives like 'search' or 'ask_ai_about_documents'. The description lacks prerequisites (e.g., needing record UUIDs) and excludes context about when to use 'data comparison' versus 'tags comparison' modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to clarify critical behavioral traits: whether 'adds' is additive (appending) or destructive (replacing), idempotency, what constitutes success/failure, or the return value (especially important given no output schema exists).
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, efficient sentence with zero waste. It is appropriately front-loaded with the action and target immediately clear.
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?
For a write operation (mutation) with no annotations and no output schema, the description is insufficient. It omits behavioral details like duplicate handling, error conditions (e.g., non-existent UUID), or side effects that would help an agent invoke the tool correctly.
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?
With 100% schema description coverage ('UUID of the record to tag', 'Tags to add to the record'), the baseline is 3. The description does not add param-specific semantics beyond the schema, but given the comprehensive schema coverage, it does not need to compensate.
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 uses a specific verb ('Adds') and identifies the resource ('tags') and target ('DEVONthink record'). It implicitly distinguishes from the sibling 'remove_tags' by using the opposite verb, though it does not explicitly clarify when to use this versus 'set_record_properties'.
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?
The description states what the tool does but provides no guidance on when to use it versus alternatives like 'remove_tags' or 'set_record_properties'. It lacks prerequisites (e.g., record must exist) and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It does not disclose that the tool performs HTTP requests (evidenced by userAgent/referrer parameters), supports multiple output formats, or that pdfOptions only applies to specific formats. The mutation aspect ('Create') is implied but not explicit about side effects.
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?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded with the action and resource. However, for a tool with 8 parameters including nested objects, the extreme brevity arguably under-serves the complexity, though this primarily impacts completeness rather than conciseness itself.
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 high complexity (8 parameters, nested pdfOptions object, HTTP header customization, readability processing) and lack of output schema or annotations, the description is insufficient. It fails to explain the web capture behavior, output formats, or what the created record contains, leaving critical behavioral gaps for an agent trying to invoke this tool correctly.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'from a web URL' which maps to the url parameter, but adds no additional context about parameter relationships (e.g., that readability mode affects content extraction or that pdfOptions requires specific formats) beyond what the schema already provides.
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 verb (Create), resource (record in DEVONthink), and specific source (web URL), distinguishing it from the sibling 'create_record' tool. However, it lacks specificity about what type of record is created (bookmark, PDF, HTML) despite the schema supporting multiple formats.
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?
No guidance is provided on when to use this tool versus alternatives like 'create_record' or 'convert_record'. Given the complexity of web capture options (PDF vs HTML vs bookmark), the description fails to specify prerequisites or ideal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'removes' implies mutation, it fails to clarify whether the operation is destructive, idempotent, or what occurs when specified tags don't exist on the record.
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?
The single sentence is front-loaded with the action verb and contains no redundant words. However, given the lack of annotations and output schema, it may be overly terse for a mutation operation.
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?
For a simple three-parameter mutation tool with complete schema coverage, the description covers the basic operation. However, given the absence of annotations and output schema, it lacks necessary behavioral context (error handling, reversibility) for safe agent invocation.
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?
With 100% schema description coverage, the schema fully documents all three parameters (uuid, tags, databaseName). The description adds no additional parameter-specific semantics beyond implying the uuid through 'specific record', warranting the baseline score.
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 (removes) and target resource (tags from a specific record in DEVONthink). It effectively distinguishes from sibling 'add_tags' through the verb choice, though it doesn't explicitly name the alternative in the text.
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?
The description provides no guidance on when to use this tool versus alternatives like 'add_tags', nor does it mention prerequisites such as needing the record's UUID beforehand or that this only removes existing tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of indicating this is a read-only operation returning suggestions rather than applying classification, which it does with the word 'Get'. However, it fails to describe what the proposals contain (suggested tags? groups?), how many are returned, or behavioral differences between the comparison modes.
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?
The single sentence is efficient and front-loaded with no redundant words. However, it borders on underspecification given the tool's behavioral complexity (multiple comparison modes, boolean flags) and lack of output schema.
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?
The description covers the core purpose but remains minimal for a 4-parameter tool with distinct operational modes. It does not explain the nature of classification proposals or expected return values, though the input schema is well-documented.
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?
Schema description coverage is 100%, providing detailed descriptions for all four parameters including the enum values for 'comparison'. The description adds no parameter-specific details, but the baseline score of 3 is appropriate given the schema's completeness.
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 (get classification proposals) and target resource (DEVONthink record). It implicitly distinguishes from sibling write operations like 'add_tags' or 'set_record_properties' by specifying this returns proposals rather than applying changes.
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?
No guidance provided on when to use this tool versus alternatives like 'search' or 'compare', or when to choose between the 'data comparison' and 'tags comparison' modes. No mention of prerequisites (e.g., whether the record must already exist in the database).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It appropriately flags the 'AI-generated' nature (indicating non-deterministic output), but omits critical behavioral details: whether the operation is idempotent, what happens if source documents are missing, storage implications, or whether the created document maintains links to sources.
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?
The description is a single, efficient sentence with no redundancy. However, it may be overly terse given the tool's complexity (AI generation with 5 parameters) and the absence of annotations or output schema, leaving room for additional context without sacrificing clarity.
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?
The description covers the core function adequately for a simple tool, but given the AI complexity and lack of annotations/output schema, it omits important context: default behaviors (implied by schema but not described), error handling for invalid UUIDs, and whether the summary updates automatically when sources change.
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 schema has 100% description coverage, establishing a baseline of 3. The description mentions 'multiple DEVONthink documents' which aligns with 'documentUuids', but adds no additional context about parameter interactions (e.g., how 'summaryStyle' affects output when combined with 'summaryType') or validation constraints beyond the schema.
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 specific action ('Create'), the nature of the output ('AI-generated summary document'), and the input source ('multiple DEVONthink documents'). It implicitly distinguishes from sibling 'create_record' by specifying AI-generated content, and from 'ask_ai_about_documents' by focusing on document creation rather than Q&A, though explicit differentiation is absent.
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?
The description provides no guidance on when to use this tool versus alternatives like 'ask_ai_about_documents' (for interactive Q&A) or 'create_record' (for manual content). It lacks prerequisites (e.g., requiring valid DEVONthink document UUIDs) and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It fails to state whether the operation is read-only, what happens when no matches are found, or the format/structure of returned results. 'Look up' implies safety but does not explicitly guarantee non-destructive behavior.
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?
The description is a single, efficient sentence with no redundant words. However, given the tool's complexity (6 parameters, no output schema, no annotations), it is arguably undersized rather than optimally concise, lacking necessary behavioral context.
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?
While the comprehensive input schema (100% coverage) reduces the description's burden for parameter explanation, the absence of annotations and output schema leaves significant gaps regarding return values, error handling, and safety guarantees that the description fails to address. Minimum viable for the complexity level.
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?
With 100% schema description coverage, the input parameters are fully documented in the schema itself. The description adds minimal semantic value beyond the schema, merely referencing 'specific attribute' which maps to the lookupType enum. Baseline score applies.
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 verb (look up), resource (records in DEVONthink), and method (by a specific attribute). However, it does not explicitly differentiate from sibling tools like 'search' or 'get_record_by_identifier', which could cause selection 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 phrase 'by a specific attribute' provides implied usage context, suggesting use when searching via known metadata fields (filename, path, etc.). However, it lacks explicit guidance on when to prefer this over 'search' or 'get_record_by_identifier', and states no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to clarify whether this tool modifies DEVONthink records, creates new documents, or is read-only; nor does it mention costs, rate limits, or output format expectations for the AI interaction.
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, efficient sentence with no wasted words. It is appropriately front-loaded with the core action and maintains high information density.
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 the 5 parameters, lack of annotations, and absence of an output schema, the description meets minimum viability by stating the core function. However, it lacks critical context about return values, side effects, or error handling that would help an agent predict the tool's impact and results.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though it implicitly frames the 'question' parameter around the use cases mentioned (analysis, comparison, extraction). It does not add syntax details or parameter relationships beyond what the schema provides.
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 provides a clear verb ('Ask'), resource ('AI'), and scope ('DEVONthink documents') with specific use cases ('analysis, comparison, or extraction'). However, it does not explicitly differentiate from siblings like 'compare', 'classify', or 'create_summary_document' which offer overlapping AI-powered functionality.
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 lists applicable use cases (analysis, comparison, extraction), providing implied guidance on when to use the tool. However, it lacks explicit guidance on when NOT to use it or which sibling tools ('compare', 'create_summary_document') might be more appropriate for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds valuable context that this depends on UI state ('currently selected'), but fails to describe the return format, what specific database metadata is returned, or whether the operation is safe/read-only.
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, efficient sentence with no redundant words. It front-loads the verb and resource, making it immediately scannable for an AI agent.
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?
While adequate for a parameterless tool, the description lacks specifics about the return value structure or content since no output schema is provided. It should indicate what database properties are returned (e.g., name, UUID, path) to be fully complete.
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 input schema contains zero parameters. Per evaluation rules, this establishes a baseline score of 4, as there are no parameter semantics to clarify beyond the schema definition.
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 identifies the action ('Get information') and target resource ('currently selected database'), including the application context (DEVONthink). It distinguishes from sibling 'get_open_databases' by specifying 'currently selected,' though it could clarify what 'information' specifically includes (name, ID, path, etc.).
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_open_databases.' It does not specify prerequisites (e.g., that a database must be selected) or error conditions if none is selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the behavioral constraint that groupPath must be database-relative and requires databaseName. However, it omits safety disclosures (read-only vs destructive), return format details, or pagination behavior expected for a search tool.
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?
Well-structured with purpose upfront, followed by examples and a constraint note. The examples are verbose but necessary for clarity. No redundant or wasted sentences.
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 the rich schema (100% coverage, 10 parameters), the description adequately covers invocation. However, with no output schema provided, the description should ideally explain what search results are returned (e.g., record metadata, content snippets, UUIDs).
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?
Input schema has 100% description coverage, establishing a baseline of 3. The description adds syntactic examples showing how parameters interact (groupPath with databaseName), but does not add semantic meaning beyond what the schema already provides for individual fields.
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?
States specific verb (Search) and resource (DEVONthink records) clearly. Examples reinforce the querying capability. However, it does not explicitly differentiate from siblings like 'lookup_record' or 'get_record_by_identifier' which also retrieve records.
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?
Provides concrete JSON examples showing parameter combinations. Includes a specific constraint note that groupPath requires databaseName. However, lacks explicit guidance on when to use this versus 'lookup_record', 'list_group_content', or 'selected_records'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose what 'information' comprises, behavior when nothing is selected, whether this requires specific permissions, or the return structure. 'Get' implies read-only, but this is weak inference without confirmation.
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?
Single sentence of eight words. Every word earns its place: action ('Get'), target ('information'), subject ('currently selected records'), and scope ('in DEVONthink'). No redundancy or filler.
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?
For a zero-parameter state-retrieval tool, the description identifies the core concept (current selection). However, lacking an output schema, it should ideally clarify what gets returned (IDs, properties, or content). It meets minimum viability but leaves functional gaps.
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?
Input schema has zero parameters. Per calibration rules, 0 params = baseline 4. The description correctly implies no filtering or identifiers are needed (operating on implicit UI state), which aligns with the empty schema.
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?
States a clear verb ('Get') and resource ('information about currently selected records') with scope ('in DEVONthink'). However, 'information' is vague given siblings like get_record_properties and get_record_content exist, leaving ambiguity about whether this returns identifiers, metadata, or full 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 phrase 'currently selected' implies UI-contextual usage (retrieving whatever the user has highlighted) versus direct lookup tools like get_record_by_identifier or search. However, it provides no explicit when-to-use guidance, prerequisites (e.g., DEVONthink running), or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully notes that the three layout keys are copied 'atomically' and that partial name matching is supported, but fails to explicitly state that this operation modifies the target entity, lacks error handling details, and omits idempotency characteristics.
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?
The description is efficiently structured with the core action stated first, followed by behavioral details (atomicity, partial matching), and ending with a practical example. There is minimal redundancy, though the input example slightly overlaps with schema documentation.
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 the lack of annotations and output schema, the description adequately covers what is copied and how matching works, but should explicitly confirm the write/mutation nature of the operation and describe success/failure indicators or return behavior to be fully complete.
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?
While the schema has 100% coverage, the description adds valuable semantic context beyond the schema by specifying that partial name matching is supported (affecting how sourceName/targetName are interpreted) and provides a concrete input example showing the expected parameter structure.
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 specific action (copy), the exact resource (column order, visible columns, column widths), and the entities involved (DEVONthink smart groups/smart rules). However, it does not explicitly distinguish itself from the sibling tool 'get_column_layout' or clarify that this is the write-oriented counterpart.
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?
It provides useful usage constraints including partial name matching support and includes a concrete JSON example showing required parameters. However, it lacks explicit guidance on when to use this versus 'get_column_layout' or prerequisites such as requiring the source to have a saved layout (only mentioned in the schema, not the description).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the return value ('Returns the full properties') and distinguishes required vs optional parameters. However, it omits critical behavioral details for a mutation tool: error handling (e.g., duplicate names), reversibility, permissions required, or side effects.
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?
Three efficiently structured sentences with no redundancy. Information is front-loaded with the action, followed by examples and optionality, ending with return value specification. Every sentence 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?
Given the high schema coverage (100%) and six parameters, the description adequately compensates for missing output schema by documenting the return value. It could be improved by mentioning error cases (e.g., invalid type strings) or database existence requirements, but is otherwise complete for the complexity level.
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?
Despite 100% schema description coverage (baseline 3), the description adds value by providing concrete examples for the 'type' parameter ('markdown', 'txt', 'rtf', etc.) and semantically grouping parameters as required ('Specify name and type') versus optional ('Optionally provide...').
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 ('Create') and resource ('new record') with specific scope ('in DEVONthink'). However, it does not explicitly differentiate from sibling tools like 'create_from_url' or 'create_summary_document', which could confuse selection when multiple creation options exist.
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?
The description provides no explicit guidance on when to use this tool versus alternatives such as 'create_from_url' or 'duplicate_record'. It lacks 'when-not-to-use' exclusions or prerequisites (e.g., permissions needed to create records).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully explains the conditional logic between `uuid` and `databaseName` parameters, but fails to disclose what 'content' entails (record objects, names, UUIDs?) or the return structure, leaving the agent uncertain about the result format since no output schema exists.
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 two sentences with zero waste. The first sentence establishes purpose immediately; the second efficiently covers both parameter interaction patterns. Every word earns its place.
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 the simple 2-parameter schema with full coverage, the description is minimally adequate. However, the absence of an output schema and annotations means the description should have described the return value or read-only nature to be complete; it falls short of this expectation.
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 schema has 100% description coverage, establishing a baseline of 3. The description paraphrases the schema's logic (omitting uuid lists root, databaseName ignored when uuid provided) without adding significant semantic enrichment like example UUID formats or clarifying that 'group' refers to DEVONthink's folder-like containers.
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 verb (Lists) and resource (content of a specific group in DEVONthink). It distinguishes from siblings like `get_record_content` (which retrieves binary content of a single record) through the use of 'Lists' implying enumeration of children/items, though it doesn't explicitly differentiate from `list_smart_groups`.
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 clear guidance on parameter usage patterns (supply UUID vs omit for root, use databaseName for named database), acting as implicit usage logic. However, it lacks explicit guidance on when to use this tool versus alternatives like `search` or `get_record_by_identifier` for finding items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It successfully explains lookup scope (UUID works across all open databases), but misses return value specification, error handling (what if ID not found?), and read-only safety confirmation.
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 well-structured sentences with zero waste. First sentence establishes core purpose; second provides critical parameter logic. Appropriately front-loaded.
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 100% schema coverage, parameters are well-documented. However, with no output schema and multiple sibling 'get_record_*' tools, the description should specify what this returns (likely a record reference/metadata) to distinguish from content/properties retrieval.
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?
With 100% schema coverage, baseline is 3. The description adds valuable semantic context about the relationship between parameters—specifically the cross-database vs single-database scope constraints that affect which identifier to use.
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?
Clear verb ('Get') and resource ('DEVONthink record') with specific identifier types (UUID/ID). However, it doesn't distinguish from sibling 'lookup_record' or clarify what 'get' returns (metadata vs reference) compared to 'get_record_content' or 'get_record_properties'.
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?
Provides clear guidance on parameter selection (UUID preferred for cross-database, ID requires databaseName), but lacks explicit 'when to use vs alternatives' guidance regarding 'search', 'lookup_record', or other retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a diagnostic check for availability and functionality, implying it's read-only and safe. However, it omits what constitutes 'working properly,' what the return value contains (boolean vs status object), or whether it performs actual AI inference tests versus simple connectivity checks.
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?
Single sentence of 10 words with no filler. Front-loaded with the action ('Check') and scope ('DEVONthink's AI services'). Every word earns its place in conveying the tool's function.
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 low complexity (no parameters, no nested objects, simple boolean/status return implied), the description is sufficiently complete for an agent to select and invoke it correctly. It could be improved by describing the return format, but the essential behavioral contract is clear.
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 tool has 0 parameters and schema description coverage is 100% (vacuously true). Per the baseline rule for zero-parameter tools, this scores a 4. No additional parameter semantics are needed or provided.
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 tool 'Check[s] if DEVONthink's AI services are available and working properly' - specific verb (check) and resource (AI services). It distinguishes from siblings like 'ask_ai_about_documents' and 'classify' by framing this as a diagnostic/availability check rather than an AI operation itself, though it doesn't explicitly name alternatives.
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 ('Check if... available') suggesting it should be used before attempting AI operations, but lacks explicit guidance such as 'call this before using ask_ai_about_documents' or troubleshooting scenarios. The when-to-use is inferred from the purpose but not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States what is checked but omits critical behavioral details: return value format (boolean vs string), behavior when app is not running (returns false vs throws error), and side effects.
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?
Single sentence, front-loaded with no waste. Appropriate length for a state-checking tool with no parameters.
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?
Adequate for simple tool but gaps remain given no output schema: missing return value semantics and error handling specifications. Sufficient for agent selection but insufficient for invocation confidence.
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?
Zero parameters with 100% schema coverage. Per guidelines, 0 params warrants baseline 4. Description appropriately requires no parameter explanation.
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?
Specific verb 'Check' + resource 'DEVONthink application' + condition 'currently running'. Clearly distinguishes from 25+ sibling tools that manipulate records/data, as this is the only application state checker.
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?
No explicit when-to-use guidance or alternatives mentioned. However, given the unique nature among data-manipulation siblings, usage is implicitly clear as a prerequisite check before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents the return format ('Returns renamed: true with uuid...'), but omits safety information such as whether the operation is reversible, permission requirements, or error handling when UUIDs are invalid.
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 consists of four efficient sentences that front-load the purpose, followed by input requirements and output specification. Each sentence contributes value without redundancy or extraneous information.
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 simple arity (3 parameters, 2 required) and lack of output schema, the description adequately covers the tool's contract by specifying inputs and return values. However, it could be improved by noting error conditions or side effects of the rename operation.
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 input schema has 100% description coverage for all three parameters (uuid, newName, databaseName). The description reinforces the required fields but does not add significant semantic meaning beyond what the schema already provides, meeting the baseline expectation for high-coverage schemas.
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 opens with 'Renames a specific record in DEVONthink,' providing a specific verb (renames) and resource (record). It clearly distinguishes from sibling operations like create_record, delete_record, or move_record through its specific focus on renaming.
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?
While the description states that 'UUID is required' and explains the parameter mapping, it does not explicitly contrast this tool with alternatives like set_record_properties (which might also modify record names) or specify when databaseName is necessary versus optional. The usage is implied by the parameter descriptions but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds context that the documentation includes 'examples and use cases,' hinting at the output structure. However, it fails to disclose safety characteristics (read-only vs. destructive), rate limits, or output format details that would help an agent understand the operational impact of calling this tool.
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 consists of exactly two sentences, both earning their place. The first establishes purpose and content scope; the second explains the parameter usage pattern. There is no redundant or extraneous text—every word contributes to agent understanding.
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 tool's low complexity (1 optional parameter, no nested objects, no output schema), the description is appropriately complete. It explains what the tool does, what it returns conceptually (documentation with examples), and how to use its single parameter. It could be improved by explicitly listing the four AI tool names in the description text rather than relying solely on the schema enum.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the semantic consequence of omitting the parameter ('omit to get docs for all four'), which is not explicitly stated in the schema description. This clarifies the filtering behavior beyond the raw schema definition.
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 tool retrieves 'detailed documentation for DEVONthink AI tools' and mentions specific content types ('examples and use cases'). It distinguishes from the 20+ sibling tools by specifying the 'AI tools' scope and referencing 'all four' to limit the domain, though it doesn't explicitly name the four tools in the description text.
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 provides clear guidance on parameter usage: 'Optionally specify a toolName to get docs for a single tool; omit to get docs for all four.' This effectively explains when to provide the parameter versus when to omit it. However, it lacks explicit guidance on when to use this tool versus general help resources or the other AI tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies a safe read operation via 'Get' and adds context about 'currently open' state, but fails to describe the return structure, format, or what constitutes an 'open' database since no output schema exists.
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 consists of a single, efficient sentence that front-loads the action verb. There is no redundant or wasted text; every word serves to clarify the tool's scope.
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?
While appropriate for the tool's low complexity (no input parameters), the description lacks information about return values since no output schema is provided. It should ideally describe what properties are returned for each database.
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 tool has zero parameters, which establishes a baseline score of 4 according to the evaluation rubric. No parameter documentation is required or present.
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 uses a specific verb ('Get') and resource ('list of all currently open databases') and clearly distinguishes from sibling tool 'current_database' by emphasizing 'all' versus a single database.
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?
Usage is implied by the description ('currently open' suggests runtime state), but there is no explicit guidance on when to use this versus 'current_database' or other database-related tools, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. The verb 'Get' implies read-only behavior, but lacks explicit safety declaration (readOnlyHint). Compensates by extensively listing return fields (uuid, name, type, etc.) since no output schema exists, though this describes output format rather than behavioral traits like side effects or rate limits.
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?
Three sentences with zero waste: purpose declaration, return value enumeration, and parameter usage pattern. Front-loaded with the core action, followed by specific details. No redundant or filler text.
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?
Well-compensated for missing output schema by listing extensive return fields. Parameter lookup patterns are clear. Only gap is lack of explicit read-only/safety declaration given zero annotations, though 'Get' strongly implies this.
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?
Despite 100% schema coverage, the description adds significant value by explaining parameter relationships and constraints: that uuid can be used alone while recordId/recordPath require databaseName, and that uuid is 'preferred'. This relational context is absent from the individual schema field descriptions.
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 ('Get') + specific resource ('detailed properties and metadata') + scope ('DEVONthink record'). Explicitly targets properties/metadata, distinguishing from siblings like get_record_content (likely returns file content) and lookup_record (likely returns basic identifiers).
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?
Provides implicit guidance by specifying three valid lookup patterns ('uuid preferred', 'recordId + databaseName', 'recordPath + databaseName'). However, lacks explicit when-to-use guidance versus similar lookup siblings like get_record_by_identifier or lookup_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the return value ('updated record properties'), but omits other behavioral details like error conditions, cross-database limitations, or explicit confirmation that the record is removed from the source location.
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?
Four well-structured sentences with zero waste: purpose first, resolution logic second, destination specification third, and return value fourth. Every clause 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?
Given 6 parameters, no annotations, and no output schema, the description adequately covers the resolution logic, destination requirements, and return format. Minor gaps remain regarding error handling and side effect specifics.
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?
Despite 100% schema coverage, the description adds valuable semantic context by establishing a preference hierarchy (uuid is 'preferred') and consolidating the parameter relationships into a coherent resolution strategy that aids agent reasoning.
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 opens with a clear, specific action ('Move a record') and context ('to a different group in DEVONthink'), distinguishing it from sibling tools like duplicate_record, replicate_record, or create_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?
While the description excellently explains how to resolve source records (uuid preferred vs. other methods), it lacks explicit guidance on when to choose this over similar operations like replicate_record or duplicate_record, or prerequisites for the move operation.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns that the operation is 'permanent' and explains the trash/deletion outcomes. It also documents the return value ('uuid and name of the deleted record') despite no output schema existing. Missing details include error handling for non-existent records and permission requirements.
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?
Four sentences cover purpose, safety warning, parameter usage patterns, and return values. Every sentence earns its place with zero redundancy. The description is front-loaded with the core action and efficiently structured.
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 4-parameter schema with no annotations, the description adequately covers the critical aspects: the destructive behavior, the mutually exclusive parameter combinations needed for lookup, and the confirmation return values. It could be improved with error scenario documentation, but it is complete enough for safe invocation.
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?
Although schema description coverage is 100% (baseline 3), the description adds significant value by indicating parameter preference ('uuid preferred') and explaining the logical dependencies between parameters (e.g., that databaseName is required for recordId lookups), which the schema structure alone doesn't convey.
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 opens with the specific verb 'Delete' targeting the resource 'record' within the domain 'DEVONthink'. It clearly distinguishes this from siblings like move_record or replicate_record by emphasizing the permanent/destructive nature of the operation.
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 crucial guidance on parameter combinations ('uuid (preferred)', 'recordId + databaseName', or 'recordPath + databaseName'), which is essential given zero required parameters in the schema. However, it lacks explicit guidance on when to use delete_record versus alternatives like move_record.
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?
No annotations provided, so description carries full burden. Successfully discloses key behaviors: creates independent copy (not linked), supports cross-database placement, and returns properties of new duplicate. Missing: permission requirements or idempotency notes.
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?
Three sentences, zero waste. Front-loaded with core action, followed by critical distinction from siblings, then capabilities and return value. No redundancy with structured schema data.
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?
Appropriately complete for a 5-parameter mutation tool with no output schema. Compensates by describing return value ('Returns the properties...') and explaining cross-database capability. Minor gap: does not clarify that uuid/recordId/recordPath are alternative identification methods.
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?
Schema has 100% description coverage, establishing baseline 3. Description reinforces that 'Destination group UUID is required' (matching schema's required array) but does not add semantic context about mutual exclusivity of uuid vs recordId/recordPath identification methods.
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-resource combination ('Duplicate a record') with explicit scope ('to any destination group'). Explicitly distinguishes from sibling tool 'replicate_record' by contrasting 'duplicates' with 'replicants' and explaining the independence property.
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 clear behavioral context to distinguish from 'replicate_record' (editing one does not affect the other). Implicitly guides selection by explaining the independence trait, though could be more explicit with 'Use this when you need independent copies vs. replicants for linked copies.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It successfully discloses partial-update behavior (unchanged properties persist) and identification preferences (uuid preferred). However, it fails to explicitly flag this as a write/mutation operation requiring existing record resolution, or disclose error behavior if resolution fails.
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?
Three dense sentences with zero waste: first declares action and valid properties, second explains record resolution hierarchy, third clarifies partial update semantics. Information is front-loaded and structured logically.
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?
For a complex 13-parameter tool with conditional resolution logic, the description adequately covers the property set, identification methods, and update behavior. However, given the lack of annotations and output schema, it should explicitly state this performs write operations on existing records to complete the safety profile.
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?
Despite 100% schema description coverage, the description adds valuable semantic context: clarifying UUID is 'preferred' over other methods, grouping coupled parameters (recordId + databaseName), and mapping technical terms to UI concepts (flag/flagged, locked/locking). This goes beyond raw schema documentation.
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?
Description explicitly states 'Set properties on a DEVONthink record' with a comprehensive enumerated list of settable properties (comment, flag, locked, excludeFrom*). This clearly distinguishes it from sibling tools like get_record_properties (read) and update_record_content (content vs metadata).
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 explicit resolution strategy ('Resolve record by uuid (preferred), recordId + databaseName, or recordPath + databaseName') and critical update semantics ('Only provided properties are updated'). However, lacks explicit 'when to use vs alternatives' guidance comparing it to create_record or get_record_properties.
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?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully describes the return format ('updated: true with uuid and name') since no output schema exists, and clarifies how content is interpreted for different record types. It could be improved by explicitly stating that this operation overwrites existing content.
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?
Four tightly constructed sentences with no waste: purpose statement, content-type behavior, required parameter reminder, and return value documentation. Every sentence earns its place, particularly the return value documentation which compensates for the missing output schema.
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?
For a 2-parameter mutation tool with no annotations and no output schema, the description is remarkably complete. It covers the operation purpose, parameter semantics for content types, and return structure. Minor gap: does not explicitly warn about destructive overwrite behavior or prerequisites like record existence.
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?
While the input schema has 100% description coverage (baseline 3), the description adds valuable semantic context about the content parameter—specifically that it sets 'plain text' for text records and 'source' for HTML/Markdown records. This type-specific behavior is not inferable from the schema alone.
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 specific action (updates content), target resource (existing record in DEVONthink), and distinguishes from siblings like create_record (creates vs updates) and set_record_properties (content vs properties). It further clarifies handling for different record types (text vs HTML/Markdown).
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 implicit usage guidance by clarifying content handling for different record types (plain text vs source), but lacks explicit when-to-use guidance versus close siblings like set_record_properties. It states 'UUID is required' but this is redundant with the schema's required field.
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?
Excellent disclosure given zero annotations. Explicitly details return value variations (plain text vs HTML source vs null for binary), which is critical since no output schema exists. Fully describes the content retrieval behavior across different record types.
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?
Four sentences, each earning its place: purpose statement, text/HTML return behavior, binary null behavior, and parameter requirements. Front-loaded with the core action, no redundancy or filler despite covering multiple content type scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a content retrieval tool. Compensates for missing output schema by detailing all possible return types (text, HTML, null). Covers both parameters adequately given the 100% schema coverage. Sufficient for agent to invoke correctly without external documentation.
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?
Schema coverage is 100%, with uuid and databaseName fully documented in the schema. Description restates 'UUID is required; databaseName is optional' which confirms the schema's required field and descriptions but adds no additional semantic context beyond the structured definitions.
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 'Gets' + specific resource 'content of a specific record' + domain context 'DEVONthink'. Distinguishes from siblings like get_record_properties (metadata vs content) and update_record_content through the 'Gets' verb and return type descriptions.
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?
Provides implied usage guidance by documenting that binary records return null, warning agents not to expect extractable content from PDFs/images. However, lacks explicit comparison to siblings like get_record_properties or lookup_record for when to choose this over alternatives.
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?
No annotations provided, so description carries full burden. It discloses return values ('ordered visible columns, all table view columns, and column widths'), lookup behavior (partial matching), and data source (preferences). Missing error behavior (what happens if neither name nor UUID finds a match), but otherwise comprehensive for a read-only tool.
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?
Every sentence delivers distinct value: purpose statement, return value disclosure, lookup mechanism, matching behavior, and concrete examples. No redundancy or filler. Front-loaded with core action, followed by outputs, then input guidance.
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?
For a 2-parameter read tool without output schema, the description adequately covers return structure and lookup behavior. The concrete examples demonstrate valid input patterns. Minor gap: does not specify return format (object/array) or error handling when lookups fail.
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?
Schema coverage is 100%, establishing baseline 3. Description adds valuable behavioral context: 'Supports partial name matching' for the name parameter and clarifies the UUID is a 'fallback'. The concrete JSON examples ('Input: { "name": ... }') add practical usage semantics beyond the schema definitions.
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?
Description opens with specific verb 'Read', targets 'column layout' for 'DEVONthink smart group or smart rule', and specifies the source 'from preferences'. Clear scope distinguishes it from sibling tools like list_smart_groups (which lists the groups themselves) and copy_column_layout (which transfers layouts).
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 clear lookup guidance: 'Looks up by name (or UUID)' and explains the UUID parameter serves as a 'fallback if name not found'. Also notes 'Supports partial name matching'. Lacks explicit comparison to copy_column_layout for when to read vs. copy, but provides strong contextual usage patterns.
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?
No annotations provided, but description carries burden well by disclosing data source (SmartRules.plist), read-only nature (implied by 'List' and 'parsing'), and detailed return structure (compensating for missing output schema). Could explicitly state 'safe/read-only' given no 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?
Three sentences with zero waste: action+method, return values, and unique usage context. Front-loaded with essential information; every sentence 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?
Excellent coverage given no output schema and no annotations. Lists all return fields (name, UUID, enabled state, etc.) and explains the unique value proposition (AppleScript limitation). Minor gap: doesn't mention performance characteristics of plist parsing.
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?
Input schema has 0 parameters. Description appropriately mentions no parameters, meeting the baseline of 4 for zero-parameter tools.
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?
Specific verb 'List' + resource 'DEVONthink smart rules' + implementation detail 'parsing SmartRules.plist'. Clearly distinguishes from sibling 'list_smart_groups' by specifying 'smart rules' and noting these are inaccessible via AppleScript API.
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 explicit context that this is 'the only way to enumerate them' due to AppleScript API limitations. Implies when to use (when you need smart rules specifically), though could explicitly contrast with 'list_smart_groups' for clarity.
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?
No annotations provided, so description carries full burden. It discloses return fields (message_id, in_reply_to, etc.) compensating for missing output schema, and details specific parsing behaviors: CRLF/LF handling, folded headers, and RFC 2047 encoded word support.
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?
Four sentences front-loaded with purpose first. Each sentence earns its place: purpose, return values, behavioral details, and input example. Minor deduction as the input example is slightly redundant given complete schema coverage, though still helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a single-parameter parsing tool. Compensates for missing output schema by enumerating all returned fields and compensates for missing annotations by detailing RFC compliance behaviors (2047, folded headers, line endings).
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?
Schema has 100% description coverage ('Absolute path to the .eml file to parse'), establishing baseline 3. Description adds an input example but no additional semantic constraints (e.g., file extension requirements, path validation rules) beyond the schema.
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 uses specific verb 'Extract' with clear resource 'MIME headers from an .eml file' and specific use case 'for email thread correlation'. It clearly distinguishes from all siblings which are database/record management tools with no email parsing functionality.
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 clear context with 'for email thread correlation' indicating the specific use case. However, lacks explicit when-not-to-use guidance or named alternatives (though no email parsing siblings exist to compare against).
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?
With no annotations provided, the description carries full burden and successfully discloses the critical behavioral trait: 'Replicants share the same underlying data — editing one affects all replicants.' It also notes the return value. Missing minor safety hints (permissions, reversibility) but covers the essential mutation semantics.
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?
Four sentences with zero waste: (1) purpose/scope, (2) critical behavioral distinction, (3) required parameter, (4) resolution options and return value. Front-loaded with the core action and efficiently structured.
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 5 parameters with complex lookup logic and no annotations, the description adequately covers the replication model, parameter relationships, and return value. Slightly short on error conditions or edge cases (e.g., invalid destination group), but sufficient for correct invocation.
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?
Schema coverage is 100% so baseline is 3. The description adds significant value by specifying the lookup resolution hierarchy ('uuid preferred'), explaining parameter dependencies (recordId requires databaseName), and clarifying the mutual exclusivity logic of the identification parameters.
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?
Specific verb 'Replicate' + resource 'record' + scope 'within the same database to a destination group'. Crucially distinguishes from sibling 'duplicate_record' by defining replicants as sharing underlying data, making the tool's unique purpose immediately clear.
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?
Explains three valid methods to resolve the source record (uuid preferred, or recordId/databaseName, or recordPath/databaseName) and states the destinationGroupUuid requirement. Implies when to use versus 'duplicate_record' by emphasizing the shared-data behavior, though it doesn't explicitly name the sibling alternative.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure and succeeds admirably. It discloses the non-destructive nature (original preserved), lists all supported format enumerations, mentions the optional destination placement side effect, and describes the return value ('Returns the properties of the newly created converted record') despite the absence of an output schema.
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?
The description is well-structured with the core action front-loaded, followed by immutability guarantees, format options, optional parameters, and return value. The format list is lengthy but justified given the lack of schema enum definition. Minor wordiness ('creating a new record' vs 'creates a new record') prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's medium complexity (5 parameters, format conversion logic) and the absence of both annotations and an output schema, the description is remarkably complete. It covers the operation's scope, behavioral constraints, input requirements (via format list), side effects, and return value, leaving no critical gaps for an agent to invoke the tool correctly.
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?
While the schema has 100% coverage of its defined properties, the description adds critical semantic value by enumerating the supported format strings (which appears to be a required parameter missing from the schema properties object) and clarifying that the destination group is optional. It could further improve by explaining the mutual exclusivity logic between uuid, recordId, and recordPath.
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 core action ('Convert a record to a different format') and explicitly distinguishes this tool from update or duplicate operations by stating it creates a new record while leaving the original unmodified. This specificity helps the agent select it correctly over sibling tools like update_record_content or duplicate_record.
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 provides clear behavioral context by emphasizing that the original record is preserved and a new record is created, implicitly guiding against using this for in-place edits. However, it does not explicitly name alternative tools (e.g., 'use update_record_content to modify in place') or state explicit prerequisites, stopping short of a perfect score.
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?
With no annotations provided, description carries full burden. Discloses return values (name, UUID, sync date, UseUUIDKey), data source (SmartGroups.plist), and API limitation. Lacks explicit safety declarations (read-only status) or error handling details, but effectively explains the parsing behavior and output structure.
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?
Three sentences with zero waste: 1) Action and returns, 2) Critical limitation/distinction, 3) Integration with sibling tool. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description comprehensively documents return values. Adequately explains domain-specific concept (smart groups vs regular groups) and relationships to other tools in the absence of annotations or structured output schema.
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?
Zero parameters present with 100% schema coverage (trivially). Description correctly focuses on behavior rather than parameters, meeting the baseline for zero-parameter tools.
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?
States specific verb 'List' with resource 'DEVONthink smart groups' and implementation method 'parsing SmartGroups.plist'. Explicitly distinguishes from siblings by noting smart groups are 'NOT accessible via the standard AppleScript API' and references the 'search' tool for subsequent operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('this is the only way to enumerate them') and clear next-step instructions ('Use the returned uuid with the search tool'). Names the specific sibling tool and parameter ('search tool (groupUuid parameter)') for querying contents.
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

Copy to your README.md:

[![Devon MCP server](https://glama.ai/mcp/servers/mnott/Devon/badges/card.svg)](https://glama.ai/mcp/servers/mnott/Devon)

Score Badge

Copy to your README.md:

[![Devon MCP server](https://glama.ai/mcp/servers/mnott/Devon/badges/score.svg)](https://glama.ai/mcp/servers/mnott/Devon)

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/mnott/Devon'

If you have feedback or need assistance with the MCP directory API, please join our Discord server