ProWoDo

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

Annotations indicate a write operation (readOnlyHint=false) and are neutral. The description adds behavioral detail: 'the tag is created in the task's company if it does not exist yet' for the text parameter, which is valuable beyond annotations. No contradiction.

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

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

Two sentences, no wasted words. First sentence states the action, second explains parameters and constraint. Efficient 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?

The description does not clarify that the task ID is required (via kwargs.pk) and that body parameters are technically optional per schema, creating inconsistency. It also omits return value information and does not address the mutual exclusivity enforcement (e.g., what happens if both are provided).

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 existing for id and text, the description adds meaning by stating they are mutually exclusive ('Provide either ...') and imposes a company constraint ('must belong to the same company'), which the schema does not cover.

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 'Attach a tag to a task' with specific verb and resource, and distinguishes from sibling tools like 'remove_tag_tasks'. It also explains the two methods (text or id).

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 conditions for using text vs id ('Provide either text or the id'), but does not explicitly guide when to use this tool versus alternatives like 'create_tasktags' or 'remove_tag_tasks'. The guidance is 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?

Discloses that non-DONE tasks are carried over or returned to backlog, which is critical behavioral context beyond the annotation flags (readOnlyHint, idempotentHint, destructiveHint all false). 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?

Two sentences, all essential information front-loaded. No fluff. Efficient and clear.

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

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

Given the tool's simplicity, the description covers the main action and task handling. No output schema, but return values are implicit. Could mention prerequisites (sprint must be active), but 'ACTIVE sprint' implies the state condition. Adequate for selection and 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 description carries full burden. It adds meaning to the body.carry_over_to parameter, explaining the effect of omission vs. providing an ID. The pk parameter in kwargs is generic but required; description does not add further, but it's acceptable.

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

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

Description clearly states it transitions an ACTIVE sprint to CLOSED, with specific verb and resource. Distinguishes from sibling tools like start_sprints and destroy_sprints by focusing on the close action. Also explains task carry-over 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?

Description implies when to use: to close a sprint. It does not explicitly provide when-not-to-use or alternatives, but the context of sibling tools and the clear action make usage straightforward. The carry_over_to parameter is well explained, guiding the agent on optional 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?

Beyond annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds that the authenticated user is automatically added as the first member, a key behavioral trait. It also implies the company will own sub-resources, providing useful context not captured in 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?

Two sentences with no superfluous text. The purpose is stated in the first sentence, and additional context in the second. Every part 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?

Given no output schema, minimal annotations, and a complex nested parameter, the description is incomplete. It omits return value (e.g., the created company object), error conditions, and prerequisites. It gives the core purpose but lacks details needed for full autonomous use.

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

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

The schema coverage is 0% for the body parameter, meaning the description adds no meaning beyond the schema. The description does not explain the body parameters (name, description, daily_resume_default) or their formats, leaving the agent with only the schema documentation, which is insufficient given 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 clearly states 'Create a new company (workspace)', using a specific verb and resource. It also distinguishes from siblings like list_companys or retrieve_companys by noting that the authenticated user becomes the first member, which is unique 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 says 'Use this to start a fresh tenant that will own its own projects, sprints and tasks', which clearly indicates when to use. However, it does not explicitly mention when not to use or provide alternative tools, missing some exclusion 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 already indicate the tool is not read-only, not idempotent, and not destructive. The description reinforces creation behavior and adds that the project groups tasks, sprints, and board columns, but lacks details on side effects, permissions, or error conditions.

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

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

Two sentences: first states action and context, second explains grouping and requirement. 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 no output schema and basic annotations, the description covers the essential creation purpose and required fields but omits return value, error conditions, and behavior when constraints are violated. Adequate but not rich.

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 compensate but only mentions company_id and title. The optional parameters description and is_archivied are not explained, leaving gaps for 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?

Description clearly states it creates a new project inside a company, specifies the resource (project) and context (company), and distinguishes it from sibling tools like update_projects and destroy_projects.

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 a project but does not provide explicit guidance on when to use it versus alternatives like update_projects or destroy_projects. No mention of prerequisites or excluded 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?

The description provides detailed behavioral context beyond annotations, including default channels, required channel at least one, and optional notification behavior. It does not contradict 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 reasonably concise, front-loading the key action and parameters. Minor redundancy ('push is on by default' could be omitted given schema default) but overall 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?

The description covers all parameters and their behaviors, which is sufficient given no output schema. However, it lacks details on error cases or permissions, which would enhance 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?

With 0% schema description coverage, the description compensates fully by explaining each parameter's purpose, defaults, and constraints (e.g., 'recipient_id' defaults to task assignees, at least one channel must be on).

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 ('Schedule a reminder on a task') and specifies the required and optional parameters, making the tool's purpose unambiguous. It also distinguishes from sibling tools like 'list_reminders' and 'destroy_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 explains when to use the tool (to create reminders on tasks) and provides default behaviors, but it does not explicitly mention when not to use it or contrast with alternatives like 'partial_update_reminders'.

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 non-readOnly, non-idempotent, non-destructive. Description adds context: 'Multiple entries per day are allowed' and optional linked tasks. 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?

Two sentences, front-loaded with resource and key parameters. Every sentence adds essential information without waste.

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

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

Lacks return value description (expected to return the created entry). For a create tool with no output schema, this is a gap. Otherwise covers essential inputs and behavioral traits.

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 already has descriptions for all parameters. Description adds value by explaining kind values (plan/done) and optional nature of tasks, going beyond schema details.

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

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

Description explicitly states 'Create a resume entry' with specific parameters (company_id, kind, date range, note, tasks). Clearly distinguishes from siblings like update, list, destroy.

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?

Implies usage through action description but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-idempotent. The description adds that new sprints start in the PLANNED state, which is helpful context beyond annotations. However, it does not disclose error behavior (e.g., missing project_id) or the return 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 extremely concise (two sentences), front-loaded with purpose, and contains no unnecessary words. Every sentence adds value.

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

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

Given the complexity of a nested body parameter with multiple fields and no output schema, the description adequately covers the core inputs and initial state. It could mention the body parameter's required nature or constraints like unique name, but is mostly sufficient for a simple creation tool.

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

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

Schema description coverage is 0% for the top-level body parameter, but the description adds meaning by listing the key required fields (project, name, start/end dates). It does not explain optional parameters like goal, review_notes, planning_notes, or retrospective_notes, which are 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 clearly states the tool creates a sprint for a project, specifies verb ('create') and resource ('sprint'), and mentions the initial PLANNED state. This distinguishes it from sibling tools like close_sprints, start_sprints, or destroy_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 description implies that required inputs include project, name, and dates, but does not explicitly guide when to use create_sprints versus alternatives like start_sprints or close_sprints. There is no mention of prerequisites or when not to use this tool.

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

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

Annotations only indicate a non-destructive write. The description adds that the successor's planned dates are pushed forward (side effect) and lists specific error conditions (400 on invalid links). This goes beyond annotation 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 a single, well-structured paragraph that covers purpose, parameters, behavior, and errors without redundancy. It is appropriately sized for the 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?

The description lacks explanation of what a successful response looks like (no output schema) and does not fully detail all parameters, especially the entity IDs. It provides essential but incomplete context for a nested object 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?

Although the input schema contains descriptions, context signals indicate 0% schema description coverage, so the description must compensate. It explains dependency_type and lag_days but does not describe company_id, project_id, predecessor, or successor, leaving those ambiguous.

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

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

