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

Since annotations are absent, the description must disclose behavioral traits. It only states the action without mentioning effects like duplicate handling, return values, or potential side effects. The existence of an output schema is not mentioned.

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, but it omits essential details. While brevity is valued, the lack of parameter or usage information makes it borderline under-specified for an agent to use correctly.

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 2 parameters, an output schema, and no annotations, the description is incomplete. It fails to explain return values (despite an output schema existing) or provide any context for safe and effective 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?

Schema description coverage is 0%, and the description adds no information about the two parameters: 'task_id' (required) and 'date' (optional). It does not explain what 'task_id' refers to or how 'date' should be formatted, leaving the agent uninformed.

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 ('Add') and the target ('an item to the daily plan'). It is specific enough to convey the core purpose, but it does not differentiate from the sibling tool 'add_to_plan', which may have overlapping functionality.

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 on when to use this tool versus alternatives like 'add_to_plan' or 'remove_from_items_plan'. There is no mention of prerequisites, constraints, or contexts where the tool is inappropriate.

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 bears full responsibility. It mentions adding a task but does not disclose any side effects, required permissions, or constraints (e.g., can the same task be added multiple times to the same day?). This is insufficient for full 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?

The description is extremely concise with two sentences, front-loaded with the primary action. No wasted words.

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

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

The tool has an output schema (not shown), so return value details are not required. The description adequately covers the main behavior and parameter semantics. Minor gaps: no mention of whether the plan must exist or if the task can be added without a plan.

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 adds crucial meaning: it clarifies that task_id is a UUID of an existing task and that date defaults to today. This goes 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 action ('Add a task') and the target resource ('the daily plan'). It differentiates from siblings like 'add_to_items_plan' by specifying 'daily plan' and from 'remove_from_plan' by being an add 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?

The description explains parameter semantics (task_id is UUID, date defaults to today) but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like 'add_to_items_plan' or 'batch_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?

No annotations are provided, so the description carries full burden. It discloses atomicity (all-or-nothing) and the return format. It details operation structure for both update and move. However, it does not cover error handling, permission checks, or edge cases.

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 concise opening sentence summarizing the purpose, followed by bullet-like explanations. Every sentence adds value 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 the main aspects: operation types, atomicity, return format. However, it lacks details on validation, error responses, batch size limits, and whether operations can be mixed. Given the complexity and presence of an output schema, it is fairly complete but could be more thorough.

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 fully compensates. It explains the operations array structure, required op and task_id, and the different fields for update vs move. It also references update_task for allowed fields. 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 clearly states the tool's purpose: executing multiple task operations atomically. It specifies the verb 'execute multiple task operations' and the resource 'tasks'. It distinguishes from sibling tools like update_task and move_task by batching operations.

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 when to use the tool: for multiple atomic operations. It references individual tools (update_task) for operation fields. It does not explicitly state when not to use it, but the context of batch vs individual 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, the description must fully disclose behavior. It explains ID resolution but fails to specify the effect of 'clear' (e.g., unmark vs delete), side effects, or safety (destructive?). Leaves ambiguity about the tool's actual 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?

Two concise sentences: first clearly states action and date format, second details ID flexibility. No fluff, front-loaded, 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?

While output schema exists (unmentioned), the description misses what the tool returns and any side effects. For a simple mutation tool, the behavioral gap (effect of clear) reduces completeness.

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 richly explains 'habit_id' acceptance of multiple reference forms and resolution process, and gives date format. This adds significant value beyond 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 clearly states the verb 'Clear' and the resource 'habit occurrence' with a specific date format. However, it does not differentiate from sibling tools like 'mark_habit_occurrence' or 'reschedule_habit_occurrence', missing explicit scope boundaries.

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 on when to use this tool vs alternatives. Context like prerequisites (occurrence must be marked) or when-not-to-use is absent, leaving the agent to infer from tool name alone.

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 must disclose behaviors. It mentions event_id resolution and the 400 error condition, but lacks details on side effects (e.g., append vs. replace), permissions, or error handling beyond the 400 case. Additional behavioral context would be beneficial.

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: a one-sentence purpose, a paragraph on event_id resolution, and a paragraph on intents/urls with error condition. Every sentence adds value, and critical 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?

Given the presence of an output schema, the description does not need to detail return values. It covers most parameters and essential behavioral notes, but the lack of explanation for the 'date' parameter and potential overwrite behavior leaves minor gaps. Overall, fairly complete for a 4-parameter 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, so the description must compensate. It explains the flexible forms of event_id, that intents come from a prior presign, and the structure of urls. However, the 'date' parameter is not explained, leaving a gap for a required field.

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

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

The description clearly states it commits intents and/or URL-provider entries to an event occurrence, with a specific verb and resource. It distinguishes from sibling tools like commit_task_attachments by focusing on event occurrences and referencing a prior presign call.

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 (after a presign call) and provides a condition to avoid (400 if both lists empty). However, it does not explicitly mention alternatives or when not to use it, but the workflow context is sufficiently 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, the description carries full burden. It discloses that the tool returns 'the full attachments Vec post-commit' and explains parameter constraints. However, it does not mention if the operation is idempotent, what side effects occur (e.g., deletion of intents), or required permissions. Some behavioral aspects are implicit (mutation), but not 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 concise (5-6 lines) and well-structured. It starts with a one-line summary, then uses clear bullet-style explanations for each parameter and constraint. Every sentence adds value 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?

Given that an output schema exists (though not shown), the description appropriately doesn't detail return fields but states 'Returns the full attachments Vec post-commit.' It covers purpose, parameter meanings, constraints, and usage context. For a commit action, this is 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 description must compensate. It explains that 'intents' is a list of attachment_ids from a prior presign call, 'urls' is a list of {url, filename?} records, and 'task_id' accepts various forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. 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 clearly states the tool's purpose: 'Commit presigned intents and/or url-provider entries to a task.' It distinguishes from siblings like presign_task_attachments (creating intents) and list_task_attachments (listing attachments). The verb 'commit' is specific and the resource 'task attachments' is clear.

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 usage context: it mentions 'presign call' as a prerequisite and states that at least one of 'intents' or 'urls' must be non-empty. However, it does not explicitly list alternatives or state when not to use this tool. It implies the workflow but lacks explicit 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?

