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

With no annotations provided, the description carries full burden and does well by describing duplicate title detection behavior with user choices (skip, forceCreate, update), content requirements for different note types, and special handling for various note types. It doesn't cover all behavioral aspects like error handling or response format, but provides substantial operational context.

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

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

Well-structured with purpose statement, behavioral details, usage guidelines, and a tip. Every sentence adds value, though it could be slightly more concise by integrating the TIP into the content requirements section. Front-loaded with core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter creation tool with no annotations and no output schema, the description provides substantial context about behavior, usage constraints, and content requirements. It covers the most critical aspects an agent needs to use the tool correctly, though doesn't describe return values or error cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about content requirements for code notes and duplicate handling, but doesn't provide significant additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'create' and resource 'note', specifies the system (TriliumNext), and mentions duplicate title detection which distinguishes it from siblings like update_note. It provides specific purpose beyond just the name.

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

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

Explicitly states when to use ('ONLY use this tool when the user explicitly requests note creation') and when not to use ('DO NOT use this tool proactively or when the user is only asking questions about their notes'). Also provides a tip about code notes, giving clear operational guidance.

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

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 communicates critical behavioral traits: the action is permanent ('cannot be undone'), destructive ('permanently remove the note and all its content'), and requires explicit user intent. However, it lacks details on error handling, permissions, or rate limits, which are relevant for a destructive operation.

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

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

The description is appropriately sized and front-loaded, with the core purpose stated first ('Delete a note permanently'). Each sentence adds value: usage guidelines, cautionary notes, and irreversible consequences. There is no redundant or unnecessary information, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operation with no annotations or output schema), the description is mostly complete. It covers purpose, usage constraints, and behavioral risks. However, it could be more complete by mentioning potential errors (e.g., invalid noteId) or confirming deletion success, though the absence of an output schema reduces the need for return value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'noteId' parameter clearly documented. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or validation rules. This meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('delete permanently') and resource ('a note'), distinguishing it from siblings like 'update_note' or 'get_note'. It explicitly mentions the permanent removal of content, which sets it apart from tools that might archive or modify notes.

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

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

The description provides explicit guidance on when to use this tool ('ONLY use this tool when the user explicitly requests note deletion') and when not to use it ('TRY NOT to use this tool proactively or for automated cleanup'). It includes examples of user requests (e.g., 'delete the note') to clarify the context, though it does not name specific alternative tools.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it retrieves note content, excludes binary content by default for performance, and allows explicit retrieval of binary data. It also hints at performance implications and search limitations for file/image notes. However, it doesn't cover error handling, rate limits, or authentication needs, which are gaps for a tool with 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.

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

The description is appropriately sized and front-loaded, starting with the core purpose. The first sentence clearly states the tool's function, and subsequent sentences add useful context without redundancy. However, the use of emojis and some verbose phrasing (e.g., 'Perfect for when someone wants to see what's in a note') slightly reduces efficiency, but overall, it remains concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers the main purpose, usage scenarios, and key behavioral traits like binary content handling. However, it lacks details on return values, error conditions, and how it differs from sibling tools, which are important gaps for an agent to use it correctly without an output schema or annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, such as mentioning 'SMART CONTENT INCLUSION' and use cases for parameters, but it doesn't provide significant additional semantics. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with extra insights.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a note and its content by ID.' It specifies the verb ('Get') and resource ('note and its content'), making the function unambiguous. However, it doesn't explicitly differentiate from siblings like 'read_attributes' or 'search_notes' beyond mentioning 'extract specific information' and 'prepare for search and replace operations,' which are use cases rather than distinctions.

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

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

The description provides implied usage guidelines by listing scenarios: 'when someone wants to see what's in a note, extract specific information, or prepare for search and replace operations.' It also mentions alternatives like using 'includeBinaryContent: true' for binary data, but it doesn't explicitly state when to use this tool versus siblings such as 'search_notes' or 'read_attributes,' leaving some ambiguity.

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

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 does so comprehensively. It reveals critical behavioral traits: write-only access, update limitations (only label value/position and relation position can be updated), the immutable nature of isInheritable property, requirements for relation values (must point to existing notes), and performance considerations for batch operations. This goes well beyond what the input schema provides about constraints.

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

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