The description uses a specific verb 'Link' and clearly identifies the resource as 'two tasks of the same project with a scheduling dependency'. It distinguishes from siblings like create_tasks and partial_update_taskdependencys by specifying the action is creating a dependency.

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 same-project dependencies and lists rejection conditions (self-link, cross-project, ancestor/descendant, cycle), which guides when not to use. However, it does not explicitly contrast with partial_update_taskdependencys for modifications.

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 mutate operation (readOnlyHint=false) but not destructive (destructiveHint=false). Description adds that tasks are appended and reordered automatically, but does not mention permissions, return value, side effects, or idempotency (idempotentHint=false). Moderate transparency beyond 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?

Two concise sentences front-load the core purpose and requirements. Uses a clear list format to enumerate optional fields. No superfluous text.

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

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

Given the complexity (many nested parameters, no output schema, many siblings), the description is minimal. It does not explain return values, error scenarios, prerequisites (e.g., project existence), or dependencies on other tools. Fields like 'order', 'effort', 'impact', and boolean flags are not addressed. The description lacks detail for confident real-world use.

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

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

Description adds meaning by naming a subset of parameters (project_id required; title, description, status, priority, story_points, parent, sprint optional) and notes maxLength for description and sub-task behavior for parent. However, the schema has 24+ properties, and many are undocumented in the description. The schema itself provides descriptions for some parameters (e.g., priority, importance), but the tool description only covers about half of the important ones.

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

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

Clearly specifies verb 'Create' and resource 'task'. Distinguishes from siblings like 'update_tasks' and 'destroy_tasks' by focusing on creation. Lists required and optional fields, reinforcing 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?

States required parameter 'project_id' and lists optional fields, but does not explicitly compare with alternative tools or provide when-to-use / when-not-to-use guidance. Usage context is implicit from the list of optional parameters and the automatic reordering note.

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

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

Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds that the tag becomes available to attach to tasks, but does not disclose behavior on duplicate tags or response format, leaving gaps.

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

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

Two sentences, front-loaded with the action and resource, followed by the effect. No unnecessary words. Efficient and clear.

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 create tool with nested schema and no output schema, the description covers purpose and effect. However, it lacks details on error handling, uniqueness, and the body structure, and the path parameter inaccuracy detracts from completeness.

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

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

Schema description coverage is 0%; the description explains that 'text' becomes available for tasks, adding value. However, it incorrectly states 'company_id' is a path parameter, while the schema places it inside the body object, causing confusion and reducing trust.

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 'Create', the resource 'task tag', and the context 'in a company'. It distinguishes from siblings like 'add_tag_tasks' (attaches existing tag) and 'destroy_tasktags' (deletion).

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

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

The description implies the tool is used to create new tags and makes them available for attaching to tasks. It provides clear context but lacks explicit exclusions or alternatives, though the purpose is self-evident.

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

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

Annotations do not indicate destructiveness or idempotency, and the description does not clarify side effects (e.g., behavior of subtasks). The mention of an optional parameter not in the schema 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?

One concise sentence front-loading the action, but includes inaccurate information about a non-existent parameter, reducing effectiveness.

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?

Lacks details on return values, side effects, or prerequisites. No output schema; description should compensate but fails to provide sufficient behavioral context.

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

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

Schema coverage is 0% as per context; the description adds no value for 'pk' beyond the schema's own description, and incorrectly introduces 'after_task_id' which is not a parameter, misleading 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 'Outdent a task' and explains it decreases depth, distinguishing it from increase_depth_tasks. However, it mentions 'after_task_id' which is not present in the input schema, causing potential confusion.

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

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

No guidance on when to use this tool versus alternatives like increase_depth_tasks. No prerequisites or exclusion criteria 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?

The description explains behavior beyond annotations: soft-delete (not hard), can be restored, archived projects drop from default list. Aligns with idempotentHint (setting to true repeatedly is safe) and destructiveHint (mutation affecting visibility). No contradiction.

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, each providing a distinct piece of information: the soft-archive action and its effect on lists. No filler, front-loaded with the core concept.

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

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

Covers main behavioral aspects and list visibility, but lacks return value information (no output schema) and potential error conditions or permissions. Adequate for a simple two-parameter tool, but could be more helpful.

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

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

Schema coverage is 0%, yet the description adds no information about the two required parameters (pk, company_id). While parameter names are somewhat self-explanatory, the description should clarify expected values or format, especially for company_id.

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

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

The description clearly states the tool soft-archives a project by setting is_archived=true, distinguishing it from hard-deleting. The title 'Archive a project' aligns with the name 'destroy_projects' but clarifies the nature. It differentiates from sibling destroy tools that likely perform hard deletions.

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 use when wanting to archive a project rather than permanently delete it. However, it does not explicitly state when to use this tool versus alternatives like update_projects (if that also modifies archived status). There is no mention of when not to use it 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?

The description 'Delete' aligns with the destructiveHint annotation. No additional behavioral details (e.g., permanence, associated data effects, permissions) are disclosed beyond what annotations already indicate. No contradiction detected.

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

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

The description is a single short sentence, which is concise but lacks structure. It is front-loaded with the action but omits useful details, making it minimally adequate.

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 destructive operation with no output schema, the description does not mention return values or side effects (e.g., permanence). Given the tool's complexity and zero schema coverage, it is incomplete.

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 any parameters. With 0% schema description coverage, the schema provides some meaning but the description adds no value. Two required parameters (task_id, reminder id) are left unexplained.

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

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

The description clearly states the action 'Delete a reminder from a task,' specifying the verb and resource. It distinguishes itself from other destroy tools by focusing on reminders, though it doesn't differentiate among various delete 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?

No guidance is provided on when to use this tool vs alternatives, prerequisites, or context. The description lacks any when-to-use or when-not-to-use information.

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 annotations (destructiveHint=true), the description clarifies the soft-delete behavior (row retained, drops from lists), adding useful context. However, there is a minor contradiction with destructiveHint.

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

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

Two concise sentences, front-loaded with the core action. No wasted words.

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

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

No output schema, and the description lacks details on return values, side effects, or post-condition. Missing parameter documentation for pk.

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%. The description only mentions company_id, omitting the pk parameter from the kwargs. This leaves one parameter undocumented.

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 'soft-removes' and explains the mechanism (is_deleted=true, row retained). It clearly identifies the verb and resource, distinguishing it from hard-delete siblings.

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

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

The description mentions the required company_id parameter but provides no guidance on when to use this tool vs alternatives or when not to use it.

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

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

Annotations already indicate destructive and idempotent hints; description adds useful behavioral constraint about status-based rejection, but doesn't elaborate on idempotency or return 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?

Single sentence, front-loaded with action and condition, 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?

Covers the key constraint (status) well; lacks mention of return type or success behavior, but tool is simple and annotations cover safety profile.

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?

Input schema has generic description for 'pk' and nested kwargs; description adds no parameter information despite 0% schema coverage, leaving the agent to infer the pk is sprint ID.

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

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

The description clearly states the verb 'Delete' and the resource 'sprint', and distinguishes from sibling 'close_sprints' by specifying status conditions.

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 (PLANNED sphinx) and when not (ACTIVE/CLOSED must use close), providing clear 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?

Adds important behavioral detail beyond annotations: that previously pushed-forward planned dates remain unchanged. Consistent with destructiveHint and idempotentHint.

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

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

Two concise sentences, front-loaded with purpose, no extraneous 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?

Describes the effect adequately but omits required parameter context (need for company_id, project_id, pk). No output schema, but effect is clear.

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 tool description adds no information about parameters. Does not compensate for lack of parameter documentation; agent must rely solely on 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?