No annotations provided, but description discloses the exchange operation and transport-specific applicability. It implies mutation (token creation) but could mention idempotency or failure behavior. Still, it adds value beyond missing annotations.

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

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

Three sentences, front-loaded with purpose, then parameter details, then transport note. Every sentence earns its place; no waste.

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

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

For a simple auth completion tool, the description covers all essentials: parameters, usage context, and transport differentiation. Output schema exists, so return values need not be described. Sibling start_auth is referenced.

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 has 0% description coverage, but description fully explains each parameter: session_id from start_auth response, code from user's browser. This adds critical meaning that the schema lacks.

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 clearly states the tool finishes authentication by exchanging a browser code for a token. It identifies the specific verb and resource, and distinguishes from sibling tools like start_auth by noting the HTTP transport case.

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?

Explicitly states when to use: only for stdio/CLI, not HTTP transport with OAuth. It also explains where session_id and code come from, giving clear context for use.

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 for behavioral disclosure. It explains reference resolution for item_id, backend wire field name for 'to', conditional requirements for complete_by, recurrence, and end_time, and idempotent behavior (200 vs 201). It does not cover permissions or error cases but provides substantial behavioral context beyond the 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 concise with four sentences, front-loading the main purpose. However, it could be more structured (e.g., bullet points) for easier parsing. It is efficient but slightly dense.

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 complexity (5 parameters, mutation, no annotations, output schema exists), the description covers parameter requirements, transformation behavior, and idempotent return codes. It does not address error scenarios or invalid conversions but is fairly complete for an AI agent.

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 thoroughly explains each parameter: item_id accepts multiple reference forms; to is the backend field name; complete_by required for Event/Chore/Habit; recurrence required for Habit/Chore; end_time Event-only. This adds crucial meaning 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 clearly states the tool's purpose: 'Convert an item to a different kind (Task / Chore / Habit / Event).' This is a specific verb+resource combination, and the conversion aspect distinguishes it from sibling create/update/delete 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 does not provide guidance on when to use this tool versus alternatives like creating a new item or updating item attributes. It lacks explicit context for appropriate usage and does not mention when not to use 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 provided, so description carries full burden. It explains core behavior (lingering, recurrence types, cadence_mode, deadline_time_of_day, subtask_template). Lacks details on error handling or failure modes.

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-structured: opening sentence, distinction from habits, recurrence format, then optional fields. Each sentence adds value, no 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?

For a tool with 6 parameters and recurrence complexity, the description covers core concept, usage context, parameter formats, and optional features. No annotations or output schema needed. Complete for an AI agent.

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%. Description explains 'complete_by' format (ISO-8601), 'recurrence' shape, and optional fields (cadence_mode, deadline_time_of_day, subtask_template). Does not cover all parameters (e.g., parent_id, labels), but adds significant value.

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 it creates a recurring chore that 'lingers until done,' distinguishing it from habits. It specifies the verb 'Create' and resource 'chore' with explicit behavioral difference.

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 contrasts chores with habits, giving clear context for when to use this tool. However, it does not explicitly state when not to use or name alternative tools beyond the sibling list.

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 full burden for behavioral transparency. It discloses that complete_by is the start time and end_time must be at or after, but it does not describe return value, side effects, permission requirements, or other behavioral traits. The mention of 'subtask_template' not in the schema may mislead.

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 relatively short and front-loaded with the main purpose. However, it includes version history ('v0.2 optional fields') and a reference to a field not in the schema, which adds unnecessary noise. It could be more succinct.

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 7 parameters, no annotations, and an output schema (unseen), the description is incomplete. It does not explain what the event creation entails, what the return value is, or how events differ from tasks. Key context like prerequisites or typical usage scenarios 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. It explains semantics for 'complete_by' and 'end_time' but provides no information for other five parameters (title, description, labels, parent_id, recurrence). Additionally, it mentions a 'subtask_template' field that does not appear in the schema, which could cause confusion.

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 tool creates a time-bound event, using a specific verb and resource. It clarifies that 'complete_by' is the start time. However, it does not explicitly differentiate from sibling tools like create_task or create_habit, though the term 'event' provides some distinction.

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

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

The description provides a validation rule (end_time must be after complete_by) and mentions version-specific optional fields, but it does not give explicit guidance on when to use this tool over alternatives. The context of creating an event vs. a task or habit is implied but not elaborated.

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 burden. It discloses that habits reset each period and unfinished occurrences do not carry forward, which is a key behavioral trait. It also provides examples for the recurrence field structure. It does not cover auth needs or potential 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 concise, using a brief summary and bullet points for optional fields. It front-loads the key difference from chores. The structure is clean, though the mention of v0.2 optional fields could be streamlined.

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 complexity of the tool (6 parameters, output schema present), the description lacks completeness. Only the recurrence parameter is explained in detail. The extra fields mentioned without schema presence and lack of explanation for other parameters leave 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 add meaning. It provides examples and shapes for the recurrence parameter but does little for other parameters like title, description, complete_by, parent_id, labels. Additionally, it mentions optional fields (deadline_time_of_day, subtask_template) that are not in the input schema, which could confuse.

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 'Create a recurring habit that resets each period', providing a specific verb and resource. It distinguishes habits from chores by explaining that unfinished occurrences do not carry forward, which sets it apart from sibling tool create_chore.

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 when to use habits instead of chores by contrasting the reset behavior. However, it does not explicitly state 'use this when you want to create a habit' or provide exclusions for other siblings like create_task or create_event.

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 must bear full burden. It mentions a write operation ('Save') but lacks detail on side effects, authentication needs, or whether duplicates are handled. This is insufficient for safe agent invocation.

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 very short with two sentences, no wasted words. However, it could have included more detail without becoming verbose. Still, it is appropriately sized for a simple 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?

