Server Quality Checklist

Tool Scores

• move_noteC
  2.9/5.0
  Behavior2/5

  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 only states the action without disclosing return values, side effects, idempotency, permission requirements, or what happens on failure. For a mutation tool, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, clear sentence with no waste. It's front-loaded with the action and resource, making it easy to parse. However, it's overly minimal, providing only the core purpose with no supplementary details.

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

  Completeness2/5

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

  Given the tool's mutation nature and lack of output schema or annotations, the description should convey what the response will be (e.g., updated note details) and any behavioral constraints. It does neither, leaving the agent without essential context for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters are fully documented in the schema (note_id from list_notes/search_notes, folder_id from list_folders). The tool description adds no additional parameter context, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description states a clear action (move) and resource (note) with a destination (folder), which is distinct from sibling tools like list_notes or delete_note. However, it doesn't explicitly differentiate from update_note, which could theoretically change note location too, though the wording makes the intent obvious.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent must infer that 'move' is the right operation, but there's no mention of when not to use it or if other tools are more appropriate for similar tasks.

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

• create_folderB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create a folder, optionally nested' and does not mention potential error conditions (e.g., duplicate names, permission requirements, or whether nesting is recursive). For a write operation, this is a significant gap—an agent cannot anticipate failure modes or side effects.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the primary purpose and the key option. Every word earns its place, with no unnecessary detail or repetition.

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

  Completeness4/5

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

  For a simple folder-creation tool with a complete schema and no output schema, the description covers the essential behavior. It does not explain return values, but that is not obligatory given the lack of an output schema. It could arguably mention that parent_id defaults to top-level, but that is already in the schema. Overall, it is complete enough for an agent to make a correct call.

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

  Parameters3/5

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

  Schema coverage is 100% for both parameters ('name' and 'parent_id' are each described). The description adds the phrase 'optionally nested inside another,' which restates the parent_id intent already captured by the schema's default and description. No new meaning is provided, so it meets the baseline but does not exceed it.

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

  Purpose5/5

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

  The description states a clear verb ('create') and resource ('folder') and mentions the optional nesting, which distinguishes it from sibling tools like list_folders or delete_folder. An agent can immediately understand what this tool does 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.

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. While there is no competing create-folder tool, it also does not direct users to list_folders for obtaining parent_id, nor does it mention any prerequisites or exclusions (e.g., 'use create_note for notes'). The schema implicitly hints at list_folders, but the description alone lacks this guidance.

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

• delete_folderA
  3.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It clearly discloses that the action is a move to Recently Deleted (soft delete) and explicitly explains the refusal behavior for non-empty folders, including the rationale (notes go with it, unknown count). This gives the agent a solid expectation of side effects without needing to infer.

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

  Conciseness5/5

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

  The description is two short sentences, each earning its place. The first states the core action; the second explains the crucial refusal condition. There is no filler or redundancy, and the most critical information (action and exception) is front-loaded.

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

  Completeness4/5

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

  For a mutation tool with no output schema, the description adequately covers the main behavior and the key edge case (non-empty folder). It explains that notes are moved along with the folder and that the operation is to Recently Deleted (implying soft delete). It does not mention error handling or return values, but these are not critical for a simple delete/move operation. The lack of explicit guidance on when to use this versus delete_note is a minor gap, but the description is otherwise complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema documents both parameters. The schema description for delete_notes_inside is particularly informative ('Set this only when the person operating you asked...'), and folder_id references list_folders. The tool description itself adds no parameter-specific detail beyond the schema, so it does not exceed the baseline.

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

  Purpose5/5

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

  The description states a specific verb ('Move'), a clear resource ('a folder, and every note in it'), and the destination ('to Recently Deleted'). This unambiguously distinguishes it from siblings like delete_note (which deletes a single note) and move_note (which moves a note), making the tool's purpose immediately clear.

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

  Usage Guidelines2/5

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

  The description explains a refusal condition (folders with notes unless delete_notes_inside is set) but provides no guidance on when to choose this tool over alternatives like delete_note or move_note. It does not mention any scenarios where this is the preferred tool or when to avoid it, leaving the agent to infer usage from the name and context.

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