Clear, specific verb 'remove' and resource 'scheduling dependency between two tasks of a project'. Distinguishes from siblings like create_taskdependencys and list_taskdependencys.

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?

States the effect of removal and explicitly notes that dates are not moved back, giving a usage nuance. Lacks explicit when-to-use vs alternatives, but context is clear.

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

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

The description adds significant behavioral context beyond the annotations: soft-delete nature, exclusion from lists, row retention, and descendant behavior. It is consistent with destructiveHint and idempotentHint 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?

Two sentences, each providing essential information without redundancy or fluff. The first states the action and effect; the second adds a critical behavioral 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?

Given the tool's simplicity (one parameter, no output schema), the annotations cover the safety profile, and the description covers the effect, retention, and descendant behavior comprehensively.

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% (the schema has a nested 'kwargs' structure), and the description does not supplement parameter-level details, such as format or constraints, for the required 'pk' parameter.

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

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

The description clearly states the tool soft-deletes a task, specifying the effect (excluded from lists, retained for history) and a key behavioral note (descendants not auto-promoted), distinguishing it from sibling 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?

The purpose is clear and the tool is distinct from siblings by resource type, but no explicit guidance is given on when to use it versus alternatives or when not to use it.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the valuable behavioral detail that tasks previously referencing the tag lose the association, which goes beyond the annotations. It does not, however, mention irreversibility or permissions required.

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 exceptionally concise: two sentences that front-load the core action and immediately follow with a critical side effect. Every word serves a purpose, and there is no superfluous 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 destructive tool with no output schema, the description explains the primary effect but fails to cover return behavior (e.g., success/error indicators) or any prerequisites. It also inaccurately describes the company_id parameter location. Given the complexity (2 params, nested objects), it is moderately complete but has notable 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?

Although the context indicates 0% schema description coverage, the schema actually provides descriptions for both parameters (company_id and pk). The description only mentions company_id as a 'path parameter', which is inaccurate since it's in the body according to the schema, and it completely omits explanation of the pk parameter. Thus, it adds minimal value beyond the schema.

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

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

The description clearly states the tool's purpose: deleting a task tag from a company, and it explicitly mentions the effect on tasks that referenced the tag. The verb 'destroy' combined with the resource 'tasktags' makes it distinct from sibling tools like 'destroy_projects' or 'remove_tag_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?

No guidance is provided on when to use this tool versus alternatives such as 'remove_tag_tasks' (which only removes associations) or other deletion tools. The description does not mention prerequisites, order of operations, or conditions under which the tool should or should not be invoked.

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 this is a non-destructive mutation. The description adds that it changes depth but does not elaborate on side effects such as whether existing children are affected, ordering changes, or potential error conditions like cycles. With annotations already denoting mutation, the description provides minimal additional 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 exceptionally concise: two sentences that front-load the core action and provide an example. Every word serves a purpose with no redundancy.

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

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

Given the tool's moderate complexity (indent task) and lack of output schema, the description fails to cover important details: how to specify the parent ID, constraints like preventing self- or cyclic indentation, and any impact on task ordering. It leaves the agent with incomplete 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 schema has 0% description coverage, so the description must compensate. It introduces 'new_parent_id' which is not present in the schema, adding meaning. However, it does not clarify how to pass it (e.g., as a property inside kwargs) or specify the required format, leaving ambiguity.

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

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

The description clearly states the tool's purpose: indent a task to become a child of another, increasing its depth. The example 'turn a sibling into a sub-task' helps. However, it does not explicitly distinguish itself from sibling tools like decrease_depth_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 when to use it (when you want to make a task a subtask) and hints at the required parameter. But it lacks explicit guidance on when not to use it or alternatives (e.g., decrease_depth_tasks for the opposite operation).

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 safe read-only, idempotent behavior. Description adds context about search/pagination and company hierarchy, but the unbacked claim of search/pagination without params may confuse agents.

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 succinct sentences: first states purpose, second adds key context. No wasted words, front-loaded with actionable info.

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?

Minimally adequate for a simple list tool. Mentions search/pagination but no output schema or return details. Lacks details on how to invoke search/pagination without 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?

No parameters exist, schema coverage is trivial. Baseline is 4 per rubric, but description mentions search/pagination which are not reflected in schema, causing inconsistency. Downgraded for misleading 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?

Clearly states it lists companies the user belongs to, and defines company. Distinguishes from siblings like 'retrieve_companys' and other list tools. However, the mismatch with input schema (claims search/pagination but no params) prevents a perfect score.

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?

Implies usage for authenticated user's memberships, but no explicit guidance on when to use vs alternatives like 'retrieve_companys' or when not to use. Lacks exclusion criteria 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 declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral details: archived projects are excluded by default unless include_archived=true, and filtering options exist. This goes beyond the annotations without contradiction.

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 concise sentences: purpose, key exclusions, and filtering capabilities. Front-loaded and efficient with no redundant 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?

Considering no output schema and low schema coverage, the description covers purpose, required parameter, default exclusions, and filtering. Missing pagination or ordering details, but otherwise sufficient for a list tool.

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

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

With 0% schema description coverage, the description carries burden. It mentions additional parameters (include_archived, search, id, title, description) not in the schema, but only lists names without detailed semantics for each. The required company_id is already in schema. Partial value provided.

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

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

The description begins with 'List the projects of a company,' clearly stating the verb and resource. It distinguishes itself from sibling tools like create_projects or destroy_projects by focusing on listing and noting specific behaviors like archive exclusion and filtering.

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 by mentioning the required company_id parameter, the behavior of include_archived, and support for search/filtering. However, it does not explicitly guide when to use this tool versus other list tools (e.g., list_tasks) or provide alternative suggestions.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: results are ordered by scheduled time, and each reminder includes specific fields. 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?

Two sentences, no redundancy, front-loaded with the main action. Every word 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 simple list operation with one parameter and existing annotations, the description covers the return fields sufficiently. However, it lacks mention of pagination, limits, or error cases, but for typical reminder lists this is acceptable.

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 adds meaning by clarifying that task_id is a path parameter (though the schema places it in the body) and mentions ordering by scheduled time. This partially compensates for the lack of schema descriptions, though more details on format or constraints would improve clarity.

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

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

The description clearly states it lists reminders of a task, ordered by scheduled time, and details the information shown (remind_at, text, channels, sent status). This provides a specific verb-resource pairing and distinguishes it from sibling tools like create_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 implies usage for viewing reminders but does not explicitly state when to use this tool versus alternatives like retrieve_reminders (which likely retrieves a single reminder) or other list tools. No guidance on when not to use it is provided.

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

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

Annotations already declare the tool safe (readOnlyHint, idempotentHint, non-destructive). The description adds value by explaining filtering options and company scoping, which are behavioral traits beyond annotations.

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

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

Three sentences with no redundancy. The core action and key filters are front-loaded; every sentence adds value.

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

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

For a list tool with no output schema and safe annotations, the description covers purpose, context (stand-ups), and main filters. Lacks guidance on default behavior when no filters are provided, but otherwise sufficient.

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

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

Schema description coverage is low, but the description highlights key filters (kind, date range, user_id). However, it does not explain pagination parameters (page, page_size) or the granular date comparison operators, leaving some meaning to inference from 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 (list), resource (resume entries), and specifies the entries are 'daily or range plan/done notes' for a company. It distinguishes from sibling tools like list_tasks or list_projects by focusing on resume entries.

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: 'Used for stand-ups and daily planning.' It implies appropriate use but does not explicitly mention when not to use or list alternatives, though sibling tools cover related actions like create, update, delete.

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 useful detail about automatic backfilling of missing lanes, beyond annotations which already indicate read-only and idempotent 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?