The description is appropriately sized and front-loaded with the core purpose and key limitation (write-only access). Each sentence adds value: distinguishing from read operations, explaining attribute types, detailing update limitations, and mentioning performance benefits. While comprehensive, it remains focused without unnecessary repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with 3 parameters, 100% schema coverage, but no annotations or output schema, the description provides substantial context about behavioral constraints, usage patterns, and limitations. It covers the tool's scope, update restrictions, relation requirements, and performance considerations. The main gap is the lack of information about return values or error conditions, but given the comprehensive behavioral disclosure, this is a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the baseline is 3. The description adds meaningful context about parameter usage: it explains the purpose of different attribute types (labels for #tags, relations for ~connections), provides concrete examples of name values ('status', 'priority', 'template', 'author'), and clarifies value requirements for relations. However, it doesn't add significant semantic information beyond what's already well-documented in the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('manage', 'create', 'update', 'delete') and resources ('note attributes'), and distinguishes it from the sibling tool 'read_attributes' by explicitly stating this is for write operations only. The description provides concrete examples of what can be managed (labels, template relations) and how they're used.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: it states 'use read_attributes to view existing attributes' and mentions 'efficient batch creation for better performance' as a performance consideration. It also specifies that this tool 'only provides write access,' clearly delineating its scope from read operations.

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

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 explicitly states 'read-only access' (safety profile), describes what gets returned ('structured data with labels, relations, and summary information'), and specifies the scope ('all attributes'). It doesn't mention error conditions or performance characteristics, but provides solid behavioral context.

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

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

Three sentences with zero waste. First sentence states purpose and scope, second clarifies access type, third describes return format. Every sentence adds value and the description is appropriately sized for a single-parameter read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with no annotations and no output schema, the description provides good coverage: purpose, scope, safety profile, and return format. It could benefit from mentioning what happens with invalid note IDs or whether it returns empty results for notes without attributes, but overall it's quite complete for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the single 'noteId' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, but doesn't need to since schema coverage is complete. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Read all attributes'), the resource ('for a note'), and what it returns ('labels and relations'). It distinguishes from siblings like 'get_note' by focusing specifically on attributes rather than the full note content, and from 'manage_attributes' by being read-only.

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

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

The description provides clear context for when to use it ('to inspect current attributes assigned to any note') and implicitly distinguishes it from write operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives like 'get_note' for full note content versus just attributes.

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

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 describes key behaviors: 'Simple title-based search with user choice when multiple matches found' and mentions fuzzy search capabilities in the parameter context. However, it doesn't address potential failure modes or error conditions.

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

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

The description is efficiently structured in two sentences: the first states the core purpose, the second provides usage rules and behavioral context. Every element serves a clear purpose with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a lookup tool with no annotations and no output schema, the description provides good context about purpose, usage rules, and basic behavior. However, without an output schema, it doesn't describe what format the resolved ID will be returned in or what happens when no matches are found.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it reinforces the noteName parameter's purpose. Baseline 3 is appropriate when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific purpose: 'Resolves a note/folder name to its actual note ID for use with other tools.' It distinguishes this from sibling tools like get_note or search_notes by emphasizing the ID resolution function rather than content retrieval or general search.

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

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

Explicit guidance is provided: 'You MUST call this function when users provide note names instead of note IDs... UNLESS the user explicitly provides a note ID.' This creates clear when-to-use rules and distinguishes it from tools that work directly with IDs.

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

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 describes the mutation nature of the operation ('replace content'), specifies a safety mechanism ('create a backup before replacing' via the revision parameter), and outlines a concurrency control requirement ('expectedHash' to ensure working with the latest version). However, it doesn't mention potential error conditions 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.

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