Given the tool has 2 required params with no descriptions, no annotations, and relies on an output schema (not shown), the description is incomplete. It lacks constraints, error handling, and behavior specifics that an agent needs 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 coverage is 0% (no param descriptions). The description adds meaning only to 'query_string' by referencing search_items, while 'name' is completely unexplained. For two required params, this is inadequate.

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 'Save a search,' which is a specific verb+resource indicating creation of a saved search. It differentiates from sibling tools like list/delete/update by the action verb, though it doesn't explicitly contrast 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 only guidance is that query_string uses the same syntax as search_items, which is a reference but not a clear when-to-use or when-not-to-use statement. No alternatives or exclusions are 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 provided, so description must cover behavior. It explains recurrence behavior and optional occurrence_id but does not mention auth requirements, side effects, or error conditions.

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

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

Description is well-structured, front-loaded with purpose, then parameter details. Slightly verbose but justified given 10 parameters.

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 all parameters with meaningful detail. Has output schema (context hint). Lacks error handling or prerequisite info but is comprehensive for a creation tool.

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

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

Schema has 0% description coverage; description adds meanings for all parameters, including formats and examples for recurrence, complete_by, productive, desire, and recurring_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 clearly states 'Create a new task' and explains parameter purposes, distinguishing it from sibling tools like create_chore, create_event, create_habit.

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?

Does not explicitly state when to use create_task vs siblings. It implies context for occurrence_id but lacks when-to-use or 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?

The description discloses that the delete is a soft-delete (archive) and explains input resolution behavior. With no annotations, this provides useful behavioral context. However, it does not mention any side effects or limitations.

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

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

Two sentences, no extraneous words. The first sentence states the purpose, the second details the parameter. Perfectly sized and 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?

Given the simple one-parameter tool and presence of an output schema, the description covers the essential aspects. It could mention the return type or success confirmation, but is largely sufficient.

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 single parameter chore_id has no schema description, but the description thoroughly explains the accepted reference forms and resolution process, adding significant meaning beyond the raw string 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 clearly states the tool archives (soft-deletes) a chore, using a specific verb and resource. It distinguishes itself from sibling tools like create_chore and update_chore by explicitly indicating deletion.

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 use this tool versus alternatives. It provides no context on when a soft-delete is appropriate or when other deletion-related tools might be preferred.

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?

Discloses ownership constraint, which is important behavioral info beyond the verb 'delete'. With no annotations, this partially fulfills transparency, but lacks details like irreversibility or permissions.

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?

Efficient one-sentence description with clear main point, though could include a bit more context without harming conciseness.

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 action and key condition, but lacks details on error scenarios, prerequisites (e.g., comment must exist), or what happens after deletion, especially given the existence of an output schema.

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

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

The description adds no meaning to the single parameter 'comment_id' beyond its name. With 0% schema coverage, it should describe how to obtain or format the ID.

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?

Clearly states the action (delete) and resource (comment) with a specific condition (owned by caller), distinguishing it from sibling tools like delete_event_occurrence_comment.

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 a usage condition (owned by caller) but no explicit guidance on when to use vs alternatives like delete_event_occurrence_comment.

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 operation is a soft-delete (archive), not a hard delete, and explains how event_id is resolved. This adds useful behavioral context beyond a simple 'delete'.

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: first states purpose, second details parameter flexibility. No redundancy, front-loaded, and every sentence adds value.

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 one parameter and no annotations, the description covers purpose and parameter semantics adequately. An output schema exists, so return values need not be explained. The description is complete for this straightforward tool.

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

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

Schema coverage is 0% (no parameter description), but the description compensates thoroughly by explaining that event_id accepts multiple reference forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. This adds significant meaning beyond the generic 'string' 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 clearly states the verb ('Archive (soft-delete)') and resource ('an event'), distinguishing it from sibling tools like delete_event_occurrence. The purpose is specific and unambiguous.

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 its purpose but lacks explicit guidance on when to use this tool vs alternatives (e.g., delete_event_occurrence, update_event). No when-not-to-use or prerequisites are 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?

With no annotations, the description should fully disclose behavioral traits. It explains return value and event_id resolution, but does not explicitly state that the deletion is permanent or destructive, nor mention any side effects or authorization needs.

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 extremely concise: two sentences plus brief parameter clarifications, front-loaded with the main purpose, and every word adds value. No unnecessary 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?

Given the tool's simplicity and presence of output schema (implied), the description covers parameters and return value well. It lacks mention of error conditions or side effects, but is otherwise adequate for a straightforward delete operation.

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 adds substantial meaning: it explains accepted reference forms for event_id and date format, which the schema lacks. This compensates fully for the schema's omissions.

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 tool clears an event occurrence row, using specific verbs like 'clear' and 'undo a prior mark', which distinguishes it from sibling tools like 'delete_event' and 'set_event_occurrence'.

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 for undoing a prior mark, but does not explicitly list when to use versus alternatives or when not to use, though context from sibling names provides differentiation.

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 carries the burden of behavioral disclosure. It explains that 'event_id' accepts multiple reference forms and is resolved to UUID, that 'att_id' is an attachment ID passed through unresolved, and states the return value {'ok': true}. This gives a clear understanding of the tool's 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 well-structured with a clear purpose statement first, followed by parameter details. It is efficient but could be slightly more concise by combining the two parameter paragraphs into one. Overall, it earns its sentences.

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 three required parameters, no annotations, and no output schema provided (though description states return value). The description covers purpose, parameter handling, and return value, but the missing explanation for the 'date' parameter reduces completeness.

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. It explains 'event_id' reference resolution and 'att_id' semantics, but fails to describe the 'date' parameter, leaving a gap for one of three required fields.

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 'Delete a single attachment from an event occurrence.' It specifies the verb 'delete', the resource 'attachment', and the context 'event occurrence', which distinguishes it from sibling tools like 'delete_event_occurrence_comment' or 'delete_task_attachment'.

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 lacks any guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide context about choosing between similar delete tools for different resources.

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

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

