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

With no annotations, the description carries the disclosure burden and does so well: it states the mutation ('dumps content as a bullet point'), the conditional side effect ('Creates the daily note if it doesn't exist'), and the return type. It does not cover edge cases like duplicate content or formatting, but the core behavioral traits are transparent.

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 compact and front-loaded: purpose first, then behavioral details, then Args/Returns. Every sentence contributes; there is no repetition of the schema or filler.

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 capture tool, this is complete: it explains the exact action, the destination inside the note, the auto-create side effect, and the return value. The output schema exists, so the explicit Returns line is a bonus; an agent has enough 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 schema only declares `content` as a required string with no description (0% coverage), so the description's Args section is essential. It defines the parameter as 'The thought, idea, or todo to capture,' which fully conveys the intended value despite being brief.

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 identifies a specific action and destination: 'capture a thought, idea, or todo to today's daily note inbox' and 'dumps content as a bullet point to the Inbox section.' It is clear, but it does not explicitly contrast with closely related sibling tools such as append_to_daily_note or capture_content, so it misses the last bit of differentiation.

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?

'Quickly capture' and 'Zero friction' give a clear context: use this for lightweight capture into the daily inbox, and the auto-create behavior explains when it can be used without a pre-existing note. It does not state exclusions or name alternative tools for other append/logging cases, but the intended scenario is obvious.

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 creation of the note and parent directories, the configurable path format, and the return value type. It omits minor details such as timezone handling and how subsection headings are matched/created, but the core side effects are transparent.

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 well-structured and front-loaded: it opens with the core purpose, then adds behavioral context, an exclusion, and a brief args/returns section. Every sentence serves a purpose and there is no redundant filler.

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?

Given only 2 parameters, no annotations, and an output schema, the description covers the essential context: what it appends, where, creation side effects, path configuration, return value, and when not to use it. Minor gaps like timezone and exact subsection formatting prevent a perfect score.

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 0%, so the description must compensate. It provides one-line meanings for both parameters ('Content to append' and 'Optional heading title to append under'). However, it does not explain formatting conventions, newline handling, or how an existing subsection is located, leaving meaningful ambiguity.

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

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

The description states a specific verb ('Append'), a clear resource ('today's daily note'), and a qualifier ('under an optional subsection'). It also distinguishes itself from log_to_daily_note by noting that sibling handles timestamped log entries, making the tool's purpose unmistakable among the many siblings.

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

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

The description explicitly routes timestamped log entries to log_to_daily_note, giving a clear when-not and an alternative. It also implicitly distinguishes from append_to_note by specifying 'today's daily note', though it does not name that sibling or other daily-note-related tools like create_daily_note.

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 behavioral burden. It does disclose that a missing subsection is created at the end and that it returns success or error. It does not mention what happens if the note itself is missing, how content is formatted, or other side effects.

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

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

The description is compact and well-structured with a clear opening sentence followed by Args and Returns sections. Every sentence adds useful information 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?

For a simple tool with three parameters and an output schema, the description covers the essential behavior and all parameter semantics. It lacks only minor context such as behavior when the target note does not exist, but it is mostly 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 0%, so the description must explain all parameters. It does so well: note_path is relative to vault root, content is what gets appended, and subsection is optional with defined behavior when not found. This goes well beyond the bare 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 clearly states a specific action ('Append content to a note') and its main option (subsection). However, it does not distinguish this from sibling tools like append_to_daily_note or log_to_note, so it stops short of full differentiation.

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 use case is implied: appending content to an existing note, optionally under a heading. But there are no explicit alternatives, exclusions, or guidance about when to prefer a sibling tool such as append_to_daily_note or log_to_note.

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 provided, the description fully discloses behavioral side effects: it moves projects and tasks, cancels open tasks, clears focus if set, and logs the event. It also states the archiving restriction and area exception, giving the agent an accurate model of consequences.

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 compact and front-loaded with the core action, followed by side effects, constraints, and parameter documentation. Every sentence earns its place; there is no filler or repeated schema information.

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

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

For a single-parameter tool with an output schema, the description is complete: it covers purpose, preconditions, exclusions, side effects, and parameter meaning. An agent can decide whether to call it and what to pass without further clarification.

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 only provides project_name as a string with 0% coverage, so the description carries full responsibility. It compensates well by defining project_name as 'The project ID or folder name to archive', adding practical meaning beyond the raw type.

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 opens with 'Archive a completed project', a specific verb and resource that clearly distinguishes archiving from sibling tools like cancel_task or update_task_status. It then explains the concrete effect (moving to Projects/_archive/), leaving no ambiguity about what the tool does.

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

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

The description gives explicit preconditions: only projects with status 'done' can be archived, and areas cannot be archived because they are ongoing. It does not explicitly name alternative tools for those cases, but the when-to-use / when-not-to-use guidance is clear.

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

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

With no annotations present, the description carries the full burden and handles it well: it discloses the status mutation to 'cancelled', the timestamp side effect, the automatic logging to the parent project note (a non-obvious side effect an agent must know), and that the reason is appended to the task body. It stops short of discussing reversibility or idempotency (e.g., cancelling an already-cancelled task), but the core behavioral profile is clearly disclosed.

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 tightly organized: a one-line purpose opener, a two-sentence behavior paragraph, and a compact Args list. Every sentence earns its place — the example ID, the automatic-logging side effect, and the reason behavior are all high-value. No filler or repetition of schema fields.

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 low-complexity tool (2 params, 1 required, output schema present), the description covers all invocation essentials: what happens, side effects, and full parameter semantics. The only substantive gap is the absence of sibling-selection guidance and edge-case behavior (nonexistent task IDs), which matters more given the large sibling list but does not prevent correct invocation.

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 0%, so the description must fully compensate — and it does. task_id gains a format example ('MDV-001') plus an alternative form (path relative to vault root); reason gains behavioral meaning ('appended to task body'). Both parameters are meaningfully documented beyond the bare schema types.

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 opens with a specific verb+resource ('Cancel a task') and then specifies the exact state change: 'Sets status to cancelled with a timestamp.' This unambiguously distinguishes it from siblings like complete_task (completed status) and update_task_status (generic status mutation); an agent can tell the tools apart without opening schemas.

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

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

The description provides no guidance on when to choose cancel_task over its closely-related siblings complete_task and update_task_status, nor does it state exclusions (e.g., when a task should be completed instead). With 48 sibling tools including multiple status-mutating ones, this selection decision is left entirely to the agent's inference, and the description gives nothing to resolve it.

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 must bear the full burden of behavioral disclosure. It reveals only that content is captured and a result is returned, leaving unclear whether the operation appends, overwrites, creates files, requires prior configuration, or produces side effects.

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

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

The summary sentence is front-loaded and the Args/Returns structure is clean, with no redundant filler. Every line conveys either parameter meaning or return behavior.

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?

Covers the basic call contract – what it does, its parameters, and that it returns a result – and an output schema exists to describe return values. It lacks context about the configured capture location, configuration requirements, and when this generic capture tool should be preferred over more specific siblings.

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?

Although schema description coverage is 0%, the description defines all three parameters: name with concrete examples, text as the main content bound to a 'text' variable, and extra_vars as optional additional variables. This adds real meaning beyond raw types, though extra_vars usage remains somewhat underspecified.

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 clear action – capture content – and identifies the destination as a configured capture location, with concrete name examples (inbox, log) in the args. However, it does not distinguish capture_content from closely related siblings such as add_to_inbox or log_to_daily_note, so it is clear but not 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?

The description offers no guidance on when to use this tool instead of sibling capture/write tools such as add_to_inbox, log_to_daily_note, or create_note. There is no mention of prerequisites, exclusions, or context that would help an agent pick this over alternatives.

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 of behavioral disclosure. It states only the action and gives no detail on side effects, reversibility, or what happens when no active project focus exists.

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, direct sentence with no filler. The key action and target are front-loaded, making it easy for an agent to parse quickly.

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 tool with an output schema, the description is minimally adequate. However, it leaves the concept of 'active project focus' undefined and does not clarify the operation's effect or whether any state change persists.

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 has zero parameters, so there is nothing for the description to clarify beyond the empty schema. The baseline of 4 applies because the parameter surface is empty.

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 clear action ('Clear') and a specific resource ('the active project focus'), making the tool's purpose immediately understandable. It also differentiates from the sibling 'set_focus' by indicating the inverse 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?

No guidance is provided about when to use this tool versus alternatives like 'set_focus' or 'get_context_focus'. Prerequisites, such as whether an active focus must exist before clearing, are also not mentioned.

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 of behavioral disclosure. It clearly states the side effects: status is set to 'done', a completion timestamp is recorded, and the completion is logged to the parent project note automatically. It does not address edge cases like already-completed tasks, but the core mutation behavior is transparent.

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 compact and front-loaded with the primary purpose. Every sentence adds useful information: the status change, the timestamp, the automatic logging, and the parameter semantics. There is no filler or redundancy.

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

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

For a two-parameter mutation tool with an output schema, the description covers the essential behavior, side effects, and parameter semantics. Minor gaps remain around failure handling and idempotency, but nothing critical is missing for a typical agent call.

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?

Even though the schema itself has no parameter descriptions, the description's Args section fully compensates. It explains that task_id can be either a task ID or a file path, and that summary is optional and appended to the task body. This adds meaning well beyond the raw 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 opens with 'Mark a task as done,' which is a specific verb and resource. It distinguishes itself from sibling tools like cancel_task and update_task_status by naming the exact terminal state and the automatic logging behavior.

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 intended use is clearly implied: call this when a task is finished and should be marked as done. However, it does not explicitly say when not to use it or mention alternatives such as update_task_status for non-done status changes or cancel_task for abandoning a 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 are provided, so the description carries the full burden. It transparently discloses template-based creation, full structure, and idempotent behavior: if the note already exists, it returns a message without overwriting. It does not mention failure modes like a missing template, but the core behavior is well covered.

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

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

The main purpose is front-loaded in the first sentence. The following sentences add non-redundant specifics about structure, idempotency, parameters, and return value. There is no filler or repetition.

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

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

With only two optional parameters, a provided output schema, and no annotations, the description is complete enough for an agent to invoke the tool correctly. It covers parameter formats, defaults, behavior when the note exists, and what is returned.

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 input schema has 0% description coverage and only states types and defaults, so the description must compensate. It fully does: it explains date is in YYYY-MM-DD format, defaults to today, and extra_vars is an optional dictionary of template variables.

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 opens with a specific verb and resource: 'Create today's daily note from the configured template.' It also clarifies the note is fully structured with standard frontmatter fields and sections, which distinguishes it from sibling tools like append_to_daily_note, create_weekly_note, and log_to_daily_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?

The intended use is clear: create the daily note from a template. The no-overwrite clause subtly implies this is not for adding content to an existing note, but it does not explicitly name alternatives like append_to_daily_note or state when to choose them.

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 behavioral burden and does disclose meaningful traits: creation is template-based, notes go to Zettel/Literature/, and the note tracks multi-pass reading progress. It doesn't cover edge-behaviors like overwriting or permission requirements, but for a straightforward creation action it is reasonably transparent.

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 well-structured: a one-line purpose, a short context block, then a clean Args list and a Returns line. It is appropriately sized for a 7-parameter tool whose schema has no descriptions. Only the final 'Result of the creation' line is somewhat non-specific, but it doesn't hurt usability.

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 creation tool with no annotations, it covers the core context: what is created, where it is stored, what workflow it supports, and what each argument means. An output schema exists, so detailed return handling isn't required. It lacks only explicit sibling differentiation and exact source_type constraints, but an agent has enough 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?

Schema description coverage is 0%, so the description fully compensates by explaining every parameter in plain language, including comma-separated authors, the filename-slug purpose of short_title, source_type examples, and extra_vars as additional template variables. This adds real semantic value beyond the bare JSON 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 opens with a specific verb and resource: 'Create a new literature note from the template.' It further distinguishes itself from sibling create tools by specifying the storage location (Zettel/Literature/) and the multi-pass reading workflow, making it clearly different from create_zettel or create_daily_note.

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

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

It gives clear context for when the tool is appropriate: literature notes are for tracking reading progress through skimming, reading, and completed states. It doesn't explicitly name alternatives or when-not-to-use conditions, but the purpose and storage location are specific enough for an agent to infer the intended use case.

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 provided, the description carries the full behavioral disclosure burden. It does this well by disclosing the ID generation scheme, the storage folder, the side effect of logging creation to the daily note, and the return value including the generated meeting ID. It stops short of mentioning failure modes or permission requirements, but the core behavior is transparent.

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 compact and well-structured: a one-line purpose, a short behavioral note, labeled args, and a labeled return section. Every sentence earns its place, and the most important identifying information is front-loaded.

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?

All four parameters are described with useful semantics, the return value is summarized, and important creation behaviors are disclosed. For a straightforward creation tool with a single required parameter and no nested objects, this description gives an agent 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?

Schema description coverage is 0%, so the description must fully compensate for the undocumented input schema. It does: title gets an example, attendees gets a comma-separated format, date gets an explicit YYYY-MM-DD format and default, and extra_vars is explained as an optional template-variable dictionary. This adds far more meaning than the bare 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 opens with 'Create a new meeting note,' which is a specific verb and resource, and then adds distinguishing details: auto-generated IDs in the MTG-YYYY-MM-DD-NNN format and storage in the Meetings/ folder. This clearly identifies the tool among the many create_* siblings without relying solely on the tool name.

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 states what the tool does but gives no guidance on when to use it versus alternatives like create_zettel, create_daily_note, or create_literature_note. There are no preconditions, exclusions, or selection criteria, so the agent gets no help choosing among the sibling creation 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?

With no annotations, the description carries the full burden and discloses key side effects: it writes to a specific path, does not overwrite an existing note (returns a message instead), and defaults the period to the current month. It stops short of detailing template configuration or folder creation, but core mutation behavior is transparent.

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?

Well-organized with Args and Returns sections, making it easy to scan. The only minor redundancy is that the first sentence restates what the second sentence already says, but overall every section 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?

Covers purpose, target path, overwrite behavior, and parameter semantics; since an output schema exists, detailed return descriptions are not required. It is slightly thin on usage boundaries and what 'configured template' refers to, but adequate for this tool's 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 description coverage is 0%, and the description fully compensates by documenting all four parameters with formats, defaults, and semantics: period (YYYY-MM, defaults to current month), period_start/period_end (YYYY-MM-DD for non-calendar periods), and extra_vars (dictionary of additional template variables).

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 ('Create') and resource ('monthly report note') with a concrete target path (Journal/YYYY/Monthly/YYYY-MM.md). This clearly distinguishes it from sibling note-creation tools like create_daily_note and create_weekly_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?

No explicit guidance on when to choose this tool over alternatives like create_daily_note or create_weekly_note. The monthly scope and path imply the intended use case, and the description covers the no-overwrite behavior, but the routing guidance is only implicit.

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 provided, the description carries the disclosure burden. It adds useful constraints such as description max length, kind semantics, and optional extra_vars, but it does not mention permissions, duplicate-title behavior, or side effects beyond creating a project or area.

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 one-line purpose is front-loaded and the Args block is compact and scannable. Every line adds information about a parameter or constraint; there is no filler or repeated schema boilerplate.

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?

All six parameters are documented with enough semantics to invoke the tool correctly, and optionality is clearly marked for description and extra_vars. Return-value details are presumably covered by the output schema, so their absence is acceptable; the remaining gaps are behavioral depth and explicit sibling-routing guidance.

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 0%, and the Args section compensates fully: every parameter is named with a purpose, and context, status, kind, and extra_vars receive concrete examples or default semantics. This goes well beyond the raw property type information in the input 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?

Opens with a specific verb and resource, 'Create a new project or area,' clearly distinguishing it from sibling creation tools like create_task, create_zettel, and create_meeting. The Args section reinforces the exact resource kind, so an agent can tell it apart without opening sibling definitions.

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 project/area distinction in the kind parameter but never explicitly states when to prefer this tool over create_task, create_zettel, or create_meeting. It implies its use context from the first line and parameter semantics, but leaves the when-to-use guidance 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 present, the description carries the behavioral disclosure burden and does well by explaining automatic project fallback, context inheritance, and parameter constraints like the 1024-character limit on descriptions and expected formats for due_date, priority, and status. It does not detail persistence guarantees or failure scenarios, but 'create' clearly signals mutation and the output schema covers return values.

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 efficiently front-loaded with the primary action and key behavioral nuance, followed by a clean, uniformly formatted Args list. Every line earns its place, and the structure makes scanning parameter semantics easy for an agent.

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?

The description covers all seven parameters, the active-focus fallback behavior, and relevant example values, while the presence of an output schema reduces the need to document return values. It could be more complete by specifying whether project names must pre-exist or how invalid due_date strings are handled, but it is sufficient for correct invocation.

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 input schema has 0% description coverage, so the Args section is essential and fully compensates by explaining every parameter's purpose, optionality, formatting, and examples. This adds substantial meaning beyond the bare schema types and defaults.

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 opens with 'Create a new task', a specific verb-plus-resource statement that clearly identifies the tool's core function. It is readily distinguishable from task-focused siblings like update_task_status, complete_task, and cancel_task because it is explicitly about creation rather than modification or removal.

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 provides clear usage context, especially the automatic fallback to the active focus context when no project is specified, and notes that context inheritance is handled automatically. It does not explicitly state when not to use the tool or name alternatives, but the creation-focused language makes the primary usage scenario evident.

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 provided, the description carries the full burden and does well: it discloses that the tool creates from a template, produces a structured note, avoids overwriting existing notes, and returns a message if the note already exists. This gives clear behavioral expectations for a write operation, though it does not mention details like permissions or file location.

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 well-organized into a clear summary followed by Args and Returns sections. Every sentence adds value: the core action, template source, idempotency behavior, and parameter semantics are all covered without unnecessary verbosity.

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 tool with two optional parameters and an output schema, the description provides sufficient context to invoke it correctly: what it creates, how week is formatted, what extra_vars does, and what happens on conflict. The presence of an output schema further reduces the need to explain return values in detail.

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 0%, but the description fully compensates by defining the week identifier format (YYYY-WXX), accepting date expressions like 'today + 1w', stating the default behavior, and describing extra_vars as a dictionary of template variables. This is exactly the context an agent needs beyond the bare 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 clearly identifies the verb and resource: 'Create a weekly note from the configured template.' It makes the tool's purpose specific and grounded in the vault's weekly note workflow. However, it does not explicitly distinguish itself from sibling tools like create_daily_note or create_monthly_report beyond the name 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 description implies usage through details like using the vault's weekly template, defaulting to the current week, and safely returning a message if the note already exists. It does not explicitly state when to choose this tool over alternatives or when not to use it, leaving some inference to the agent.

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?

Description discloses that files are stored in Zettel/ or per vault configuration, and that creation returns a result including the file path. It does not mention behaviors like duplicate-file handling, overwriting, or validation failures, which matters because no annotations are provided to cover mutation or safety.

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 structured into purpose, storage context, Args, and Returns sections, front-loading the core purpose in the first sentence. It is somewhat lengthy, but each line serves a purpose for a 6-parameter tool.

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?

The description covers purpose, storage location, all parameters, and the return value, and an output schema exists to detail the result shape. It omits edge-case behaviors such as duplicate short_title collisions or directory auto-creation, which would fully round out the picture.

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?

With 0% schema description coverage, the description compensates by explaining every parameter, including examples and semantics: short_title is a filename slug, source and connections are wikilinks, extra_vars are template variables. This adds substantial meaning beyond raw JSON schema types.

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?

Description opens with 'Create a new zettel (atomic knowledge note)', naming a specific verb and resource. It further distinguishes the tool by stating zettels live in the Zettel/ directory and capture a single atomic insight, separating it from sibling create_* tools like create_daily_note or create_literature_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?

Description gives clear context for when to use: it is for atomic knowledge notes stored in Zettel/ rather than daily notes, projects, or meetings. It does not explicitly name alternatives or state when not to use the tool, but the zettel-specific context is unambiguous.

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 provided, the description carries the full burden. It discloses that the tool is an export/read operation, describes the output content, and clarifies the date-range behavior. It stops short of stating potential caveats like data volume, permission requirements, or invalid-area behavior, but the core behavior is transparent.

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 well-structured and front-loaded: the first sentence states the core purpose, followed by a short context sentence, then a clear Args section, and a Returns line. Every sentence adds useful information with no repetition of the schema.

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

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

The description covers the tool's purpose, parameters, defaults, and return value, and an output schema exists to detail the return shape. It is complete for an export tool, though it does not mention edge cases or constraints such as invalid area names or very large date ranges.

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 0%, so the description fully compensates. Every parameter is explained: area name/ID with examples, format choices, and date format with defaults that add meaning beyond the schema's null/default values.

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 ('export'), a clear resource ('area metrics'), and the concrete output formats ('CSV or JSON'). It also defines the content as 'daily note metadata for the area's criteria fields over a date range,' which clearly distinguishes it from siblings like get_area_report or get_activity_report.

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 explicitly frames the tool for 'trend analysis' and 'plotting trends externally,' giving clear context for when it is appropriate. It does not explicitly name alternatives or exclusions, but the use case is specific enough to guide selection.

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 must carry the transparency burden. It does disclose the return format (newline-separated list) and the no-results behavior, which is useful. However, it does not mention read-only behavior, error cases like a nonexistent note_path, or any other side effects.

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

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

The description is compact and front-loaded with the core purpose, followed by concise Args and Returns sections. Every element serves a clear function with no redundant filler.

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-style tool, the description covers purpose, input semantics, and output format. The existence of an output schema reduces the need to explain return values further. Minor gaps include unspecified behavior when the target note does not exist or when note_path includes an extension.

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 only declares note_path as a required string, so the description adds important meaning by defining it as 'Path to the note relative to vault root.' This compensates well for the 0% schema description coverage, though it omits details like file extension or exact matching behavior.

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 action ('Find all notes that link to the specified note') and clearly identifies the resource and direction of linking. It naturally distinguishes this tool from the sibling find_outgoing_links by specifying inbound links.

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 guidance is given about when to use this tool versus alternatives such as find_outgoing_links, search_notes, or read_note. The intended use is only implied by the purpose statement, with no when-not-to-use or alternative routing.

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

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

With no annotations provided, the description carries the behavioral burden. It does disclose the return format as a newline-separated list and handles the empty case, which is useful. However, it does not discuss error behavior, invalid note paths, or what types of links count, leaving some 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?

The description is compact and well-structured with a clear Args and Returns layout. It leads with the main purpose and includes only essential information, with no redundant or filler content.

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, single-purpose tool, the description covers the core inputs and outputs sufficiently. It is slightly incomplete regarding edge cases and link syntax, but the provided information is enough to invoke the tool in the common case.

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 only defines note_path as a string with no description, but the tool description adds the critical semantic 'Path to the note relative to vault root.' This meaningfully clarifies how the parameter should be formed and compensates for the zero schema description coverage.

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 ('Find') and resource ('all notes that the specified note links to'), making the outgoing direction explicit. This clearly distinguishes it from the sibling tool find_backlinks, which would cover the reverse direction.

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

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

The description implies a read-only link-following use case but provides no explicit guidance on when to choose this tool over alternatives like find_backlinks, search_notes, or read_note. There are no exclusions or conditions to help an agent select among siblings.

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 provided, the description takes on full disclosure. It transparently states the side effect (saving a PNG to assets/dashboards/), the output format, and the return message. It does not mention overwrite behavior or permissions, but for a generate-and-save tool this is adequate.

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 compact and front-loaded: the main purpose is in the first sentence, followed by specific output details and a structured Args/Returns section. No redundant or filler text.

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, the description covers what it generates, where it saves the file, how the parameter behaves, and what the return is. Even without the explicit output schema, an agent has everything needed to invoke 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?

Schema coverage is 0%, so the description must explain the one parameter, and it does: 'project' is defined as an ID or folder name, and omitting it yields a vault-wide dashboard. This goes far beyond the bare anyOf string/null 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 states a specific verb ('Generate') and a specific resource: a visual PNG dashboard with charts, saved to the vault. It enumerates the chart types (pie, progress bars, activity timeline, velocity comparison), which clearly distinguishes it from sibling reporting tools like get_dashboard_report or get_activity_report that presumably return data rather than an image.

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 clearly indicates the tool's use case: producing a visual PNG report that can be embedded in notes, with an optional project scope. It does not explicitly name alternative tools or state when not to use it, but the context of generating an image file is clear enough to route an agent.

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 provided, the description carries the full burden, and it does well by disclosing the report's content, scope, and period limitations. It doesn't explicitly state 'read-only' or 'no side effects,' but 'generate a report' and 'Returns...' strongly imply a safe read operation. A one-line side-effect statement would make it fully transparent.

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 well-structured with a clear opening summary, a returns bullet list, an alternative-tool pointer, and an Args section. It is not bloated, though the final 'Returns: Activity report for the specified period' line is redundant after the detailed returns list.

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?

Given the two optional-looking parameters and the presence of an output schema, the description covers return categories, parameter formats, mutual exclusion, and the key sibling alternative. The main missing context is the explicit requirement to pass one of the two period parameters and a clearer statement that the tool performs no mutations.

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 0%, so the description must compensate, and it does: it explains the exact formats for month (YYYY-MM) and week (YYYY-Wxx), and states that they cannot be used together. However, both parameters are nullable with defaults and no required markers, and the description never explicitly says at least one of week or month must be supplied.

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

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

The description states a specific verb and resource: 'Generate a metrics-centric activity report for a time period' and enumerates the exact metrics returned (heatmap, daily note coverage, project progress, actionable sections). It also distinguishes itself from get_context_week by clarifying that task-level detail belongs to the sibling tool.

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 context is explicit: the tool supports weekly and monthly periods, notes that context week does not support monthly, and directly instructs the agent to use get_context_week for task-level detail. This gives clear when-to-use and when-not-to-use 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 provided, the description carries the full burden. It transparently explains that the tool checks health_criteria against daily note metadata and returns JSON with area, period, and criteria results. This gives a clear read-only behavior profile and expected return shape, though it does not mention permissions or potential side effects explicitly.

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 well structured with a one-line summary, a short mechanism explanation, and explicit Args/Returns sections. It is compact and every section provides necessary information 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?

The description covers purpose, behavior, parameters, and return structure, making it usable for a basic invocation. However, it lacks guidance on selecting this tool among the many report-like siblings and does not clarify edge cases such as invalid area names or unsupported period formats. It is adequate but has clear 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 0%, so the description must compensate for parameter documentation. It does so well: 'area' is explained as name or ID with examples ('health', 'HEA'), and 'period' is explained with valid values ('week', 'month', '2026-W11', '2026-03'). This is useful and mostly complete, though the exact accepted area ID format is not exhaustively specified.

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

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

The description states a specific verb and resource: 'Get area health report: criteria vs actuals for a period.' It clearly identifies what the tool does and mentions the area health concept, which helps distinguish it from generic note or reporting tools. However, it does not explicitly contrast it with similar sibling report tools.

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

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

The description implies when to use this tool: when you need area health criteria versus actuals for a period. It gives no explicit guidance about when not to use it or which sibling tool to choose instead, and there are several similar reporting tools available such as get_activity_report, get_dashboard_report, and export_area_metrics.

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 behavioral transparency burden. The verb 'Get' and the 'activity context' wording signal a non-mutating read, and the flexible date handling ('today', 'yesterday', or date expression') adds useful behavioral nuance. It does not mention failure behavior, permissions, or how logs are filtered, but the output schema covers return structure.

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 compact and front-loaded: one purpose sentence followed by a parameter line, with no filler or restatement of schema fields. Every clause adds useful information.

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

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

For a simple one-optional-parameter read tool with an output schema, the description supplies purpose, parameter formats, and day-scoped context. It is nearly complete, though a one-line nod to siblings like get_context_week for cross-day context would make the boundary even clearer.

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 0%, so the Args section is essential, and it fully compensates by documenting the accepted date formats: 'YYYY-MM-DD', 'today', 'yesterday', or a date expression. This adds meaning beyond the bare string type and default value in 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 opens with a specific verb and resource: 'Get activity context for a specific day' and enumerates what that includes: tasks, notes modified, and logs. This makes the tool's scope unmistakable and distinguishes it from siblings like get_context_week and get_context_note without extra text.

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 phrase 'for a specific day' clearly signals a day-scoped query, which implicitly tells an agent to reach for this tool rather than week, note, or focus context siblings. However, it never explicitly states when to prefer this tool over alternatives or when not to use it, so the usage 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.

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

No annotations are provided, so the description carries the behavioral burden. It clearly indicates a read-only operation ('Get', 'Returns') and discloses the content returned: active project, task counts, recent tasks, and activity. It does not discuss failure modes or focus-setting requirements, but for a parameterless getter this is adequately transparent.

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

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

The description is three short sentences with no filler. It front-loads the purpose, then gives return contents, then states the use case. Every sentence 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?

This is a simple, parameterless read tool with an output schema present. The description covers what it does, what it returns, and when to use it, which is sufficient for an agent to select and invoke 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 has zero parameters, so there is no parameter semantic burden on the description. The description appropriately focuses on what the operation returns and when to use it.

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 ('Get') and resource ('context for the currently focused project') and specifies what is returned: active project, task counts, recent tasks, and activity. This clearly differentiates it from siblings like get_project_context, get_context_day, and get_context_note by focusing on the currently focused project.

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 explicitly states when to use it: 'Use this to understand what the user is currently working on.' This gives clear context for usage, though it does not name excluded cases or explicitly contrast with alternative 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?

With no annotations, the description carries the full burden. It does disclose what the returned context includes, which is useful. However, it does not explicitly state side-effect-free behavior, error behavior for missing notes, or any access constraints; it relies on the verb 'Get' to imply a read operation.

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

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

The description is compact and front-loaded: the main purpose is stated first, followed by a minimal Args section. There is no redundant or filler content, and every sentence adds useful information.

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

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

Given a simple read operation, an output schema, and well-documented parameters, the description is largely complete. The only notable gap is the lack of explicit guidance on when to choose this tool over closely related siblings, but that is partially mitigated by the clear content list.

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 0%, but the description fully compensates by documenting both parameters: note_path is described as relative to the vault root, and activity_days is described as the number of days of activity history to include. This is exactly the semantic information an agent needs beyond the raw 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 clearly states the verb ('Get') and the resource ('context for a specific note') and specifies the content categories: metadata, sections, activity, and references. It does not explicitly contrast itself with sibling tools like get_metadata or read_note, but the stated scope is specific enough to distinguish 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?

The description implies when to use the tool: when you need a broader context bundle for a particular note. However, it gives no explicit guidance about when not to use it or when a sibling tool like get_metadata or find_backlinks would be more appropriate, so usage guidance is only implicit.

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 of behavioral disclosure. It does disclose the return categories and the read-only nature implied by 'Get.' However, it does not explicitly state side-effect behavior, prerequisites, or how missing/empty week data is handled, leaving some behavioral ambiguity for an agent.

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 compact and front-loaded: purpose, returned content, usage guidance, alternative tool, and parameter documentation all appear in a logical order without filler. Every sentence contributes actionable information.

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

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

For a single-optional-parameter tool with an output schema, the description covers the parameter semantics, the tool's purpose, and the key alternative. No critical information needed to select or call this tool 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 0%, but the description fully compensates by documenting the week parameter's accepted values ('current', 'last', YYYY-Wxx) and the None default. This adds essential meaning that the sparse schema alone does not provide.

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 opens with a specific verb+resource: 'Get task-centric activity context for a specific week.' It then enumerates the returned content (task lists, per-day focus breakdown, project log entries), making the tool's scope and output clear. This distinguishes it from the sibling get_activity_report, which is explicitly described as aggregate.

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 states what the tool is for ('understand what happened at the task level during a week') and explicitly directs users to get_activity_report when they need aggregate metrics instead. This gives clear when-to-use and when-not-to-use guidance, which is especially valuable given the large sibling tool set.

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 bears the full transparency burden. It does disclose that the tool summarizes the day and returns the output of 'mdv today', which strongly implies a read-only operation. However, it doesn't explicitly state side effects, permissions, or what empty/failure behavior looks like.

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

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

The description is two short sentences, front-loaded with the main purpose. The second sentence adds the concrete return source 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?

For a no-argument tool with an output schema, the description gives enough operational context: what it summarizes and what it returns. It is slightly incomplete only in not offering any comparison to the many sibling reporting tools.

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 has zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter detail, but none is needed; baseline 4 for a no-parameter tool is appropriate.

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

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

The description starts with a specific verb and resource ('Get the daily dashboard summary') and clarifies scope with 'today's tasks, events'. The mention of 'mdv today' further pins down the exact data source, distinguishing it from broader report siblings like get_dashboard_report.

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 use case is implied by 'today's tasks, events' — an agent can infer this is for a daily overview. However, there is no explicit when-to-use rule or comparison with sibling tools like get_dashboard_report or get_activity_report, so the guidance is only implied.

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 transparency burden. It discloses that the tool returns a structured JSON report with detailed fields and may return an error message. It also explains the behavior of activity_days ('Days of activity history to include'). It stops short of declaring read-only status or rate-limit behavior, but the 'Get' framing and report-only output are adequate for this reporting 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?

The description is well-structured and front-loaded: a one-line summary, a compact but informative breakdown of the return payload, explicit use cases, then clear Args and Returns sections. Every sentence adds useful information 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?

For a tool with two optional parameters and an output schema, the description is complete. It explains the return structure, parameter semantics, and appropriate usage contexts. The presence of an output schema means return-value details do not need to be fully restated, and the description already provides a strong overview.

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 0%, so the description is the only source of parameter meaning. It fully compensates: project is explained as 'Scope to a specific project (ID or folder name)' and 'Omit for vault-wide report'; activity_days is explained as 'Days of activity history to include' with its default of 30. This exceeds the schema's bare type definitions.

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?

Description uses a specific verb and resource: 'Get a structured dashboard report with project metrics, velocity, and activity.' It clearly enumerates the report contents (vault summary, per-project breakdowns, daily activity, task lists), so an agent understands exactly what the tool produces and can distinguish it from siblings like get_daily_dashboard or get_activity_report based on content.

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 explicitly states use cases: 'Use for rich status checks, project reviews, and weekly/monthly reporting.' It also gives scoping guidance for the project parameter ('Omit for vault-wide report'). It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear enough for an agent to decide when this tool fits.

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 behavioral burden. It states that the tool returns a JSON string with metadata or an error description, giving an agent a clear expectation. It does not explicitly confirm non-mutation, but the 'get' verb and metadata focus make the read-only behavior unambiguous enough for this simple 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?

The description is compact and front-loaded: a one-sentence purpose, one required arg, and a return behavior. There is no extraneous text, and the Args/Returns structure makes the information scannable.

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 getter with an output schema, this is nearly complete. It specifies the path semantics and the return/error behavior. A clearer statement about behavior when frontmatter is absent would make it fully airtight, but that 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?

The input schema only defines note_path as a string, and schema description coverage is 0%. The description fills this gap completely by specifying 'Path to the note relative to vault root,' which is exactly what an agent needs to construct a valid call.

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 opens with a specific verb and resource: 'Get the frontmatter metadata from a note as JSON.' This clearly separates it from siblings like read_note (full note content) and update_metadata (mutation).

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 purpose implies when it is appropriate—when only frontmatter/metadata is needed—but there is no explicit 'use this instead of read_note' or any exclusions/alternatives. Usage context is inferred, not 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 transparency burden. It discloses that the tool returns a full context note and lists contained data types, which is useful. It does not mention potential side effects, performance implications, or failure behavior, though the 'get' naming and 'Returns' wording imply a read-only operation.

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 short and front-loaded with a clear summary, followed by return details and an Args section. There is minor redundancy between 'metadata, sections, tasks, activity, and references' and the second sentence's list, but overall it is concise and easy to scan.

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 low-complexity tool with one parameter and an output schema, the description provides enough information to invoke the tool correctly. It explains what kind of input is expected and what kind of output is returned, though it lacks explicit guidance on alternatives or edge cases.

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 0%, so the description must compensate. It adds meaning beyond the bare string type by specifying that project_name can be either a name or an ID, which is sufficient guidance for this single-parameter tool.

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 opens with a specific verb and resource: 'Get rich context for a project,' and then enumerates the content areas (metadata, sections, tasks, activity, references). It also clarifies it returns the full context note including recent task activity, backlinks, and outgoing links, which differentiates it from more narrowly scoped siblings like get_metadata, find_backlinks, and find_outgoing_links.

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

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

The description implies usage: use this tool when you need broad, rich project context as opposed to a single facet. However, it does not explicitly state when not to use it or mention alternatives such as get_project_status, get_project_progress, or find_backlinks, leaving routing partly 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 burden of behavioral disclosure; 'Show' implies a read-only operation and the parameter behavior is explained. It does not disclose error conditions, whether anything is computed or cached, or any limitations, so it is adequate but not 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 convey both the core function and the parameter behavior; the action is front-loaded and every sentence earns its place. There is no redundant restatement of schema fields or annotations.

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 an output schema, the description covers the essential behavior and parameter semantics. It could be slightly more complete by orienting the agent against sibling progress/status tools, but nothing needed to invoke 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 coverage is 0%, so the description is the only source of parameter meaning; it explains that project_name is optional and toggles between detailed single-project progress and an aggregate summary. This fully compensates for 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?

States a specific verb ('Show') and resource ('progress metrics for a project or all projects'), making the operation clear. It does not explicitly distinguish itself from siblings like get_project_status or get_project_context, which is why not 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?

Provides clear invocation guidance for the optional project_name parameter: including it returns detailed progress, omitting it returns a summary across all projects. However, it gives no guidance on when to prefer this tool over closely related siblings such as get_project_status or get_activity_report.

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 signal side effects; 'Show' implies a read-only operation and 'Kanban view' suggests a formatted status representation. It does not explicitly state that it does not modify project data or mention prerequisites. This is adequate but leaves room for more transparency.

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 total, with the purpose front-loaded and the parameter explanation separated under 'Args'. No filler or repeated schema info. This is an efficient structure.

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?

The tool is simple, has one required parameter, and an output schema exists, so the description does not need to explain return values. It covers purpose and parameter semantics, but does not orient the agent among closely related siblings like get_project_progress and get_project_context. Given the low complexity, this is mostly 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?

The schema only defines project_name as a string with 0% description coverage, so the description's 'Name or ID of the project' is valuable because it expands the accepted input beyond what the schema says. It does not provide format examples, but fully covers the single required parameter's 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?

The description uses a specific verb ('Show') with a resource ('detailed status of a project') and identifies the view format ('Kanban view'). It distinguishes the tool from siblings like get_project_context and get_project_progress, though it does not name 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?

No guidance is provided about when to choose this over sibling tools such as get_project_progress or get_project_context. The description only states what the tool does, leaving the agent to infer selection criteria. There are no exclusions or alternative conditions.

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. The verb 'Show' does imply a read-only operation with no mutation, which is appropriate. However, it does not disclose behavior around missing tasks, permissions, or whether only existing tasks are returned, leaving some ambiguity.

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 brief and front-loaded, with a clear one-sentence summary followed by an Args block. It contains no filler, though the Args section mostly restates the schema.

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

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

Given the tool's low complexity—one required parameter and an output schema—the description is largely complete for invoking the tool. It identifies the operation and the parameter, while the output schema covers return values. It could be improved by noting how to discover task_id, but nothing essential for a basic call 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 schema provides only 'task_id' as a required string with no description. The description adds 'task_id: The ID of the task,' which is nearly tautological and does not explain where to find the ID, its format, or how it relates to other task tools. With 0% schema coverage, the description should compensate more but barely does.

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 uses a specific verb ('Show') and resource ('details for a specific task'), making it clear this is a single-task retrieval tool. It is implicitly distinguished from sibling tools like list_tasks and create_task, though it does not explicitly call out the difference from get_metadata.

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 gives no explicit guidance on when to use this tool versus alternatives such as list_tasks, get_metadata, or update_task_status. The intended use is only implied by 'for a specific task,' and there is no mention that task IDs can be obtained from list_tasks.

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 available, the description carries the behavioral disclosure burden. It explicitly states that hidden directories and empty folders are skipped, and that the return value is a newline-separated list of folder paths relative to the vault root. This provides useful behavior beyond the bare schema.

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 compact and well-structured with a one-line summary, behavioral notes, Args, and Returns. Every sentence adds useful information 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 simple list operation with one optional parameter, the description covers purpose, parameter semantics, filtering behavior, and return format. Nothing important is missing for an agent to call it correctly.

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

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

Schema coverage is 0%, but the description fully documents the only parameter: 'folder' is a parent folder relative to vault root, and an empty value means top-level folders. This fully compensates for the schema's lack of descriptions.

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

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

The description states a specific verb and resource: 'List subfolders in the vault.' It also clarifies optional scoping to a parent folder, making the tool's purpose unambiguous and distinguishing it from note- or task-oriented sibling tools.

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 gives clear usage context: when 'folder' is empty, it lists top-level vault folders, implying when you would want a broader or narrower listing. No explicit alternative is named, but no direct folder-listing sibling exists, so this is acceptable.

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 discloses that the tool only returns markdown note paths, scopes to a folder if supplied, omits the folder scope when empty, and returns newline-separated paths relative to vault root. This is reasonably transparent for a read-only listing operation, though it does not mention edge cases like invalid folders or recursive traversal.

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 compact and well-structured, with a one-sentence summary followed by clear Args and Returns sections. Every sentence adds necessary information, and the main purpose is front-loaded.

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 list tool with one optional parameter and no annotations, the description covers purpose, parameter semantics, scoping behavior, and return format. Nothing critical is missing for an agent to select and invoke this tool 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 schema provides no description for the 'folder' parameter, but the description fully compensates: it defines the parameter as a subfolder relative to vault root, explains the empty case, and clarifies the output semantics. This gives the agent everything needed to understand and supply the parameter correctly.

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 specific action ('List all markdown notes in the vault') and the optional scope ('scoped to a folder'). This distinguishes it from sibling tools like list_folders (folders, not notes) and search_notes (content search, not listing).

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 gives clear context for when the tool is useful: listing all notes or notes within a specific subfolder. It does not explicitly name alternatives or exclusions, but the behavior is straightforward enough that an agent can infer appropriate usage.

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 full responsibility for behavior. 'List' suggests a read-only operation and 'with task counts' discloses the computed output, but the description does not clarify how the two filters combine, what statuses are valid beyond examples, or whether any default filtering occurs.

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 compact and front-loaded with the core purpose before the Args section. There is no filler or redundant wording, and the parameter explanations are brief but useful.

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 list tool with an output schema, the return structure is already covered externally. The description handles the purpose and both parameters adequately, though a short note on when to choose list_projects over project-report siblings would make it 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 0%, so the Args section is essential and it does compensate: it explains that status_filter filters by status with active/archived examples and kind_filter filters by kind with project/area examples. It does not provide exhaustive allowed values or combination semantics, but it adds real meaning beyond the bare 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 opens with 'List all projects with task counts', a clear verb+resource statement that establishes the tool as a project listing endpoint. It is distinguishable from list_notes/list_folders/list_tasks by resource, though it does not explicitly differentiate itself from project-related siblings like get_project_status or get_area_report.

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 guidance on when to use this tool versus alternatives such as get_project_status, get_project_progress, or get_area_report. The description only states what the tool does and describes its filters, leaving the agent to infer the right selection context.

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 burden of disclosing behavior. 'List' clearly conveys a non-mutating retrieval operation and the filters are specified, but the description does not disclose pagination, ordering, matching semantics, or whether archived tasks are included by default; these are notable gaps for a list tool.

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

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

The description is compact and front-loaded: one summary sentence followed by two one-line parameter definitions. Every sentence adds value and there is no filler, while the Args block is cleanly separated.

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 optional-filter list operation with an output schema present, the description covers the core calling contract: what it returns conceptually, how to filter, and which statuses are valid. It is not fully complete because it omits ordering/pagination behavior and exact-match semantics, but these are secondary for a basic list tool.

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

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

The schema has no per-parameter descriptions, but the description compensates fully: project_filter is explained as filtering by project name and status_filter lists the exact allowed status values. This adds meaning beyond the raw string/null schema types and gives an agent actionable filter syntax.

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 opens with a specific verb and resource ('List tasks') and immediately scopes the operation to an optional-filter list. This clearly distinguishes it from singular/detail task tools like get_task_details and from mutating task tools like update_task_status without needing to inspect their schemas.

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

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

There is no guidance about when to prefer list_tasks over sibling tools such as get_task_details, search_notes, or update_task_status, and no exclusions are given. The read-only listing use case is implied by the verb, but the description does not state context or alternatives.

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?

Since no annotations are provided, the description carries the full behavioral disclosure burden. It clearly indicates a write operation ('Append') and gives the exact inserted format, but it does not disclose whether the daily note or Logs section is created on demand, whether HH:MM is automatically generated from current time, or how repeated appends behave.

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 compact and well-structured: a purpose sentence, a format line, then Args/Returns. It is front-loaded with the most important information, and the format example provides concrete value without unnecessary prose.

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?

The output schema covers return values, so that part is not a gap. However, edge-case behavior such as creation of a missing daily note or Logs section and automatic timestamp generation is unstated, which could lead to incorrect calls in valid use cases. For a simple appending tool, this is adequate but not 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 coverage is 0%, so the description must explain log_message on its own. It does so with a clear definition ('The log message to append') and a format example showing where the content lands. This fully resolves the meaning of the single parameter.

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 a specific verb ('Append') and resource ('Logs' section of today's daily note), with an explicit format template. It is easy to distinguish from siblings like append_to_daily_note or run_macro because it names the exact target and content shape.

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 does not provide any guidance on when to use this tool versus nearby alternatives such as log_to_note or append_to_daily_note. The usage context is implied by the name and target, but no explicit conditions or exclusions are given, leaving an agent to guess which sibling fits a non-obvious scenario.

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 provided, the description carries the full behavioral disclosure burden. It discloses the append action, the target section, the exact log entry format including a date and time, and the return behavior. It omits edge cases such as whether a missing note or missing 'Logs' section would be created, but the core behavior is well specified.

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 compact and well-structured, with the purpose stated first, followed by the format, arguments, and return value. There is no filler or redundant repetition, and each section 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 write tool, the description covers the main call path, arguments, format, and return value. However, it lacks edge-case behavior (missing note, missing section) and does not help an agent choose among the many sibling log/append tools, leaving some contextual ambiguity.

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 0%, but the description compensates by defining both parameters meaningfully: note_path is a path relative to the vault root, and content is the log message to append. The format line further clarifies how content will be rendered into the note.

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 action (append), the resource (log entry), and the destination (the 'Logs' section of any note), with an explicit format. It is unambiguous about what the tool does, though it does not explicitly differentiate itself from sibling tools like log_to_daily_note or append_to_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?

The description implies usage context: logging into the 'Logs' section of a general note, including project or task notes. However, it gives no explicit guidance about when to use this tool instead of log_to_daily_note, append_to_note, or add_to_inbox, and does not mention any exclusions.

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

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

With no annotations provided, the description carries the behavioral burden. It states that the note content is returned, that max_lines may truncate output, and that omitting max_lines returns the full note. 'Read' also clearly implies a non-mutating operation, which is sufficient for a simple read 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?

The description is concise and well-structured with a one-line purpose followed by Args and Returns sections. Every sentence adds information about invocation or behavior, with no filler or redundant content.

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 operation with an output schema, the description is complete: it defines the purpose, both parameters, truncation behavior, and error return. Nothing critical is missing for an agent to correctly select and invoke this tool.

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

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

The input schema has 0% description coverage, but the description fully compensates. It explains note_path as relative to the vault root and describes max_lines as optional with explicit default behavior. This gives the agent everything needed to set both parameters correctly.

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 opens with 'Read a note from the vault,' which names a specific verb, resource, and domain. It clearly differentiates content retrieval from sibling operations like get_metadata, search_notes, or append_to_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?

The use case is implied: use this tool when you need a note's actual content, rather than metadata or search results. However, the description does not explicitly state when to prefer read_note over alternatives like get_metadata or search_notes, nor does it give any exclusion criteria.

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 provided, the description carries the full burden. It discloses the failure mode when old_text is not found, the count semantics (first match vs all), and the scope limitation. It does not mention reversibility or permissions, but the core side effects are well described.

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

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

Every sentence earns its place. The opening establishes purpose, the caveats clarify edge cases, the Args section adds semantic detail, and the Returns line sets expectations. No filler or redundant restatement of the tool 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 small mutation tool, the description covers the operation, the inputs, the failure case, the replacement count behavior, and the return type. Since an output schema is present, explaining return values in more detail is unnecessary. The description is sufficiently complete for correct invocation.

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 0%, so the description must compensate. It fully explains every parameter: note_path as a vault-relative path, old_text as exact text, new_text as replacement, and count with its default and special behavior. This adds meaning well beyond the raw 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 clearly states a specific verb ('Replace'), the target resource ('a note's body content'), and precise behavior ('plain string find-and-replace'). The explicit exclusion of frontmatter helps distinguish it from metadata-focused or append-focused sibling tools.

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 gives clear context: it operates on note body content only, not frontmatter, and is appropriate for plain string replacement. It does not explicitly name sibling alternatives, but the scope and constraints make intended usage clear enough for an agent.

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 fully disclose behavior, but it only mentions executing a CLI macro and returning output or an error. It does not warn that macros can have arbitrary side effects on notes or the vault, which is a significant transparency gap for an execution 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?

The description is compact and efficiently structured with a one-line purpose followed by Args and Returns sections. Every line earns its place and nothing is redundant or verbose.

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?

The definition covers parameters and return text, but for a macro-execution tool it is undeniably incomplete without a side-effect warning or prerequisites (e.g., that macros can modify the vault). Given no annotations and no guidance on failure or behavior, an agent is undersupplied for safe and correct use.

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?

Despite 0% schema description coverage, the Args section explains all three parameters and adds semantic value: name has concrete examples, args is defined as positional arguments, and variables is mapped explicitly to the '--var k=v' CLI convention. This compensates well for the bare schema, though it could be more precise about argument ordering.

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 action and target: 'Run a predefined macro using the mdv CLI.' This clearly distinguishes it from note-management siblings; examples like 'daily-standup' and 'new-project' reinforce what resource is being invoked.

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 does not say when to prefer run_macro over other tools or when not to use it. There are no exclusions or alternative tool mentions; the only implied context is the verb 'Run' and the macro examples, which is not real 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 provided, the description carries the full behavioral disclosure burden. It explains case-insensitive matching, the default path-only return mode, and the context_lines behavior. It does not mention sorting, limits, or explicitly state read-only behavior, but the core behavior is well disclosed.

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 compact, front-loaded with the primary purpose, and uses a clean Args/Returns structure. Every sentence adds useful information and there is no filler or redundant repetition of the tool 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?

Given the tool's moderate complexity, lack of annotations, and presence of an output schema, the description is complete enough for correct invocation. It covers all parameters, default behavior, return format, and the optional context behavior. No critical gaps remain for an agent to use 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?

Although schema description coverage is 0%, the description fully documents all three parameters in the Args section, including defaults and the semantic difference when context_lines is 0 versus greater than 0. This fully compensates for the schema's lack of parameter descriptions.

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?

Description starts with a specific verb and resource: 'Search notes containing the query text.' It clearly distinguishes this tool from sibling tools like list_notes or find_backlinks by focusing on textual search within note content, with case-insensitive matching explicitly stated.

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

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

The description makes the use case clear: search notes by query text, optionally limiting the scope with a folder and controlling context line output. It does not explicitly mention alternatives or when-not-to-use, so it falls short of a 5, but the intended usage is unambiguous.

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 of disclosing behavior. It only states that focus is set and does not explain whether the previous focus is overwritten, whether the note persists, what side effects occur, or how the result 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?

The description is a single focused sentence plus a compact args list; there is no filler and the purpose is front-loaded before the parameter details.

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 low-complexity 2-parameter tool with an output schema, parameter coverage is adequate. However, because this is a state-changing focus tool with no annotations, the missing behavioral context (overwriting, note lifecycle, relationship to clear_focus) leaves the description only minimally 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?

The schema has no property descriptions (0% coverage), so the description compensates well: it explains that project accepts an ID or name and that note is an optional contextual comment. It adds meaningful semantics beyond the raw type information.

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 action and resource: it sets the active project focus. This clearly distinguishes it from sibling getters like get_context_focus and the unsetter clear_focus. The verb 'set' plus the 'active project focus' resource leaves no ambiguity about what the tool accomplishes.

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 is provided beyond the verb itself. The description does not mention alternatives, prerequisites, or when to prefer set_focus over clear_focus/get_context_focus, leaving the agent to infer the intended scenario.

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 adds the key merge behavior ('preserving existing fields'), clarifies that metadata_json contains fields to update/add, and states that a success or error message is returned. This is meaningful behavioral context beyond the schema, though it does not mention permissions, reversibility, or what happens when the note does not exist.

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 compact and well-structured, with a clear one-line purpose followed by Args and Returns sections. Every sentence adds value and the key behavioral detail ('preserving existing fields') is front-loaded.

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

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

For a simple two-parameter tool with an output schema, the description covers purpose, parameters, merge behavior, and return type. It is largely complete, but the lack of any guidance about when to choose this over related note-updating tools is a small gap given the large sibling list.

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 0%, so the description must compensate. It does: note_path is described as relative to vault root, and metadata_json is described as a JSON string containing fields to update/add. This adds real semantics beyond the raw schema, though an example or constraints on JSON structure would push it higher.

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 ('Update'), a specific resource ('frontmatter metadata in a note'), and a distinguishing behavior ('preserving existing fields'). This clearly separates it from broader note-editing siblings like append_to_note or replace_in_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?

The description implies when to use the tool—when you need to modify or add frontmatter metadata—but it does not explicitly state when not to use it or mention alternatives. Usage context is inferable from the purpose, but no exclusions or sibling routing are provided.

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. It does disclose the mutation explicitly and specifies the exact effect of the completed flag, plus the return behavior. However, it omits details about matching semantics (e.g., first match vs. all matches, case sensitivity) and possible side effects, so it is adequate but not thorough.

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 tight and well-organized: a one-sentence purpose, a short Args list, and a Returns line. Every sentence earns its place and the most important information is front-loaded.

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, the core invocation details are covered and an output schema exists. Still, the description does not clarify ambiguous matching behavior or how this tool relates to complete_task/cancel_task, so an agent may not reliably distinguish the right tool without additional context.

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 0%, so the description is the only source of parameter meaning. It compensates fully by defining all three arguments, including the note path base, what task_pattern matches, and the boolean semantics of completed.

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 a specific action ('Update') and resource ('task checkbox in a note'), and the parameter names align with the operation. It is clear on its own, though it does not explicitly differentiate itself from sibling tools like complete_task or cancel_task, which are likely to overlap in intent.

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 guidance about when to use this tool instead of the many sibling task-related tools, nor any exclusions or prerequisites. The description only explains mechanics, not selection context.

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 provided, the description carries the full burden of disclosing behavior. It reveals the underlying command (`mdv validate`), the checks performed, the fix side effects ('Auto-fix safe issues', 'fixes applied'), and the return type. It could be stronger by explicitly warning that `fix: true` modifies notes, but the disclosure is largely adequate.

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 well-organized with a one-line purpose, an Args section, and a Returns note. It is concise, front-loaded with the core purpose, and every sentence adds useful information without fluff.

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?

All four parameters are documented, the behavioral scope is clear, and the return value is described even though an output schema exists. The description is complete enough for an agent to call the tool correctly without additional context.

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 0%, and the input schema has no descriptions. The description compensates fully by explaining each parameter: path scope, note_type filtering, fix behavior, and limit. This adds clear operational meaning beyond the bare 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 states a specific action ('Validate notes') against a clear resource ('Lua type definitions (frontmatter schema)'). It is immediately distinguishable from sibling tools like vault_lint or get_metadata because it names the validation target and the underlying command.

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 how to use the tool (optional path, note_type, fix, limit) but gives no guidance on when to choose validate_note over alternatives. There is no mention of when not to use it or which sibling tool might be more appropriate for related tasks.

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 provided, the description carries the full disclosure burden and handles it well. It reveals it runs the `mdv check` command, returns an 'AI-friendly summary of vault health,' and importantly flags that the fix parameter is 'not yet implemented' — preventing an agent from expecting repairs it won't get. It could have explicitly stated read-only behavior, but 'check' plus 'returns a report' reasonably implies it.

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 purpose sentence is front-loaded with the most important information, followed by a compact implementation note and structured Args/Returns sections. The parameter documentation is slightly verbose but earns its place given the 0% schema coverage; no sentence is wasted.

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?

Given there is an output schema, the description doesn't need to detail return values, and it still offers a useful high-level summary ('issues grouped by category'). It covers the command executed, all parameter semantics, and the unimplemented fix behavior. Minor gaps: it never frames the tool as read-only and doesn't discuss performance or vault prerequisites, but nothing an agent needs to call 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 0%, so the description must compensate — and it does thoroughly. It enumerates every valid category value (broken_references, malformed_wikilinks, schema_violations, structural_consistency, orphaned_notes, db_sync), explains the null default via 'Omit to run all checks,' and clarifies the fix boolean's semantics including its unimplemented status. This adds substantial meaning beyond the bare 'string|null' and 'boolean' 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 states a specific verb and resource: 'Check vault structural correctness' with concrete examples in parentheses (broken links, schema violations, orphans). It clearly distinguishes this as a whole-vault health check rather than a note-level operation, though it doesn't explicitly name validate_note as the sibling it is not.

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 context is implied through the category list and 'Omit to run all checks.' It makes clear that you can scope the check by category, but it gives no explicit guidance on when to choose this tool over the nearby sibling validate_note, nor any exclusions or prerequisites.

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