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 this is an append operation creating a timestamped entry (implying non-destructive addition), but it does not explain whether a missing daily note is created, whether the operation is idempotent, what permissions are required, or what the response 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?

Two tightly written sentences with zero waste. The key scoping information (today's daily note or a given date) is front-loaded, and the usage context follows efficiently.

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 tool with no output schema and no annotations, the description covers purpose, usage context, default date behavior, and entry format. The main gap is not stating whether the note is created if absent, which is a meaningful behavioral detail for an append 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 100%, so both parameters are already documented with types and defaults. The description restates the date parameter's default and adds that entries are timestamped and one bullet, but does not add substantial meaning beyond what the schema provides. 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?

The description states a specific verb ('Append') and resource ('today's daily note'), with scope for a given date. It is clear enough to distinguish from general note tools like write_note and edit_note by virtue of targeting the daily note, though it does not explicitly name those 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?

It gives clear context for when to use the tool: 'The right place for observations, decisions, and things to remember.' It does not name alternatives or exclusions (e.g., when to use remember or write_note instead), so it falls short of a 5.

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?

The readOnlyHint already covers the safety profile, and the description adds genuinely useful behavior: matching notes are returned in full while neighbors are only pointers, which sets expectations about cost and result shape. It does not mention any limits or pagination on the hop expansion, keeping it from a 5.

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

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

Two sentences, zero waste, with the payoff (full content plus neighbor pointers) front-loaded before the routing advice. Nothing is repeated from the title.

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 carries the return-shape burden and does reasonably well by distinguishing full content from pointers. The exact form of a "pointer" is left implicit, a small gap for what is essentially a read-aggregation 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 100%, so both parameters are already documented, including max_notes' default and 1-10 bounds. The description adds no parameter-specific meaning beyond what the schema provides, which is the expected baseline.

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 (load/build) and resource (working context for a topic) and describes exactly what comes back: full content of top-matching notes plus one hop of wikilinked notes as pointers. An agent can tell this apart from search_notes and read_note without opening their 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?

"Prefer this over multiple search+read rounds when starting work on a topic" gives a clear triggering condition and implicitly names the alternatives it replaces. It stops short of an explicit exclusion (e.g. a single known note should use read_note), so it is strong rather than exhaustive.

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, so the safety profile is carried. The description adds that edits are surgical and find_replace is an exact-string match, which helps. It does not disclose what happens when the find string is missing or non-unique, nor that changes are unrecoverable, which is significant for a mutation 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 compact sentences with the operation modes front-loaded and the sibling preference trailing. No filler or redundancy.

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, and the description never says what a successful or failed edit returns, nor how a failed find_replace is reported. For a destructive four-parameter mutation tool this leaves real gaps, though the core calling semantics are covered.

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 75%, so most parameter meaning is already documented, including that find is exact-string and find_replace-only. The description reinforces the three operation values but adds no format or constraint details beyond what the schema and enum already convey. 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 (edit) and resource (existing note) plus the three supported modes: append, prepend, find_replace. It also distinguishes itself from the sibling write_note by saying to prefer it over rewriting whole notes, so an agent can differentiate without opening 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?

"Prefer this over rewriting whole notes" gives a clear selection rule against the obvious alternative, and "surgically" sets the intent. It lacks explicit when-not guidance or mention of read_note/search_notes as prerequisites for locating a find target.

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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description does add real information beyond the annotations by stating the return is 'note paths' (not note content) and that the default scope is the whole vault, but it says nothing about ordering, limits, or whether folder listing is recursive.

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 sentence with zero filler, front-loaded with the verb and resource. 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 read-only listing tool with no output schema, the description covers the basic shape (paths, optional folder) but leaves open whether results are paginated, how the limit default behaves, and how ordering works. Adequate but with clear gaps for a tool that can return many entries.

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?

Coverage is 50%: the folder parameter is documented in the schema, and the description merely restates it ('optionally under a folder'). The limit parameter is never mentioned in the description, so nothing compensates for the half of the schema that lacks semantic 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?

Specific verb 'List' with the resource narrowed to 'note paths', plus a scoping qualifier ('optionally under a folder'). An agent can tell this is a path-enumeration tool rather than a content search, though it never names search_notes as the contrasting sibling.

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 when-to-use guidance, no mention of when to prefer search_notes or read_note instead, and no prerequisites. The only conditional ('optionally under a folder') describes a parameter, not a usage decision.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds that the entire raw markdown body is returned (not metadata or an excerpt), which is useful, but says nothing about error behavior for missing paths or truncation of very 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?

One sentence, front-loaded with the verb and resource, with the key qualifier (vault-relative path) at the end. Nothing is redundant or padded.

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-parameter read tool with full schema coverage and a readOnlyHint, the description covers what is returned at a high level. Since no output schema exists, it could say slightly more about the response shape, but nothing critical 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?

There is a single parameter with 100% schema description coverage ('Vault-relative path, e.g. projects/idea.md'), so the schema already carries the semantics. The description echoes the vault-relative framing without adding new meaning, which is the baseline 3.

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 (read) and resource (a note) plus the return scope ('full markdown content') and the path convention ('vault-relative'). It is clear against list_notes/search_notes in effect, but it never names a sibling explicitly, so a 4 rather than 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?

Usage is only implied: the tool requires a known path, which implicitly contrasts with search_notes/list_notes for discovery. There is no explicit when-to-use, when-not, or named alternative, so it stays at the minimum-viable level.

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?

readOnlyHint already declares this is a safe read, and the description usefully adds the sort order ('newest first'), which annotations do not cover. It says nothing about truncation behavior at the limit cap, what a 'modified' timestamp means, or what the results contain, so behavioral disclosure is only partial.

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 tight sentence with the scope and ordering front-loaded and no padding. 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?

For a simple two-parameter read tool with annotations covering safety, this is close to sufficient. The remaining gaps are the undocumented 'limit' semantics and the absence of any statement about what each returned item includes, which matters more here because there is no output schema.

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 only 50%: 'days' is documented with a default in the schema, but 'limit' has no description anywhere. The phrase 'last N days' merely restates the 'days' parameter without adding format, default, or edge-case meaning, and the description does nothing to compensate for the undocumented 'limit'.

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 plus a scope (notes modified in the last N days) and an ordering (newest first). An agent can tell this apart from list_notes or search_notes on scope grounds, 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?

The recency framing implies when this tool is appropriate (recent-changes style queries) versus a full listing or a search. However, no explicit when-to-use/when-not or comparison to search_notes, list_notes, or read_note is given, leaving routing 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, the description carries the full behavioral burden and does well: it explains persistence, dated bullet formatting, stable ^id behavior, and the non-destructive supersede semantics where the old fact remains visible with strikethrough and a pointer. It omits permissions, failure modes, and return behavior, which keeps it below a 5.

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 three tightly written sentences, front-loaded with the core action and followed by the key edge case and prerequisite. Every sentence adds useful information without 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?

For a 3-parameter tool with 100% schema coverage and no annotations, the description covers the main invocation behavior, supersede semantics, and search-first workflow. It is nearly complete, though it does not describe what the tool returns or any permission constraints.

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 baseline is 3, but the description adds meaningful semantics beyond the schema for supersedes: the old fact remains visible with strikethrough and a pointer. It also reinforces the durable-fact and memory-path behavior for fact and topic.

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 and resource: it records a durable fact in shared memory (memory/*.md) as a dated bullet with a stable ^id. That is concrete enough for an agent to distinguish it from generic note-writing siblings such as write_note or edit_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?

It gives a clear usage instruction to search_notes first for existing facts, and it explains when to use the supersedes parameter. It does not explicitly say when to prefer write_note or edit_note instead, so it falls short of full alternative routing.

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, so the safety profile is covered. The description adds genuine behavioral content beyond that: the hybrid keyword+semantic retrieval model and the shape of results (paths, headings, snippets), which tells the agent it gets excerpts, not full documents. Ranking, pagination, and result-ordering behavior are not described.

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, front-loaded with what the tool does, then what it returns, then the follow-up routing. Every sentence carries distinct information with zero repetition of the schema.

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

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

For a read-only search tool with a fully documented schema and no output schema, the description covers purpose, retrieval mechanism, and return shape, which is sufficient to call it correctly. It leaves out ranking/ordering behavior and whether results are truncated by the limit, minor gaps for this complexity level.

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

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

Schema coverage is 100%, with each of query, mode, and limit documented in the schema including the enum and defaults. The description's mention of hybrid keyword+semantic implicitly signals the mode values but adds no syntax, formatting, or query-construction guidance beyond the schema, 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 (search the vault) plus the mechanism (hybrid keyword + semantic search), and explicitly distinguishes itself from read_note by scoping itself to discovery and routing full-content reads elsewhere.

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 line 'Use read_note for full content' gives a clear alternative for the follow-up step, implying this tool is for locating notes. It does not address when to prefer search_notes over list_notes, recent_activity, or build_context, so sibling routing is only partially covered.

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 present, the description carries the full burden, and it does disclose one important behavior: the tool fails rather than overwrites when the path already exists. It says nothing about required permissions, what the created note returns, or how tags are persisted, leaving meaningful behavioral gaps for a mutation 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, each doing distinct work: the first states the action, the second states the failure mode plus the redirect. Nothing is redundant and the key constraint follows immediately after the action.

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 four-parameter mutation tool with no output schema and no annotations, the description covers the failure case but omits what a successful call produces and how tags/folder interact with the created path. It is minimally sufficient to call correctly but not fully self-contained.

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 75%, so most parameters are documented structurally (title, content, folder), and the description adds little beyond restating that the body is markdown. The 'tags' parameter has no description in either place, so the description doesn't compensate for the remaining gap.

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 gives a specific verb and resource ('Create a new markdown note') and explicitly distinguishes itself from the sibling edit_note by noting that creation fails on an existing path. An agent can separate write_note from edit_note or append_daily without opening a 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?

It states a concrete condition ('Fails if the path already exists') and names the correct alternative ('use edit_note to modify existing notes'), which is explicit routing guidance. It stops short of covering the other siblings, such as when to prefer append_daily or remember, so it isn't fully exhaustive.

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