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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the write profile and non-idempotency are covered structurally. The description adds one genuinely useful behavioral fact — that the call returns the note id — which matters since there is no output schema, but says nothing about duplicate handling, tag creation, or failure modes.

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, no redundancy, with the core action and return value front-loaded before the optional tag advice. Every sentence carries 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?

For a small three-parameter create tool with full annotation coverage, the description covers what it does and what it returns. A note on whether tags must already exist or on duplicate behavior would close the remaining gap, but no output schema is needed here since the return value is stated.

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

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

Schema description coverage is 100%, so title, content and tags are already documented with types and length limits. The description adds only marginal semantic value by hinting at the organizational purpose of tags; title and content get no elaboration 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?

"Save a new note" gives a specific verb and resource, and "Returns the note id" adds the outcome. The word "new" implicitly separates it from update_note, but no sibling is named explicitly, so the reader must infer the boundary with update_note/get_note.

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

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

"Use tags to group related notes" is guidance on how to use a field, not on when to choose this tool over update_note or search_notes. The distinction from update_note is only implied by "new note"; there are no exclusions or prerequisites stated.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is carried structurally. The description reinforces this with "Permanently" and "cannot be undone", which is useful but largely restates destructiveHint; it adds nothing about permissions, whether the note is recoverable from a trash, or behavior for an unknown id.

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, zero filler, with the destructive consequence front-loaded right after the action. Nothing to trim.

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 single-required-parameter mutation with full annotation coverage and no output schema, this is close to sufficient. A minor gap remains around error/not-found behavior, but nothing essential to correct invocation is missing.

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% and the id parameter is documented in-schema, including its source (list_notes or search_notes). The description adds no format or sourcing detail beyond that, so baseline 3 applies.

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?

States a specific verb and resource ("delete one note by id") and the scope is unambiguous. The verb alone separates it cleanly from the read/write siblings (add_note, get_note, update_note), though no sibling is named explicitly.

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?

Usage is implied by the name and the "by id" phrasing, and the permanence warning signals this is not the reversible path. However, it never says when to prefer update_note or how to recover an id, and gives no exclusions or preconditions.

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?

Annotations already declare readOnlyHint and a closed world, and the description usefully adds that output is a single concatenated Markdown document ordered newest first and that nothing is written to disk. It does not mention size limits, pagination or what happens with very large note sets.

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, front-loaded with the return shape and ordering, with no filler or repetition.

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 no output schema, the description correctly fills the gap by describing the return value and ordering, and the safety profile is covered by annotations. Only edge-case behavior (large exports, empty results, tag misses) is unaddressed.

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% and the single tag parameter is documented there; the description only echoes that omitting it means all notes are exported. Baseline 3 is appropriate since the schema carries the parameter detail.

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?

States a specific verb and resource (return all notes), the output form (one Markdown document) and the ordering (newest first), which separates it from list_notes/search_notes that return structured results. It never names a sibling, so the differentiation is implicit rather than explicit.

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 parenthetical 'or only those with one tag' implies when to pass the tag filter, but there is no explicit when-to-use versus list_notes/search_notes/get_note guidance and no stated exclusions or limits.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the response includes 'full content' (vs a preview), which is useful payload context not in annotations, but says nothing about error behavior for a missing id or about pagination/sizing of large notes.

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 short sentence with the verb and scope front-loaded and zero filler. Nothing to trim and nothing wasteful.

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 one-parameter read tool with annotations covering safety and no output schema, the description supplies the one thing missing elsewhere: that the return value is the complete note body. An agent has everything needed to call 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?

There is only one parameter and schema description coverage is 100%, so the schema already documents 'id' including its source. The description's 'by id' merely restates that; baseline 3 applies when the schema does all the work.

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?

States a specific verb ('Fetch') and resource ('one note by id') and adds a distinguishing detail: it returns 'full content', which separates it from list/search style siblings. It does not explicitly name list_notes or search_notes as alternatives, so differentiation is implied rather than stated.

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 single-note scope implies this is the tool to use once an id is known, and the schema notes the id comes 'from list_notes or search_notes'. However, the description itself contains no explicit when-to-use/when-not guidance or prerequisite statement.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: results are ordered newest first and only one tag may be applied. It still omits pagination or result-size limits, which matters for a list 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?

Two short sentences, zero waste, with the ordering and filter constraint front-loaded. Nothing could be removed without losing 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?

There is no output schema, so the description carries the burden of explaining return shape, and it never says whether all notes are returned or how results are bounded. For an unbounded list operation, the absence of any pagination or volume hint is a meaningful gap.

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%, so the single 'tag' parameter is already fully documented in the schema. The description's 'single tag' wording reinforces the cardinality constraint but adds little beyond that. Baseline 3 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?

States a specific verb and resource ('List notes') plus the ordering ('newest first') and the optional filter, which separates it conceptually from search_notes. It doesn't explicitly name the sibling it is not, so it stops short of 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?

'Optionally filter by a single tag' implies the filtering use case, but there is no explicit guidance on when to use this versus search_notes, nor any stated exclusion. Usage must be inferred from the sibling name alone.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the searched fields (titles, tags, bodies), relevance ranking ('best matches'), and that full content is returned rather than snippets — all of which shape how an agent should use results.

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 tight sentences with zero filler: the search scope is front-loaded and the return behavior follows. Nothing redundant and nothing that could be cut.

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 two-parameter read tool with no output schema, the description covers what is searched and what comes back ('full content'), which is the key missing piece an agent would otherwise lack. Minor gaps remain around result ordering and empty-result behavior, but nothing essential is absent.

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%, so both 'query' and 'limit' are fully documented in the schema, including the default of 5 and max of 20. The description reinforces keyword-style querying but adds no syntax or formatting detail the schema doesn't already supply, so the baseline 3 applies.

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?

States a specific verb and resource ('keyword search across note titles, tags and bodies') and what it returns, which clearly separates it from get_note (single record by ID) and list_notes (unfiltered enumeration). It does not explicitly name a sibling as an alternative, keeping it just below 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?

The description implies the tool is for keyword-based lookup ('Keyword search... space-separated keywords'), which lets an agent infer it should be used when it has search terms rather than an ID. However, there is no explicit statement of when to prefer search_notes over list_notes or get_note, and no mention of result limits or exclusions.

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?

Annotations already declare the safety profile (not read-only, idempotent, not destructive), so the description's job is to add mutation semantics. It does: it discloses the at-least-one-field requirement (a constraint the schema does not enforce, since only id is required) and that tags are replaced wholesale rather than merged. It could still state explicitly that omitted fields are preserved.

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: purpose first, then the invocation precondition, then the one non-obvious field behavior. No filler and nothing buried.

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 four-parameter, non-destructive update tool with a fully documented schema and safety annotations, only the return behavior is unaddressed (e.g., whether the updated note is echoed back). No output schema exists, so a brief return-value note would have made it 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 coverage is 100%, so all four parameters are already documented, including 'New tags (replaces all existing tags)'. The description's note about tag replacement therefore restates schema content rather than adding to it. Baseline 3 applies since the schema carries the parameter burden.

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?

States a specific verb ('Edit') and resource ('existing note'), making it immediately distinguishable from add_note, delete_note and get_note by their own verbs. It does not explicitly name a sibling, but the intent is 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?

'Provide the id and at least one of title, content or tags' gives a concrete precondition for invocation, which is the key usage rule for a partial-update tool. It stops short of stating exclusions such as when to prefer add_note vs update_note for a missing id, but no alternatives are needed for a simple CRUD edit.

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