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

No annotations provided, so the description carries full burden. While 'Create' implies a write operation, there's no disclosure of critical behavioral traits: backup format, whether it overwrites existing files, if it's blocking/synchronous, handling of large datasets, or restoration requirements. For a storage-intensive backup operation, this is a significant gap.

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?

Single sentence of nine words with no filler. The core value proposition ('full backup') is front-loaded. Appropriate length for the information provided, though the information provided is minimal.

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 backup tool with no output schema and no annotations, the description is insufficient. It omits backup format, scope (attachments? metadata?), overwrite behavior, and return value indicators. With zero required parameters, the agent lacks guidance on what constitutes a valid minimal invocation.

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%, with 'destination' and 'encrypt' already documented in the schema. The description doesn't add parameter syntax details or format examples (e.g., path format), but meets baseline expectations given the schema's completeness.

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

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

Clear verb ('Create') and resource ('full backup of all notes and settings'). The mention of 'settings' distinguishes it from sibling tools like export_to_json or notes_* operations that likely handle only note content. However, it doesn't explicitly contrast with export_to_cloud despite the local path-based destination implying a difference.

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?

No guidance on when to use this tool versus export_to_cloud or export_to_json. No mention of prerequisites (e.g., disk space requirements) or when not to use it. The agent must infer usage context solely from the tool name.

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?

No annotations are provided, so the description carries full disclosure burden. It fails to mention critical behavioral aspects: authentication requirements (OAuth/tokens), whether the operation is destructive (overwrites existing files), folder creation behavior if path doesn't exist, rate limits, or return value format (URL, ID, or success boolean).

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

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

The description is a single, efficiently structured sentence of seven words. It front-loads the action and resource with zero filler text. Every word earns its place.

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

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

Given the tool's complexity (cloud integration with 4 provider options), the description is minimally viable. The input schema is fully documented, but the description omits crucial cloud-specific context like authentication flows and output format. Without an output schema or annotations, the description should disclose what the export operation returns or how to verify success.

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 schema adequately documents parameters. The description adds example provider mappings ('Google Drive' for 'google', 'Dropbox' for 'dropbox') which provides minor semantic value beyond the schema's generic 'Cloud provider' label, but does not elaborate on parameter formats, constraints, or the optional nature of the folder parameter.

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 uses a specific verb ('Export') with clear resource ('notes') and destination ('cloud storage'). It implicitly distinguishes from siblings like 'export_to_json' (local file) and 'search_notes' (read-only query) by specifying cloud destination. However, it does not explicitly differentiate from 'export_backup' which may also use cloud storage.

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 no guidance on when to use this tool versus alternatives like 'export_to_json' or 'export_backup'. It lacks prerequisites (e.g., required authentication setup for cloud providers) and does not mention when-not-to-use scenarios or error conditions.

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, yet it fails to mention critical file operation semantics such as overwrite behavior, default output locations when 'outputPath' is omitted (despite it being optional), or whether the operation is atomic. The description only implies a write operation via 'Export' without detailing 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.

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

The description is a single, efficient sentence with no redundant or circular phrasing. However, it may be overly terse given the complexity of file export operations and the lack of supporting annotations or output schema.

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 file-writing tool with no output schema and no annotations, the description inadequately covers operational semantics. It fails to specify what occurs when optional parameters are omitted, whether existing files are overwritten, or what confirmation/data is returned upon completion, leaving dangerous gaps for an agent performing filesystem mutations.

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 for both parameters ('Output file path' and 'Include file metadata'), establishing a baseline where the description need not compensate. The description adds no additional semantic context about path formats, relative vs. absolute paths, or the nature of the metadata included, but meets the minimum threshold given the schema's completeness.

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

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

