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

With no annotations, the description carries the full behavioral disclosure burden. It states the append action and supported formats but does not explain behavior for missing notes, whether content is inserted at the end, effects of insert_blank_line, or response/error behavior.

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 concise sentences with no filler. The core action and target are front-loaded, and the mode detail is relevant without unnecessary elaboration.

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 four parameters, no annotations, and no output schema, the description is incomplete. It omits the meaning of insert_blank_line, lacks usage differentiation from update/create tools, and gives no behavioral context for a mutating operation.

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 0%, so the description must compensate. It covers note_id and content implicitly and mentions plain/text vs HTML which maps to content_format, but it does not explain insert_blank_line at all. The description adds only partial value beyond the raw 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 uses a specific verb ('Append'), identifies the resource ('existing note'), and names the key selector ('by note_id'). It clearly distinguishes from sibling tools like create, update, or get operations.

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 context is clear: use when you want to add content to an existing note identified by note_id. However, there is no explicit guidance on when to prefer this over notes_update_note or when not to use it, leaving alternatives unaddressed.

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, the description carries full burden for behavioral disclosure. It states that creation happens and that account/parent targeting is possible, but it does not explain side effects, default account behavior, whether duplicate folder names are allowed, what happens if the parent folder does not exist, or any 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.

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

Two short, front-loaded sentences deliver the core purpose and key optional capabilities with no redundant or filler language. Every word adds meaning.

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 five parameters, no annotations, and no output schema, this description is too thin. It does not explain the default target account, whether parent folders can be created recursively, what the return value is, or how failures are surfaced. An agent would need significant additional assumptions to invoke it reliably in non-trivial 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 0%, so the description must compensate for five undocumented parameters. It only mentions 'account' and 'parent folder' generically, but does not explain the relationship between account_id/account_name or parent_folder_id/parent_folder_name, which parameters take precedence, or how optional parameters behave when omitted.

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 states a specific action and resource: 'Create a folder in Apple Notes.' It clearly differs from sibling tools like notes_create_note and notes_delete_folder because the object being acted on is a folder and the operation is creation.

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 gives no guidance on when to use this tool instead of alternatives, nor does it mention any related tools such as notes_list_folders for finding parent folder IDs or notes_list_accounts for targeting an account. The usage context is only implied by the verb 'create.'

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, the description carries the full behavioral disclosure burden. It discloses supported body formats but doesn't explain what happens when no account or folder is specified, whether existing data is touched, whether the note body is required despite all parameters being optional, or what the result of creation looks like.

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, front-loaded sentence with no filler. Both clauses earn their place: the primary action and the key format/title options. It is appropriately concise for the simplicity it conveys.

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 seven parameters, no annotations, and no output schema, the description is too thin to fully support correct invocation. It doesn't explain destination resolution when folder/account params are omitted, parameter precedence, requiredness of body, or return behavior, leaving significant ambiguity for an agent.

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 0%, so the description must compensate. It does clarify body, title, and body_format by mentioning plain/HTML text, but it completely omits the four folder/account parameters (folder_id, account_id, folder_name, account_name), which are needed to control where the note is created. It also fails to clarify whether body is mandatory.

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 ('Create a note in Apple Notes') and adds the key capability of plain text or HTML body with optional title. It is specific enough to identify the tool's purpose, though it doesn't explicitly contrast it with sibling tools like notes_update_note or notes_append_to_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?

No guidance is given about when to use this tool versus the many siblings, such as notes_update_note, notes_append_to_note, or notes_move_note. The 'create' wording implies new-note usage, but there are no explicit conditions, exclusions, or alternatives 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 the full behavioral burden, and it does disclose the most essential trait with '(destructive)'. Yet it stops there: it never states whether the deletion is permanent/reversible, whether the operation cascades to notes inside the folder, or how the API signals success or failure. For a destructive tool, the fate of contained notes is the single most consequential unknown.

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 short sentences, zero filler. The destructive warning is front-loaded in the first sentence, the safety requirements come second, and the optional targeting semantics last. Every sentence earns its place and the most critical information appears first.

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 6-parameter destructive operation with no annotations and no output schema, the description is under-specified. The critical missing context is what happens to the notes contained in the folder: are they deleted, moved, or does the operation fail? Permanence/recoverability is also undisclosed. An agent cannot fully predict the consequences of invoking this 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?