Concise but contains inaccurate information about parameters, undermining its effectiveness.

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?

Lacks explanation of return format or behavior without parameters, and the mention of a non-existent parameter makes it incomplete.

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?

Description references a 'sprint_id' parameter that does not exist in the input schema, misleading the agent about required inputs.

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

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

Description clearly states it lists board lanes of a sprint and mentions the kanban board, but does not explicitly distinguish from sibling 'retrieve_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?

Mentions passing 'sprint_id' to scope, but the input schema has no parameters, causing confusion about how to use the 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 readOnly, idempotent, and non-destructive behavior. The description adds the key behavioral trait of scoping to the user's companies, which is not in annotations. It also mentions filtering and ordering. This is good supplementary 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?

Two sentences that are front-loaded with the main action, then filtering options, then a specific use case. Every sentence adds value 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?

For a list tool with rich parameters and annotations, the description covers the core functionality (scope, filtering, ordering, use case). It does not mention pagination explicitly, but the schema includes page/page_size with descriptions. Slightly missing default ordering, but overall complete enough.

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 'state' and 'start/end date' for filtering and ordering, which adds high-level meaning beyond the schema. However, schema coverage is high (many parameters have descriptions), so the baseline is 3. The description does not detail all date parameters or pagination, but that is acceptable given 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 lists sprints for the user's companies, with filtering by state and ordering by date. It distinguishes from sibling tools like retrieve_sprints (single sprint) and list_sprint_lanes (lanes within a sprint). The verb 'List' and resource 'sprints' are specific.

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 suggests using the tool to find a project's active sprint, providing a concrete use case. While it doesn't name alternatives like retrieve_sprints for a single sprint, the context of sibling tools makes the distinction clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the structure of each dependency link (predecessor, successor, type, lag days) and the optional task filter, which goes beyond the annotations. However, it does not mention pagination or ordering 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 two sentences (40 words), front-loaded with the main purpose, and every part adds value (purpose, field details, filter option). No redundancy or unnecessary text.

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

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

Given there is no output schema, the description partially explains the return structure (fields of each link) and the filter. However, it omits details like pagination, sorting, or whether the response is a list. The inconsistency between 'path params' and the actual body schema undermines completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds context about the task query parameter and the meaning of dependency_type (FS/SS/FF/SF) and lag_days. But it incorrectly describes company_id and project_id as 'path params' when the schema places them inside a body object, causing potential confusion. The task filter is not in the schema, creating a mismatch.

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 scheduling dependencies of a project, specifies the fields in each link (predecessor, successor, type, lag days), and mentions a filter option by task ID. It distinguishes itself from sibling tools that handle other resources (e.g., list_tasks, list_projects).

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 viewing dependencies of a project or a specific task, but it does not explicitly state when to use this tool over alternatives, such as retrieving a single dependency with retrieve_taskdependencys or when to avoid using it. No when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value by noting pagination and ordering by board position, providing behavioral context beyond 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 with no wasted words. The first sentence clearly states the purpose, and the second efficiently lists filters, making it easy to scan.

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

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

Despite no output schema, the description covers intent and key filters but fails to explain all parameters or provide details on pagination defaults and exact response structure. Given the schema's low coverage, it could be more complete.

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

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

The input schema has 0% description coverage, so the description must compensate. It lists several key filters (project_id, sprint, search, etc.) but omits others like page, page_size, and progress-related parameters, leaving 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 clearly states 'List tasks the user can access' with a specific verb and resource. It also highlights rich filtering options, distinguishing it from sibling list tools for other resources like projects or 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 lists filters but does not explicitly state when to use this tool versus alternatives like retrieve_tasks for single tasks. It lacks guidance on when not to use it or prerequisites such as required project 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 already declare readOnlyHint and idempotentHint, so the description adds value by explaining the company-scoped nature and attachment to tasks. However, it does not disclose details like response format or pagination.

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

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

Two sentences, front-loaded with the core action, no extraneous information. Each sentence adds value.

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

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

The description covers the basic purpose and scope, but lacks details about the return value (e.g., an array of tag objects) since there is no output schema. For a simple list tool, it is adequate but could be more 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?

With 0% schema description coverage, the description should compensate, but it only mentions the company_id path parameter without clarifying its format, constraints, or the fact that it is required. The body object is not explained.

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

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

The description clearly states the verb 'List' and the resource 'task tags', and specifies the scope ('in a company' with company_id). This distinguishes it from other list tools among siblings.

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

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

The description implies usage context (retrieving company-scoped tags) but does not explicitly state when to use this tool versus alternatives like create_tasktags or update_tasktags.

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. Description adds search feature claim, but it's unsupported by schema. No disclosure of pagination, ordering, or response format.

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

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

Two concise sentences, front-loaded with purpose, second adds usage hint. 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?

Lacks output schema and does not describe return format, pagination, or ordering. Inconsistencies about search and parameter location reduce completeness.

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

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

Schema coverage is high (company_id description present). Description adds no new parameter details beyond what schema provides, but clarifies path vs body incorrectly.

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?

Explicitly states 'List the users who are members of a company', which is a specific verb-resource pair. Title 'List company members' aligns. Distinguishes from siblings like list_companys and retrieve_users.

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?

Mentions requiring company_id and supports search for user resolution, but the input schema lacks the search parameter and shows company_id in body not path. Contradictory info reduces trustworthiness.

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 minimal behavioral hints (readOnly, idempotent, destructive all false). The description adds value by explicitly stating the swapping behavior and that no request body is needed. It does not mention potential side effects or limitations (e.g., bottom task behavior), but the added context is helpful.

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

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

The description is two sentences: the first covers the action and effect, the second notes 'No request body needed'. It is front-loaded with the key operation and contains no wasted words.

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

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

For a simple tool with one required parameter and no output schema, the description is largely complete. It explains the operation, effect, and body requirement. Missing slightly is a note on edge cases like what happens when the task is already at the bottom, but overall 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 does not mention parameters or add any meaning beyond the input schema. The schema itself describes 'pk' as 'The id of the task', but the tool description contributes nothing to parameter understanding, leaving the agent with only schema info.

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

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

The description uses a specific verb 'move' and resource 'task', clearly stating the one-position-down sibling scope and the ordering effect (swapping with the task below). This distinguishes it from siblings like move_up_tasks and other move 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 implies usage for reordering tasks within the same parent but does not explicitly state when to use this tool vs alternatives (e.g., move_up_tasks, reorder_children_tasks) or any exclusions. The context is clear but lacks guidance on not using it.

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

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

