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

With no annotations, the description must carry the behavioral burden; it usefully discloses that notes are created from a template unless empty=true and that the path is returned. However, it omits important behavior for a write operation: what happens if a note with that title already exists, whether creation requires auth, and error conditions.

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 well-formed sentence that front-loads the core action and parenthetically qualifies it, with zero wasted wording.

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 3-parameter tool with fully documented parameters, the description is nearly adequate and helpfully states the return value in the absence of an output schema. It still leaves duplicate-title handling and failure modes unstated, which matters for a creation tool with no 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 coverage is 100%, so all three parameters are already documented in the schema, and the description largely restates the 'empty' semantics. It adds only marginal value (the template-vs-title-only framing) beyond the structured field descriptions, 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 (creates) and resource (note), plus the two modes of creation and the return value. The create action is clearly distinct from the read/list/search siblings, 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 description explains the meaning of the 'empty' flag but gives no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. An agent gets no routing help beyond the obvious verb.

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. 'Returns' implies a read-only operation and it discloses the shape of the returned board (ordered columns containing cards), which partially compensates for the absent output schema. However, it says nothing about permissions, empty-board behavior, or data freshness.

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 names the resource first and then adds the one detail that matters (return structure). No filler, 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 zero-parameter read tool with no output schema, the description supplies the key return-shape information (ordered columns, each with its cards) that would otherwise be unknown. Only minor gaps remain, such as what an unconfigured board returns.

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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing parameter behavior that does not exist.

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 ('Returns the Kanban board') and even characterizes the payload structure (configured columns, in order, each with its cards). It is clearly distinct from the note/task siblings that make up the rest of the toolset, though it does not explicitly name any of them.

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 statement of when to use this tool versus alternatives such as list_tasks, nor any prerequisites or exclusions. The agent must infer usage purely from the name and the single-sentence 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation and describes returned fields, but does not state whether the operation is read-only, whether it paginates, how many notes are returned, or any performance or scope constraints.

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

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

The description is a single efficient sentence that front-loads the verb and resource and then the returned data. 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 zero-parameter list tool with no output schema and no annotations, the description is adequate but incomplete. It gives no behavioral context (read-only? pagination? scope?) and does not distinguish itself from search_notes, leaving gaps an agent may need filled.

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?

Parameter count is 0 and schema coverage is 100%, so the baseline is 4. The description adds relevant context by enumerating the fields each listed note will contain, which is useful even though no parameters exist.

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

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

The description clearly states the verb 'Lists' and the resource 'Lazymark notes', and enumerates the returned fields (path, title, tags, task count). It does not explicitly differentiate from search_notes, but the enumerated output fields hint at the list vs. search distinction without naming the 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?

No explicit when-to-use or when-not-to-use guidance is present. The listing behavior and returned field set imply a browsing use case, but an agent must infer that search_notes is the alternative for filtered lookups.

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 supplied, so the description carries the full burden. It does disclose the shape of each returned task, which is genuinely useful for a tool with no output schema, but it says nothing about read-only safety, result limits, pagination, or ordering, leaving real behavioral gaps.

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

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

A single front-loaded sentence with no filler; the field enumeration earns its place because there is no output schema. It is efficient 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 simple read-only, zero-required-parameter list tool with full schema coverage, describing the returned fields adequately compensates for the absent output schema. Missing usage routing and pagination notes keep it from being fully 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 100%, so all three optional filters (column, note_path, pending_only) are already documented in the schema itself. The description adds no syntax, format, or combination semantics beyond that, which is the expected baseline when the schema does the heavy lifting.

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+resource ('Lists the tasks') plus the returned fields (id, text, column, done status), which lets an agent distinguish it from get_kanban and list_notes. It stops short of explicitly contrasting itself with the sibling listing tools, so it is clear but not fully differentiated.

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 guidance, no mention of alternatives (get_kanban, search_notes, list_notes), and no statement of prerequisites or context. The only filtering hints live 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 burden and does well: it discloses that only the task's line is rewritten and that a concurrent on-disk change causes no write and an error return (optimistic concurrency). It does not mention permissions, auth requirements, or what a successful call returns, leaving modest gaps.

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 core action front-loaded and the concurrency caveat immediately after. No filler, no restatement of 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?

For a two-parameter mutation tool with no annotations and no output schema, the description supplies the key operational semantics (partial line rewrite, conflict-triggered error with no write). It could be slightly more complete on success behavior or auth, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (id and column) are already fully documented in the schema, including the id format and where to find column ids. The description adds no parameter-level detail, so baseline 3 applies.

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

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

States a specific verb (moves) and resource (a task) plus the target domain (another column of the Kanban board), which cleanly separates it from siblings like toggle_task, set_task_date, and get_kanban. An agent can identify the operation without opening the schema.

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

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