The description clearly states the action ('Export'), target ('all notes'), and format ('JSON file'), providing specific semantic content beyond the tool name. However, it does not explicitly differentiate from sibling tools 'export_backup' or 'export_to_cloud', leaving ambiguity about whether those tools also use JSON format or serve different use cases.

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 no guidance on when to select this tool versus the sibling 'export_backup' or 'export_to_cloud' tools. It omits prerequisites such as file system permissions, directory existence requirements, or whether this operation is reversible.

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. While it states 'delete,' it fails to disclose scope (global vs. user-specific), which timestamp is evaluated (created vs. modified), whether the operation is reversible, or what the return value contains (count deleted, success boolean, etc.).

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 single-sentence description is efficiently structured and front-loaded with the action verb. However, for a high-risk bulk deletion tool, this brevity constitutes underspecification rather than effective conciseness, as it sacrifices necessary safety and scope context.

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 this is a destructive bulk operation with no annotations and no output schema, the description is incomplete. It omits critical context including the irreversible nature of the action, the specific date field used for filtering, the scope of deletion, and the response format.

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%, establishing a baseline of 3. The description mirrors the parameter description ('older than specified days') but does not add clarifying semantics, such as which date field is used for age calculation or whether the threshold is inclusive/exclusive.

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 uses a specific verb ('delete') and resource ('notes') with clear scope criteria ('older than specified days'). The age-based criteria implicitly distinguishes this from the sibling 'notes_delete' tool, which likely targets specific notes by ID rather than bulk age-based cleanup.

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?

No guidance is provided on when to use this versus 'notes_delete' for selective deletion, nor are prerequisites mentioned. Critically, given this is a bulk destructive operation, there are no warnings to use 'export_backup' first or cautions about irreversibility.

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. While 'Create' implies a write operation, the description fails to disclose idempotency behavior, what happens if a note with the same title exists, or what the tool returns upon completion.

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?

Single sentence with no waste. The core action is front-loaded ('Create a new note') followed immediately by the parameter reference. Every word earns its place.

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

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

Given the simplicity (2 parameters, no nested objects, no output schema), the description covers the minimum necessary. However, without annotations or output schema, it should ideally mention return behavior or side effects (e.g., ID generation, confirmation) to be fully complete.

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 description references 'title and content' which maps to the two parameters, but with 100% schema description coverage already providing clear definitions ('Title of the note', 'Content of the note'), the description adds no additional semantic value beyond naming the 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 clearly states the verb (Create) and resource (note), distinguishing it from sibling tools like notes_delete, notes_read, and search_notes through the action-oriented language. However, it doesn't explicitly differentiate from potential update or duplicate scenarios.

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?

No guidance provided on when to use this tool versus alternatives (e.g., when to create vs. update, or whether to check for existing notes first). No prerequisites or conditions mentioned.

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 full burden and successfully discloses critical behavioral trait: immediate execution without confirmation. However, it omits error handling (what if title not found) and reversibility details.

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?

Extremely efficient two-sentence structure: first sentence states purpose, second discloses behavioral risk. No redundant or filler content; information density is optimal.

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?

Appropriate for a single-parameter destructive tool. The immediate-execution warning suffices given the simplicity, though mentioning error cases (e.g., title not found) would improve completeness.

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 coverage is 100% (title parameter fully described), so baseline applies. Description reinforces that deletion is by title but does not add syntax constraints, validation rules, or uniqueness requirements beyond 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?

Description provides specific verb ('Delete'), resource ('note'), and scope ('by title'), clearly distinguishing it from sibling tools like notes_create, notes_read, and notes_cleanup.

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?

Contains implicit usage guidance through the warning 'Executes immediately without confirmation,' but lacks explicit when-to-use criteria or differentiation from notes_cleanup for bulk 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?

No annotations provided, so description carries full burden. Fails to disclose error behavior (what happens if title not found?), return format, case sensitivity rules, or whether partial matches are accepted.

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?

Five words, zero waste. Verb-fronted structure ('Read a note...') immediately communicates action. No redundant phrases or filler.

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?

Minimally adequate for a single-parameter read operation with 100% schema coverage. However, gaps remain regarding error handling and distinction from search functionality given the presence of three search siblings.

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 coverage is 100%, establishing baseline 3. Description echoes the parameter purpose ('by its title') but adds no additional constraints, format examples, or validation rules beyond 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?

Clear verb ('Read') and resource ('note') with specific lookup mechanism ('by its title'). Distinguishes from mutation siblings (create/delete) and export tools, though it doesn't explicitly differentiate from search_notes for partial matches.

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

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