The description notes that moving a task shifts other siblings, which is a behavioral trait beyond the annotations (all false). It does not disclose potential errors (e.g., if tasks don't share parent/project), permissions, or reversibility, which would be helpful given the mutation nature.

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 and mostly clear, with no wasted words. However, it could be slightly improved by integrating the missing pk parameter without adding 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?

Given the complex schema (nested objects, two required fields in different sub-objects) and no output schema, the description is incomplete. It omits the pk parameter, does not describe the response or error conditions, and lacks sufficient detail for an agent to reliably 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?

The description explains direction (before/after) and related_task_id but omits the required 'pk' parameter (the task being moved). With 0% schema description coverage, the tool description should compensate, but it fails to mention pk, leaving a critical 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 uses specific verbs (place, shifting) and clearly identifies the resource (task) and action (reorder relative to a sibling). It distinguishes from sibling tools like move_up_tasks or reorder_root_tasks by specifying the exact positional relation (before/after a given sibling).

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

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

The description states the constraint that both tasks must share the same parent and project, which helps define when the tool applies. However, it does not explicitly mention when not to use it or suggest alternatives among the many sibling reordering tools.

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

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

Annotations indicate the tool is not read-only or idempotent. The description adds context about the null behavior and the restriction on closed sprints, which goes beyond the annotations. 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?

Two sentences, no wasted words. The first sentence conveys the purpose, the second focuses on parameter guidance and a key constraint. 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?

The tool is simple with one key parameter. The description covers the main behavior, null handling, and the closed sprint restriction. Missing return value or error information, but not critical for a mutation tool without an output schema.

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

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

The input schema already provides descriptions for both parameters (project_task_status_id and pk). The description repeats the null behavior and constraint, adding little extra value beyond the schema. Baseline is raised by 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 action 'Move a sprint board lane (a task) to a different board column,' with a specific verb and resource. It distinguishes from sibling move tools by focusing on board columns and mentions the 'Incoming' column option.

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 guidance on the parameter 'project_task_status_id' and its null option, along with the constraint that lanes from closed sprints cannot be moved. It does not explicitly mention alternative tools, but the constraints are clear enough for correct 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 are all false (no hints). The description adds constraints (task cannot already be in target project, user membership requirement) but doesn't disclose effect on task state or return value. This is adequate but not rich.

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

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

The description is only two sentences, which is concise, but it contains a misleading parameter reference that harms its efficiency. It could be more structured with clear parameter names.

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 is a mutation, but the description does not explain what is returned or what side effects occur (e.g., does it update the task? Does it affect other records?). The missing parameters are a major gap.

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

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

The description mentions 'project_id' and 'company_id' as parameters, but the input schema only includes 'pk' under a nested 'kwargs' object. The schema description coverage is 0%, and the description contradicts the schema, causing confusion. This 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 clearly states the action: 'Move a task to a different project (and company).' This is a specific verb and resource, and it distinguishes the tool from siblings like 'move_to_sprint_tasks' or 'move_down_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 explicit conditions: pass 'project_id' and 'company_id', the target project must belong to that company, user must be a member, and the task cannot already be in the target project. However, it does not explicitly state when not 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?

Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds behavioral details: descendants follow automatically, and closed sprints are rejected. Could mention idempotency or side effects, but overall adds value beyond annotations.

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

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

Three sentences: action overview, parameter details, return value. No redundancy, efficiently packed with all necessary 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 tool with nested schema and no output schema, description covers action, parameter constraints, return values, and rejection condition. Sufficient for agent to select and invoke correctly among many siblings.

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

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

Schema has 0% description coverage. Description compensates fully: explains task_ids must be non-empty, same project, and descendants follow; sprint_id null means backlog. Adds critical semantics not in schema.

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

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

Description clearly states the verb 'move', the resource 'tasks', and specifies the target destinations (sprint or backlog). It also differentiates from sibling tools like move_to_project_tasks by focusing on sprint vs project movement.

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 describes when to use: moving tasks into a sprint or backlog. Provides constraints: tasks must be in same project, closed sprints are rejected. Implicitly distinguishes from move_to_project_tasks by mentioning sprint and backlog as targets.

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 the tool is a mutation but not destructive. The description adds the detail 'No request body needed,' but does not disclose behavior when the task is already at the top or any side effects like reindexing.

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 with no unnecessary words. It is front-loaded with the action and provides a key constraint ('No request body needed') 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 simple reorder tool with one parameter, the description is nearly complete. It lacks details on error handling (e.g., task already at top) and output, but given the tool's simplicity, it 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 only parameter 'pk' has a description in the schema ('The id of the task'), but the tool description adds nothing beyond that. It does not explain the parameter's role or constraints, and schema 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 clearly states the action: moving a task one position up among its siblings, swapping order. It specifies the resource (task) and the effect, distinguishing it from siblings like move_down_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 usage for reordering tasks under the same parent but does not explicitly state when to use this vs alternatives like move_down_tasks or reorder_children_tasks. No exclusions or prerequisites are mentioned.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds that it is a mutation (PATCH) and requires specific parameters, but does not disclose side effects, authorization needs, or response structure. It adds some context but not rich behavioral 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?

Two concise sentences, front-loaded with purpose and key requirements. No unnecessary words 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 has nested objects (body and kwargs), no output schema, and 0% schema coverage, the description is insufficient. It does not explain how to structure the body for the partial update, what fields are available, or what the response is. Falls short of providing complete guidance.

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

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

Schema description coverage is 0%, so the description must compensate. However, it inaccurately states 'company_id path parameter' while schema shows it in the body. It does not list updatable fields beyond mentioning 'title or description' as examples, leaving many parameter details ambiguous.

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

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

The description clearly states the tool performs a 'partial update (PATCH)' of a project, sending only fields to change. It specifies the resource (project) and method, and contrasts with a full update implicit in sibling tool 'update_projects'. The verb and resource are clearly identified.

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 partial updates but does not explicitly state when not to use or compare with alternatives like 'update_projects' (full update) or other sibling partial update tools. It mentions required parameters but lacks exclusion criteria.

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

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

The description adds the HTTP method (PATCH) and examples of updated fields, but given minimal annotations, it does not fully disclose behavioral traits such as whether omitted fields are untouched or any side effects. The schema mismatch further undercuts 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 a single, succinct sentence that front-loads the key information (partial update, PATCH, fields to change). No redundant words, though a slightly more structured format could improve readability.

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 should mention return value or behavior. It only describes input expectations, leaving response format unknown. Additionally, the schema mismatch with described fields undermines completeness for a partial update tool.

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

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

The input schema has 0% description coverage, and the description lists example fields (remind_at, text, etc.) not present in the schema, causing confusion. Required parameters (pk, task_id) are not explained. The description fails to compensate for the lack of schema documentation, and the examples are inconsistent.

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

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

The description clearly states it is a partial update (PATCH) of a reminder, specifying the resource and verb. Distinguishes from full update by mentioning 'partial' and 'send only the fields to change', but could explicitly differentiate from sibling 'update_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 advises to send only fields to change, implying usage for partial modifications. However, it does not explicitly state when to use this tool over alternatives like update_reminders, nor does it mention prerequisites or context for use.

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

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

Annotations indicate mutation (readOnlyHint=false). Description adds that it's a PATCH operation, which is consistent. No additional behavioral details beyond annotation values, but no contradiction.

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, directly to the point. No extraneous information. Purpose and method are 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 low complexity (2 required params, no output schema), the description covers purpose and required fields. Could mention response format or error conditions, but adequate for the scope.

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?

Description mentions required parameters (company_id and entry id) and their roles, adding clarity beyond the schema's field descriptions. Compensates for low schema description coverage effectively.

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

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

Clearly states it's a partial update (PATCH) of a resume entry, with specific fields like note or date range. Distinguishes from full update sibling (update_resumeentrys) by specifying partial 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?

Explicitly says to send only fields to change, indicating when to use partial updates. Does not explicitly exclude full updates or mention alternatives, but context from siblings implies distinction.

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

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

Description claims 'send only the fields to change' but the schema requires project_id, name, start_date, and end_date in the body, contradicting the partial update semantics. This mismatch is a major behavioral transparency gap. No mention of permissions, error handling, or idempotency, and annotations do not clarify.

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

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

Two concise sentences front-load key information: HTTP method, partial update behavior, and exclusion of lifecycle transitions. 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?

While purpose is clear, the description fails to explain the return value, error scenarios, or the schema contradiction. The absence of an output schema increases the need for description completeness, which is unmet.

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 context, so the description should compensate, but it only gives examples ('name or planned dates') without explaining the purpose of other fields like goal, review_notes, etc. The contradiction between partial semantics and required fields further confuses parameter usage.

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

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

Description clearly specifies 'Partial update (PATCH) of a sprint' with verb and resource. It also distinguishes from sibling tools by noting that lifecycle transitions use dedicated start/close tools, not this one.

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 that lifecycle transitions should use start/close tools, providing clear when-not-to-use guidance. However, it does not mention the alternative of full update via update_sprints, which is a sibling.

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 minimal (all false), so the description bears the burden of behavioral disclosure. It effectively communicates key side effects: scheduling propagation and date pushes. No contradiction with annotations exists. However, it omits authorization or rate limit 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?

Two sentences, no redundancy. The main action and key side effects are front-loaded. Every sentence provides essential information without fluff.

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

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

The description covers behavioral aspects (propagation, checks) well but lacks parameter explanations. With no output schema, the agent may need more detail on required inputs. Given the complexity, the description is partial but not severely incomplete.

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

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

Schema coverage is 0% (no descriptions in schema). The description only mentions the changeable fields (dependency_type, lag_days) but does not explain the required parameters (body.company_id, body.project_id, kwargs.pk) or their roles. This leaves the agent unclear about how to identify the dependency.

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 (Change/PATCH) and resource (task dependency), specifying the exact fields (dependency_type, lag_days). This distinguishes it from siblings like destroy_taskdependencys (delete) and create_taskdependencys (create), making the tool's 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 implicitly indicates when to use this tool (for partial updates to dependency_type or lag_days) and lists constraints (self-link/cross-project/hierarchy/cycle checks) that may cause errors. However, it does not explicitly state when not to use it or compare with full update.

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 non-readOnly, non-idempotent, non-destructive. The description adds behavioral insight: order re-normalization after save, and that sending is_completed=true with progress=100 and status=DONE marks the task done. This is 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 (two sentences plus a note), front-loaded with purpose, and each sentence adds value. No fluff.

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

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

Given the tool's complexity (many fields, no output schema, minimal annotations), the description covers essential context: partial update nature, order behavior, and a usage example. It does not explain return values or permissions, but that is acceptable.

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 fields like progress, status, story_points, order, and gives an example of combining fields. However, it does not describe all 20+ fields; the schema's own titles and some descriptions partially compensate. The description adds value for key parameters but is incomplete.

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

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

The description clearly states it's a partial update (PATCH) of a task, with specific verb and resource. It distinguishes from sibling tools by emphasizing 'send only the fields to change', which is the core distinction from full updates.

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 tells when to use this tool (send only fields to change) and provides an example (marking a task done). It implicitly contrasts with full updates but does not explicitly name alternatives like update_tasks. The note about order re-normalization adds practical 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 adds the PATCH method and an example operation (rename text), which provides some behavioral context beyond annotations. However, it does not disclose side effects, permission requirements, or idempotency details. Since annotations are minimal, the description partially compensates but falls short of full transparency.

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

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

The description is extremely concise: one sentence of 18 words that front-loads the core purpose. Every word is necessary, with 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?

Given the simple nature of the tool (2 parameters, no output schema), the description is adequate but has gaps. It does not specify which fields can be updated beyond text, nor does it describe the response format or error conditions, which an agent may need 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?

With 0% schema description coverage, the description must compensate. It identifies both parameters (company_id and tag id) and notes company_id as a path parameter. However, it does not explain the structure of the body object or specify other updatable fields, leaving ambiguity for 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 it performs a partial update (PATCH) of a task tag, with an example of renaming its text. This distinguishes it from sibling tools like update_tasktags (full update) and destroy_tasktags (delete), providing a specific verb and resource.

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 required parameters (company_id and tag id), which implies when to use it. However, it does not provide explicit guidance on when not to use it, nor does it mention alternatives like update_tasktags for full updates. Usage context is implied but not elaborated.

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

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

The description states that removing a non-attached tag is harmless, implying idempotent behavior, but the annotations set idempotentHint to false, creating a contradiction. It also notes cross-company tag removal, but the contradiction lowers the score.

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 two sentences, front-loads the main purpose, and adds relevant context in the second sentence without unnecessary words.

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

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

The description covers the core action and a notable edge case (cross-company tags), but lacks details on return values, errors, or prerequisites. With no output schema and sparse annotations, it is adequate but not fully comprehensive.

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

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

The input schema already describes both parameters (id and pk) with clear definitions. The description adds no additional parameter meaning beyond mentioning the tag id, so it matches the baseline of 3 given 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 'Detach a tag from a task by tag id', which is a specific verb and resource. It distinguishes from sibling add_tag_tasks by implying the reverse operation, but does not explicitly name the alternative.

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

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

No explicit guidance on when to use this tool versus alternatives like add_tag_tasks. The description only states functionality without usage 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 indicate non-read-only and non-destructive. The description adds specific behavioral context: it compacts and re-normalizes order values, which is a modification but non-destructive. It does not mention permissions or idempotency, but the annotations already provide those hints.

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 with no wasted words. The first sentence explains what it does and the parameter, the second provides context for when to use it.

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 parameter, no output schema), the description covers what it does and when to use it. It lacks information about return value, but for a maintenance operation this is acceptable.

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 that the single parameter 'pk' is the parent task id, which adds meaning beyond the schema's description ('The id of the task'). This is crucial for understanding the tool's operation.

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 specific verbs 'Compact and re-normalize' and specifies the resource 'order values of direct children of a given task'. It clearly distinguishes from siblings like 'reorder_root_tasks' by mentioning 'direct children' and requiring a parent task id.

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

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