• create_noteA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description fully carries the behavioral burden. It discloses that the first line of body becomes the title and details specific Markdown rendering limitations (headings become bold, checkboxes become plain bullets), giving the agent concrete expectations beyond basic creation.

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

  Conciseness5/5

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

  Tightly written in two short paragraphs. The core purpose and the key title behavior are front-loaded, and every sentence earns its place without redundancy or fluff.

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

  Completeness4/5

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

  Given the simple 2-parameter schema with full descriptions, the description covers the essential behavioral quirks and the title-extraction rule. It does not mention return value or side effects, but for a create operation this is a minor gap, not a blocker for correct invocation.

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

  Parameters4/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds meaningful behavioral nuance about the body parameter (Markdown rendering details), which goes beyond the schema's basic 'Markdown' note and clarifies edge-case formatting that affects output.

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

  Purpose4/5

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

  States a clear verb+resource ('Create a note') with no ambiguity about the operation. However, it does not explicitly distinguish from sibling tools like update_note or append_to_note, even though the name itself carries that distinction.

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

  Usage Guidelines3/5

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

  The description implies the tool is for creating a new note, but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or contextual triggers. Usage intent is left to inference.

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

• get_noteA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It clearly discloses how checklists are represented (with real ticked state) and that attachments appear only as placeholders because files are not read. This is concrete, useful transparency beyond the schema. It does not mention error cases or return of metadata, but the core behavior is well covered.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main purpose and returning format, followed by important caveats about checklists and attachments. Every sentence earns its place with concrete, non-redundant information. No fluff or repetition.

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

  Completeness4/5

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

  Given there is no output schema, the description explains the return format (Markdown body, checkbox states, attachment placeholders) sufficiently for an agent to understand what to expect. It does not mention whether note metadata is returned, but 'in full' implies completion. Minor gaps like error handling exist but are not critical for a read tool with one parameter.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single parameter note_id, which already explains its provenance (from list_notes or search_notes). The tool description adds no further parameter details, but it is unnecessary given the schema covers it. Baseline of 3 is appropriate when the schema already documents the parameter.

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

  Purpose5/5

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

  The verb 'Read' and resource 'one note' are specific, and 'in full' with 'body as Markdown' clarifies scope. The description distinguishes this from listing or search tools by focusing on full content retrieval, so an agent can easily tell it from siblings like list_notes or search_notes.

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

  Usage Guidelines3/5

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

  The description implies usage when you need the complete note body, especially since it mentions reading 'one note in full' as opposed to listing. However, it does not explicitly name alternatives or state when not to use it (e.g., when you need to browse summaries, use list_notes). The usage context 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.

• list_notesA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that results are summaries, pinned first, and that bodies are not fetched. It also states each entry carries note_id, folder, and modification time. This gives the agent a solid understanding of the return shape and non-destructive nature. It doesn't mention pagination or default sorting, but those are already in the schema, so the description adds value without redundancy.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The core purpose is front-loaded ('List notes as summaries, pinned first, without fetching their bodies'), followed by output details and a routing hint. Every sentence earns its place, and the structure is easily scanable.

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

  Completeness4/5

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

  For a listing tool with five optional parameters and no output schema, the description provides sufficient context: what it returns (summaries with key fields), ordering (pinned first), and a pointer to get_note for full content. It doesn't explicitly mention how sort affects ordering or pagination, but those are covered by the schema. An agent could call this correctly with the provided information, though a brief note about search_notes as a text-search alternative would round it out.

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

  Parameters3/5

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

  Schema coverage is 100% and all parameters (sort, limit, offset, folder_id, include_trash) are well-documented there. The description adds no new parameter semantics—it doesn't explain the sort options or offset/limit behavior beyond what the schema already states. It does mention that note_id is needed by other tools, which is output-related rather than parameter-related. Since the schema is thorough, a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'List notes as summaries, pinned first, without fetching their bodies.' It clearly differentiates from get_note (which fetches bodies) and implicitly from search_notes (which is a different operation). The agent immediately knows what this tool does and what it doesn't.

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

  Usage Guidelines4/5

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

  The description explicitly routes the agent to get_note for reading a single note: 'Use get_note to read one.' This is clear contextual guidance. However, it doesn't mention when to prefer this over search_notes or list_folders, so the guidance is not exhaustive. It provides a clear also-use hint but no when-not-to-use exclusions.

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