Schema description coverage is 0%, so the description must compensate, and it meaningfully does: 'Can be targeted by folder_id or folder_name (+ account scope)' explains the either/or relationship between the two targeting params and clarifies that account_id/account_name serve as scoping context. This goes beyond the bare schema, though it leaves unspecified what happens if both folder_id and folder_name are supplied.

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 opens with a specific verb+resource pair, 'Delete a folder,' and adds the '(destructive)' warning. It clearly distinguishes this tool from its sibling notes_delete_note, since the resource is named explicitly, so an agent can tell the two delete operations apart without inspecting schemas.

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 gives preconditions — 'Requires confirm=true and reason' — which is a form of usage guidance, and the tool's purpose is narrow enough that an agent can infer it is the right choice for removing folders. However, there is no explicit when-to-use vs alternatives discussion, no note about when folder_name vs folder_id targeting is preferable, and no warning about preconditions like folder emptiness.

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 present, so the description carries the full burden. It does disclose that the operation is destructive and that confirm=true and a reason are required, which is valuable safety context. Yet it does not state whether deletion is permanent, what side effects occur, or whether special permissions are needed.

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 sentence with no filler. It front-loads the action and destructive nature, then states the key requirement, making it easy for an agent to parse quickly.

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 destructive tool with no annotations and no output schema, the description provides the essential safety context: deletion, confirm=true, and reason. It is minimally viable but lacks detail about deletion permanence, side effects, or authorization requirements, leaving clear gaps.

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 0%, so the description must compensate. It adds the important qualifier that confirm must be true, and it notes that reason is required. However, it does not explain what the reason should capture or what note_id refers to, leaving part of the parameter semantics to inference.

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 operation: 'Delete a note' and explicitly flags it as destructive. It is unambiguous about the resource and action, but it does not explicitly distinguish itself from sibling tools like notes_delete_folder or notes_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 implies the tool is used when a note needs to be deleted and communicates the required preconditions of confirm=true and a reason. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or reversibility.

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 must carry the burden. It adds useful behavior by stating it returns both HTML and text body, and the word 'Get' implies a read-only operation. However, it does not disclose potential error cases, permissions, or whether attachments are included, leaving some behavioral aspects undocumented.

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?

A single, front-loaded sentence that contains no filler. Every phrase adds information: the action, the target, the lookup key, and the return payload. It is an ideal length for a simple retrieval 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 the low complexity (one parameter, no output schema, no nested objects), the description is largely complete. It explains what the tool returns ('full HTML + text body') and how to target a note. It could note that the parent folder or metadata is not included, but that is a minor omission for such a simple getter.

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 0%, so the description must compensate for the parameter. It does mention 'note_id' and indicates that it selects the note, but it does not explain the expected format, source, or how to obtain a valid ID. For a single, obviously named parameter this is minimally sufficient but not more.

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 states a specific verb ('Get'), a specific resource ('a specific note'), and the key identifier ('note_id'), which clearly distinguishes it from sibling tools like list, search, or recent-note retrieval. It also indicates the return content ('full HTML + text body'), making the purpose unambiguous.

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

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

The description implies usage: when you have a note_id and need that exact note's full body. However, it does not explicitly mention when not to use it or name alternatives such as notes_search_notes or notes_list_notes. The guidance is reasonable but left to inference.

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 responsibility for behavioral disclosure, and it only states the core listing action. It does not reveal whether results include note bodies, how limit is applied, ordering of recent notes, or any side-effect safety 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?

One sentence with no redundant wording, and the key scope ('recently modified', 'last N days') is front-loaded. 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?

The tool has no output schema and no annotations, so the description is the only source for result semantics. It is too thin to fully support correct invocation, particularly around limit, include_body, and the meaning of 'modified'.

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 0%, so the description must provide parameter semantics; it only grounds 'days' as the N in 'last N days'. 'limit' and 'include_body' remain unexplained, leaving the agent to guess at valid usage.

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 uses a specific verb and resource ('List ... notes') and adds a defining temporal scope ('recently modified ... last N days') that separates it from sibling tools like notes_list_notes and notes_search_notes. An agent can tell what operation this performs without opening the schema.

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 temporal qualifier implies the use case: retrieving notes changed within a recent window. However, the description does not state when to prefer this over notes_list_notes or notes_search_notes, nor when it should not be used.

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 clearly communicates this is a read-only listing operation with no mention of side effects, but it does not describe return format, permissions, or edge cases. This is adequate for a simple list tool, but not exceptionally transparent.

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?