The description states it is a 'Maintenance operation to fix gaps after several moves', implying it should be used when gaps exist. However, it does not explicitly exclude other scenarios or name alternative tools like move_up/down_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 mutation but no destruction. Description adds that it's a maintenance operation, fixes gaps, and does not accept an ordering list. This clarifies the non-destructive, automated nature 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, front-loaded with action, no wasted words. Clearly conveys the core purpose and a key constraint.

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?

Adequate for a simple maintenance tool, but the parameter inconsistency undermines completeness. Lacks explanation of prerequisites or return values, though no output schema exists.

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

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

The input schema has no parameters, but the description says 'Pass project_id'. This is a direct contradiction that misleads the agent. Schema coverage is 100% for zero parameters, so the description should not introduce undefined 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 tool compacts and re-normalizes order values of root tasks, with specific verb and resource. It distinguishes from siblings like '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?

Describes the tool as a maintenance operation for fixing gaps, and notes it does not accept an explicit ordering list. Provides clear context but does not explicitly exclude alternatives or state when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, providing safety profile. The description adds behavioral context by stating the returned fields and access restriction (only user's companies), which goes beyond 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 resource, then adds an important constraint. Every clause is necessary and no redundant information.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers what the tool does, what it returns, and access restrictions. Annotations cover safety. No gaps are evident.

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 context, so description must compensate. It mentions 'by its id' but does not fully explain the nested 'kwargs' structure or the 'pk' parameter beyond the schema's minimal description. Adds some meaning but not comprehensive.

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 'Retrieve' and the resource 'single company (workspace)', and specifies returned fields (name, description, metadata). It implicitly distinguishes from sibling list_companys but does not explicitly mention the alternative.

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 indicates when to use (by id) but does not provide explicit guidance on when not to use or mention alternatives like list_companys. The access constraint is noted but not as a usage exclusion.

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=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds context about returned fields, which is useful but beyond annotations. 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?

Single sentence of 22 words, front-loaded with action and key details. No extraneous information. Highly efficient.

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 retrieval with 2 params and no output schema, the description covers purpose, required parameters, and return fields. It lacks error handling or response structure but is sufficient for basic use.

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

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

Schema description coverage is 0% per context, so description must compensate. It mentions company_id as 'within a company' and pk implicitly, adding some context. However, it does not elaborate on parameter constraints or formats.

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 'retrieve', resource 'project', and specifies retrieval by id within a company. It also lists the fields returned (title, description, archived). This distinguishes it from list_projects and other project tools.

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

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

The description implies usage when you have a specific project id and know the company id, but does not explicitly contrast with list_projects or other retrieval tools. No guidance on when not to use is provided.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds minimal context by specifying it retrieves a single reminder, but no further behavioral details 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?

A single sentence with no fluff, efficiently conveying the basic action. However, it could be improved by including key details about required parameters.

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

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

The tool has 2 required parameters and nested objects, yet the description omits the composite key requirement and provides no output format. Annotations help but the description alone is insufficient for correct invocation.

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

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

The description does not add any meaning beyond the input schema. With 0% schema description coverage, it fails to compensate by explaining parameters like task_id and pk, or their relationship.

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 retrieves a single reminder by id, but it does not specify that both task_id and reminder id are required. It does not distinguish from sibling list_reminders or other 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?

No guidance on when to use this tool over alternatives like list_reminders or other retrieve tools. No usage context or exclusions 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 already declare readOnlyHint, idempotentHint, and destructiveHint as true. The description adds value by specifying the exact data returned (kind, date range, note text, linked tasks), which aids the agent in understanding output without side effects.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every part adds value (verb, resource, identifiers, returned fields). 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?

While the tool is simple and annotations cover safety, the description does not fully explain the required 'pk' parameter. It mentions 'by id' but does not map it to the schema. For a tool with two required params, this omission means the description is 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%, so the description must explain parameters. It mentions 'company_id' but does not explain the 'pk' parameter (the resume entry ID). Users must infer that 'by id' refers to pk, but this is not explicit, leaving ambiguity.

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

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

The description clearly states the action (retrieve a single resume entry), identifies the key identifiers (id and company_id), and lists the fields returned (kind, date range, note text, linked tasks). This distinguishes it from tools like list_resumeentrys or update_resumeentrys.

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 use when needing a specific resume entry by ID within a company. However, it does not explicitly state when not to use it or suggest alternatives (e.g., list_resumeentrys for multiple entries). The context is clear but lacks 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, idempotentHint, destructiveHint. The description adds that the tool shows which task sits in which board column, providing behavioral context beyond annotations. 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?

Single sentence, front-loaded, no wasted words. Every part 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?

Description covers what the tool retrieves and its purpose. Given simple inputs, good annotations, and no output schema, it is adequately complete, though could mention scope more explicitly.

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

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

Schema coverage is 0% with a generic 'pk' description. The description mentions 'by id' but does not specify format or constraints, insufficiently compensating for the lack of schema detail.

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 ('Retrieve') and resource ('a single sprint board lane'), and distinguishes from sibling tools like list_sprint_lanes by indicating retrieval by ID. It also adds context about showing task-to-column mapping.

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 when an ID is known but does not explicitly state when to use this tool versus alternatives like list_sprint_lanes. No guidance on when not to use it.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the return fields (name, project, start/end dates, lifecycle state), which is beyond 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?

Single sentence, 12 words, front-loaded action verb. Every word is necessary and informative.

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 explains return fields. Could mention error handling or that the response is a full sprint object, but this is largely adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by id', not explaining the nested kwargs structure or that pk is the primary key. The parameter's role is only implied.

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 retrieves a single sprint by id and lists the return fields (name, project, dates, lifecycle state). This distinguishes it from list_sprints which returns multiple 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?

No guidance on when to use this tool versus alternatives like list_sprints or retrieve_projects. No context on prerequisites or typical 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns specific fields, but does not provide additional behavioral context such as error handling or prerequisites. It is adequate but not enhanced beyond 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?

Single sentence, no wasted words, directly conveys purpose and included fields. Excellent 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 simple retrieval without output schema, the description explains key return fields. Sibling tools are present, but no mention of limitations or error conditions. Still fairly complete given the tool's simplicity.

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 schema itself includes descriptions for parameters (e.g., company_id, project_id, pk). The description adds no new meaning beyond saying 'by id'. Baseline 3 is appropriate as the schema carries the burden, though compensation would be needed for complete 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 verb 'Retrieve', the resource 'a single task dependency of a project', and specifies it is by 'id'. It lists the fields included (predecessor, successor, dependency_type, lag_days), which distinguishes it from list_taskdependencys.

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

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

No guidance on when to use this tool versus alternatives like list_taskdependencys for multiple dependencies, or partial_update_taskdependencys for modifications. The description only states what it does, not when it is 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds value by listing the returned fields and suggesting inspection before updates. It does not contradict annotations and provides useful context 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 two sentences with no extraneous information. The first sentence states the core functionality and returned fields; the second provides a usage recommendation. Every sentence earns its place, making it highly efficient.

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 retrieval tool with no output schema, the description adequately lists the returned fields and suggests a use case. It could mention error handling or that the response includes only the fields listed, but overall it is complete enough given the tool's simplicity and the 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%, meaning the input schema provides minimal parameter descriptions. The description only mentions 'by id' without elaborating on the id format, source, or validation. It fails to compensate for the low schema coverage, leaving the agent with insufficient guidance on the required parameter.

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

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

The description clearly states the verb 'Retrieve' and the resource 'a single task by id'. It lists the fields included (title, description, status, progress, story points, tags, assignees, order), which distinguishes it from list_tasks (which retrieves multiple) and other retrieve_* tools. The use case 'Inspect a task with this before updating it' 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?

The description provides a clear usage hint: 'Inspect a task with this before updating it.' This guides the agent on when to use this tool. However, it does not explicitly state when not to use it or mention alternatives like list_tasks for batch retrieval. The guidance is strong 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?

Description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) by describing a retrieval operation. Adds minor context about company scope but no extra behavior details like error handling or response format.

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

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