• delete_noteA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It openly states that this is not a purge, that the note is kept for 30 days, that recovery is only via the app, and that the server cannot undo it. This gives the agent a clear picture of the tool's side effects and limitations. It does not mention error cases or permissions, but the core behavior is well covered.

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

  Conciseness5/5

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

  The description is efficiently front-loaded with the primary action ('Move a note to Recently Deleted') followed by a concise, essential caveat. It avoids redundancies and each sentence contributes meaningful value. The length is appropriate for the tool's simplicity.

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

  Completeness5/5

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

  For a tool with one parameter and no output schema, the description fully covers the tool's purpose, its retention behavior, and the recovery path. It also clarifies that the operation is not irreversible from the server's perspective. There is no missing context that an agent would need to invoke it correctly.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter, and the schema already describes note_id as 'The note's id, from list_notes or search_notes'. The tool description adds no additional parameter-level detail beyond what the schema provides, so this aligns with the baseline of 3 for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the action ('Move a note to Recently Deleted') with a specific verb and resource. It explicitly distinguishes this from a purge, and the sibling tools include delete_folder and move_note, so the scope is clear. The description leaves no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description provides clear context that this is a soft delete with a 30-day retention policy and recovery only through the app. It implies when to use it (when you want a recoverable delete) but does not explicitly state when not to use it or mention alternatives. It does not explicitly route to another tool, but the context is sufficient for an agent to decide.

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

• search_notesA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses several important behaviors: case-insensitive matching, full-archive search (not a recent window), and that results include an excerpt around body hits and indicate whether the match is on title or body. This is substantial behavioral disclosure, though it does not explicitly state read-only nature or potential performance implications. The guidance is adequate but not exhaustive.

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

  Conciseness5/5

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

  The description is concise, with two paragraphs that are front-loaded with the core purpose. It uses only four sentences, each providing distinct value: the first gives the primary function, the second explains the archive coverage and interpretation of zero results, and the third describes output format details. No fluff or redundancy.

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

  Completeness5/5

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

  For a search tool with four parameters (all schema-documented) and no output schema, the description provides sufficient context for an agent to call it correctly. It explains the search scope, output format (excerpt, match type), and the meaning of zero results. It does not require additional return-type documentation since it describes the result structure explicitly. No critical information is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds some context about how parameters relate (e.g., searching titles and bodies) but does not provide additional meaning beyond what the schema already specifies for each parameter. It does not enhance understanding of limit, offset, or folder_id beyond their schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's verb (search), resource (notes), and scope (titles and full note bodies), and explicitly mentions case-insensitivity. It also differentiates from list_notes by emphasizing that it searches content, not just lists notes. The clarity is high and unambiguous.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: when you need to search note content, rather than listing or retrieving specific notes. It explicitly notes that the entire archive is searched, which is useful context. However, it does not explicitly name alternative tools or state when NOT to use it, which would strengthen the guidance. Still, the context is clear enough for an agent to infer usage.

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