The description mentions 'soft-delete', indicating non-destructive behavior, and explains the flexible input format for event_id. However, it does not disclose what happens if no comment exists, error handling, or permission requirements. With no annotations, more detail would be helpful.

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 long, front-loading the core action and then adding detail on event_id. No extraneous information; every sentence contributes value.

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 two required parameters and an output schema, the description covers the basic action and event_id flexibility but omits the return value, missing parameter format for date, and edge cases. It is adequate but not comprehensive.

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 thoroughly explains event_id (accepts various reference forms and resolves to UUID), but only vaguely mentions date as part of the occurrence. The date parameter lacks format or constraints, leaving it partially ambiguous.

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: 'Soft-delete the latest comment on an event occurrence (date).' It specifies the verb (soft-delete), resource (latest comment on an event occurrence), and context (occurrence date), distinguishing it from siblings like delete_comment (general) and delete_event_occurrence (deletes occurrence 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 for deleting the latest comment on an event occurrence, but does not explicitly compare to alternatives like patch_event_occurrence_comment or delete_comment. No 'when to use' or 'when not to use' guidance is 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 fully bears the burden. It discloses that the operation is a soft-delete ('Archive') and explains the ID resolution behavior, providing useful behavioral context.

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

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

Three sentences with no fluff: first sentence states purpose, second explains parameter. 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?

Given output schema existence, return values need not be explained. The description covers purpose and parameter semantics fully, but lacks any mention of conditions or outcomes beyond soft-delete.

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 does so excellently by explaining that habit_id accepts UUID, sequence shorthand, canonical ref, or app URL and is resolved to UUID, adding significant meaning beyond the schema's generic string 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 clearly states 'Archive (soft-delete) a habit', specifying the action (soft-delete) and the resource (habit), distinguishing it from sibling tools like delete_task or delete_chore.

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 ID resolution but lacks explicit guidance on when to use this tool versus alternatives like update_habit or other delete tools. No conditions or exclusions are 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, but the description does not disclose any behavioral traits beyond the implied action of deletion, such as irreversibility or 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 a single sentence that is front-loaded and concise, but it omits important details that would make it more effective.

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 delete tool with an output schema, the description is adequate but lacks behavioral context (e.g., irreversibility) that helps the agent understand the full impact.

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 the tool description does not add any meaning to the 'saved_search_id' parameter beyond its name.

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 (delete) and the resource (saved search), distinguishing it from sibling tools like 'list_saved_searches' and 'update_saved_search'.

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 use this tool versus alternatives, such as prerequisites or conditions for deletion.

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 provided, so description carries burden. Discloses it's a hard-delete and the returned task_id, but lacks details on side effects, authorization, or error conditions.

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

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

Two short paragraphs, front-loaded with purpose, followed by parameter details. Every sentence adds value.

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 input and output adequately. Output schema exists, reducing need for return value explanation. However, could mention error conditions or prerequisites.

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?

Adds significant meaning beyond schema (0% coverage) by detailing that task_id accepts UUID, sequence shorthand, canonical ref, or app URL, and explains the returned value.

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?

Clearly states it 'hard-deletes a task by id', with a specific verb and resource. Differentiates from sibling delete tools for other entities and delete_task_attachment.

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?

Implied usage (when you need to delete a task), but no explicit guidance on when to use vs alternatives, prerequisites, or consequences.

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?

Describes ID resolution behavior (task_id resolved to UUID) and that att_id is passed through. No annotations, so description carries burden. Could mention irreversibility, but sufficient for understanding.

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 front-loaded sentences with no waste. Every sentence adds distinct value: purpose and ID resolution 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?

Covers input parameters well. No output schema shown but presumably available; description doesn't need to explain return values. Missing potential error conditions, but acceptable for a simple delete operation.

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 coverage, description adds critical meaning: explains accepted reference forms for task_id and clarifies that att_id is an attachment id (not item ref). Significantly beyond type info.

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?

Clearly states it deletes a single attachment from a task. Differentiates from siblings that delete other entities like tasks or comments.

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?

Specifies the action and the context (delete attachment from task). Provides guidance on ID formats for task_id. No explicit when-not-to-use but clear from name and description.

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

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

Discloses it returns a complete backup of specified data. Implicitly non-destructive (read operation), though no explicit safety guarantee. Good context despite lack of annotations.

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

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

Three sentences with no wasted words. First sentence states purpose, second details contents, third mentions reimport. 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?

Given no parameters and presence of output schema, description covers all essential behavioral aspects (what is exported, import capability). Complete 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?

No parameters, so schema coverage is 100%. Description adds value by clarifying it exports 'all' user data with no filtering, which is meaningful beyond 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?

Description explicitly states it exports all user data as JSON, a complete backup. Lists specific data types (tasks with full history, mood vectors, recurrence rules, root ordering, daily plans). Distinguishes from sibling import_data.

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?

Clearly indicates usage for backup purposes and mentions reimport via web UI. No direct when-not or alternatives, but context suggests export is for backup, import for restore.

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

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

The description discloses an administrative access requirement, which is a behavioral trait. However, it does not explicitly state whether the operation is read-only or if it has any side effects. With no annotations provided, the description carries the full burden, and it only partially fulfills 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 description is a single, clear sentence with no wasted words. It efficiently conveys the tool's purpose and access restriction.

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 no parameters and an output schema (which describes return values), the description is fairly complete. However, it could elaborate on what 'aggregate feedback statistics' entails, but that is partially covered by the output schema.

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

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

There are no parameters in the input schema, so the description does not need to add parameter semantics. According to the rubric, 0 parameters warrant a baseline of 4, which is appropriate here.

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 tool returns aggregate feedback statistics, with an access restriction (admin only). It distinguishes from sibling tools like list_feedback by implying it provides summary data rather than individual items. However, it could be more specific about what statistics are included.

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 mentions 'admin only', which implies usage context, but it does not explicitly state when to use this tool versus alternatives like list_feedback. No exclusion criteria or alternative recommendations 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 carries full burden. It discloses that task_id accepts multiple reference formats, preserves existing chain, and returns both tasks. But it lacks details on permissions, error handling, or side effects, which is a gap.

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

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

The description is relatively concise with four short sentences, front-loading the purpose. The explanation of task_id formats is useful but could be condensed without losing meaning.

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 7 parameters and no schema descriptions, the description is incomplete. It fails to document most parameters, lacks error conditions, and only briefly mentions return value. The presence of an output schema partially compensates for return format, but parameter documentation remains insufficient.

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 description must explain parameters. It only details task_id's reference formats, ignoring the other 6 parameters (title, description, labels, etc.), which are left without meaning beyond their names.

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 tool inserts a new task after a given task_id, using specific verbs and resource. It distinguishes from siblings like create_task (standalone creation) and move_task (reordering by explaining it inserts a next-step task).

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

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

The description implies usage for inserting a task after another in a sequence, and mentions it preserves downstream chain, which differentiates it from other tools. However, it does not explicitly state when not to use or name alternatives, leaving some ambiguity.

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 provided, so description carries full burden. It explains expansion of RRULE and timezone handling. Lacks mention of read-only nature but is implied by 'query'.

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-structured with concise intro and clear parameter explanations. No redundant sentences.

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?

Complete for a simple query tool. Output schema exists, so return format is covered. Could mention pagination or limits but not necessary.

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 description provides all semantics: start/end are YYYY-MM-DD with inclusive/exclusive; tz is IANA timezone for local midnight alignment.

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 explicitly states it queries calendar events for a date range, including recurring tasks from RRULE. This distinguishes it from sibling tools like get_daily_plan or get_tasks_calendar.

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?

Clear context for use: date range queries. It does not explicitly say when not to use or mention alternatives, but the behavior for recurring events is well explained, implying differentiation.

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 burden. It discloses how the plan auto-seeds from recurring tasks, carries forward incomplete items, and includes due items. It also explains timezone handling and parameter defaults. No side effects or destructive actions are indicated, which is appropriate for a read-only 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 with a clear intro followed by parameter details. It is concise without unnecessary text, though the parameter documentation could be slightly more compact. Every sentence contributes to understanding.

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 only 2 optional parameters, no required fields, and an output schema (not shown), the description covers all essential aspects: behavior, parameter semantics, and timezone handling. It is complete and leaves no critical 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 coverage is 0%, so the description must compensate. It explains both parameters in detail: date format (YYYY-MM-DD), default behavior (today in user's timezone), and timezone (IANA format, persistence after first use). This adds significant value 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 'Return today's curated daily plan' and explains its contents (recurring tasks, incomplete items, due items). It is specific about the verb and resource, but does not explicitly differentiate it from sibling tools like get_items_plan or get_calendar_events.

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 guidance on when to supply the timezone parameter and mentions that the date defaults to today in user's timezone. However, it does not discuss when to use this tool versus alternatives or note any prerequisites.

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 provided, so the description carries full burden. It explains resolution behavior, default vs full response, and ambiguity handling. It does not explicitly state read-only or idempotency, but the 'get' verb and context imply it. Overall, it adds significant behavioral context.

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

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

Description is well-structured: starts with a clear one-liner, then organized bullet points for input forms, and detailed explanation of ambiguity. Every sentence adds value. No wasted words.

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

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

Given the complexity of input forms and ambiguity, the description is comprehensive. It covers all parameters, default behavior, and when to use flags. Output schema exists, so return values are not needed. Complete for the tool's purpose.

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. It explains all three parameters in detail: item (multiple forms, resolution, ambiguity), full (comparison to default), and as_alias (escape hatch). Adds rich semantics beyond 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 clearly states it fetches a single item (Task/Habit/Chore/Event) by any reference. It distinguishes itself from sibling tools like search_items by focusing on single-item retrieval via various reference forms.

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 (fetch a single item by reference) but does not explicitly contrast it with sibling tools like search_items or get_item_history. However, it provides detailed usage guidance for parameters, including when to use as_alias.

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 explains acceptance of various reference forms and UUID resolution, but does not mention pagination, rate limits, error handling, or whether history is full or limited. No annotations to supplement.

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

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

Two sentences, front-loaded with purpose, no fluff. Parameter details are efficiently integrated.

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?

Output schema exists, so return format is covered. However, missing usage guidance and behavioral traits like scope of history limit completeness. Adequate but not thorough.

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 has 0% description coverage, but description provides rich details on accepted formats (UUID, sequence shorthand, canonical ref, app URL), adding significant meaning beyond 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?

Description clearly states verb 'Return' and resource 'change-history list for any item kind', and distinguishes from siblings like 'get_item' by specifying history vs current 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?

No explicit guidance on when to use this tool vs alternatives like 'get_item' or 'search_items'. Sibling tools are listed but no comparison or conditions 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains date format and timezone, but does not mention that this is a read-only operation, nor any potential limits, pagination, or ordering. For a tool with no annotations, more detail is needed.

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 front-loaded: the first sentence states the purpose, followed by two lines detailing parameter formats. Every sentence adds value with no repetition 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?

Given the tool's simplicity (3 params, output schema present) and the context of many siblings, the description covers the key aspects: purpose, parameter formats, and timezone handling. The presence of an output schema reduces the need to describe return values, making this fairly complete for an agent to use 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?

With 0% schema description coverage, the description effectively adds meaning: it specifies that 'start' and 'end' are 'YYYY-MM-DD' with 'end' exclusive, and 'tz' is an 'optional IANA timezone'. This clarifies usage beyond the raw schema types, though it could further explain defaults or behavior when tz is omitted.

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 it provides a 'Calendar view across all item kinds (Task, Habit, Chore, Event)'. This identifies the specific verb ('view') and resource ('all item kinds'), and distinguishes it from sibling tools like 'get_tasks_calendar' or 'get_calendar_events' that likely focus on subsets.

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 for a combined calendar view, but does not explicitly state when to prefer this over siblings like 'get_tasks_calendar' or 'get_calendar_events'. No exclusions or alternatives are mentioned, leaving the agent to infer based on tool names.

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 mentions the polymorphic return type and parameter defaults, but does not disclose any side effects, read/write nature, rate limits, or pagination behavior. The behavioral disclosure is incomplete.

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

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

Two sentences front-load the purpose and then provide key details on return type and parameters. Every sentence is informative and there is no waste.

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

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

Given the tool returns a daily plan across multiple item kinds with an output schema, the description covers the return structure (discriminator), parameter defaults, and timezone format. Minor gaps exist (e.g., no mention of ordering or plan scope), but it is largely complete.

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

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

The input schema has 0% description coverage, but the description compensates by explaining that 'date' defaults to today and 'tz' is an optional IANA timezone. This adds essential 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?

Description clearly states it retrieves a daily plan covering Tasks, Habits, Chores, Events, and mentions the polymorphic array with kind discriminator. However, it does not explicitly differentiate from the sibling tool 'get_daily_plan', which may have overlapping functionality.

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 on when to use this tool versus alternatives like 'get_daily_plan', 'get_item', or 'search_items'. The description implies usage for daily planning but does not provide explicit context or 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?

The description discloses that the tool returns only historical data for finished tasks, which is a key behavioral trait. Since no annotations are provided, the description carries the full burden; it also implies a read-only operation without 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 extremely concise at a single sentence, front-loading the key information without any unnecessary words.

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

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

Given zero parameters and the presence of an output schema, the description adequately covers the purpose and scope. It could mention ordering or limits, but the output schema likely handles return structure.

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?

No parameters exist, so the description has no need to add parameter information. The baseline for zero parameters is 4, and the description does not detract from that.

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 tool returns the user's historical mood-per-task log for finished tasks, specifying the verb 'return', the resource 'mood-per-task log', and the scope 'finished tasks', which distinguishes it from sibling tools like get_item_history.

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 guidelines are provided about when to use this tool vs alternatives. The description implies it is for finished tasks, but does not explicitly state that it is not for ongoing tasks or provide alternative tool suggestions.

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 full burden for behavioral disclosure. It only states the basic function (returning settings blob) without mentioning that it is read-only, requires authentication, or has no 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 a single, clear sentence that efficiently communicates the tool's purpose with relevant examples. No unnecessary words.

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

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

Given the tool has no parameters and an output schema exists, the description is largely sufficient. It could optionally hint at the output structure, but the examples provide enough 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?

The tool has zero parameters, so schema coverage is 100%. The description adds value by giving examples of settings fields, which goes beyond the empty schema. Baseline for zero parameters is 4.

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 tool returns the user's settings blob and lists example fields (theme, done-visibility). This distinguishes it from siblings like update_settings, which is a write 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 explicit when-to-use or when-not-to-use guidance is provided. The context implies it is for reading settings, but alternatives like how to modify settings (update_settings) or get other data are 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?

With no annotations, the description must carry the full burden of behavioral disclosure. It explains that the tool returns a calendar view with recurring expansions and due dates, and clarifies parameter date formats and timezone handling. However, it does not explicitly state whether the operation is read-only or if any side effects occur, and lacks details on authentication or rate limits.

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

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

The description is extremely concise, with a front-loaded first sentence defining the tool's purpose, followed by a single sentence explaining parameter formats. Every piece of information is relevant and there is no 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?

Given the tool's modest complexity (3 parameters, output schema present), the description covers the key input details and purpose. It does not describe the output schema structure, but per rules that is not required since an output schema exists. The description is sufficient for an agent to understand input requirements and overall behavior.

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 adds essential meaning: specifying that 'start' and 'end' are YYYY-MM-DD strings with 'end' exclusive, and that 'tz' is an optional IANA timezone for local-midnight alignment. This significantly aids correct parameter usage.

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 that the tool provides a 'Calendar view of tasks (recurring expansions + due dates)', which specifies the verb (view), resource (tasks), and scope (calendar). It effectively distinguishes this tool from siblings like get_calendar_events (for events) and get_items_calendar (for all items).

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 versus alternatives. There is no mention of prerequisites, when to avoid it, or which sibling tools might be more appropriate for specific use cases.

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 is the sole source. It discloses the expected structure and dry-run behavior but does not detail side effects, permissions, or conflict handling. Adequate but not exhaustive.

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 very concise—two sentences that state the purpose and explain the parameter. No wasted words; the key 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?

Given one parameter, no required fields, and an output schema, the description is mostly complete. It covers input structure and dry-run capability, though it could mention whether existing data is overwritten or appended.

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 coverage, the description adds critical meaning: 'data' must be the full ExportData object with specific keys, and an empty dict triggers a dry-run. This goes beyond the schema's minimal definition of an optional object.

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 tool imports an ExportData blob produced by export_data. It specifies the verb ('import') and resource ('ExportData blob'), and distinguishes itself from the sibling export_data 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?

The description implies when to use: after exporting data with export_data. It mentions a dry-run option (pass empty dict), but does not explicitly exclude other scenarios. No alternative import tools exist among siblings, so 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, the description carries the full burden. It correctly discloses input reference resolution, status values, and date format/inclusiveness. However, it omits details like whether the operation is read-only, pagination behavior, ordering, or error handling, leaving gaps in 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?

Three short paragraphs, each adding value: purpose first, then chore_id details, then status and date info. Front-loaded and efficient with no redundant sentences.

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 existence of an output schema, the description covers essential input parameters and output statuses. It lacks mention of ordering or pagination, which are common for list endpoints, but overall it provides enough context for the tool's primary function.

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 effectively explains chore_id reference forms and resolution, date format (YYYY-MM-DD), and inclusive range. This adds significant meaning beyond the bare schema, though it could be more explicit about default values (null means no bound).

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 tool lists derived occurrences for a chore within a date window. The verb 'list' and resource 'chore occurrences' are specific, and the tool is easily distinguishable from sibling list tools like list_habit_occurrences and list_event_occurrences.

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 provided on when to use this tool versus alternatives. While the purpose is clear, the description does not mention scenarios where other tools (e.g., get_calendar_events) might be more appropriate or when not to use this tool.

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

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

Annotations are absent, so the description carries the burden. It reveals that event_id is resolved to UUID and that url is a freshly signed GET for s3-backed entries. This gives good insight into input handling and output behavior. Could mention potential expiration of the URL or pagination.

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 (4 sentences) and well-structured: purpose first, then event_id flexibility, then output shape. No redundant 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 the output schema exists and the description covers the response shape, this is fairly complete. It lacks mention of error handling or pagination, but for a simple list tool it is sufficient. Sibling tools are listed but not referenced.

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 adds significant value for event_id by listing accepted reference forms. However, the date parameter is not explained (e.g., format). With only two parameters, this partial coverage justifies a 3.

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

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

The description clearly states the action ("List attachments") and the resource ("on a specific event occurrence (date)"). It distinguishes from sibling tools like delete_event_occurrence_attachment and presign_event_occurrence_attachments by specifying the list 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?

The description explains how to provide event_id in various formats but does not specify when to use this tool versus alternatives such as list_task_attachments or presign_event_occurrence_attachments. No context about prerequisites or exclusions is 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?

No annotations provided, so the description carries the full burden. It discloses the return shape and notes that Events never produce 'DoneLate', adding behavioral context beyond basic functionality.

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, front-loads the purpose, then systematically covers parameters, return shape, and a behavioral note. No redundant sentences.

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 simplicity and the presence of an output schema, the description covers the key aspects: purpose, parameter formatting, return shape, and a behavioral constraint. Missing pagination details but adequate.

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 fully explains event_id's accepted formats and resolution process, and clarifies from_date/to_date format and optionality, adding significant value.

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 tool lists occurrences for an Event in a date range, with a specific verb and resource. It distinguishes from siblings like list_chore_occurrences and list_habit_occurrences by focusing on events.

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 specify the event_id (multiple reference forms) and that from_date/to_date are optional. It provides clear usage context but does not explicitly mention when not to use this tool or name 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?

No annotations provided; the description only adds 'admin only' as a behavioral constraint. Does not disclose whether the operation is read-only 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?

Single sentence with no wasted words, conveying all essential information upfront.

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?

Sufficient for a simple list operation with no parameters and an output schema, though lacks mention of pagination or sorting which could be relevant.

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?

No parameters in schema, so description cannot add value beyond the schema. Baseline 3 applies as schema coverage is 100%.

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?

Clearly states verb 'list', resource 'feedback', and context 'submitted' with access restriction 'admin only'. Distinguishes from sibling 'feedback_stats' which implies statistical aggregation.

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?

Defines a clear prerequisite (admin only) but does not explicitly address when to use this tool versus alternatives like 'feedback_stats'.

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 adds some transparency by noting habit_id resolution and date inclusivity. However, it omits other behavioral traits such as authorization requirements, pagination, or idempotency, leaving gaps that an agent needs to infer.

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, front-loading the purpose in the first sentence. It uses clear formatting for parameter details and avoids unnecessary words. Every sentence adds value.

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 an output schema present, the description does not need to explain return values. It thoroughly covers parameter behavior and usage. Minor gaps exist (e.g., default date range behavior), but overall it is complete enough for a tool with this complexity.

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

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

Schema coverage is 0%, but the description adds significant semantic value: it explains that habit_id accepts various reference forms (UUID, sequence shorthand, canonical ref, URL) and that dates must be YYYY-MM-DD with inclusive range. This goes well beyond the schema's basic 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 clearly states 'List occurrences for a habit in a date window,' specifying the verb, resource, and scope. It also clarifies that habit_id accepts multiple reference forms, making the tool distinct from siblings like list_chore_occurrences or list_event_occurrences.

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 habit_id and dates should be provided, but it does not explicitly guide when to use this tool versus alternatives. Given the sibling tools, the resource differentiation is implicit, but explicit usage guidelines would improve clarity.

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 behavioral disclosure. It thoroughly explains the default compact projection, the rejection of unfilterable fields with a 400 error, the limit cap behavior (backend rejects >500), and the automatic injection of fields like ref, org_slug, type, and sequence. It also clarifies the effect of the 'full' and 'window' parameters. This level of detail is exemplary.

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 sentence and bullet points for filters. It is somewhat lengthy but each sentence adds value. It could be slightly more concise, but the organization compensates.

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 complexity (7 parameters, no annotations, no param descriptions in schema), the description covers all necessary aspects: projection details, filter syntax, limit behavior, and error handling. The existence of an output schema (not shown) means return values need not be explained, and the description still mentions the compact vs full rows. It is complete enough for an agent to use 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 input schema has 0% description coverage, so the description must compensate. It does so by explaining each parameter: kind (listing possible values), status, from_date/to_date (format and behavior), limit (maps to $top and cap), full (boolean to drop projection), and window (opt-out default). 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 clearly states it lists items of various kinds (Task/Habit/Chore/Event) with windowing, calling itself the 'canonical, bounded list view'. It specifies the verb 'list' and the resource 'items', but does not explicitly differentiate from sibling tools like search_items or get_items_calendar, leaving some ambiguity about when to choose this tool over alternatives.

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 context such as the default projection and mentions when to use window='all' for full history. However, it does not explicitly state when to use this tool versus search_items or other listing tools, nor does it provide exclusions or conditions for not using it. Usage guidelines are implied but not 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?

Despite no annotations, the description thoroughly discloses behavior: it returns a JSON array with specific structure, reconciles inconsistencies by dropping unpinned/deleted entries, and guarantees self-consistent output safe for rendering. No contradictions.

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 extremely concise (about 60 words) and front-loaded. The first sentence states the core purpose, the second adds output details and behavioral guarantees. Every sentence earns its place with no wasted words.

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

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

Given zero parameters and an output schema (inferred), the description fully covers the tool's behavior including reconciliation logic and output format. No gaps remain for an agent to understand invocation or results.

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 zero parameters, so the description does not need to add parameter details. Baseline 4 is appropriate as the schema coverage is 100% and no parameters exist to clarify.

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 'List' and clearly identifies the resource as 'sidebar-pinned items in display order'. It distinguishes this tool from siblings like 'set_item_pinned' and 'reorder_pinned_tasks' by focusing on listing, not pinning or reordering.

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 states the tool's purpose (listing pinned items in order) and implies usage in sidebar rendering context. However, it does not explicitly state when not to use this tool or provide alternatives for other listing needs.

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?

Without annotations, the description carries the full burden. It discloses ordering behavior but omits potential details like pagination, limits, or authentication requirements. This is acceptable for a straightforward list but lacks thoroughness.

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

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

One sentence, no fluff. Front-loaded with the verb and resource. Every word serves a purpose.

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 simplicity, the description is fairly complete. It explains the action and ordering. An output schema exists for return values. Could mention if it returns all items or paginated, but not a major 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?

There are no parameters, so the schema is empty. Schema description coverage is 100% trivially. The description adds nothing about parameters, but that's fine since none exist. Baseline 4 for 0-param tools.

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 'List' and resource 'saved searches', and adds the key detail 'in their explicit order', which distinguishes it from a generic list. The tool name itself is descriptive, and the description reinforces its specific 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?

No explicit guidelines on when to use this tool versus alternatives like 'search_items' or 'reorder_saved_searches'. For a simple 0-parameter list, some guidance is not critical, but it would strengthen clarity.

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 provided, but the description explains URL signing for S3 and task_id resolution, offering good transparency beyond the basic 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?

Three efficient sentences covering purpose, output, and parameter behavior without waste.

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

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

Despite output schema existing, the description provides the wire shape, and all relevant behaviors are covered for a simple 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?

Schema coverage is 0%, but the description fully explains that task_id accepts UUID, shorthand, canonical ref, or app URL, adding critical meaning.

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 'List a task's attachments' and provides the output wire shape, distinguishing it from siblings that create, delete, or presign attachments.

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 for retrieving attachments without explicit when-not or alternatives, but the context of sibling tools makes the purpose 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?

Discloses removal of saved credentials, but lacks details on token invalidation, side effects, or return value. With no annotations, more detail is needed.

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?

Extremely concise, single sentence, front-loaded with key action and resource.

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?

While concise, the description omits what happens after logout (e.g., return value, whether session ends globally). Output schema exists but isn't leveraged.

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?

No parameters exist, so no additional meaning needed. Baseline of 4 applies.

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

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

The description clearly states the action ('Log out') and the resource ('saved credentials'), distinguishing it from auth-related siblings like start_auth and complete_auth.

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?

Implied usage (end session) but no explicit guidance on when to use or not use, nor mention of prerequisites like being authenticated.

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 burden for behavioral disclosure. It mentions that habit_id is resolved to UUID and date defaults to today, but does not reveal idempotency, error handling, or whether it overwrites existing occurrences. Key behavioral traits are missing.

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, with a clear purpose in the first sentence and parameter details in a structured second paragraph. No superfluous text, though could be slightly more compact without losing meaning.

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 habit_id and date well, but lacks information on error conditions, idempotency, or the relationship to clear_habit_occurrence. With an output schema present, return values are not required, but overall context for a complete agent decision is moderately adequate.

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 description adds significant meaning beyond the schema for habit_id (accepts various reference forms and resolves to UUID) and date (YYYY-MM-DD format, defaults to today). However, the 'done' parameter (boolean) is not explained, leaving a gap despite low schema coverage (0%).

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

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

The description clearly states 'Mark a habit occurrence as done or not-done,' specifying the verb (mark), resource (habit occurrence), and the binary outcome. Among sibling tools like clear_habit_occurrence and reschedule_habit_occurrence, this tool is unambiguously distinct.

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 for marking a habit occurrence, but does not explicitly state when to use this tool versus alternatives like clear_habit_occurrence or other habit-related tools. No guidance on prerequisites or 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, the description carries full burden. It explains ID resolution, status values including alias, and the behavior of 'Done' resolving to DoneOnTime/DoneLate. It also mentions the 404 error case. Some side effects (e.g., updating any other data) are not mentioned but likely minimal.

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 with several sentences, each adding value. It is front-loaded with the core action. No wasted words.

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

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

Given the tool's complexity (2 parameters, one required, output schema exists), the description covers behavior, parameter details, and an error case. It does not describe the output format, but the presence of an output schema lessens that need.

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 has 0% coverage, so description compensates fully. It explains chore_id accepts multiple reference forms and resolves to UUID, and enumerates valid status values including aliases. This adds meaning beyond the raw schema types.

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