ProWoDo

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

Annotations indicate readOnly=false, idempotent=false, and destructive=false, but the description adds valuable behavioral context beyond this: the side-effect that providing text creates the tag if it does not exist, the constraint that the tag must belong to the same company as the task, and the instruction to give the user the app_url deep link instead of describing navigation. These are meaningful additions that help the agent understand the tool's real-world behavior and output presentation.

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

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

The description is three sentences, front-loaded with the core action, then explains the two input modes and the company constraint, and ends with a practical output instruction. No fluff or repetition; every sentence 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 (three parameters, nested object, no output schema), the description provides sufficient information to invoke it: how to specify the task (pk), how to specify the tag (text or id), and a key output hint (app_url). It doesn't explicitly detail the response body, but the app_url instruction implies the response contains that field, which mitigates the absence of an output schema. Overall, it covers the essential behavioral and usage aspects.

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

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

The schema actually includes descriptions for id, text, and pk (though the context signal claims 0% coverage, which seems inconsistent). The description adds important semantics beyond the schema: it explicitly states that text and id are mutually exclusive ('Provide either text or id') and clarifies the company-matching requirement. This helps disambiguate how the parameters relate and when to use each, adding value over 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: 'Attach a tag to a task.' It gives the specific verb 'attach' and resource 'tag to a task', and distinguishes from sibling tools like create_tasktags (which creates new tag entities) and remove_tag_tasks (which removes tags). The mention of alternative input methods (text or id) further clarifies the tool's specific role.

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

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

The description provides clear context for usage: 'Provide either text or id' and 'The tag must belong to the same company as the task.' It implies the appropriate scenarios for each input type (create-on-the-fly vs. existing tag). However, it does not explicitly mention alternatives or when-not-to-use cases, such as 'use create_tasktags to create a standalone tag' or 'use remove_tag_tasks to detach.' This is clear context without exclusions, so it falls short of a 5.

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

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

The description directly contradicts the annotations: it claims 'Idempotent: if the user is already assigned, returns the existing assignment without error,' while `idempotentHint` is false in the annotations. This is an annotation contradiction and severely undermines trust in the tool's behavioral disclosure.

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, starts with the primary action, and every clause adds useful information: the action, idempotency, and a business rule. There is no filler or repetition.

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

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

For a mutation tool with two required parameters, no output schema, and incomplete annotations, the description provides key context (idempotency, company constraint) but misses a clear explanation of the response/return value and does not resolve the idempotency contradiction. It is adequate but not complete.

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

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

The schema description coverage is 0% per context, and the tool description does not compensate by explaining the parameters beyond the action. It adds the company-membership constraint for `user_id` content, but it does not clarify the `kwargs`/`body` nesting or the parameter roles beyond what the schema already states. For nested required parameters, more semantic guidance is needed.

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 ('Adds') and resource ('a user as an assignee on a task'), making the action immediately clear. It also distinguishes itself from the sibling `unassign_user_tasks` by naming the assignment direction, and the idempotency note further disambiguates behavior.

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

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