A single, front-loaded sentence with no filler. It efficiently states the action, resource, and scope in 9 words, earning a perfect score for conciseness.

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 zero-parameter, read-only list tool with no output schema and no annotations, the description is sufficient. It states exactly what the tool returns (a list of accounts) and its scope (all on this Mac). No additional context is needed for an agent to invoke it correctly.

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 tool has zero parameters, and the schema is an empty object with 100% coverage. Per the rubric, a 0-parameter tool earns a baseline of 4; the description correctly implies no arguments are needed, so this baseline is appropriate.

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 ('List') and resource ('Apple Notes accounts'), clearly distinguishing this tool from siblings like notes_list_folders and notes_list_notes. It also specifies scope ('all' and 'available on this Mac'), leaving no ambiguity about its function.

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 implies the usage context: invoke this tool when the agent needs to enumerate Apple Notes accounts on the Mac. It does not explicitly name alternatives or exclusions, but the resource is distinct enough that a competent agent can infer when to select it.

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 behavioral disclosure burden. 'List' conveys that the tool is read-only and returns metadata without side effects, which is useful, but it does not describe pagination, output format, authorization requirements, or behavior when the note does not 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 description is a single sentence with no wasted words. It states the action and scope immediately, making it easy for an agent to parse quickly.

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?

The tool is simple with one required parameter and no output schema, so the description is mostly sufficient to invoke it correctly. However, it does not explain what 'metadata' includes, and without an output schema the agent must guess at the return shape. Some usage guidance relative to sibling tools would also 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 description coverage is 0%, so the description must help explain the note_id parameter. The phrase 'in a specific note' minimally connects note_id to the target resource, but it adds no detail about the expected format, source, or how to obtain a valid note_id. For a single self-explanatory parameter this is adequate but not rich.

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 ('List') and resource ('metadata for all attachments in a specific note'), clearly stating the operation and its scope. This distinguishes it from sibling tools like notes_list_notes or notes_get_note, which operate on notes rather than attachments.

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 about when to use this tool versus alternatives, nor any mention of prerequisites such as needing a valid note_id. The usage context is only implied by the phrase 'in a specific note,' which is not enough to help an agent choose between this and related notes 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 bears the full behavioral burden. It discloses that this is a listing/read operation and that account_id/account_name act as optional filters, but it does not describe default behavior when no parameters are given, output format, or behavior when both account_id and account_name are supplied.

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 short sentences with no filler. The core operation is front-loaded and every phrase carries meaning, from the resource type to the optional scoping behavior.

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 list tool with no required parameters, the description provides enough to select and invoke it: it names the operation, the resource, and the optional filters. It falls slightly short of full completeness by omitting any note about return shape or edge cases, but those are minor for this 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?

Schema description coverage is 0%, so the description must add meaning to the parameters. It does so by stating they are optional scoping mechanisms, which is useful. Still, it leaves gaps around exact-match behavior, value formats, and what happens if both parameters are provided.

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 ('List') and a clear resource ('folders across Apple Notes'), making the tool's purpose immediately identifiable. It also differentiates from sibling tools like notes_list_accounts and notes_list_notes by naming the distinct resource type.

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 intended use is implied clearly: use this tool when you need to list folders in Apple Notes, optionally scoping by account. However, it does not explicitly state when not to use it or name alternatives, so the agent must infer the distinction from sibling tool names rather than from 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, the description carries the full burden of behavioral disclosure. It reveals that body output is optional and that scoping can be applied, but it doesn't mention default limit behavior, pagination, sorting, return format, or whether it returns metadata only by default. This is a meaningful gap for a listing 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 a single front-loaded sentence with no filler, which is commendable, but it is under-specified rather than efficiently complete. It earns a middle score: concise but at the cost of necessary detail.

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 tool with 6 optional parameters, 0% schema coverage, no annotations, and no output schema, this description is insufficient. The agent has no guidance on default behavior, parameter semantics, return structure, or how this tool differs from the recent-notes sibling. A complete description for a tool this complex would need substantially more.

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 0%, so the description must compensate, but it only vaguely references 'scoping by account/folder' and 'full body output'. It does not explain the relationship between account_id vs account_name, folder_id vs folder_name, limit defaults, or include_body meaning beyond the schema's bare property names.

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 clear verb ('List') and resource ('notes'), and adds meaningful scoping detail: optional filter by account/folder and optional full body output. It distinguishes itself from list_accounts and list_folders, though it doesn't explicitly contrast with notes_get_recent_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?