Single sentence, 14 words, no fluff. Information is front-loaded and to the point.

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 (retrieve by ID with two parameters), the description is adequate but lacks details on return value or error states. No output schema, so a brief mention of output 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?

Schema description coverage is 0%, so the description should compensate. However, it only reiterates the parameter names without adding meaning beyond the schema's own descriptions (e.g., 'by id' and 'company_id').

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

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

Description clearly states the action (retrieve), resource (single task tag), and scope (by id within a company). It effectively distinguishes from sibling tools like list_tasktags and create_tasktags.

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

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

No explicit guidance on when to use this tool versus alternatives like list_tasktags. Context is implied but not stated.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds value by specifying the returned fields (name, email, display name), but does not disclose additional behavioral traits.

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

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

Two concise sentences with no wasted words. First sentence states purpose and identifier; second sentence covers requirement and return fields.

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

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

For a simple retrieval tool with good annotations and schema, the description adequately explains the return fields partially. Lacks full response structure, but sufficient for the given 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 input schema itself provides descriptions for both parameters, so the tool description adds minimal new meaning beyond reiterating the company_id requirement. Baseline score is appropriate given 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 verb (Retrieve), resource (single member of a company), and identifier (user id), distinguishing it from sibling tools like list_users.

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 required parameters but does not provide explicit guidance on when to use this tool versus alternatives, such as when a single user 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 are minimal (readOnlyHint: false, etc.), but the description adds critical behavioral context: failure conditions and the project-level constraint. 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?