Usage is only implied by the purpose: it should be used when a task needs to change columns. No explicit when-not conditions or alternatives are named, and no prerequisites (e.g. that the task id must come from list_tasks/get_kanban) are stated, though that is partially covered by the schema.

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 does disclose the read-only nature of the operation and what is returned (Markdown content of a note scoped to the notes folder), but says nothing about behavior for missing paths, paths outside the folder, or large notes.

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

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

A single sentence with no filler, front-loading the verb and resource. It is efficient, though its brevity borders on under-specification for the tool's edge cases.

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 usefully states that the return is the note's Markdown content, which compensates somewhat. However, with no annotations and no error/edge-case behavior described, it is only minimally complete for an agent invoking it.

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

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

Schema coverage is 100% and the schema description for 'path' already explains absolute/relative resolution, the notes-folder constraint, and that list_notes/create_note ids work as-is. The description adds no parameter meaning beyond that, so baseline 3 applies.

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

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

The description gives a specific verb (reads), resource (a note in the notes folder), and content type (Markdown). It is clearly separable from list_notes, search_notes and create_note, though it never names them 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?

There is no when-to-use or when-not guidance and no mention of alternatives such as search_notes for content discovery or list_notes for enumeration. Usage is only weakly implied by the verb 'reads'.

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 disclosure burden. It usefully states the default case-insensitive behavior, the ordering ('by note and line'), and the per-match payload, but says nothing about result limits beyond the schema, no-match behavior, or permissions. Reasonable for a read-only search, but incomplete.

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 with no filler; scope and case behavior are front-loaded, and the return shape and ordering land in the second sentence without 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, but the description compensates by naming the returned fields (note, line, context) and their ordering. For a read-only search tool with full schema coverage, that is nearly enough; only no-match and result-volume behavior are unstated.

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 all four parameters including query, regex, case_sensitive, and limit are already documented. The description's 'case-insensitive' remark reinforces rather than extends the schema, and adds no syntax or format detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Searches text in all the notes') plus a clear scope ('all the notes'), which implicitly separates it from read_note and list_notes. It never names those siblings explicitly, so the 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?

Usage is only implied: the phrase 'in all the notes' suggests this is the cross-note lookup versus read_note's single-note retrieval, but there is no explicit when-to-use, when-not-to-use, or alternative named. Mid-tier 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, and it does disclose a meaningful behavioral trait: it rewrites only the task's line, which bounds the side effect. It also flags a format dependency (Obsidian Tasks configured date format). It is silent on permissions, failure modes (e.g., invalid or nonexistent date), and the response shape.

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

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

Three short sentences, zero filler, with the core action front-loaded and the scope-limiting and boundary facts following in priority order. Every sentence contributes something an agent can act on.

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 three-parameter mutation tool with full schema coverage, no output schema and no annotations, the description covers the action, the format dependency, the side-effect scope, and the completion-date exclusion. The main remaining gap is that permissions and error behavior are unaddressed.

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

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

Schema coverage is 100%, so the schema already documents all three parameters including the id format, the YYYY-MM-DD / "none" convention, and the start/due enum. The description adds only the format context ('Obsidian Tasks format, the configured date format'), which is marginal on top of the schema.

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

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

The description names a specific verb pair (sets/removes) and resource (start date or due date of a task), so an agent immediately knows the operation. It stops short of explicitly naming a sibling tool for the excluded case, referring instead to 'moving the task to the done column' rather than move_task.

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 an implied use case (setting/removing start or due dates) and one boundary: completion dates are out of scope and handled by a column move. That boundary is useful but is phrased as an aside and never names the alternative tool or states when to prefer this over siblings like toggle_task.

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 exist, so the description carries the full burden. It usefully discloses the two-way state transition (done -> first column on repeat), but says nothing about permissions, whether a completion date or other fields are mutated as a side effect, or error behavior 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?

A single front-loaded sentence that conveys the action and its conditional branch with zero filler. 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 mutation tool with no annotations and no output schema, the description covers the core state change but omits return/error expectations and the id-vs-line/path invocation choice implied by zero required parameters. Adequate but with real gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter detail and does not clarify the presence of the legacy line/path form versus the preferred id, nor that one form is required even though required count is 0.

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 (marks done / returns) and resource (task), and spells out the toggle state machine (done column vs first column). It is distinguishable from move_task in spirit, but the description never names move_task or otherwise explicitly contrasts its two-state behavior with arbitrary column moves.

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 'or, if it already was' clause implies when the tool applies (flipping completion state), but there is no explicit when-to-use/when-not guidance and no alternative named despite move_task and set_task_date being siblings. Usage is left to inference.

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