The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, and the second provides critical workflow guidance. There's no redundancy or unnecessary elaboration, and the information is front-loaded with the most important details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 7 parameters, no annotations, and no output schema, the description does well by explaining the core operation, safety considerations, and required workflow. However, it doesn't describe what the tool returns or potential error cases, leaving some gaps in understanding the complete interaction context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds some context about the 'expectedHash' parameter ('Content hash from get_note response') and implies the workflow relationship, but doesn't provide additional semantic meaning beyond what's already documented in the comprehensive schema descriptions for all 7 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the specific action ('search and replace content within a single note'), clearly identifying both the verb and resource. It distinguishes from siblings like 'update_note' by focusing on text replacement rather than general updates, and from 'search_notes' by operating on content within a single note rather than searching across notes.

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

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

The description provides explicit guidance on when to use this tool ('When someone wants to replace text in a note') and includes a clear prerequisite workflow ('first call get_note to get the current content and hash, then use this function'). It also distinguishes from alternatives by specifying this is for content replacement within a single note, not for other note operations.

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

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

Since no annotations are provided, the description carries full burden. It effectively describes the tool's behavioral traits: it's a read-only search operation (implied by 'search'), supports comprehensive filtering, handles boolean logic, and includes hierarchy navigation. However, it doesn't mention rate limits, authentication requirements, or pagination behavior, which would be helpful 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.

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

The description is overly verbose and poorly structured. It's a single dense paragraph mixing high-level purpose with detailed parameter usage examples. Important guidance is buried in the middle rather than front-loaded. While informative, it could be much more concise and better organized for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no annotations and no output schema, the description does a good job explaining what the tool does and how to use it. It covers the main functionality, parameter usage, and provides concrete examples. However, it lacks information about result format, pagination, error handling, or performance characteristics that would be useful for a comprehensive search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds some value by explaining when to use 'text' vs 'searchCriteria' parameters and providing examples of template values, note types, and MIME types. However, it doesn't significantly enhance parameter understanding beyond what's already well-documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Unified search with comprehensive filtering capabilities' and lists specific search types (keyword, date ranges, field-specific, etc.). It distinguishes from siblings by focusing on search functionality rather than CRUD operations like create_note, delete_note, or update_note.

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

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

The description provides explicit guidance on when to use different parameters: 'For simple keyword searches, use the 'text' parameter. For complex boolean logic... use searchCriteria.' It also gives specific examples for template searches, note type searches, and MIME type searches, clearly indicating appropriate usage scenarios.

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

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

With no annotations provided, the description carries the full burden and delivers comprehensive behavioral disclosure. It explains immutability constraints (note type and MIME type), concurrency protection (expectedHash prevents overwriting other users' changes), mode selection logic, file type matching requirements, revision behavior, and workflow prerequisites. No contradictions exist since annotations are absent.

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

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

The description is appropriately front-loaded with core functionality and warnings, but it's lengthy due to necessary detail for a complex tool. Every sentence earns its place by providing critical guidance (e.g., mode selection rules, immutability constraints, workflow steps). Some redundancy exists (e.g., multiple warnings about get_note), but overall structure supports clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with 7 parameters, no annotations, and no output schema, the description provides exceptional completeness. It covers prerequisites (get_note), constraints (immutable types, file matching), behavioral nuances (revision defaults, mode selection), error prevention (hash verification), and alternatives (create_note for type changes). No significant gaps remain given the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter interactions and semantics: it clarifies when to use title-only updates, distinguishes between append/overwrite modes with user intent examples, explains fileUri constraints, and emphasizes the critical role of expectedHash. However, it doesn't fully detail all 7 parameters' nuances beyond what the schema already covers well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'update' with the resource 'note' and specifies multiple update types (title-only, content overwrite, content append, file replacement). It distinguishes from siblings by focusing on updates rather than creation (create_note), deletion (delete_note), or retrieval (get_note).

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

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

Explicit guidance is provided on when to use this tool vs alternatives: 'ALWAYS call get_note first to obtain current hash', 'To change file types, create a new note instead', 'ONLY use when user explicitly requests note update'. It also distinguishes from sibling tools by outlining a specific workflow (get_note → review content → update_note).

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