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

There are no annotations, so the description carries the burden. It transparently implies a read-only retrieval ('what ... said recently') and adds that each result includes the driving decision, but it does not disclose ordering, filtering semantics, or whether the call has any side effects. This is a minor gap 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 a single short sentence with no filler and places the core idea first. It is concise, though slightly cryptic due to the blacksmith metaphor.

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 one optional parameter and an output schema, the description does not need to explain return values. However, it leaves the meaning of 'nags' and the n parameter implicit, and it does not orient the agent against the sibling tools, so completeness is adequate but not strong.

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 does not mention the sole parameter n. The name and default hint suggest it is a count, but the description fails to clarify whether n limits the number of results, a time window, or pagination.

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 conveys that the tool retrieves the blacksmith's recent statements (nags) and associates them with the decision that prompted them, which is a clear resource and action even though phrased as a question rather than an imperative. It differentiates from the tasks_* siblings by focusing on the blacksmith's communications/nags rather than task state.

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 guidance on when to choose this tool over siblings such as hearthsmith_tasks_list or hearthsmith_tasks_done, nor any exclusions or prerequisites. The intended use must be inferred from the tool name and 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 full burden. It discloses only that the operation adds a task and clarifies parameter formats, but it does not state side effects, permission requirements, idempotency, error behavior, or what happens after creation. This is a meaningful gap for a mutating 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 two sentences with no filler. The core operation is front-loaded, and the additional sentence adds directly useful parameter context. Every word 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?

Despite the presence of an output schema, the description is thin for a tool with five parameters and no annotations. It omits usage guidance, behavioral effects, and semantics for some parameters. An agent would still need to guess about expected input formats for tags and notes and what to do after the 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?

Schema description coverage is 0%, so the description must compensate. It usefully explains that due is an ISO date/datetime in local time and that project accepts a hyperpanes id or name. However, tags, notes, and title are left to inference from their schema titles, so the compensation is only partial.

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, 'Add a task,' which clearly distinguishes it from sibling tools like hearthsmith_tasks_done, hearthsmith_tasks_list, hearthsmith_tasks_block, and hearthsmith_tasks_snooze. The extra details about due and project reinforce what this tool is for.

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 guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The creation purpose is implied by the verb 'Add,' but the agent is given no explicit decision context relative to the 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 provided, the description carries the behavioral disclosure burden. It does reveal a key behavioral outcome ('the pet stops nagging'), but it does not explain whether blocking is reversible, how it interacts with other task states, or what side effects occur beyond the nagging behavior.

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

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

The description is a single concise sentence with no wasted words, and the core action is front-loaded. It earns a high score for structure, though it sacrifices informative content for brevity.

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 two-parameter tool with an output schema, so the missing return-value documentation is not a concern. However, the description does not explain how blocking differs from marking done or snoozing, nor what 'blocked' implies for future task behavior. It is minimally viable for invocation but not fully contextual.

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 description must compensate, but it does not. task_id is inferable from its name and required status, but the purpose and effect of the optional 'reason' parameter are entirely unexplained.

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 ('Mark a task blocked') and a concrete consequence ('the pet stops nagging about it'). It clearly identifies the resource and operation, though it does not explicitly contrast with sibling tools like done or snooze, which also affect nagging 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?

No guidance is given about when to use block versus alternatives such as hearthsmith_tasks_done or hearthsmith_tasks_snooze. The parenthetical describes the effect but leaves the decision entirely to inference.

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

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

With no annotations, the description carries the full burden. It discloses a useful behavioral trait—accepting an id prefix—but does not mention whether the action is reversible, what happens to already-done tasks, or any side effects. Core behavior is stated, but edge-case behavior is left unspecified.

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 concise sentences with the primary action front-loaded and the parameter nuance in the second sentence. There is no fluff or redundant restating 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 has a single parameter and an output schema, the description is mostly adequate. However, it lacks usage guidance and any detail about ambiguous prefixes, repeated calls, or state-transition consequences. It is serviceable 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?

The schema only provides the parameter name 'Task Id' with no description. The tool description adds real meaning by explaining that the id can be a prefix, which is critical for correct invocation. Without this, the agent would likely assume an exact ID is required.

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 is a precise verb-resource statement: 'Mark a task done.' This clearly distinguishes it from siblings such as list, add, block, and snooze. The second sentence about id prefix adds a useful constraint without muddying the core purpose.

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 versus alternatives like block or snooze. No context, prerequisites, or exclusions are provided, leaving the agent to infer the appropriate situation.

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 must carry the behavioral burden. 'List' implies a read-only operation, and the state values are enumerated, but the description does not disclose pagination, sorting, or any side effects. 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?

The description is compact, front-loaded with the core action ('List tasks'), and immediately clarifies the key parameters. Every sentence earns its place with no 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?

The tool has an output schema, so return details are not needed. The description covers the essential filtering options and states the allowed state values. Minor omissions like pagination or default behavior are acceptable for a simple list tool, so it is nearly 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?

Despite 0% schema description coverage, the description fully explains both parameters: state lists all allowed values (open, done, blocked, delegated, all) and project filters by hyperpanes project id/name. This adds significant 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 begins with 'List tasks,' a specific verb and resource, and clearly distinguishes this from siblings like hearthsmith_tasks_done, hearthsmith_tasks_add, etc. It is unambiguous that this tool retrieves a collection of tasks, not modifies them.

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

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

The description provides filter options (state, project) and implies this is the general listing tool, but it does not explicitly state when to prefer this over siblings such as hearthsmith_tasks_done or hearthsmith_nags_recent. It gives context but no exclusions 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?

With no annotations, the description carries the full burden, but it only says 'snooze nagging.' It does not disclose that the task remains open, that the snooze is temporary, that minutes controls the delay, or what effects this has relative to done and block. These are important behavioral traits for a mutation-like task action.

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 one short sentence with no filler and leads with the action. It is concise and readable, though the brevity comes at the cost of missing useful guidance.

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?

Despite low complexity and the presence of an output schema, the description omits the key distinction from sibling tools (done/block) and the role of the minutes parameter, which an agent needs to choose and invoke the tool correctly. It is minimally understandable but incomplete for confident use in a task-management family.

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 the input schema. It only hints at task_id via 'for a task' and minutes via the verb 'snooze'; it never mentions the default duration, units, or which parameter is required, leaving the schema to do all the work.

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

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

"Snooze nagging for a task" states a specific verb (snooze) and resource (nagging/reminders for a task), which distinguishes it from sibling actions like done, list, and add. It is weaker than a 5 because it never explicitly says the reminders are temporarily postponed, leaving some ambiguity with block.

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 snooze versus finishing (done), blocking (block), or reviewing nags (nags_recent). An agent must infer the selection criteria from the tool name and sibling list, so the description fails to provide context for choosing this tool.

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