Provides no guidance on when to use this versus search_notes or search_advanced. Does not mention prerequisites (e.g., note must exist) or exact title matching requirements.

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 full disclosure burden but fails to specify behavioral traits: it doesn't state whether the operation is read-only, what format the summary returns in, length constraints, or error handling if the title doesn't exist.

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 single sentence is appropriately front-loaded and contains no wasted words. However, extreme brevity contributes to underspecification—it earns points for efficiency but loses the opportunity to add necessary behavioral context.

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 2-parameter tool with full schema coverage and no output schema, the description meets minimum viability by identifying the core operation. However, it lacks critical context about the return value (string? object? saved to note?) and side effects, which are essential given zero annotation coverage.

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 coverage is 100%, establishing a baseline of 3. The description mentions 'note' which loosely maps to the 'title' parameter, but adds no semantic context beyond the schema (e.g., examples of customPrompt usage or title format requirements).

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 uses a specific verb ('Generate') and resource ('AI summary of a note'), clearly distinguishing it from sibling tools like notes_read (which presumably returns raw content) and notes_create. However, it lacks explicit scope clarification (e.g., length, format of summary) that would make it a 5.

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?

No guidance provided on when to use this versus notes_read, or when customPrompt is necessary versus optional defaults. No mention of prerequisites like the note existing or potential costs/tokens for AI generation.

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 but inadequately discloses critical behavioral traits. While it mentions searching 'system files,' it fails to warn that the tool accesses sensitive credential directories (/.ssh, /.aws per the parameter schema) or disclose authorization requirements, output format, or depth of recursion. The phrase 'the agent should automatically expand' is an imperative instruction rather than behavioral disclosure.

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 two sentences, but the second sentence ('For maximum results, the agent should...') is structurally misplaced. It instructs the agent how to behave rather than describing the tool's capabilities, violating the expectation that descriptions characterize the tool, not command the agent.

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 explicit capability to access sensitive system directories containing credentials (per parameter schema), the description is dangerously incomplete. It lacks security warnings, privacy considerations, or scope limitations necessary for a tool that searches ~/.ssh and ~/.aws directories. No output schema exists to compensate.

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 coverage is 100%, establishing a baseline of 3. The description mentions 'regex support' which aligns with the 'pattern' parameter, but adds no further semantic context about syntax expectations or the implications of 'includeMetadata' beyond what the schema already provides.

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 identifies regex support and mentions 'system files and environment variables' as the search domain, which distinguishes it from sibling tools like search_notes. However, 'Advanced search' remains vague and doesn't explicitly clarify whether this operates on the filesystem, a database, or 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 no guidance on when to use this tool versus search_by_date, search_notes, or other siblings. The second sentence offers operational advice ('expand the search scope') rather than selection criteria, failing to help the agent choose between available search 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Search' implies a read-only operation, the description does not clarify return format, pagination behavior, timezone handling for ISO dates, or whether the search is inclusive/exclusive of the range endpoints.

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

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

The description is extremely concise with zero redundant text. Every word earns its place. However, given the presence of multiple sibling search tools, it borders on being too terse to provide necessary selection context, preventing a perfect score.

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?

While the tool itself is simple (2 parameters, no nesting) and the schema is complete, the description is incomplete given the ecosystem context. With three search-related siblings available, the description fails to provide sufficient guidance for the agent to select the correct tool for date-based queries.

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 clear ISO format specifications for both parameters. Since the schema fully documents the parameters, the description does not need to add parameter semantics, meeting the baseline expectation for this dimension.

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 provides a clear verb (Search), resource (notes), and scope (by date range). However, it does not explicitly differentiate from the sibling 'search_notes' or 'search_advanced' tools, which could help the agent understand when to prefer this specific endpoint over the others.

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?

There is no guidance on when to use this tool versus the sibling search tools (search_notes, search_advanced). Given the multiple search options available, the description should explicitly state that this is specifically for date-based filtering or when to prefer it over alternatives.

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. It discloses that results are 'sorted by relevance,' which is useful behavioral context. However, it omits whether the operation is read-only, result limits/pagination, or what fields are searched (titles vs body vs metadata).

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

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

Two sentences with no waste: first states purpose, second states return behavior. Front-loaded and appropriately sized for a simple search 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?

Given no output schema exists, the description partially compensates by mentioning return sorting behavior. However, it lacks detail on result structure (e.g., whether it returns full notes, excerpts, or IDs) and omits safety characteristics that annotations would typically cover.

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%, establishing a baseline of 3. The main description adds no specific parameter guidance (e.g., query syntax tips, case sensitivity use cases), but the schema adequately documents both parameters without needing elaboration.

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 identifies the action ('Search through all notes') and the target resource (notes content). It implies broad scope with 'all notes,' distinguishing it from siblings like search_by_date, though it doesn't explicitly differentiate from search_advanced.

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?

No guidance provided on when to use this versus search_advanced, notes_read, or other siblings. No mention of prerequisites or when case-sensitive search is recommended.

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