• list_foldersA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description must carry the full burden. It explicitly discloses that it returns the full list, not a page, and explains the rationale (small folder list). It also clarifies potential confusion about duplicate names by emphasizing path vs folder_id. While it does not state 'read-only' explicitly, 'List' strongly implies it, and there is no indication of side effects. This is above average for a simple read operation.

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

  Conciseness4/5

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

  The description is four sentences, front-loaded with the primary function. It provides essential context in clear paragraphs. There is a slight redundancy in the last sentence ('Returns everything rather than a page' and 'the whole point is to see the shape of the archive...'), but overall it is tight and efficient.

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

  Completeness5/5

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

  For a parameterless list tool without an output schema, the description covers everything an agent needs: what is returned (full path, note count), how to interpret data (path vs folder_id), and that it returns all items non-paginated. It also explains the purpose of the archive shape, making it complete for correct invocation.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4 per the rubric. The description adds context about the output fields (path, note count, folder_id) that would be useful for downstream tool usage, though it does not need to explain parameters since none exist.

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

  Purpose5/5

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

  The description clearly states the verb and resource: 'List every Apple Notes folder, with its full path and how many notes it holds.' It goes beyond a simple statement by explaining the purpose of the output (folder_ids, path disambiguation) and explicitly contrasts with siblings that operate on notes. An agent can immediately distinguish this from list_notes or search_notes.

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

  Usage Guidelines4/5

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

  The description gives a strong usage hint: 'This is where folder_ids come from' and explains that folder_id is what other tools take, implying this is the entry point for folder references. It also explains the non-paginated behavior ('Returns everything rather than a page'). However, it does not explicitly mention alternatives or 'when not to use', but given the unique purpose, the guidance is sufficient.

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

• append_to_noteA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavior. It explicitly states that the operation is a whole-note rewrite underneath, which is a significant side-effect the agent must know. It also reveals the refusal on attachments/checklists and ties it to update_note's behavior, giving a transparent picture of what happens under the hood.

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

  Conciseness5/5

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

  Two sentences with no filler. The first sentence is front-loaded with the core purpose, and the second explains the critical underlying behavior. Every word earns its place, and the structure is easy to parse quickly.

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

  Completeness4/5

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

  For a tool with no annotations and no output schema, the description covers the essential behaviors: the rewrite semantics, the refusal condition, and the rationale for the replace_attachments parameter. It does not mention return values or error handling, but given the simplicity of an append operation and the thorough schema explanations, the information is sufficient for an agent to call it correctly.

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

  Parameters4/5

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

  The schema covers all parameters at 100%, so the baseline is 3. The description adds value by explaining why the replace_attachments parameter exists—because the operation refuses on attachments/checklists—and clarifies the underlying mechanism. This context aids correct parameter usage, especially for the subtle replace_attachments flag, moving it above baseline.

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

  Purpose5/5

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

  The description opens with a precise verb and resource: 'Add text to the end of a note, keeping what is already there.' This clearly defines the operation and scope, distinguishing it from generic update operations. It also differentiates from the sibling update_note by highlighting the restriction on attachments and checklists, ensuring an agent can select the right tool.

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

  Usage Guidelines4/5

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

  The description gives a clear condition for use (append) and an explicit refusal condition (attachments/checklists). It references update_note as a sibling with similar constraints, implying when append is inappropriate. However, it stops short of explicitly naming alternatives or stating 'use this instead of X when Y,' so it relies on inference rather than direct routing.

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

• update_noteA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses that it is destructive ('Anything not in `body` is gone'), that the first line becomes the title, and that it refuses on attachments/checklists. It also explains the technical limitation. This is comprehensive 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.

  Conciseness5/5

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

  The description is three brief paragraphs, each serving a distinct purpose: core action, caveat, and restriction. No unnecessary words. It's front-loaded with the primary purpose.

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

  Completeness5/5

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

  For a destructive replacement tool with no annotations and no output schema, the description covers what the tool does, when to use it, what happens to the data, and when it will not work. An agent would have sufficient understanding to invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description doesn't add significant meaning beyond the schema for body and note_id; for replace_attachments, the schema already explains when to set it. The description's mention of refusal is behavioral, not parameter-specific. So it stays at baseline.

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

  Purpose5/5

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

  The description opens with 'Replace a note's entire body,' a specific verb and resource. It explicitly contrasts with 'edit' and states it's a whole-note replacement, distinguishing it from append_to_note and other siblings.

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

  Usage Guidelines5/5

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

  It gives an explicit prerequisite: 'Read the note with get_note first unless you are deliberately starting over.' It also states the refusal condition for attachments/checklists, which guides when not to use it. The whole-note vs edit contrast implies when to choose this over append_to_note.

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