No guidance is given on when to use this tool versus alternatives like notes_get_recent_notes or how the optional scoping relates to list_accounts/list_folders. The 'optional' wording implies filtering use cases, but no explicit when/when-not or alternative routing is provided.

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 bears the full burden of behavioral disclosure. It reveals the operation is a move, but does not state whether the source note is removed, whether it replaces any existing destination note, whether attachments and metadata are preserved, or whether both target_folder_id and target_folder_name are needed or alternative paths.

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, front-loaded sentence containing no filler. It states the core operation and the key parameters with appropriate brevity.

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?

The tool has five parameters, no annotations, no output schema, and no detailed parameter guidance. The one-sentence description leaves important gaps: the roles of account_id/account_name, the relationship between target_folder_id and target_folder_name, and what happens during the move. This is insufficient for a five-parameter mutation 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?

Schema description coverage is 0%, so the description must add meaning to parameters. It clarifies that target_folder_id and target_folder_name specify the destination folder and that note_id identifies the note, but it ignores account_id and account_name entirely and does not explain how the two target folder parameters relate to each other.

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 is specific: 'Move a note to another folder' identifies the verb, resource, and result of the operation, and the mention of note_id plus target folder distinguishes it from note creation, deletion, update, and append operations. It clearly differentiates from all siblings.

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 implies the tool is used when relocating a note to another folder, which provides basic usage context. However, it gives no explicit guidance on when to choose this over alternatives, no exclusions, and no mention of whether target_folder_id or target_folder_name are mutually exclusive or which is preferred.

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 burden of behavioral disclosure. It does disclose that the search covers title, body, folder path, and account, and that scope can be limited to account/folder. However, it does not mention case sensitivity behavior, result ordering, whether the body is included in results by default, or any other operational details. The description gives a basic behavioral overview but not deep transparency.

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 concise, two clauses in a single sentence, and the core purpose is front-loaded. It wastes no words and quickly communicates the key functionality. It could be slightly more informative without becoming bloated, but it succeeds at being tightly scoped.

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?

With 8 parameters, no output schema, and no annotations, the description is not sufficiently complete. It does not mention default behavior for limit, how include_body affects results, whether case_sensitive defaults to false, or how account/folder scoping behaves when both id and name are provided. The description leaves too many important operational details undocumented, making it incomplete for an agent to reliably invoke the tool with appropriate parameters.

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 0%, so the description must compensate for the 8 parameters. The description does clarify that 'query' searches across title, body, folder path, and account, and that filters can be applied to account/folder. However, it does not explain the semantics of include_body, case_sensitive, limit, or the relationship between folder_id vs folder_name and account_id vs account_name. This is minimal compensation for an 8-parameter 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 states a specific action ('Search') and a resource ('notes'), and clarifies the search scope ('across title, body, folder path, and account'). It clearly indicates this is a search tool rather than a listing or retrieval tool, which helps distinguish it from notes_list_notes and notes_get_note. However, it does not explicitly differentiate itself from those sibling tools by name or exclusion criteria.

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 implies the tool is for keyword-based search across note content, and optional scoping to account/folder is mentioned. It does not explicitly state when to use it instead of notes_list_notes or notes_get_recent_notes, nor does it provide any 'when not to use' guidance. The usage context is somewhat implied but not fully articulated.

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 responsibility for behavioral disclosure. It states that fields can be set and that body supports plain text or HTML, but it does not explain whether unspecified fields are preserved, what permissions are required, whether the update is reversible, or what happens if note_id does not exist. This is a mutation tool, so the missing behavioral detail is significant.

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 short sentences, no filler, and the core operation is front-loaded. The description earns its length: every sentence adds operational information.

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?

The tool is relatively simple and the description covers the core operation, target key, and updatable fields. Still, with no output schema and no annotations, the absence of alias guidance, body_format defaults, and side-effect disclosure leaves noticeable gaps; adequate but not 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?

Schema description coverage is 0%, so the description must add meaning. It explains note_id as the target, title and body as the settable fields, and body as supporting plain text or HTML. However, it never names body_format explicitly or states its default behavior when omitted, leaving an agent to infer the connection between 'Body supports plain text or HTML' and the enum 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 clearly states a specific verb ('Update'), resource ('existing note'), and identifying key ('note_id'), then lists the fields that can be changed (title, body). This distinguishes it from sibling tools like create, append, move, and delete without requiring the agent to inspect each one.

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 context is clear: use this when modifying an existing note by its ID. However, it never states when not to use it, nor does it point to alternatives such as notes_append_to_note for adding content or notes_get_note for reading. The guidance is implied rather than explicit.

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