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

With no annotations, the description carries the full burden. It usefully discloses the default filing behavior (Tasks section, or today's daily note when no note is given) and that the task is a checkbox item, but it omits whether a missing note gets created, error behavior, and what is returned.

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, front-loaded with the core action and destination. No wasted words, and the useful default-behavior detail is included rather than 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 five-parameter write tool with no annotations and no output schema, the description covers purpose and default placement but leaves gaps: behavior when the target note does not exist, and whether/how success is reported. Adequate but with clear omissions.

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 80%, so the schema already documents due, note, text, and heading. The description adds little beyond restating due-date and priority support, and the priority enum still has no description anywhere. 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 (add) and resource (a checkbox task) plus the destination (a project's Tasks section or today's daily note). This clearly distinguishes it from siblings like complete_task, update_task, and list_tasks, which operate on existing tasks rather than creating new ones.

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 implies when to use it by describing the default destination (daily note if no note given) and what it supports (due date, priority). However, it never explicitly routes the agent away from alternatives such as update_task or complete_task, so the guidance is implied rather than 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?

With no annotations, the description carries the full burden and does disclose two real traits: the operation is non-destructive and a missing heading is auto-created at the end. It omits what happens if 'ref' matches no note (error vs. creation) and gives no return-value context.

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 no filler. The core action is front-loaded and the clarifying safety note follows immediately.

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-param mutation tool with no annotations and no output schema, the description covers the mechanics but leaves meaningful gaps: behavior when the note does not exist, and what the agent should expect on success or failure.

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 baseline is 3. The description adds genuine meaning beyond the schema for 'heading' by explaining the create-if-missing behavior, which the schema's terse 'Section heading to append under' does not convey.

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 ('Append markdown to a note') plus a qualifier about the target heading. The phrase 'without overwriting anything' implicitly distinguishes it from replace_note_body, but that sibling is not named, leaving the contrast to inference.

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 safe default way to add content without overwriting anything' gives a clear selection rule for content addition. It does not name explicit alternatives or state when-not-to-use conditions, so it falls short of full routing 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. It discloses that the operation is non-destructive and that archived notes are excluded from search and listings by default. However, it omits reversibility (how to unarchive), permission requirements, and 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?

Two tightly written sentences: the first front-loads the action and its role, the second adds a key behavioral effect. No wasted words, and structure is logical.

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 one-parameter tool with no output schema or annotations, the description covers purpose, effect on search/listings, and non-destructive nature. It could still mention reversibility or failure conditions, but it is largely 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 the 'ref' parameter is fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, 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 ('Move') and resource ('a note') with destination ('into the archive folder'), and clarifies its role as 'the non-destructive alternative to deletion'. This distinguishes it clearly from other note operations like replace_note_body or append_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?

Implies usage context by calling it 'the non-destructive alternative to deletion', which tells the agent when to prefer this over deleting. No explicit when-not or named alternative tool, but the context is clear enough.

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 must carry the behavioral burden and it does well for a zero-parameter tool: it discloses the full set of content categories returned, which is the key behavioral fact. It does not explicitly state read-only safety, permissions, or pagination/limits, leaving a small gap.

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

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

Two tight sentences: the first front-loads what the agent gets back, the second front-loads when to call it. No filler or restatement of the name.

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 must describe the return contract – and it enumerates every content category (projects/next tasks, overdue/upcoming tasks, inbox, recent notes). For a no-param aggregate read tool, 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify beyond the schema. No misleading param hints are present.

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 (orient) and enumerates exactly what the tool surfaces: active projects with next tasks, overdue/upcoming tasks, inbox items, and recent notes. This composite scope distinguishes it clearly from single-purpose siblings like list_tasks, list_projects, and list_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?

Gives explicit trigger conditions – session start, or the question 'what am I working on?' – which an agent can act on directly. It stops short of naming alternatives (e.g. use list_tasks for a filtered task list), so it is clear context but not exhaustive 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the write target (inbox) and the deferred-processing intent, but says nothing about whether titles are deduplicated, whether the capture is reversible, what is returned, 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 sentences, front-loaded with what happens (capture into inbox) before the usage condition. Every clause earns its place with no 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?

For a two-parameter, single-required-field capture tool with no output schema and no annotations, the description covers purpose, destination, and usage condition adequately. Only the return value / post-capture behavior is unaddressed, which is minor here.

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 baseline is 3. The description adds only the general notion of 'a thought, link, or piece of information' and does not elaborate on the two parameters beyond what the schema already documents (including the markdown acceptance and title derivation).

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 (capture) and destination (inbox) plus the kinds of content accepted (thought, link, information). It is clear on its own, but it never names the sibling it most resembles (create_note/append_note), so an agent must infer the distinction from the 'inbox' framing alone.

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 when something is worth keeping but you don't yet know where it belongs' is an explicit selection condition, and it implicitly excludes the directed-note siblings. There is no explicit when-not statement or named alternative, which is what keeps it from 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses a side effect beyond the obvious one ('Stamps today's date'), but says nothing about whether completion is reversible, what happens on an ambiguous fragment, or what is returned on success.

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, with the action and accepted inputs front-loaded and the side effect stated last. Every clause 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?

For a single-parameter mutation tool with no output schema and no annotations, the description covers both input modes and one non-obvious side effect. It is only short on error/ambiguity behavior, which is a modest gap at this complexity.

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 already 100%, so the baseline is 3. The description goes beyond the schema by explaining the provenance of the id ('from list_tasks') and that the free-text form must be a unique fragment, which adds real matching semantics.

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 ('Mark a task done') and names the two accepted identifiers, so an agent knows exactly what the tool does. It does not differentiate itself from the sibling update_task, which could plausibly also set completion state, so it falls 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?

The description tells the agent where task ids come from ('from list_tasks') and that a text fragment is an accepted alternative, which is implied usage guidance. It never states when to prefer this tool over update_task or what to do if the fragment is not unique.

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. It usefully discloses the type→folder placement behavior (note→notes/, project→projects/, etc.), which is genuine behavioral context. But it is silent on overwrite semantics, what happens when a note already exists at the path, and permission/error behavior, which matters for a create 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 sentences, front-loaded with the core action and the type mapping inline. The parenthetical folder list is dense but earns its place; nothing redundant.

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?

A 6-parameter create tool with a nested frontmatter object and no output schema needs the description to cover side effects and edge cases. The type routing is well covered and the schema handles parameter detail, but the destructive 'overwrite' path and existence/error behavior are entirely 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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema's bare enum by mapping each type value to its destination folder. It adds nothing for body, tags, overwrite, or frontmatter beyond the schema text.

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+resource ('Create a markdown note') and richly specifies the type parameter's folder routing, which makes the resource concrete. It does not, however, distinguish this from siblings like capture, append_note, or daily_note, so an agent gets no routing signal from the purpose text itself.

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 only guidance is content-style ('use [[wikilinks]]... link generously'), not tool-selection guidance. It never says when to use create_note versus capture, append_note, or replace_note_body, nor any preconditions. An agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden, and it does disclose the created note's section layout and frontmatter. However, it omits other behavioral traits an agent needs: permissions required, behavior on duplicate titles, side effects, and what the call returns.

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, correctly front-loaded with the action and produced structure before the contextual note about relationships. No filler, though the second sentence is more contextual than strictly necessary.

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?

No output schema exists, so the description should ideally say what the call returns (note path, id, etc.) and how duplicates are handled; it does not. It is adequate for understanding what will be created but leaves the return and edge-case behavior unspecified.

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 83%, so the schema already documents nearly all parameters including the enum and date pattern. The description only hints at 'status frontmatter' and adds no format or constraint detail beyond the schema, matching the baseline for high-coverage schemas.

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 ('Create a project note') and specifies the internal structure it produces (Goal/Tasks/Notes/Log sections, status frontmatter), which distinguishes it from the generic create_note sibling. It stops short of explicitly naming create_note as the alternative, so an agent must infer the distinction.

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 second sentence gives context on what projects are ('the unit of ongoing work') and how to relate notes to them via [[wikilinks]], which implies when a project is appropriate. But there is no explicit when-to-use-vs-create_note or exclusion 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?

No annotations are present, so the description carries the full behavioral burden. It usefully discloses append (additive, non-destructive) semantics and the automatic timestamp, but says nothing about whether the daily note is created if it is missing, ordering, or failure behavior — notable gaps for a write tool with zero annotation coverage.

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 the action and target front-loaded and the intent trailing; 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 one-parameter append tool with no output schema, the description covers what gets written and where. The remaining gap is mutation-side behavior (note creation on miss, error handling) that would matter more given the complete absence of annotations.

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% for the single "text" parameter, so the baseline is 3. The description reframes the field as "decisions, progress, and events," adding only marginal meaning beyond the schema's "What happened / what was decided."

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 ("Append") and a precise resource ("today's daily note Log section") with the "timestamped" qualifier, which separates it from the generic append_note sibling. It stops short of naming that sibling explicitly, so differentiation is inferable 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?

"Use to record decisions, progress, and events as they happen" gives a clear situational context for when to reach for this tool. It offers no exclusions or named alternatives (e.g., vs. append_note or capture), which keeps it out of the top band.

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 it delivers the single most important trait: the call may create the note from the daily template as a side effect. It stops short of saying whether creation is silent, what template is used, or what happens on write failure.

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 primary action and the date scope, with the create fallback appended. Nothing extraneous.

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-optional-parameter tool with no output schema and no annotations, the description covers the default value, the date override, and the auto-creation behavior. Remaining gaps (return shape, template details) are minor.

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 'date' parameter is already documented with its pattern and default. The description restates the today/specific-date behavior but adds no format or edge-case detail beyond the schema, matching 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 and resource ('Return today's daily note'), scopes it to a specific date, and discloses the get-or-create semantics. It doesn't explicitly differentiate itself from siblings like read_note or create_note, but 'daily note' is a recognizable distinct resource.

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: call it to obtain today's (or a given date's) daily note. There is no explicit when-not guidance or pointer to alternatives such as read_note for arbitrary notes or create_note for non-daily notes, so the agent must infer the boundary.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the sort order ('most recently modified first'), which is genuinely useful and not in the schema, but says nothing about the default result cap, pagination, or what happens when filters are combined. For a read-only list operation the risk profile is low, so this partial disclosure is adequate rather than rich.

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, no filler. The capability and the ordering are front-loaded, with the sibling routing in the second sentence where it belongs.

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-required-parameter read tool, the description covers filters, ordering, and alternative routing. The gap is that no output schema exists, so it could have said what a result looks like (note identifiers/titles) or how the default limit behaves. Minor omissions only.

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 every parameter already has a description, so the schema does the heavy lifting. The description restates the folder/type/tag filters without adding syntax or semantics beyond the schema, and never mentions the 'limit' parameter or its default. 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?

Specific verb (List) plus resource (notes) plus the three filter dimensions (folder, type, tag) and the ordering guarantee. It explicitly names the sibling it is not (search_notes), so an agent can separate the two without opening either 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?

States the use case directly: 'Use for browsing' versus 'use search_notes for content queries.' This is an explicit when/when-not with a named alternative, leaving nothing 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 burden; it discloses that it is a read-style listing and what data is returned, which is useful. However, it says nothing about ordering, pagination, or whether task counts are scoped to the project only, leaving meaningful behavioral gaps for an unannotated 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, front-loaded with the action and return contents, followed by the valid filter values. Every clause earns its place with no 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?

For a one-parameter read tool with no output schema, the description covers what is returned (status, counts, next tasks) and the valid status filter values. It is nearly complete, missing only ordering/pagination expectations.

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 baseline would be 3, but the description supplies the actual allowed status values (idea, active, paused, done, dropped), which the schema omits since it only says "e.g. 'active'" with no enum. That enumeration is real added value beyond the structured field.

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 ('List') and resource ('projects') and enumerates what the result contains (status, open/done task counts, next tasks). It is clearly distinct from siblings like list_tasks and list_notes by naming the resource, though it never explicitly differentiates itself from create_project/set_project_status.

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 when-to-use or when-not-to-use guidance is offered. The status filter implies a way to narrow results, but nothing tells the agent when to reach for this versus list_tasks, brain_overview, or other sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It helpfully discloses the ordering ('most used first') and that counts are included, but says nothing about read-only nature, pagination, or result limits.

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 packs scope, content, and ordering with zero waste.

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 read-only listing with no parameters, the description adequately conveys the return content (tags plus usage counts) and ordering. Nothing critical to calling it 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?

The tool takes zero parameters, which is the baseline for a 4. There is nothing for the description to add on the parameter front.

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+resource ('List tags') and adds scope and output shape ('All tags in the vault with usage counts, most used first'). Clear, though it does not differentiate itself from listing siblings like list_notes or list_projects.

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 explicit when-to-use or when-not-to-use guidance and no named alternative. Usage is only implied by the 'list' verb in a tag-related toolset.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the sort order and the filtering axes, but says nothing about result size limits, pagination, performance over a large vault, or what a returned task row contains.

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 filler, with the scope and sort order front-loaded before the filter list. Nothing is repeated or padding.

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-required-parameter read tool with no output schema, the description covers purpose, scope, sort, and filters adequately. It falls short only on the missing 'tag' semantics and any hint about result volume or truncation.

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% (only 'tag' is undocumented), so the baseline is 3. The description restates the status values and the project/tag/dueBy filters but adds no semantics beyond the schema, and does not clarify what 'tag' matches or whether filters are ANDed.

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+resource ('List checkbox tasks') with explicit scope ('across the vault') and even the sort order ('due date then priority'), which is enough to separate it from list_notes, list_tags, and list_projects. It never names a sibling or states a contrast, 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?

The second sentence enumerates the narrowing dimensions (status, project, tag, dueBy), which implies when to filter, but there is no guidance on when to use this vs. list_notes/read_note or any exclusion. The default of 'open' only appears in the schema, not the description.

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 it does disclose the return contents (resolved and broken outgoing links, backlinks), which is genuinely useful. However, it says nothing about behavior for an unresolvable ref, read-only guarantees, or any limits on graph depth or result size.

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 no filler, and the return contents are front-loaded before the usage hint. Every clause 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?

With no output schema, the description correctly compensates by naming what comes back. It is nearly complete for a single-parameter read tool, missing only edge-case behavior (an unknown or broken ref) that would round it out.

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 there is a single parameter ('ref'), so the schema already explains that it accepts a note path, title, or alias. The description adds no syntax, disambiguation, or format guidance beyond that, 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?

The description gives a specific verb and resource ('Show a note's graph neighborhood') and enumerates the two things returned: outgoing wikilinks (resolved and broken) plus backlinks. That is far more precise than a tautology. It stops short of 5 because it never distinguishes itself from the nearby sibling 'related_notes', which an agent could easily confuse with this graph-neighborhood view.

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 to explore context around a topic' gives an implied purpose but no explicit when-to-use conditions, prerequisites, or named alternatives such as related_notes or search_notes. The agent is left to infer which of the three link/related tools to pick.

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 and does useful work: it discloses case-insensitive matching and that the response includes frontmatter plus full body, which matters since no output schema exists. It omits failure behavior (e.g., what happens when the reference resolves to nothing) and any concurrency or size caveats.

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 lookup-key enumeration front-loaded and the return payload second. Nothing is repeated 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 no output schema, the description covers the essential call mechanics and return contents. The only meaningful omission is not-found/ambiguity handling when a reference is missing or matches multiple notes.

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 baseline is 3, but the description adds meaning beyond the schema by declaring case-insensitive matching and adding 'filename' as an accepted form that the schema's 'Path like ... or a title/alias' does not mention. That extra acceptance detail is actionable for constructing ref.

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 (note) and enumerates the accepted reference forms (path, title, alias, filename). It is unambiguous what the tool returns, but it never names or contrasts itself with siblings like search_notes, list_notes, or related_notes, which an agent must distinguish it from.

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 description makes clear this fetches an existing note when you already know its reference. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as search_notes when the reference is unknown.

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 does meaningful work: it discloses the five signals used and, importantly, that semantic similarity only applies 'when embeddings are enabled' — a conditional capability most tools omit. It does not state that results are read-only, how they are ranked, or whether the operation is expensive, but the mechanism disclosure is well above the norm for an unannotated 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 sentences, zero filler. The first front-loads the result-category breakdown; the second delivers usage. Every clause carries information an agent needs.

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 two-parameter read tool with full schema coverage and no output schema, the definition covers purpose, mechanism, and usage adequately; the enumerated reasons effectively preview the return shape. It is only missing result ordering/ranking and any sibling comparison, which are minor gaps rather than blockers.

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 'ref' (path/title/alias) and 'limit' (max 25, default 8) are fully documented structurally. The description adds no syntax, format, or defaulting detail 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?

The description states a specific verb+resource ('Find notes related to a given note') and enumerates the substantive result categories (direct links, shared link-neighbors, rarity-weighted tags, unlinked title mentions, semantic similarity). It is clearly distinguished from generic search by its relation-based scope, but it never names the overlapping sibling note_links, so differentiation is left to inference.

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 two concrete use cases ('pull surrounding context before working on a topic' and 'find where a new note should link'), which is clear positive guidance. It does not state when to prefer note_links or search_notes instead, or any exclusions, so the when-not side is missing.

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, and it does disclose the key destructive-scope fact: the entire body is overwritten while frontmatter is preserved. That is exactly the trait an agent needs to avoid accidental data loss. It stops short of stating reversibility, confirmation behavior, or error cases, 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?

Two sentences, zero filler, with the core operation and its constraint front-loaded ahead of the routing advice. Every clause 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?

For a simple two-parameter, fully schema-documented tool with no output schema and no annotations, the description covers the operation, its scope, and its sibling routing. The only shortfall is the absence of any note on reversibility or return behavior, which is minor here.

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 'ref' and 'body' are already documented in the schema. The description adds no format or syntax detail beyond the schema (e.g., what 'markdown body' accepts), 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 ('Rewrite a note's entire body') and immediately scopes it with '(frontmatter preserved)', which is the exact distinction that matters. It contrasts cleanly with the append_note sibling, which shares the resource but not the operation.

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?

Names the alternative tool explicitly ('Prefer append_note for additions') and gives the precise condition that selects this one ('only for deliberate rewrites/reorganizations'). Both when-to-use and when-not-to-use are present, so no inference is required.

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 and does disclose non-obvious behaviour: titles are boosted, matching is fuzzy and prefix-based, and results are fused with semantic search only when embeddings exist. It stops short of stating that the operation is read-only and that results are ranked (no ordering or pagination behaviour is described), so the safety profile must still be inferred.

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 padding, and the core capability is front-loaded before the list of filters. Every clause adds information an agent can act on; nothing restates the tool name or 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 6-parameter read-only search with no annotations and no output schema, the description covers matching semantics and all filter dimensions adequately. It leaves the return shape and result ordering unexplained, but those are lower-stakes for a search call whose limit is already documented in the 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 100%, which sets the baseline at 3, but the description earns more by enumerating the accepted type values (note/project/daily/person/reference/area) that the schema leaves unenumerated (0 enums). It also confirms the filterable dimensions (tag, folder prefix, frontmatter status) in one sweep, though it adds no format detail beyond the schema's own examples.

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') and goes further by naming the retrieval mechanics (full-text with boosted titles, fuzzy + prefix matching, fused semantic search). It never names the obvious siblings (list_notes for unfiltered listing, related_notes for neighbour discovery), so an agent must infer the boundary rather than being told it.

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/when-not guidance and no alternative is named, even though list_notes and related_notes overlap meaningfully with this tool. The only conditional in the text ('when the vault has embeddings enabled') describes internal behaviour, not when an agent should pick this tool over a sibling.

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. It usefully discloses one non-obvious side effect — that 'done' stamps a completion date — which goes beyond the schema. However, it omits whether the change is reversible, whether it overwrites a prior status, permission requirements, and the error behavior for an unknown ref, leaving real 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 compact sentences with the action and the valid status set front-loaded, followed by the one notable side effect. 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?

For a two-parameter mutation with no annotations and no output schema, the description covers status semantics and the completion-date side effect but omits failure modes, permissions, and what the tool returns. It is minimally viable rather than 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 50% (ref is documented as 'Project path or title' in the schema; status is an undocumented enum). The description re-lists the enum values but adds no new meaning beyond the schema's enum, and says nothing about ref resolution ambiguity (path vs. title collision). At 50% coverage this is only marginally additive.

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 (Change) and resource (a project's status), and enumerates the accepted status values, so an agent can tell it performs a status mutation on a project. It does not name or contrast itself with the related project tools (create_project, list_projects), which is the only thing keeping it from 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 says what it does but never says when to use it, what prerequisites exist (must the project already exist), or which sibling to use for adjacent jobs like creating a project. There is no when-to-use or when-not-to-use guidance at all.

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, and it does disclose the key behavioral facts: a merge (other keys are preserved) and null-based key removal. It says nothing about permissions, error handling when the note is missing, or how YAML types are coerced.

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 packed sentences; the core operation and its deletion semantic lead, and the use-case list follows. No wasted words.

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 two-parameter mutation tool with no output schema and no annotations, the description supplies the essentials: merge semantics, deletion mechanism, and intended use cases. Missing only peripheral behavioral notes (auth, failure modes).

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 (ref, updates) are already documented in the schema; baseline 3 applies. The description adds only a hint that the keys are things like status/priority/due, which is marginal value over the schema's 'Keys to set; null deletes a key'.

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 ('Merge keys into') and resource ('a note's YAML frontmatter'), plus the null-deletion semantic that defines the operation. It is distinguishable from siblings like replace_note_body or append_note by resource, 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?

'Use for status, priority, due, area, tags, aliases' gives concrete context for when this tool applies. There is no statement of when not to use it or which sibling to prefer for body edits, so it falls short of a full routing guideline.

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 burden and does disclose meaningful traits: the edit is in-place and does not rewrite the note, and matching works on ids or unique text fragments including done/cancelled items. It stops short of stating what happens on no match or ambiguous fragment, or what the mutation returns.

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 plus one routing clause; the edit scope and mode list are front-loaded and every phrase earns its place with no restatement of the title or name.

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 5-parameter mutation tool with no annotations and no output schema, the description covers what is mutated, how targets are resolved, and the sibling alternative. Only the failure/ambiguity behavior and return shape remain unaddressed, which is a minor 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 baseline is 3, but the description adds intent-to-parameter mapping that the schema doesn't ('reopen', 'cancel', 'reword', 'reprioritize') and clarifies that the `task` argument accepts either an id or a unique fragment spanning closed tasks.

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?

Names a specific verb (edit) and resource (one task) and enumerates the concrete edit modes — reschedule, reprioritize, reword, reopen, cancel. It also explicitly distinguishes itself from complete_task and from note-rewriting siblings, so an agent can route 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?

Gives explicit routing: 'Use complete_task to finish a task,' plus the lookup path ('Matches by id (from list_tasks) or a unique text fragment'). It also states the tool will reach done and cancelled tasks, which tells the agent when this tool is appropriate versus a narrower one.

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 at all, the description carries the full burden, and the diagnostic framing ('lint') does usefully imply a read-only, non-mutating operation. However, it says nothing about the output form, whether findings are severity-ranked, whether thresholds for 'stale' or 'overdue' are configurable, or how large/costly the scan is. It adds some behavioral signal but leaves the agent guessing about the response.

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, and the capability list is front-loaded before the usage hint. The six-item colon list is dense and slightly scannable rather than prose, but every item carries information and nothing is redundant.

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 tool with no annotations and no output schema, the description covers what is checked but not what comes back or in what structure. Enumerating the six check categories is the right core, yet an agent still cannot anticipate the result shape, which is the main remaining 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?

The schema is an empty object with no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the enumerated checks are the only 'input' semantics an agent needs, and they 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?

States a concrete verb ('lint') against a concrete resource (the vault) and enumerates the six specific classes of problems it detects: broken wikilinks, duplicate titles, stale active projects, overdue tasks, orphan notes, inbox pileup. That enumeration makes it unmistakably distinct from every sibling, all of which read, list or mutate individual notes/tasks/projects rather than diagnosing vault-wide integrity.

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 during reviews' gives a trigger context, which is more than most definitions offer, but it never states when NOT to use it or names any alternative. Since no sibling performs a comparable diagnostic, the routing risk is low, but the guidance remains 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.