Two concise sentences. The first sentence states the core action, the second adds failure conditions. 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 description covers the main preconditions and failure modes. It does not describe the return value, but for a simple state transition tool this is acceptable given no output schema and clear purpose.

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

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

The description provides no additional meaning beyond the input schema. The schema has 0% coverage (generic 'primary key' description), and the description does not explain the 'pk' parameter or the nested 'kwargs' structure.

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 'Transition' and resource 'sprint from PLANNED to ACTIVE'. It distinguishes itself from siblings by specifying the required state and the constraint of only one active sprint per project.

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

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

The description explicitly states when to use the tool (to start a planned sprint) and conditions for failure (sprint not PLANNED or another sprint already ACTIVE). It provides clear context, though it does not explicitly mention alternative tools.

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

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

The description claims the tool is idempotent ('Idempotent: if the user is already assigned...'), but the annotations set 'idempotentHint' to false. This is a direct contradiction. Without annotations, the description would provide useful behavior info, but due to the contradiction, transparency is severely undermined.

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 with no extraneous information. It is front-loaded with the core action and immediately adds idempotency and constraint details. 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 (2 parameters, no output schema), the description covers the essential purpose, idempotency behavior, and a key constraint. It even mentions the return type (existing assignment). However, the contradiction on idempotency and lack of parameter details reduce completeness slightly.

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, meaning the schema does not document parameters. The description does not mention parameter names, types, or expected values beyond implicit reference. It fails to compensate for the lack of schema descriptions, leaving the agent with insufficient guidance on how to populate 'pk' and 'user_id'.

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

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

Description clearly states 'Adds a user as an assignee on a task', specifying the verb 'adds', resource 'user', and target 'task'. It also mentions idempotency and a company constraint, which distinguishes it from related tools like 'task_unassign_user'.

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

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

Description provides usage guidance by noting idempotency (safe to call even if already assigned) and a prerequisite (user must belong to same company as task's project). However, it does not explicitly state when not to use or compare to alternatives like 'task_unassign_user'.

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 noop behavior and the return value unassigned=false, which is useful. Annotations provide little (readOnlyHint=false, destructiveHint=false), so the description adds value. However, it could detail error conditions or side effects better.

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

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

The description is extremely concise with two short sentences. Every sentence adds value without redundancy.

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

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

Given the tool has 2 parameters and no output schema, the description covers the main behavior and noop case. It mentions the return value 'unassigned=false' but could be more complete about error responses or full return structure.

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

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

The input schema already provides descriptions for both parameters (user_id and pk), so the tool description does not add additional meaning beyond what is in the schema. Baseline 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 it removes a user from a task's assignee list, using a specific verb and resource. It distinguishes from the sibling tool task_assign_user which assigns a user.

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 the noop behavior if the user is not assigned, but does not explicitly state when to use this tool vs alternatives like task_assign_user or other task modification tools. It also lacks 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?

Discloses PUT method and all-fields-required behavior. Annotations already cover non-destructiveness and idempotency; description adds context on request semantics. 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?

Two sentences, no verbosity. Each sentence adds essential information. Front-loaded with key behavior.

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

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

Given no output schema and many sibling tools, the description adequately explains the tool's nature and when to use it. Could mention response or error behavior, but overall sufficient.

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

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

Schema description coverage is 0%, and description only mentions company_id and project id. Does not explain other required fields in body or provide parameter details. Needs more parameter information.

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

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

Clearly states this is a full update (PUT) of a project, requiring every writable field. Distinguishes itself from the partial-update sibling tool.

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

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

Explicitly tells when to use (full update) and when to use an alternative (partial update). Also mentions required path parameters.

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 idempotentHint=true and destructiveHint=false; description adds that every writable field is required, clarifying the PUT semantics. No contradiction and adds useful behavioral context.

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

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

Two concise sentences: first states core function, second provides usage guidance. No wasted words, front-loaded with key 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 no output schema and nested objects, the description explains the full-update nature and field requirement. Combined with annotations and schema, it provides a good contextual picture. Lacks mention of writable fields list but schema covers structure.

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

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

Description does not elaborate on parameters beyond the schema. Schema descriptions are present (e.g., task_id and pk descriptions) but minimal. Baseline 3 is appropriate as description adds no extra parameter info.

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

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

Clearly states it's a full PUT replacement of a reminder requiring all writable fields. Differentiates from sibling 'partial_update_reminders' by explicitly mentioning it as the alternative for small edits.

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 suggests using the partial-update tool for small edits, providing clear context for when to prefer alternatives. No explicit when-not-to-use for this tool but sufficient 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 convey idempotency and non-destructiveness. Description adds that it is a PUT operation and requires all fields, but does not elaborate on response or side effects beyond 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?

Two sentences, front-loaded with essential information, no unnecessary words.

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

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

Covers purpose, required parameters, and alternative tool, but lacks details on return value or validation behavior. Sufficient for a simple update tool with sibling references.

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 clarifies that company_id and entry id are required and that the body must contain all writable fields. However, it does not detail what those fields are.

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

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

Clearly states it performs a full update (PUT) of a resume entry, requiring all writable fields. Explicitly distinguishes from the sibling tool partial_update_resumeentrys.

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

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

Specifies that it is a full update requiring every writable field and advises to prefer the partial-update tool for small edits, providing clear context on when to use.

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

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

Annotations already convey idempotency (idempotentHint: true) and non-destructive nature. The description adds the HTTP method (PUT) and the requirement that all writable fields must be provided, which are behavioral traits beyond annotations. While not exhaustive (e.g., no mention of validation errors or side effects), it is sufficient for this tool.

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

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

Two sentences deliver the core purpose, method, requirement, and usage recommendation without redundancy. Every sentence adds value, and the key information is front-loaded.

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

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

The description covers the essential context for a full update tool: method, field requirement, and alternative tool. The input schema provides enough detail on parameters. The absence of output schema is acceptable for a PUT endpoint. Slight lack of guidance on error states or prerequisites, but overall complete for most 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?

The description does not elaborate on individual parameters beyond stating 'every writable field required'. While the input schema includes some descriptions (e.g., date format, project_id as primary key), the description adds no parameter-level semantics. Given the context signals indicate 0% schema description coverage from the description itself, this is a 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 it performs a full update (PUT) of a sprint, replacing all writable fields. The verb 'update' and parenthetical 'PUT' combined with 'every writable field required' precisely define the action and scope, distinguishing it from partial updates.

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?

Explicit guidance is given: 'Prefer the partial-update tool for small edits such as adjusting dates.' This directly tells the agent when to use this tool versus an alternative (partial_update_sprints), providing clear decision-making 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 already indicate idempotency and non-destructiveness; the description adds that the operation runs the same propagation and validation as create, including self-link, cross-project, and cycle checks.

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 succinct sentences: purpose and required fields, behavioral detail, and usage guidance. 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?

Covers purpose, required fields, behavioral notes, and alternative tool. However, the input schema does not include the nested fields mentioned in the description, which could cause confusion; the description compensates but the mismatch is a minor gap.

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

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

Despite 0% schema coverage, the description names the four fields (predecessor, successor, dependency_type, lag_days) that must be supplied, which are not visible in the input schema, thus providing critical semantic information.

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

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

The description clearly states it is a full update (PUT) of a task dependency, names the specific fields that must be supplied, and distinguishes it from the sibling partial_update tool.

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

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

Explicitly advises to prefer the partial-update tool for small edits, and notes that all specified fields are required, providing clear when-to-use and when-not-to-use guidance.

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