The description gives a clear context for when to invoke the tool: assigning a user to a task, and it states a concrete prerequisite (the user must belong to the same company as the task's project). It does not explicitly mention alternative tools or when not to use it, but the sibling list makes the main contrast obvious via `unassign_user_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?

Annotations indicate readOnly=false, but the description adds valuable context beyond that: it discloses the side effects on non-DONE tasks (carried over or returned to backlog) and the presence of app_url in the response. This enriches the behavior without contradicting 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?

The description is two sentences, front-loaded with the core action, and provides essential behavioral and user-guidance details without waste. Every sentence carries meaningful information.

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

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

For a simple mutation with one required parameter and no output schema, the description covers the main action, task handling, and a key response element (app_url). It does not mention errors or permissions, but given the annotations and simplicity, it is sufficiently complete.

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

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

The schema already provides a thorough description for carry_over_to (including null handling), and pk is a generic primary key. The tool description mostly restates the carry_over_to semantics, adding little new parameter meaning. With schema coverage effectively high, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb and state change: "Transition an ACTIVE sprint to CLOSED." This distinguishes it from siblings like start_sprints, update_sprints, and list_sprints by focusing on the close action and the active-to-closed transition.

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

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

The description provides clear context for use: it explains the carry-over behavior for non-DONE tasks and instructs who should receive the app_url deep link. However, it does not explicitly compare with alternatives or state when not to use the tool, so it lacks explicit 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?

Discloses critical behavioral traits beyond annotations: 4 MB size cap for inline content, allowed file types (images, PDF, text, CSV, Office, zip), and that company-level attachments have null app_url because they have no dedicated page. The annotations only indicate non-readonly, so this context is essential and well-covered.

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

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

The description is dense but not bloated; every sentence adds value. It opens with the core action, then systematically covers content types, requirements, size caps, project optionality, allowed types, and return value. No filler or repetition.

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

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

For a complex tool with nested schema and multiple modes, the description covers all necessary aspects: attachment targets, mutual exclusivity, required fields, size thresholds, file type constraints, and the app_url nuance. Without an output schema, the mention of app_url and its null case is particularly valuable.

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

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

Despite schema descriptions for individual fields, the description adds mutual exclusivity constraints, size limits, and clarifies that content_type is required only with content_base64. It also explains the semantics of project_id (omit for company-level) and the app_url return behavior, which are not fully captured in the schema.

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

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

The description starts with a specific verb+resource+scope: 'Create an attachment on a company or one of its projects.' It clearly distinguishes this from sibling create tools (e.g., create_tasks, create_companys) by explicitly mentioning 'attachment' and its target scope.

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 explicit when-to-use vs when-not-to-use guidance: 'Provide exactly ONE of: text, content_base64, or link' and 'for larger files, upload to Drive and pass the URL as link instead.' It also clarifies when file_name is required and when project_id should be omitted.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses a meaningful side effect: 'The authenticated user is automatically added as its first member.' This adds behavioral context not available in annotations and helps the agent understand what happens on creation. No contradictions with 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 short, purposeful sentences. The first sentence states the core action, the second gives a key side effect, and the third provides usage context. No fluff or repetition, and the most important information is front-loaded.

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

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

The description covers the essential aspects: what it does, the automatic membership side effect, and how the new company fits into the system (owning projects/sprints/tasks). It does not state return value expectations, but the absence of an output schema makes that less critical. Overall, it is well-rounded for a create tool with this schema complexity.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. However, the description does not mention 'body', 'name', or nested fields at all. The required 'name' is implied by the action, but the description adds no insight into 'description' or 'daily_resume_default', leaving the schema to carry that burden.

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: 'Create a new company (workspace)' with a specific verb and resource. It distinguishes itself from sibling create_* tools by explaining that a company is a 'fresh tenant' that will own its own projects, sprints, and tasks, so it cannot be confused with creating those sub-entities.

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

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

It provides clear usage context: 'Use this to start a fresh tenant' and explains the ownership model. While it does not explicitly name alternative tools or when not to use it, the description makes the unique role of create_companies clear relative to create_projects, create_sprints, etc.

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 adds valuable behavioral context beyond the annotations: projects carry an app_url pointing to the dashboard, and the timeline (Gantt) is plan-gated, redirecting non-plan users to a billing page. This is substantial extra information beyond the basic readOnly/idempotent/destructive hints, though it could further mention idempotency or error behavior.

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

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

The description is reasonably concise for the amount of information it conveys. Every sentence adds some value, such as the URL structure and plan-gating behavior, though it could be tightened 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 key aspects of project creation, including the company context, required fields, and plan-gated timeline. However, it does not explain the return value or response format, which is significant given there is no output schema. It also omits permission requirements or potential failure modes.

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

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

The description mentions company_id as a path parameter and states that a title is required, adding meaning over the schema. However, it does not explain the 'description' or 'is_archivied' parameters, and the schema coverage is low (0%), so the description only partially compensates for the lack of parameter documentation.

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 and resource: 'Create a new project inside a company' and explains the project's role as grouping tasks, sprints, and board columns. It also mentions the required title and the app_url, making the purpose specific and distinct from sibling tools like create_tasks or create_sprints.

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 context of when to use the tool is implied: creating a project within a company and providing at least a title. However, it does not explicitly state when not to use it or mention alternatives such as create_tasks or create_sprints, leaving the usage guidance to inference rather than direct instruction.

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 already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds valuable behavioral details: default recipient (task assignees), default channel (push on), the constraint that at least one channel must be enabled, and the behavior of notify_if_completed. It also discloses that the response includes an app_url deep link.

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 three sentences that start with the primary action and then detail optional parameters. Every sentence adds functional value without repetition, making it easy to parse quickly.

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

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

Given the nested object and multiple boolean channels, the description covers the key creation behaviors and even mentions the response's app_url. It doesn't explain error conditions or permissions, but these are not commonly required when the annotation and schema are present, and the description remains complete enough for basic invocation.

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

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

The description enriches the schema by explaining practical semantics: remind_at is 'when to fire', recipient_id defaults to assignees, channel flags have a 'push on by default' and 'at least one must be on' rule, and notify_if_completed is clarified. However, it refers to task_id as a 'path parameter' while the schema nests it under body, which is a minor inconsistency that could confuse the agent.

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 'Schedule a reminder on a task' with a specific verb and resource, distinguishing it from sibling tools like update_reminders or destroy_reminders. It also names key parameters, making the tool's function 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 by specifying parameters and defaults, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. For example, it could say 'use update_reminders to modify an existing reminder' but doesn't, leaving the selection to be inferred from the name.

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

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

Annotations indicate a non-read-only, non-idempotent, non-destructive mutation; the description is consistent. It adds useful context like 'Multiple entries per day are allowed' and explains the kind values, but does not disclose additional side effects, required permissions, or error conditions beyond what annotations imply.

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

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

The description is three sentences, each earning its place. It front-loads the core purpose in the first sentence, details settable parameters in the second, and adds a key constraint (multiple entries per day) in the third. There is no wasted wording.

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

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

For a create tool with no output schema, the description covers the main aspects: purpose, key parameters, kind semantics, optional tasks, and multiplicity. It does not mention return value or prerequisites like the company existing, but given the tool's straightforward nature, it is sufficiently complete.

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

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

Schema description coverage is 0% at the top level, so the description must compensate. It mentions company_id, date_from/date_to, note, and tasks, and clarifies the meaning of kind (plan vs done) and that tasks are optional. However, it does not explain date formats or task ID types, which are left to the nested schema. This adds some value but leaves gaps.

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 the action ('Create a resume entry'), the resource ('for a company'), and the scope (plans or done over a date range). It clearly differentiates from sibling tools like update or destroy by focusing on creation and the kind parameter semantics.

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 logging planned or completed work by a teammate, and notes that multiple entries per day are allowed. However, it does not explicitly state when to use this tool versus alternatives like update_resumeentries or destroy_resumeentries, nor does it provide exclusions or 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?

Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds valuable context: new sprints start in PLANNED state and the response includes an app_url. This goes beyond what annotations provide.

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, impactful, no fluff. The purpose is front-loaded and the behavioral detail about app_url is included efficiently.

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 create tool with no output schema, the description adequately covers core behavior, required inputs, and a key outcome (app_url). It doesn't mention optional params or error handling, but the essential context is present.

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 covers the required parameters (project, name, start/end dates) but omits optional fields like goal, review_notes, planning_notes, and retrospective_notes. Since the schema has 0% description coverage, this is a partial compensation – helpful but not complete.

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 ('Create a sprint') and resource ('for a project'), distinguishing it from sibling tools like start_sprints, update_sprints, and close_sprints. It also adds unique context about the app_url deep link, which is specific to creation.

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

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

The description explicitly lists required inputs (project, name, planned start/end dates) and gives a specific instruction for the result (give app_url to the user). It doesn't mention when to use this vs alternatives, but the context is clear enough for an agent.

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

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

The description adds behavioral details beyond the annotations: it discloses that the author is the authenticated user and that each comment has an app_url deep link. These are not present in the annotations or schema, and they do not contradict the annotations (readOnly=false, destructive=false). It does not cover all possible side effects, but provides meaningful 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?

The description is three sentences, each adding distinct information: purpose, author context, reply behavior, and app_url. It is well-structured and not verbose, though slightly dense. It earns a 4 for being concise without sacrificing key 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?

Given no output schema, the description partially handles the response by mentioning app_url, but it does not describe the full return value, error cases, or prerequisites (e.g., task must exist). It provides enough for basic usage but lacks completeness for a simple create tool with a nested request body.

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 mentions only comment_id and its purpose, but the schema already describes it as 'Optional parent comment id (reply/threading)'. The description does not explain the body structure (text, task_id) or add semantics beyond what the schema already provides. With 0% schema description coverage, the description fails to compensate for the gap.

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 with a specific verb and resource: 'Add a comment to a task'. It also provides a concrete use case ('e.g. a stakeholder update') and distinguishes this tool from siblings like create_ticketcomments by explicitly targeting task 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?

The description gives clear usage context, including that the author is the authenticated user and how to reply to existing comments via comment_id. However, it does not explicitly mention when not to use this tool or suggest alternative tools like list_taskcomments for reading comments, so it stops short of a full 5.

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

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

The description goes beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by explaining concrete behaviors: the successor's planned dates are pushed forward, rejection causes are enumerated, and each dependency returns an app_url deep link. This provides valuable context about side effects and response details, with no contradiction to 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?

The description is four sentences, front-loaded with the main purpose, and every sentence adds essential information (behavior, constraints, return details). No fluff or repetition of schema data.

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

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

For a creation tool with no output schema, the description provides sufficient context: it explains the action, its side effect (pushing dates), error scenarios, and a key return field (app_url). Combined with the detailed input schema and annotations, it gives an agent everything needed to invoke the tool correctly.

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

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

The schema only has a nested 'body' parameter with descriptions on its inner fields but no top-level description. The description compensates by explaining dependency_type values (FS/SS/FF/SF) and the meaning of lag_days (shifts constraint, can be negative), which adds semantic clarity beyond the raw schema. It does not repeat the existing descriptions for successor/predecessor IDs, keeping value high.

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 links two tasks of the same project with a scheduling dependency, using a specific verb (create/link) and resource (task dependencies). It distinguishes itself from sibling tools like destroy_taskdependencies and list_taskdependencies by focusing on creation and by detailing the dependency types and lag behavior.

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

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

The description specifies a key constraint: the two tasks must belong to the same project, and it lists rejection conditions (self-link, cross-project, ancestor/descendant, cycle) that guide when not to use this tool. However, it does not explicitly mention alternatives such as partial_update_taskdependencies for modifying existing dependencies, so it stops short of full when/why-not 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?

Annotations already indicate a mutating, non-idempotent operation. The description adds valuable behavioral context: new tasks are appended and the level is reordered automatically, and every task has an app_url deep link in the response. This goes beyond the structured annotations and helps the agent anticipate side effects and output.

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

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

The description is three sentences and reasonably front-loaded with the core action. The first sentence states purpose, the second lists key parameters, and the third explains behavior and output usage. It earns its length, though the misleading 'Optional: title' phrase could be reworded for precision.

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 (many fields, nested body object, no output schema), the description is not complete enough. It incorrectly labels title as optional, omits numerous optional parameters, and does not clarify that body is a required wrapper object. It does provide helpful app_url guidance, but the inaccuracies and omissions leave significant gaps 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?

Top-level schema description coverage is 0%, so the description must compensate, but it only lists a handful of parameters (project_id, title, description, status, priority, story_points, parent, sprint) and omits many others like order, reach, effort, impact, progress, confidence, date fields, and flags. Worse, it incorrectly states title is optional when the schema marks it required, leading to potential misuse.

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 task', a specific verb and resource, and is distinct from sibling tools like create_projects or create_sprints. However, it inaccurately lists title as optional when the schema requires it inside body, slightly muddying the clarity of what is required to create a 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 gives some usage context: mentioning that parent is for sub-tasks, sprint associates a sprint, and instructing to give the returned app_url to the user instead of describing click paths. But it lacks explicit when-to-use vs alternatives (e.g., create vs update_tasks) and does not mention any exclusions or preconditions beyond requiring project_id.

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 already indicate a non-read-only, non-idempotent write operation. The description adds that the tag becomes available to attach to company tasks, but it does not address potential duplicate tags, validation rules, or authentication requirements.

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

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

The description is brief and front-loaded with the main action, using only 24 words. However, the inaccurate path parameter phrasing is a structural flaw that detracts from clarity, though the length itself is appropriate.

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

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

With no output schema and low schema description coverage, the description needed to clarify parameter structure and behavioral nuances. It instead introduces a path parameter error and does not compensate for the nested body object, leaving invocation ambiguous.

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 misidentifies company_id as a path parameter when the schema expects it within the body object, which could lead to incorrect invocation. It provides some meaning for text but fails to explain the body wrapper structure and gives no additional detail for text 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 uses the specific verb 'Create' and resource 'task tag' with scope 'in a company', clearly stating what the tool does. It distinguishes from sibling tools like add_tag_tasks by noting the tag becomes available for future attachment to tasks.

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 the tool is for creating new task tags but does not explicitly state when to use it versus alternatives. No exclusions or comparisons with sibling tools such as add_tag_tasks or destroy_tasktags 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?

Annotations only indicate the tool is a non-read operation. The description adds valuable behavioral context: default is_internal=true, public comments appear on the customer's ticket page, and app_url is an internal deep link that must not be shared with customers. This goes beyond what annotations alone communicate.

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 yet information-dense. Each sentence adds a distinct value: the action, the default internal nature, how to make a public reply, and caution about app_url. There is no redundancy or filler; structure front-loads the main purpose and then gives operational details.

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

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

For a create operation with one nested parameter object, the description covers the primary behavior, defaults, customer visibility implications, and link usage warnings. It also cross-references another tool for obtaining a public URL. No output schema is present, but for a write operation this level of detail is sufficient and complete.

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

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

The schema shows nested fields (text, is_internal, submission_id) but has minimal descriptions; the description compensates by explaining the semantics of is_internal (default true, how to switch to public). It indirectly clarifies submission_id's role as the ticket identifier, but does not explicitly describe the 'text' field or its optionality, leaving a small gap.

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

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

The description opens with a clear action verb and resource: 'Add a comment to a ticket.' It immediately distinguishes between internal and public comments, making the tool's purpose distinct from sibling read/list or destroy 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?

It explicitly states the default behavior (internal note) and provides the exact condition for using is_internal=false to make a comment visible to customers. It also warns against sharing app_url internally and directs users to public_url from retrieve_ticketsubmissions for customer-facing links, giving both when-to-use and alternative 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?

Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds useful behavioral context by mentioning the optional after_task_id positioning and the app_url deep link instruction for responding to users. However, it does not disclose potential side effects on child tasks or ordering, which would be relevant for an outdent operation.

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

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

The description is two concise sentences, front-loaded with the primary action, then the optional behavior, and finally a practical user-facing instruction. Every word earns its place without unnecessary detail.

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

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

For a simple tool with one required parameter, the description covers the core action and adds a user-response guideline. However, it references after_task_id which is not in the schema, creating a completeness gap. It also does not mention whether the outdent affects subtasks or the resulting order, leaving some behavioral ambiguity. The absence of an output schema makes the app_url instruction valuable, but the schema mismatch detracts from overall 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 schema only documents 'pk' (the task id), and the description does not explain it beyond what the schema already provides. More problematically, the description introduces 'after_task_id' as an optional parameter, but this parameter is absent from the input schema. This mismatch creates ambiguity: an agent would expect to provide after_task_id but cannot find it in the schema. The description fails to compensate for the 0% schema description coverage.

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

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

The description uses the specific verb 'Outdent' and clearly states the resource ('a task') and the effect ('decreases its depth'). It distinguishes this tool from its sibling 'increase_depth_tasks' (indent), and the optional positioning after a sibling adds clarity about its behavior.

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

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

The context is clear: this tool is for outdenting tasks to reduce their depth. It does not explicitly name alternatives or exclusions, but the sibling tools like increase_depth_tasks, move_up_tasks, and reorder_* make the intended usage evident from context. There is no explicit 'when not to use' guidance, so it falls short of a 5.

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

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

Beyond the annotations (destructive=true), the description adds the crucial soft-delete behavior: the record is kept for history but hidden from list_attachments. It also discloses the tenant-scoping restriction. This enriches the annotation data meaningfully.

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, both dense with useful information. The first sentence states the action and its consequence; the second explains the tenant restriction. No fluff or repetition.

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

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

For a two-parameter delete operation with good annotations, the description covers the core behavior (soft-delete), the scope (company membership), and the side effect (disappears from list). No output schema is present, but the description does not need to detail return values for a simple 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?

The schema already provides descriptions for both parameters (company_id and pk). The description reinforces the meaning of company_id by emphasizing company membership and scoping. It doesn't add new parameter syntax, but the schema coverage is high, so the baseline is 3 and the added scoping context raises it.

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

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

The description opens with the specific verb 'soft-delete' and the resource 'attachment', immediately clarifying the action. It also distinguishes this tool from related list/retrieve tools by stating the record 'disappears from list_attachments' and that deletion is scoped to the company.

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

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

The description gives clear context: the tool is for deleting attachments you own within a company you belong to, and it cannot delete another tenant's attachments. It implies when to use it, though it does not explicitly name alternative tools or say 'use this instead of X'.

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 directly contradicts the destructiveHint=true annotation by stating this is a soft-archive, not a hard delete, and can be restored later. This is a clear contradiction, so the score is 1 regardless of other useful details.

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, front-loaded with the most important behavior (soft-archive not hard-delete), and contains no fluff. It is concise and well-structured.

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 the behavior is described well (soft-archive, restorable, drops out of default list), the description omits return values, prerequisites, and parameter details. Additionally, the annotation contradiction undermines the overall completeness for a mutation 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 description coverage is 0% per the context, and the description does not explain the meaning of company_id or pk beyond what the schema already states. The description adds no parameter-specific guidance, failing to compensate for the lack of coverage.

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

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

The description clearly states the tool soft-archives a project by setting is_archivied=true, using a specific verb and resource. It distinguishes itself from hard deletion, making its purpose 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?

It provides clear context on when to use it (when you want to preserve history and allow restoration) and contrasts with hard-deleting. However, it does not explicitly name alternative tools or state 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 already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds the 'from a task' relationship, which is useful context, but it does not disclose consequences like permanence or error handling for nonexistent reminders.

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

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

The description is a single, direct sentence with no filler or redundancy. It is front-loaded with the action and resource, making it easy to parse quickly.

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

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

For a simple delete tool with annotations and a detailed schema, the description is adequate but minimal. It lacks any usage context, behavioral details beyond the core action, or guidance on edge cases. However, it is sufficient for basic invocation when combined with the schema and annotations.

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

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

The description itself mentions no parameters, but the input schema provides descriptions for both task_id ('ID of the task the reminder belongs to') and pk ('The id of the reminder'). Thus the schema carries the semantic burden, and the description adds no extra meaning, resulting in a baseline score of 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 tool's action: 'Delete a reminder from a task.' It specifies the verb (delete), the resource (reminder), and the context (from a task), which distinguishes it from sibling tools like update_reminders or retrieve_reminders.

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 like partial_update_reminders or update_reminders. It does not mention prerequisites, exclusions, or scenarios where another tool would be more appropriate.

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?

Even though annotations already include destructiveHint=true, the description adds crucial context: it reveals the exact mechanism (`is_deleted=true`), confirms data retention, and explains list behavior. This is valuable because 'destroy' often implies permanent deletion, and the description corrects that assumption. It also adds a requirement (`company_id`), though it mislabels it as a path parameter when the schema shows it in the body.

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, front-loads the most critical information (soft delete, retention), and avoids redundancy. Every piece of text serves a distinct purpose: defining the action, explaining the mechanism, listing consequences, and noting a prerequisite.

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

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

For a low-complexity delete tool, this covers behavior, side effects, and a prerequisite. It doesn't describe return values, but with no output schema and simple semantics, that's acceptable. The only minor gap is not explaining what happens to related data or whether the operation is reversible, but it's not strictly 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?

With 0% schema description coverage, the description needs to compensate. It does mention `company_id`, which adds value, but completely omits the `pk` parameter from the description. Additionally, it incorrectly refers to `company_id` as a 'path parameter' when the schema indicates it's in the body. Partial compensation with room for improvement.

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: it soft-deletes a resume entry by setting `is_deleted=true`. The specific verb 'soft-removes' plus the resource 'resume entry' provides clarity that can't be mistaken for other operations, distinguishing this from hard-delete or update 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?

By explaining that the row is retained and 'drops out of subsequent lists,' the description implies this is the soft-delete alternative to a full delete. It could more explicitly say 'use this instead of define to keep the row,' but the context makes the use case clear. A slight deduction for not naming an alternative tool or giving when-not-to-use scenarios.

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 already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context that non-PLANNED sprints return a conflict and must be closed. This goes beyond the annotations by specifying the state-dependent behavior. It doesn't detail auth requirements or the exact conflict format, but the added behavioral info justifies a 4.

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-loaded with the core action, and every word adds value. There is no redundancy or irrelevant detail. It is a model of 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?

For a low-complexity tool with one parameter and no output schema, the description covers the essential context: the action, the constraint on sprint states, and the conflict behavior. It could mention what a successful deletion returns or what 'conflict' means in HTTP terms, but given the presence of destructiveHint and the simplicity of the operation, the description is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. However, the description does not mention the required 'pk' parameter at all. The schema only provides a generic 'pk' description with no context about how to identify a sprint. Since the description fails to clarify the parameter's role in selecting the sprint, a score of 2 is appropriate.

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

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

The description starts with 'Delete a sprint', which is a specific verb+resource. It further clarifies that only PLANNED sprints can be deleted, distinguishing it from close_sprints and other sprint operations. This makes the purpose unmistakable.

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

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

The description explicitly states when to use the tool: 'Only PLANNED sprints can be deleted; ACTIVE or CLOSED sprints return a conflict and must be closed instead.' This directly names the alternative action (closing) for other sprint states, providing clear usage 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?

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds the crucial behavior that this is a soft delete—the comment stops appearing but is not permanently removed. This provides reversibility context that annotations alone do not convey.

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, well-structured sentence that front-loads the key action ('Soft-delete') and its effect. Every word contributes to clarity, 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?

The description adequately covers the core action and the soft-delete behavior. The schema handles parameter details and annotations cover idempotency. The lack of an output schema means return values are not expected, so this is sufficiently complete for the 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?

With schema description coverage at 0%, the tool description does not compensate for parameters. It does not mention task_id or pk, leaving the agent to rely solely on the schema's own descriptions. This is a significant gap for a two-parameter nested 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 'Soft-delete (hide) a comment on a task', using a specific verb and resource. It distinguishes itself from permanent deletion and sibling tools like destroy_tasks or destroy_ticketcomments by explicitly mentioning 'task' and the soft-delete nature.

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 conveys when to use this tool: to hide a comment without permanently removing it. It implies a soft-delete context but does not explicitly name alternatives or scenarios where a hard delete would be appropriate, so no exclusions are stated.

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

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

The description discloses a key side effect: 'Does not move any dates back — previously pushed-forward planned dates on the successor are left as-is.' This adds behavioral insight beyond the annotations, though it does not mention all potential consequences (e.g., cascading effects on tasks).

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 to the point, consisting of two sentences with no redundant information. It effectively communicates the purpose and a critical side effect without unnecessary elaboration.

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 action and a notable behavioral effect. It does not describe return values or error conditions, but given that this is a destroy operation and no output schema exists, the description is adequately complete for typical usage.

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 provides no additional meaning for the parameters (company_id, project_id, pk). The schema already gives descriptions, so the description adds no semantic value beyond what is already coded. Since schema coverage is complete, the baseline score of 3 is appropriate.

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

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

The description clearly states the action: removing a scheduling dependency between two tasks of a project. The verb 'Remove' and the specific resource 'scheduling dependency' make the purpose unambiguous, and it distinguishes itself from other destroy 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 does not explicitly state when to use this tool versus alternative operations (e.g., update_taskdependencies). However, it is implicitly clear that it is for removing dependencies, but no conditions or exclusions 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?

Beyond the annotations (destructiveHint, idempotentHint), the description adds crucial context: the soft-delete nature, exclusion from lists, row retention, and that descendants are not auto-promoted. This fully informs the agent of 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?

Two tight sentences, front-loaded with the core action, and no redundant or unnecessary words. Every phrase 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?

For a one-parameter delete tool with strong annotations, the description is largely complete. It explains side effects and hierarchy behavior, though it omits return format and permission requirements, which are less critical given the output schema absence.

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

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

Schema description coverage is 0%, and the description does not explain the single 'pk' parameter or the 'kwargs' wrapper. The schema only provides 'The id of the task,' so the description adds no value for parameter understanding.

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

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

The description states a specific verb (soft-deletes) and resource (task), and clearly distinguishes from a hard delete by noting row retention. It also differentiates from sibling destroy_* tools by targeting tasks specifically.

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

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

The description implies when to use this tool (when you want to remove a task from lists but keep history) but does not explicitly state alternatives or exclusions. There is no mention of when not to use it, such as for permanent 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?

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds valuable context by specifying that tasks referencing the tag lose the association. This goes beyond the annotation hints and does not contradict them.

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

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

Two short sentences front-load the action and then state the impact, with no filler or repetition. Every clause contributes 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 the core purpose and a meaningful side effect, and the annotations provide destructive and idempotency hints. However, it omits usage exclusions and leaves the placement of company_id ambiguous relative to the schema (path vs body), making it minimally sufficient but not fully complete.

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

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

The description mentions company_id as a path parameter and refers to 'the tag', but does not explain that kwargs.pk is the tag ID or how body/kwargs are structured. With schema description coverage at 0%, the description fails to compensate for missing parameter 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 uses a specific verb ('Delete') and resource ('task tag') and clarifies scope ('from a company'). It also distinguishes itself from sibling tools like remove_tag_tasks by stating the consequence that tasks referencing the tag lose the association.

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 state when to use this tool versus alternatives such as partial_update_tasktags or remove_tag_tasks. Usage is only implied by the delete verb and the consequence statement, with no explicit exclusions or alternative 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?

Beyond the annotations (readOnlyHint: false, destructiveHint: true, idempotentHint: true), the description adds valuable context by specifying that the comment is hidden but not permanently removed. This clarifies the exact effect on the thread and the reversible nature of the deletion. It does not describe return values or permissions, but with annotations present, it provides sufficient extra behavior.

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

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

The description is a single, well-structured sentence that conveys the essential behavior with no wasted words. It front-loads the key verb and resource, then clarifies the nuance, making it highly concise and readable.

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

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

Given the tool's moderate complexity (2 parameters, no output schema) and the presence of annotations, the description covers the most important contextual aspect: the effect of the operation (soft-delete, hide but not permanent). It could mention reversibility or prerequisites, but the combination of annotations and schema fills the gap adequately, making it complete enough for an 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?

The tool description does not mention parameters at all, but the input schema provides clear descriptions for both `submission_id` ('ID of the ticket submission') and `pk` ('The id of the ticketcomment'). Therefore, the schema itself handles parameter semantics, and the description adds nothing beyond that, aligning with the baseline 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Soft-delete (hide) a comment on a ticket; it stops appearing in the thread but is not permanently removed.' It uses a specific verb ('soft-delete'), identifies the resource (comment on a ticket), and distinguishes this from a permanent delete, making its function 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 gives clear context by explaining that this is a soft delete and not a permanent removal, which implies when it should be used (when hiding is sufficient) and when it should not (when permanent deletion is intended). However, it does not explicitly name alternative tools or provide exclusions, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description is consistent with a mutating operation. The description adds a note about app_url deep links and instructs to give them to the user, which is a useful behavioral hint. However, it does not disclose other behavioral traits such as prerequisites, side effects, or error conditions, and the phantom parameter reference further clouds 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 concise, only two sentences, with the main purpose front-loaded. The second sentence about app_url is slightly tangential but is a useful instruction for user interaction. However, the incorrect parameter reference detracts from the overall structural clarity.

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 no output schema, and the description does not explain return values or side effects. It also fails to clarify how 'new_parent_id' should be supplied (since it is not in the schema), leaving the agent confused about the execution. The app_url instruction adds some context but does not address the core invocation requirements.

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% for the actual parameters. The description instructs to pass 'new_parent_id', which does not exist in the input schema (only 'pk' is required). This actively misleads the agent about the required inputs, and no explanation of the real parameter 'pk' is provided. The description fails to compensate for the schema's minimal documentation.

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 'Indent' and the resource 'task', and explicitly explains the result: 'becomes a child of another task (increases its depth)'. The example 'turn a sibling into a sub-task' provides a concrete scenario, and the sibling tool name 'decrease_depth_tasks' reinforces the distinction.

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

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

The description gives a concrete use case ('turn a sibling into a sub-task') and instructs to 'Pass new_parent_id', which suggests when and how to use it. However, it does not explicitly mention alternatives or exclusions, and the referenced parameter 'new_parent_id' is not present in the input schema, making the guidance misleading.

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 already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context beyond annotations, such as the cross-task scope, filter options, and that each reminder includes an app_url deep link. It does not disclose pagination or default ordering, but the schema covers pagination fields.

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

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

The description is three sentences long, each carrying substantial information: purpose, filters, differentiation, and output note. It is concise and front-loaded with the core purpose, 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?

The tool is a list operation with no output schema, but the description mentions an important output field (app_url) and the key filtering capabilities. The schema provides pagination details, so the description covers enough context for correct usage. However, it does not mention default ordering or pagination behavior, though these are less critical given the schema.

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

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

The input schema already describes most parameters (e.g., page, page_size, date formats), but the description adds semantic meaning by explaining that remind_at filters are available with __date, __gte, __lte and is_sent is a filter. The example 'what fires today' clarifies a typical use of the __date parameter, going beyond the schema's basic format descriptions.

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

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

The description clearly states the tool lists reminders across all of the user's tasks, using a specific verb and resource. It explicitly distinguishes itself from the sibling list_reminders by noting it is not scoped to one task, making its purpose 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 explains when to use this tool: when you need reminders across all tasks, and contrasts it with list_reminders for task-specific queries. It also indicates filterable fields, giving practical guidance for typical use cases like 'what fires today'.

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 already mark this as read-only/idempotent, but the description adds critical behavior: signed URLs expire after 15 minutes, `app_url` is null for company-level attachments, and attachments can be files or links distinguished by `kind`. It also clarifies that retrieve_attachments is unnecessary for getting links, which is a useful operational detail.

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 dense but every sentence adds value: purpose, attachment types, URL expiry, no-need-for-retrieve, alternative tools, filtering, and app_url behavior. It is front-loaded with the main purpose and wastes no 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?

Without an output schema, the description sufficiently explains the return concept (list of attachments with url, kind, app_url) and how it maps to other tools. It gives the agent enough context to invoke correctly, including edge cases like company-level attachments and signed link expiry.

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 must carry the load. It explains `company_id`, `project_id`, and `project_id__isnull` with real-world meaning, but omits `file_name__icontains` and pagination parameters (`page`, `page_size`). Some parameter semantics are covered, but not all.

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 attachments for a company or project, with a specific verb ('List what is attached') and resource scope. It also distinguishes from sibling tools like retrieve_attachments, read_attachments, and list_taskattachments by explaining what this tool is for (browsing) versus others.

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 explicit guidance: browse the list to decide what to open, use the row's `url` directly (no need for retrieve_attachments), and names alternative tools for creation/destruction/reading. It also explains filtering with `project_id` and `project_id__isnull` for company-level vs project-level attachments.

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 already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds that it supports search and pagination, which is useful, but does not detail how these are invoked or what format results take. Given the annotations, the description adds moderate extra value.

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: the first delivers the core purpose and domain context, the second mentions features. It is front-loaded, has no redundant content, and 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?

For a simple listing tool with read-only annotations, the description covers the purpose, the meaning of 'company', and notes search/pagination. It does not need to explain return format since it is a standard list, and annotations cover safety. It is sufficiently complete for an agent to select and call it.

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

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

There are zero parameters, and the schema is empty. The baseline for 0 params is 4, but the description only mentions 'search' and 'pagination' without naming parameters or formats. This adds some semantics but is not specific enough to guide invocation, so a score of 3 is appropriate.

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

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

The description clearly states the tool's function: listing companies the authenticated user belongs to. It also defines what a company is, distinguishing it from other entities. This is specific and distinct from sibling tools like retrieve_companies, which likely fetches a single company.

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 (to list companies) but does not explicitly contrast it with alternatives like retrieve_companies or other list tools. It provides context about the hierarchy but lacks explicit when/when-not 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?

Annotations already mark this as a safe read-only, idempotent operation. The description adds meaningful behavioral detail beyond that: archived projects are excluded unless include_archived=true, the timeline is plan-gated, and each project includes an app_url. No contradiction with annotations exists.

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

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

The description is front-loaded with purpose and key parameters, but the final three sentences about app_url, shared view URLs, and plan-gated timeline add contextual detail that is not directly necessary for invoking the tool. It is compact but contains some tangential information.

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

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

For a read-only list tool with no output schema, the description covers the required company_id, filtering flags, pagination hints through schema, and even return-value context (app_url). It is missing a full statement of what the response object contains, but the rest of the context is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains company_id, include_archived, and filtering by id/title/description, which clarifies the tersely named icontains fields. It does not explain page/page_size semantics, but those already have schema descriptions, and 'search' is mentioned without a matching schema property.

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

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

The description opens with a specific verb and resource: 'List the projects of a company.' It clearly distinguishes this listing tool from siblings like retrieve_projects by describing collection-level behavior, filtering, and archived-project exclusion.

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

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

It provides clear context for when to call the tool: listing a company's projects, requiring company_id, excluding archived by default, and supporting filters. It does not explicitly state when to prefer a sibling such as retrieve_projects, so it falls just short of full alternative 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?

Annotations already declare readOnly and idempotent, so the description adds value by disclosing the ordering, returned fields (including whether sent), and the app_url deep link. This goes beyond the structured annotations and gives practical 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?

The description is two sentences, front-loaded with the primary action, and every clause adds relevant detail (ordering, fields, deep link). There is no redundancy or 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 simple read-only list tool with one parameter and no output schema, the description covers the essential return semantics and ordering. It is slightly incomplete because of the path/body confusion and lack of mention of list_all_reminders, but overall it provides enough context for correct use in most scenarios.

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 refers to task_id as a 'path parameter', but the schema shows it inside the required body object, a factual mismatch that could mislead an agent. It adds no extra meaning beyond the schema's own description of the parameter.

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

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

The description states a specific action ('List'), resource ('reminders of a task'), and scope (task_id), clearly distinguishing it from the sibling 'list_all_reminders'. It also mentions ordering by scheduled time, which further clarifies its 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?

Usage is implied by 'of a task', indicating this is for a specific task's reminders. However, it does not explicitly contrast with list_all_reminders or provide when-not-to-use guidance, leaving selection partly to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the filter capabilities and the use case, but does not detail pagination behavior or return format, which is acceptable given the 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?

The description is two sentences, front-loaded with the main purpose and filters, and includes the use case. 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 has 1 parameter (body) with many nested properties, the description covers the main filters and use case. It does not explain the comparison operators, but those are advanced and the schema provides titles. The output schema is absent, but the description does not need to explain return values. Overall, it is complete enough for a listing tool with good annotations.

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

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

Schema description coverage is 0%, but the description lists the key filter parameters (kind, date range, user_id) and explains their purpose. However, it does not explain the comparison operators (date_from__gt, etc.) or the page/page_size parameters, which are self-explanatory from the schema. The description adds some value but does not fully compensate for the lack of schema descriptions.

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

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

The description clearly states the tool lists resume entries (daily or range plan/done notes) for a company, with specific filter options. It distinguishes itself from sibling tools like create_resumeentries and retrieve_resumeentries by focusing on listing with filters.

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 it is used for stand-ups and daily planning, providing context for when to use it. It does not explicitly exclude alternatives, but the filter options and purpose make it clear this is the listing tool for resume entries.

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 already declare readOnlyHint and idempotentHint, establishing a safe read operation. The description adds useful behavioral context: the auto-backfill of missing lanes for tasks already in the sprint and the notion of a kanban board. It does not contradict the annotations, and it gives insight beyond the structured fields.

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

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

The description is three short sentences, each earning its place: the first states the verb and resource, the second explains scoping and a notable behavior, the third provides a helpful metaphor. It is front-loaded with the essential information and contains 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?

The description covers the core purpose and sprint_id scoping, and the annotations cover safety, reducing the burden. However, it leaves a meaningful gap: since `sprint_id` is optional in the schema, the agent is not told what happens if it is omitted, nor is the `task_id` filter mentioned. Without an output schema, a bit more on return shape or default behavior would improve 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 schema has a single `body` parameter with nested optional fields, but top-level schema description coverage is 0%. The description explains only `sprint_id` (to scope the list) and does not mention `task_id`, `page`, or `page_size`. This leaves the agent to infer or guess the meaning of these parameters, especially `task_id`, which has no schema description either.

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') and resource ('board lanes of a sprint'), and the parenthetical '(task placements in columns)' plus 'This is the sprint kanban board' distinguishes it from sibling list tools like list_sprints or list_tasks. The core purpose is 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 gives explicit usage guidance by instructing to pass `sprint_id` to scope to one sprint. It lacks an explicit alternative comparison (e.g., versus retrieve_sprint_lanes) or what happens without sprint_id, but the context is clear enough for most selection scenarios.

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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context: the data scope (companies the user belongs to) and the presence of app_url with a direct instruction to give it to the user instead of navigation instructions. This goes beyond the annotations and helps the agent understand behavioral expectations.

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

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

The description is three sentences, front-loaded with the primary purpose, followed by a usage tip and an actionable instruction about app_url. Every sentence adds value with no redundancy or filler.

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

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

For a list tool with readOnly and idempotent annotations, the description covers the main purpose, filtering, and a key output field (app_url). It does not mention pagination defaults or other fields, but the lack of an output schema and the simplicity of the use case allow this level of detail to be sufficient. The scope and the deep-link behavior add completeness beyond bare listing.

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

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

The schema already includes descriptions for page, page_size, and date formats, but the description adds meaning for the state filter (PLANNED|ACTIVE|CLOSED) and the ability to order by start/end date. The schema coverage signal is 0% for the top-level body parameter, but the inner properties have some descriptions. The description does not explain the date range suffixes (_gte, _lte) or the ordering mechanism in detail, so it partially compensates for the coverage gap.

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

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

The description states exactly what the tool does: 'List sprints for projects in the companies the user belongs to.' It specifies the resource (sprints), the scope (projects in the user's companies), and supports filtering by state and ordering. This clearly distinguishes it from sibling tools like retrieve_sprints (single sprint) and list_sprint_lanes.

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 concrete use case: 'Use it to find a project's active sprint.' It does not explicitly mention alternatives or when not to use it, but the specific use case and the context of sibling tools (e.g., retrieve_sprints for a single sprint) imply the right scenarios. This is clear context without explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds useful behavioral context: the returned fields (name, size, url) and that each attachment includes an app_url deep link to the task's drawer. This goes beyond the annotations and helps the agent anticipate output, though it does not mention pagination or ordering. Score 4 is appropriate because it complements rather than contradicts 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?

The description is three sentences, each informative: purpose, alternative upload method, and output detail (app_url). No wasted words, front-loaded with the core function. It is appropriately concise while covering essential aspects.

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 read-only list tool with one parameter and no output schema, the description is sufficiently complete. It specifies the output fields (name, size, url) and highlights the app_url deep link. It does not mention pagination or limits, but given the low complexity and the annotations, this is not a significant gap. A 4 reflects that it might need a small note on ordering or limits but is already solid.

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 task_id is explicitly described in the schema ('ID of the task the attachments belong to'), so schema coverage is effectively high (the signal says 0% but that likely refers to description coverage, not schema). The description does not add any additional parameter semantics, so the baseline of 3 applies: the schema carries the burden and the description adds nothing beyond it.

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

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

The description clearly states the action: 'List the files attached to a task' with the specific returned fields (name, size, url). It distinguishes this from sibling tools like list_attachments (which likely lists all attachments) and retrieve_taskattachments (singular), and it provides an example use case. The verb 'list' and resource 'task attachments' are explicit.

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

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

The description gives a concrete usage scenario ('e.g. customer context on a ticket') and mentions an alternative approach for attaching files via request_taskattachment_upload, which helps the agent decide when to use this tool for reading vs. writing. It does not explicitly state when not to use it or contrast with list_attachments or retrieve_taskattachments, but the guidance is sufficient for typical selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the return format (each comment has app_url, a deep link), but does not disclose other behaviors like ordering or potential pagination. This goes slightly beyond annotations without being rich.

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

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

The description is two sentences long, front-loaded with the core purpose, and the second sentence adds a relevant detail about the return format. Every word earns its place with no redundancy 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?

With only one parameter and no output schema, the description is reasonably complete for a simple read tool, but it omits some useful context such as whether the response is a list, if results are ordered, and how it differs from retrieve_taskcomments. The mention of app_url gives partial return-value information, but not a full picture.

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

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

Schema description coverage is 0%, so the description needs to compensate for the under-documented task_id parameter. It mentions 'of a task' but does not explain how task_id is used or what values are valid. The inherent meaning of 'task_id' in the schema is minimal, so the description adds little over 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 states the tool's purpose as returning 'the comment thread of a task', which identifies the resource (task comments) and implies a listing operation. It distinguishes from sibling tools like list_ticketcomments and list_taskattachments by specifying 'task' and 'comment thread', though it does not explicitly say 'list all 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?

No guidance is provided on when to use this tool versus alternatives such as retrieve_taskcomments (likely fetching a single comment). The description implies usage via 'of a task' but offers no exclusions or explicit context for selection.

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

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: each link contains `predecessor`, `successor`, `dependency_type`, `lag_days`, and an `app_url` deep link to the successor's drawer. It also clarifies the bidirectional task filter 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 dense but well-organized and front-loaded with the main purpose, and every sentence adds useful information about scope, filtering, or result contents. It avoids fluff and is appropriately sized for a listing 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?

In the absence of an output schema, the description lists the key fields returned and explains the deep-link behavior. It is mostly complete for a read-only listing tool, though it could explicitly mention pagination behavior and the fact that the schema declares no required parameters.

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 schema description coverage at 0%, the description carries the burden of explaining parameters. It usefully identifies `company_id`/`project_id` as path params and explains the semantics of `task`, but it does not explain `page` or `page_size` behavior in any detail, nor does it clarify that no parameters are required at the schema level.

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

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

The description opens with a specific verb, 'List the scheduling dependencies of a project', and names the scoping parameters (`company_id` + `project_id`). This clearly distinguishes it from sibling tools like `create_taskdependencies`, `destroy_taskdependencies`, and `retrieve_taskdependencies`.

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

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

It explains when to use the `task` parameter: to get only links touching that task, on either side, including both blocking and dependent links. It does not explicitly compare against `retrieve_taskdependencies` for fetching a single dependency, but the filter guidance is clear and useful.

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 already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: pagination, ordering by board position, and that every task includes an app_url deep link to give to the user. It does not describe response shape or rate limits, but for a read-only list tool this is adequate. 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 long but dense with useful information. It front-loads the core purpose and then logically groups filters (tickets, plan-my-day, assignments, etc.). Every clause contributes value, though it could be slightly more organized with bullet points. Overall, the length is justified by the tool's complexity.

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 large number of parameters, lack of output schema, and minimal schema descriptions, the description covers major use cases well: ticket filtering, plan-my-day date ranges, milestone/priority/tag/assignee filters, and the helpful app_url deep link. It does not explain all parameters or response structure, but for a list tool this is strong contextual coverage.

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

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

The schema has ~40 parameters with almost no descriptions (0% coverage). The description compensates by explaining key filters (project_id, sprint, sprint__isnull, parent_id, is_completed, depth, search, title__icontains, description__icontains, has_ticket, status, date/time filters). It does not cover every parameter (e.g., progress, importance, story_points, assigned_to_me), but it explains the most important ones and the __gte/__lte/__isnull conventions.

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 tasks the user can access', providing a specific verb and resource. It immediately distinguishes itself from sibling tools like list_projects and list_sprints by noting 'Rich filtering' and detailing the many filter options, making its purpose 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 explicitly names alternative tools for mutations ('To assign/change status/tag a ticket use the task tools (task_assign_user, partial_update_tasks, add_tag_tasks)') and provides concrete use cases with filter suggestions, such as "Open tickets" and "Plan-my-day". This tells the agent when to use this tool versus 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?

Read-only and idempotent behavior is already provided by annotations, and the description adds the company scoping constraint. However, it does not disclose other behaviors like pagination or ordering, so the additional context beyond annotations is 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 two concise sentences that state purpose and scoping without any redundancy or irrelevant detail.

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

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

For a simple list operation with one parameter and no output schema, the description is complete. It explains what task tags are and how they are scoped, which is sufficient for an agent to select and invoke the 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 description coverage is 0%, but the description mentions company_id as the scoping parameter. It does not explain the body wrapper or value type beyond what the schema already contains, providing only marginal added 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 the tool lists task tags for a company, using the verb 'List' and specifying the resource. It distinguishes itself from create/retrieve tag tools by mentioning company scoping.

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 company-scoped context implies when to use this tool (to get all tags for a company), but there is no explicit comparison to alternatives like retrieve_tasktags or list_tasks. The usage guidance is implicit rather than explicit.

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

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

The annotations already declare readOnlyHint and idempotentHint true, so the safety profile is covered. The description adds useful behavioral context: the comments are returned oldest first, and each comment contains an internal deep link that should not be shared with customers, pointing to public_url for customer-facing use. This goes beyond the annotations without contradicting them.

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-loaded with the main purpose, and every word earns its place. The caution about app_url is concise and necessary.

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

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

For a straightforward list tool with one parameter and rich annotations, the description is mostly complete. It explains the ordering, the content of each comment, and a critical security caveat. It doesn't outline the return format, but no output schema is provided, and the title implies a list.

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

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

The description does not mention the submission_id parameter or explain its format/role beyond referring to 'a ticket submission.' With schema description coverage at 0%, the description fails to compensate, though the schema itself does describe the parameter as 'ID of the ticket submission.'

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

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

The description states that the tool returns the comment thread of a ticket submission, ordered oldest first. This is a clear enough purpose, though it doesn't explicitly use the verb 'list' or differentiate from retrieve_ticketcomments beyond implying a collection.

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 explicit guidance on when to use this tool versus alternatives like list_taskcomments or retrieve_ticketcomments. The only usage-related note is about not sharing app_url with customers, which is more of a behavioral warning than a selection guideline.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the search capability across fields, but it omits return format and falsely describes the parameter location. The mention of 'search' without the schema containing it further undermines trust in the description's accuracy.

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

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

The description is two sentences with the core purpose front-loaded. The second sentence packs a long list of search fields but remains reasonably compact and contains no filler. It earns a high score for efficiency, though the long list could be trimmed slightly.

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

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

There is no output schema, so the description should explain return values or list contents; it does not. It also fails to clarify how to pass the search parameter (query string vs. body) and misstates the company_id parameter location. With a nested body schema, this description leaves important gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions company_id and a search parameter, but search is not present in the schema, and company_id is called a path parameter while the schema defines it inside the required body object. This creates confusion rather than clarification, making it impossible for an agent to correctly construct the request based on this description.

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 the users who are members of a company' with a specific verb and resource. It further distinguishes the tool by adding the use case of resolving a name to a user_id before assigning a task, which sets it apart from sibling list/retrieve 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 provides an explicit use case ('use it to resolve a person's name to a user_id before assigning a task'), which helps with when to use. However, it does not mention alternatives or when not to use it, and it incorrectly identifies company_id as a path parameter when the schema places it in the request body, potentially misleading invocation.

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 already indicate it is a non-read-only, non-idempotent, non-destructive mutation. The description adds the behavioral detail of swapping order with the task below it, which is beyond the annotations. The note about no request body is useful though slightly confusing relative to the schema, and the app_url tip adds response-handling 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?

The description is brief and front-loaded with the core action. The extra sentence about no request body and the app_url tip are useful and concise, with no redundant or filler content.

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

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

For a simple reorder operation with annotations covering the mutation profile, the description explains the behavior and offers a response-handling tip. However, it does not mention edge cases like behavior when the task is already the last sibling, or explicitly link to sibling alternatives, leaving a small but notable gap.

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

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

Schema description coverage is 0%, so the description needs to compensate. It mentions 'a task' but does not explicitly explain the 'pk' parameter or how to identify the task. The schema itself only says 'The id of the task,' and the description adds little beyond the obvious target, so it only partially compensates.

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

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

The description clearly states the specific action: moving a task one position down among siblings (same parent) and swapping with the task below. This unambiguously distinguishes it from move_up_tasks, reorder_children_tasks, and other sibling reorder 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?

Provides clear context that the operation targets a task within its sibling group, implying a single-step downward move. It does not explicitly name alternatives or state when not to use it, but the scoping to siblings provides sufficient situational 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 the reordering effect (shifting siblings), the constraint (same parent/project), and the app_url output handling. Annotations are minimal (false/false/false), so this extra context is valuable. No contradictions with 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?

The description is three sentences, each with a distinct purpose: core action, parameter usage, and output handling. No fluff, well-structured 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 no output schema, the description includes the essential app_url deep-link instruction. It doesn't detail return format or error cases, but for a reorder tool with this complexity, the coverage is 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 explains related_task_id as a sibling and direction as before/after, adding meaning over the schema. However, it doesn't explicitly map the pk parameter to the task being moved, leaving a slight gap in parameter semantics.

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

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

The description clearly states the tool places a task immediately before or after a sibling, shifting other siblings. This specific verb+resource+relative positioning distinguishes it from sibling tools like move_up_tasks or move_to_project_tasks.

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

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

Provides clear usage context by stating the prerequisite that both tasks must share the same parent and project, and instructs to pass related_task_id and direction. However, it doesn't explicitly contrast with alternative reorder tools or state 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?

Adds meaningful behavioral constraints beyond annotations: the target column must belong to the lane's sprint project, null parks in synthetic 'Incoming', and closed sprints are prohibited. No contradiction with readOnly/destructive hints since this is a write 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 sentences, fully front-loaded with the main action, and every clause carries necessary information. No filler or repeated schema details beyond the key context.

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 parameters, no output schema, and nested body, the description fully covers the input semantics, edge cases (null), and constraints (closed sprints). There is no missing important information for selecting/invoking the tool.

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

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

The schema itself provides descriptions for both parameters, and the description reinforces the meaning of project_task_status_id, specifically the null behavior and ownership requirement. Adds value by explaining the semantic relationship between param and project.

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 'Move' and the resource 'sprint board lane (a task)' to a 'different board column'. It distinguishes from siblings like move_to_project_tasks by focusing on sprint lanes specifically, and clarifies the lane is a 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?

Provides clear usage context: pass project_task_status_id for a target column or null for 'Incoming', and notes closed sprints cannot be moved. Does not explicitly name alternative tools, but the when-to-use is clearly implied by the resource and action.

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?

While annotations already indicate this is not read-only, the description adds non-obvious behavioral constraints: the task cannot already be in the target project, and the user must be a member. It also provides a practical note about app_url, which helps the agent guide the end user. No contradiction with 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?

The description is three sentences long, front-loaded with the core purpose, and every sentence adds meaningful detail. It is concise and well-structured without unnecessary 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 mutating tool with no output schema and only basic annotations, the description covers the essential preconditions and even provides an actionable tip about app_url. It lacks explicit return-value information, but the core usage is sufficiently well-specified for an agent to invoke 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 description explains the meaning of project_id and company_id, including their relationship and membership requirements, which goes beyond simple parameter names. However, it omits any handling of the `pk` parameter (task id), and since schema description coverage is listed as 0%, the description does not fully compensate for all parameters.

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 'Move a task to a different project (and company)', using a specific verb and resource. This distinguishes it from sibling tools like move_to_sprint_tasks or move_relate_to_tasks.

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

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

The description provides clear context for when to use the tool by stating required conditions ('target project must belong to that company', 'user must be a member', 'task cannot already be in the target project'). It does not explicitly mention alternatives or exclusions, but the context strongly implies it is for cross-project moves.

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 adds valuable behavioral details beyond annotations: it explains that descendants move automatically, closed sprints are rejected, and the return values are moved_count and affected_ids. Since annotations are neutral (all false), the description carries the transparency burden and does so effectively.

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

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

The description is three sentences, front-loaded with the core action, and every sentence adds useful information: scope, parameter meaning, constraints, and return values. No fluff or repetition.

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

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

Given the tool's simplicity (one nested parameter, no output schema), the description covers all essential aspects: what it does, parameter semantics, constraints, and return values. It is complete enough for an agent to invoke the tool correctly without additional information.

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 schema description coverage at 0% (top-level body param lacks description), the tool description compensates fully by explaining task_ids (non-empty, same project) and sprint_id (null = backlog). It adds constraints not present in the schema (same project, non-empty), making parameter semantics extremely clear.

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 moves tasks into a sprint or back to the backlog, with the verb 'move' and specific resource 'tasks' plus 'sprint'. It distinguishes from sibling tools like move_to_project_tasks by explicitly mentioning sprint/backlog context and descendant behavior.

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

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

The description provides clear context for when to use this tool (moving tasks to a sprint or backlog) and includes a constraint (closed sprints rejected). It doesn't explicitly compare with alternatives, but the sprint-specific context naturally differentiates it from move_to_project_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?

Annotations already indicate this is a mutating (readOnly=false), non-idempotent, non-destructive operation. The description adds valuable behavioral context beyond annotations: it specifies the swap ordering, states no request body is needed, and instructs to return the app_url deep link to the user instead of describing UI clicks. This exceeds the baseline set by annotations alone.

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, front-loaded with the primary action, and every clause earns its place. The app_url instruction is a concrete actionable directive rather than filler.

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

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

For a tool with one parameter, no output schema, and clear annotations, the description covers the essential behavior, scope (siblings), input requirement (no body), and user-facing output handling (app_url). It does not mention edge cases like what happens if the task is already first, but the core information is sufficient for correct invocations.

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

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

Schema description coverage is 0%, and the description does not mention the 'pk' parameter or the 'kwargs' wrapper at all. The tool name implies a task id, but the description adds no semantic detail about how to identify the task. The schema's own description for pk is minimal ('The id of the task'), so the description fails to compensate for the low coverage.

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

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

The description states a specific verb+resource+behavior: 'Move a task one position up among its siblings (same parent), swapping order with the task above it.' This clearly distinguishes it from siblings like move_down_tasks and reorder_children_tasks by specifying the exact scope and granularity.

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

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

The description provides clear context: it explains the operation affects siblings under the same parent and requires no request body. It also gives a usage directive for the app_url deep link. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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

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

Annotations only set all hints to false, so the description must carry the burden. It mentions the PATCH method and 'send only the fields to change', which is some behavioral context, but then diverges into unrelated information about app_url and plan-gated timeline views, which do not describe this tool's side effects, auth, or error behavior. The description does not disclose what fields are accepted or what happens on success/failure.

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

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

The first two sentences are useful, but the next two sentences about app_url, other views, and plan gating are tangential to updating a project. This extra information makes the description less concise and obscures the core usage 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 tool has nested input objects, no output schema, and minimal annotations, the description should clarify the request structure, accepted fields, and response. It only covers some prerequisites and goes off-topic. The plan-gating comment is irrelevant to the update operation itself, and the discrepancy around company_id weakens reliability.

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 states 'Requires the company_id path parameter and the project id', but the schema places company_id in the body object, not in path params, creating a contradiction. It also gives examples of updatable fields (title or description) but does not provide a complete list. The schema's own property descriptions are not leveraged by the description, and the overall coverage is low.

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

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

The description opens with 'Partial update (PATCH) of a project', which is a specific verb and resource, and distinguishes it from the full 'update_projects' sibling. It also clarifies the partial semantics with 'send only the fields to change'.

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

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

The description clearly indicates when to use this tool: when you need to change a subset of project fields, using PATCH. It also states the required parameters (company_id and project id), providing prerequisites. However, it does not explicitly name alternative tools like update_projects for full updates, though the naming makes it implicit.

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

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

Annotations only indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description must convey behavior. It states PATCH semantics and mentions the app_url deep link, but does not disclose permissions, reversibility, or response behavior. This leaves meaningful behavioral gaps.

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

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

The description is two sentences with the first sentence front-loading purpose and usage, and the second adding useful resource context. It is concise, avoids redundancy, and every word 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?

For a mutation tool with no output schema and minimal annotations, the description covers purpose, parameters, and one resource fact. It lacks details about return values, error conditions, or required permissions, making it adequate but not comprehensive for a write 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?

Schema description coverage is 0%, so the description must compensate. It lists example updatable fields (remind_at, text, channel flags, recipient_id) that are not present in the schema's body, providing essential value. However, it does not explicitly map these fields to the body/kwargs structure, leaving some ambiguity about payload placement.

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

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

The description states 'Partial update (PATCH) of a reminder', which is a specific verb and resource, and clearly distinguishes it from the sibling 'update_reminders' by emphasizing partial updates. Listing example fields further clarifies the tool's scope.

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

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

The phrase 'send only the fields to change' clearly indicates when to use this tool instead of a full update, providing clear context. However, it does not explicitly name an alternative tool like 'update_reminders', so it lacks an explicit when-not directive.

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 provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds context that this is a PATCH (partial update) that only modifies specified fields, which is behavior beyond the annotations. It does not mention side effects, permissions, or error behavior, but the partial-update semantics are clearly disclosed.

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

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

The description is a single, well-organized sentence that leads with the action (Partial update/PATCH), explains the key behavior, and lists required parameters. Every word adds value; there is no redundancy 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 moderate complexity (two required parameters, no output schema), the description covers the core semantics: what it does, the partial nature, and required inputs. It does not explain the domain concept of 'resume entry' or error cases, but these are likely understood from the broader API context. It is reasonably complete for a partial-update 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?

The input schema already provides descriptions for both parameters (company_id and pk), so schema coverage is effectively 100% despite the context signal. The description reiterates that company_id and the entry id are required but adds no new meaning beyond the schema. The 'send only the fields to change' hints at optional fields but does not enumerate them, so it does not significantly enhance parameter understanding.

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 performs a partial update (PATCH) of a resume entry, with explicit mention of sending only changed fields. It distinguishes from full updates by using the term 'partial' and gives an example (note or date range), making the purpose unambiguous and differentiating it from sibling tools like update_resumeentries.

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

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

The description implies when to use this tool: when you want to change only a subset of fields, as opposed to a full update. It states the required parameters (company_id and entry id) but does not explicitly name the alternative tool (update_resumeentries) or provide explicit 'when not to use'. The guidance is clear but not exhaustive.

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 all false, so the description carries the burden of disclosing behavior. It adds useful context: PATCH semantics, the exclusion of lifecycle transitions, and the app_url existence. However, it doesn't mention auth, side effects, or how omitted fields behave. More importantly, the claim 'send only the fields to change' conflicts with the schema's required body fields (project_id, name, start_date, end_date), which undermines transparency about actual 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 three sentences, each earning its place: the core PATCH definition with examples, the lifecycle-transition exclusion, and the actionable app_url guidance. It is front-loaded and contains no filler.

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

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

The description covers the key usage context: partial update, allowed field categories, lifecycle exclusions, and a concrete user-facing action. However, with no output schema, no auth/error/side-effect information, and the conflicting required-field representation, it leaves gaps that could lead to incorrect invocation. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, and the description only gives examples like 'name or planned dates' without mapping to exact parameter names. The schema itself describes date format and project_id, but many fields (goal, planning_notes, review_notes) lack guidance. The 'send only fields to change' assertion contradicts the body schema's required fields, making it unclear whether all required body fields must be supplied despite the partial-update intent.

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

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

The description opens with 'Partial update (PATCH) of a sprint', giving a specific verb, HTTP method, and resource. It clearly distinguishes this from lifecycle transition tools by stating 'Lifecycle transitions use the dedicated start/close tools, not this one.' This is far more specific than the generic title 'Update a sprint' and effectively differentiates it from sibling tools.

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

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

The description explicitly states when to use this tool: to send only fields to change, and when not to use it: for lifecycle transitions, pointing to 'dedicated start/close tools.' It also provides user-facing guidance about the app_url deep link, telling the agent to give it to the user. This is clear, actionable usage 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?

Goes well beyond annotations (readOnlyHint=false, destructiveHint=false) by disclosing a side-effect (re-running successor scheduling propagation), specific failure modes (self-link/cross-project/hierarchy/cycle checks with 400), and a response feature (app_url deep link to the successor's drawer). This is rich, non-obvious behavior an agent needs, and it is consistent with the 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 tight, front-loaded sentences: action, side-effect, and constraints/response detail. No filler—each sentence earns its place and the structural flow from intent to consequence is ideal for an agent scanning quickly.

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

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

For a mutating tool with no output schema, the description covers the core scenario: fields, side-effect, error conditions, and a response attribute (app_url). Minor gaps include lack of detail on the exact response envelope or whether dates can also be pushed backward (only 'forward' is mentioned), but overall it is thorough for the 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?

Although schema coverage is 0%, the description does name the two mutable payload fields (dependency_type, lag_days) which are absent from the top-level schema — genuinely useful. However, it does not clarify value formats or constraints (e.g., allowed enum for dependency_type, range for lag_days), and with zero schema-coverage in the description, it could have compensated more.

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?

Uses a specific verb ('Change') with a specific resource ('a dependency's dependency_type or lag_days'), and appends the HTTP method (PATCH). This distinguishes it from sibling tools like the full update_taskdependencies, making the scope (partial update of two fields) unmistakable.

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 this tool is for modifying dependency_type or lag_days, which signals selection over the full-update sibling, but there is no explicit when-to-use/exclusion statement or named alternative. Usage context is visible only through the narrow field list, leaving the agent to infer the comparison.

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 significant behavioral traits beyond the annotations: backend order re-normalization, the combination needed to mark done (is_completed=true, progress=100, status=DONE), and the app_url deep link to hand to users. These are non-obvious and valuable, and no contradiction with annotations exists.

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

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

The description is compact and front-loaded with the purpose. Every sentence adds value: the partial-update definition, the order re-normalization warning, the done-marking recipe, and the app_url guidance. No filler or redundancy.

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

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

Given the large number of parameters and no output schema, the description covers the most important usage notes (order, completion, app_url). It doesn't explain return format or errors, but the inclusion of app_url as a return property helps. This is a reasonably complete description for a complex update tool, though it could touch on validation constraints.

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

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

Despite the schema having 0% description coverage for parameters, the description adds important meaning for order (re-normalization effect), the completion combo (is_completed/progress/status), and mentions story_points. It does not cover all parameters but provides key semantics for the tricky ones, compensating partially for the schema gap.

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 this is a partial update (PATCH) of a task, listing example fields (progress, status, story_points, order). It distinguishes from siblings like update_tasks by emphasizing partial nature, and the resource is 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?

It provides clear usage context: send only fields to change, and gives concrete scenarios like marking a task done with specific values. However, it does not explicitly contrast with alternative tools (e.g., update_tasks) or state when-not-to-use, so it falls short of a 5.

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

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

The description discloses the HTTP method (PATCH), indicating a mutating operation, and notes that both `company_id` and the tag id are required. However, with annotations all set to false (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description carries the burden of explaining behavioral traits. It does not state what happens to unspecified fields, whether the operation is idempotent, or any potential side effects. The PATCH hint is useful but 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 two sentences long, front-loaded with the core purpose ('Partial update (PATCH)'), and every word adds value. It avoids redundancy and is immediately scannable.

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

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

For a simple 2-parameter CRUD tool with no output schema, the description provides the essential information: the operation type, the resource, an example use case, and required inputs. It could have mentioned the absence of an output schema or behavior on unspecified fields, but given the simplicity of the tool, the description is sufficiently complete for an agent to invoke it correctly.

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

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

The schema provides basic descriptions for company_id and pk, but schema description coverage is 0%, meaning the tool description adds no extra detail about the parameters' meaning. However, the description adds structural nuance by labeling `company_id` as a 'path parameter' and referring to pk as 'the tag id', which clarifies how the parameters are used in the request. The example 'rename its text' implies that additional body fields (like text) can be included, though not listed in the schema.

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

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

The description clearly states the tool performs a 'Partial update (PATCH) of a task tag' and provides a concrete example ('rename its text'). It specifies the resource (task tag) and the HTTP method, distinguishing it from full updates. This is a specific verb+resource combination that leaves no ambiguity.

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

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

The description explicitly identifies the operation as a 'Partial update (PATCH)', which implies its use case is for modifying specific fields of a tag rather than replacing the entire resource. It does not name alternative tools (e.g., update_tasktags), but the 'Partial update' phrasing effectively communicates when to use this tool versus a full update. The required parameters are also mentioned, giving context on 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?

Goes far beyond the readOnly/destructive annotations by detailing the 256 KB return limit, pagination via truncated and next_offset, the misleading nature of 'size' metadata, unreadable file types, and app_url behavior for company-level attachments. No contradiction with 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?

The description is long but every sentence adds necessary information—usage sequence, pagination mechanics, known limitations, and fallback. It is well-organized and front-loaded with the core purpose, making it valuable despite its length.

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

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

With no output schema and limited annotations, the description covers all critical context: how to invoke, how to page, what to warn users about, and where to redirect for unsupported formats. It is fully self-sufficient 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?

Despite schema description coverage at 0%, the description thoroughly explains the purpose of each parameter: attachment id in kwargs, company_id in body, and offset for paging. It also explains how to use the response's next_offset to continue reading, adding meaning not present in the schema.

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

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

The description opens with a specific verb and resource: 'Read the text content of an attachment'. It also distinguishes itself from list_attachments and retrieve_attachments by explaining that their returned URL is a short-lived signed URL that cannot be fetched directly, clarifying this tool's unique role.

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 this tool ('Use this after list_attachments or retrieve_attachments'), what to pass (attachment id in kwargs, company_id in body), and provides an explicit alternative for unsupported file types ('point the user at app_url instead'). This covers both use and non-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?

With all annotations set to false, the description carries the full burden of behavioral disclosure. It reveals non-obvious behaviors: cross-company tag attachment is possible and removable, missing tags are handled harmlessly, and the task response includes an app_url that should be passed to the user. This goes well beyond what annotations provide.

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 core action is stated in the first sentence, followed by two sentences of valuable edge-case and output guidance. Every sentence earns its place; there is no fluff or repetition.

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

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

The description covers several important behaviors (cross-company removal, harmless missing tag, app_url guidance) but lacks details on error handling for invalid task ids, permissions, or the full response structure. With no output schema and no annotations, this leaves some critical context unresolved, though it is adequate for many use cases.

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

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

Schema description coverage is 0% according to context signals, so the description must compensate. It only explains the tag id ('by tag `id`') but never mentions the task id (pk) or the wrapper structure body/kwargs. The agent would have to rely on the nested schema descriptions, which the context signal indicates are insufficient. The description adds meaning for only one of the two parameters.

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

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

The description opens with a clear verb-resource pair: 'Detach a tag from a task by tag `id`.' It distinguishes the tool from siblings by clarifying that any attached tag can be removed, including cross-company ones, which is a unique scope detail. The purpose is unmistakable and well-differentiated.

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

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

The description provides clear context on when to use the tool: it can remove any tag, even cross-company ones, and it explicitly guarantees that removing a non-attached tag is harmless. It lacks an explicit comparison with alternatives like add_tag_tasks or destroy_tasktags, but the usage context is well conveyed.

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 already indicate the tool is not read-only, not idempotent, and not destructive. The description adds value by explaining that it modifies `order` values and is a maintenance operation, giving the agent a clearer understanding of the side effects beyond the raw annotation flags.

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-loaded with the main action, and contains no unnecessary words. Both sentences earn their place: the first explains what it does, the second explains why it exists.

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

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

For a simple one-parameter tool with annotations and no output schema, the description covers purpose, input, and usage context adequately. It doesn't mention return values or edge cases (e.g., empty children), but these are less critical for a maintenance operation with a clear intent.

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

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

The schema only describes `pk` as 'The id of the task,' but the description clarifies it should be the parent task id, adding important context. With only one parameter and zero schema coverage in the description, this additional clarification compensates for the gap.

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 ('Compact and re-normalize the `order` values') and the resource ('the direct children of a given task'). It specifies the scope (direct children) and the input (parent task id), making it distinct from siblings like reorder_root_tasks or move_up_tasks.

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

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

The description provides clear context for when to use the tool: 'Maintenance operation to fix gaps after several moves.' This implies usage scenarios but does not explicitly name alternatives or exclusions. The context is enough to guide an agent when reordering is needed.

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 already indicate this is not read-only, not idempotent, and not destructive. The description adds that it 'fixes ordering gaps' and is a 'maintenance operation', but does not detail side effects or prerequisites, such as whether the project must exist or what happens to dependent tasks. Given the annotations, the added context is minimal but present.

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 only three sentences and front-loads the main action, but the unnecessary and contradictory 'Pass `project_id`' directive detracts from its clarity.

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 omits how to provide the required project_id despite referencing it, and with no output schema it does not clarify return values or side effects. The tool cannot be correctly invoked based on the provided information.

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 defines zero parameters, yet the description instructs the agent to 'Pass `project_id`', which is not defined in the schema. This contradiction makes it unclear how to supply the required project identifier and is a critical flaw.

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

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

The description states a specific verb ('Compact and re-normalize'), target ('order values of top-level (root) tasks'), and scope ('of a project'), clearly distinguishing it from the sibling `reorder_children_tasks` which targets child tasks.

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

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

It explains this is a maintenance operation for fixing ordering gaps and explicitly excludes explicit ordering lists, giving the agent a clear when-to-use/when-not-to-use. It does not name alternative tools, but the sibling naming convention provides enough 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?

Annotations only say the call is not read-only and not idempotent, but the description adds crucial behavioral detail: the token is one-time, consumed by the first successful upload, and the upload itself creates the attachment. This prevents the agent from expecting immediate listing or retry semantics.

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 dense but well-structured: purpose, workflow, constraints, and caveats all appear in three sentences with no redundancy. The key deliverable and distinction from `create_attachments` are front-loaded, and every sentence adds practical 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 no output schema and annotations providing only negative hints, the description carries the complete burden and succeeds: it explains the returned fields (`upload_url`, `expires_at`, max size, content types), the asynchronous attachment creation, and the lifecycle relative to `list_attachments`. This is sufficient for safe and correct invocation.

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

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

The schema gives little semantic coverage at the top-level body parameter, and the description compensates by explaining `company_id` and optional `project_id` scoping and the exact upload contract. However, it does not explain the `title` sub-parameter, leaving a small gap in full parameter coverage.

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

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

The description explicitly names the deliverable (`upload_url`) and clearly states the tool's purpose: obtaining a short-lived, one-time URL for offloading file bytes that are too large/binary for `create_attachments`. It also distinguishes this tool from siblings by explaining that this only reserves a slot and that the attachment is not visible in `list_attachments` until upload completes.

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 clear use-case boundary: use it for files too large or too binary to inline via `create_attachments`. It gives concrete steps — POST multipart form-data to `upload_url` with field name `file`, before `expires_at`, with max size and allowed content types from the response — which is exactly the guidance an agent 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?

Annotations only indicate non-readOnly, non-idempotent, and non-destructive—minimal safety info. The description significantly enriches this by disclosing short-lived expiry, one-time token consumption, that the attachment is created only after successful upload, and that it won't appear in list_taskattachments until then. These behavioral details go far beyond annotations, aiding correct usage and expectation management.

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 front-loaded with the core purpose, then explains the required upload flow and important caveats. Though multi-sentence (actually one long compound sentence), it contains no fluff; each clause adds essential information about usage, behavior, and constraints. It is concise relative to the complexity of the operation.

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 one parameter, no output schema, and non-trivial multi-step nature, the description covers all critical aspects: how to obtain the URL, how to upload (multipart, field name), expiry, token one-time use, attachment creation timing, and relation to list_task_attachments. It is fully self-contained and sufficient for correct invocation without additional oracle calls.

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

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

The schema already provides a clear description for task_id: 'ID of the task the file will be attached to.' The description adds little beyond saying the attachment is 'scoped to task_id', which slightly reinforces but does not materially extend semantics. Since the schema covers the only parameter adequately, a baseline of 3 is appropriate; the description does not need to compensate for missing schema documentation.

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: obtaining a short-lived, one-time URL to upload file bytes for attachment to a task. It explicitly distinguishes itself from other tools by emphasizing it is 'the only way to attach a file to a task over MCP' since task attachments lack inline-content creation. This specific verb+resource description effectively differentiates it from siblings like request_attachment_upload.

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 explicit when-to-use guidance by stating it's the sole method for task attachments and correct use is the only way. It also details the required steps (POST multipart form data with field 'file' before expiry) and clarifies that the call merely reserves a slot and does not create the attachment until the upload completes. This effectively tells the agent when and how to invoke the tool versus 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?

Annotations already declare readOnlyHint and idempotentHint. The description adds significant context beyond these: signed links expire in 15 minutes, file fields are null for links, and app_url behavior for company-level attachments. No contradiction with 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?

The description is four sentences long, each delivering meaningful information without repetition. It is front-loaded with the core purpose and logically organized, 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?

With no output schema, the description fully discloses return fields and behaviors (kind, url, file metadata, app_url). It covers edge cases (expiring links, null fields for links, company-level attachments) and references related tools, making it comprehensive for the 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?

The description clarifies the pk parameter by mentioning 'by its id' and hints at company_id via 'company-level attachments'. However, it does not explicitly define the role of company_id. Given schema description coverage is 0%, the description only partially compensates for the gap.

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 function ('Retrieve a single attachment by its id') and enumerates the returned fields, distinguishing it from sibling tools like list_attachments and read_attachments. It uses a specific verb and resource, leaving no ambiguity.

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 instructs to use list_attachments first to find the id, and read_attachments to read text content. This provides direct alternatives and when-to-use guidance, surpassing simple implied usage.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds behavioral context by stating the returned fields (name, description, metadata) and the membership visibility constraint. It doesn't mention potential 404s or auth errors, but the annotation coverage lowers the burden.

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, compact sentence that front-loads the action, resource, and id. It contains no filler or repeated schema information and every clause earns its place.

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

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

For a simple retrieve-by-id tool, the description covers the resource type, return scope, and access restriction. It lacks explicit alternative guidance and error behavior, but the read-only annotations, single parameter, and absence of output schema make this sufficiently 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?

There is only one parameter, pk, and the schema describes it as 'The id of the company', so the description's 'by its id' adds little new meaning. With schema description coverage reported at 0%, the description should compensate for the nested kwargs structure, but it does not explain how to pass the parameter beyond the id concept.

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 the specific verb 'Retrieve', names the exact resource 'company (workspace)', and scopes it by 'id'. It also clarifies the access restriction, distinguishing it from list_companies which returns collections.

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 implies when to use the tool: to fetch a singular company by id, with the caveat that only member companies are accessible. It does not explicitly name alternatives or provide when-not-to-use guidance, but the single-vs-list distinction is apparent from sibling 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?

The description describes a read-only operation returning profile data, but annotations declare readOnlyHint=false and idempotentHint=false, directly contradicting the nature of the tool. This is a serious inconsistency that undermines 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 two sentences, front-loaded with the core function, and includes essential use-case guidance without any redundant or extraneous content.

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

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

For a no-parameter tool without an output schema, the description fully covers what the tool does, what it returns, and when to use it. The tool's simplicity means no further detail is needed, aside from the annotation contradiction already noted.

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 and the schema is empty, so the description cannot add parameter semantics. Per the rubric, a zero-param tool gets a baseline of 4, and the description appropriately focuses on return values and 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 uses a specific verb ('Return') and identifies the exact resource ('authenticated user's own profile') with listed fields. It also differentiates from sibling tools by resolving 'me' into a user_id rather than guessing names.

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 call this tool ('resolve me/my tasks/assign it to me') and provides an alternative to avoid ('instead of guessing the person's name against the company member list'). This gives clear context relative to alternatives like list_users.

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