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?

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 provide basic read-write info (not read-only, not idempotent, not destructive). The description adds value by noting 'New tasks are appended and the level is reordered automatically', which goes beyond annotations. However, it omits side effects or default behaviors for omitted optional 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, front-loaded with purpose and prerequisites, with no wasted words. Every sentence adds value, making it efficient for an agent to parse.

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 good purpose and conciseness, the description lacks return value information (no output schema) and does not cover all 16 parameters in the nested body. For a creation tool with high complexity, the description is sufficient but not thorough, missing some behavioral details and error scenarios.

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

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

Schema description coverage is 0%, meaning the description must compensate. It lists some optional fields but misses many (e.g., order, progress, dates). The description adds grouping and constraints (e.g., max length of description) but remains incomplete, leaving the agent to infer or rely on schema alone for other 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 'Create a task' with specific verb and resource. It distinguishes itself from sibling tools like 'destroy_tasks' and 'update_tasks' as the only creation tool, leaving no ambiguity.

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

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

The description lists required 'project_id' and optional fields, giving context for when to use. However, it doesn't explicitly state when not to use (e.g., for updates) or mention alternatives like 'partial_update_tasks', relying on the tool name and context.

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

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

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?

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?

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 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 and idempotentHint=true, and the description adds behavioral context about pagination, ordering by board position, and filter capabilities. There is no contradiction, and the description enhances transparency 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?

Two sentences, front-loaded with purpose, then a concise list of filters. No wasted words while covering essential 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 schema's 0% description coverage and no output schema, the description is helpful but incomplete. It details many filters and pagination but omits some parameters and does not describe the return structure. The tool's simplicity (list) partially compensates, but more detail would improve completeness.

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

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

The description explains many parameters (project_id, sprint, parent_id, etc.) and mentions pagination, but it does not cover all schema parameters like progress, story_points, or is_deleted. With 0% schema description coverage, the description provides partial but incomplete compensation.

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. Among sibling tools, this is the only 'list_tasks' tool, so it is well-distinguished.

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 needing to list tasks with rich filtering, but does not explicitly state when not to use it or mention alternatives. Given that it is the sole list tool for tasks, the context is clear enough.

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?

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?

The description discloses an important side effect: backend re-normalizes sibling order after save, which affects index interpretation. Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but not this nuance. The explanation 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?

The description is two sentences: first states purpose with examples, second adds critical behavioral note and a practical example. No redundant text, well front-loaded, every sentence earns its place.

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

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

Given the tool's complexity (nested body with many fields, no output schema), the description explains order behavior and gives a completion example but omits that body requires 'title' even if not changed, and doesn't mention kwargs constraints. Annotations are minimal, so description carries more burden; it is somewhat 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 description coverage is 0% per context, so the description must compensate. It mentions key parameters (progress, status, story_points, order, is_completed) and explains order behavior. However, it does not detail all parameters or clarify that body requires 'title' even in partial updates. Provides some additional meaning but not full 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 this is a partial update (PATCH) of a task, listing example fields. It distinguishes itself from other sibling edit tools by specifying 'partial' and providing the verb+resource combination. The purpose is immediately clear.

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

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

The description implies use when only some fields need updating ('send only the fields to change') and gives a specific scenario ('Mark a task done...'). However, it does not explicitly state when not to use it or compare it with alternatives like full update_tasks or move tools. Guidance is present but not comprehensive.

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 adds minimal behavioral context beyond annotations. It states removal is harmless for non-attached tags, but annotations set idempotentHint=false, creating a contradiction. It does not disclose error handling for mismatched tags or non-existent tasks.

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

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

The description is two sentences long with no redundant information. It front-loads the primary action and is efficiently 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 the main action and a key constraint but lacks details on error scenarios (e.g., if tag does not exist, task not found, or company mismatch). With no output schema and low annotation coverage, it leaves gaps for edge cases.

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

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

The schema provides full descriptions for both parameters (body.id and kwargs.pk). The description adds a constraint that the tag must belong to the same company as the task, which provides extra context 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 'Detach a tag from a task by tag `id`' which specifies the action and resource. It distinguishes from sibling 'add_tag_tasks' which performs the opposite operation.

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

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

The description provides a condition ('tag must belong to the same company as the task') and notes that removing a non-attached tag is harmless, implying idempotency. It does not explicitly name alternatives but the sibling list includes the inverse operation 'add_tag_tasks', providing 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, 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 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 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 indicate idempotentHint true and destructiveHint false. The description adds the behavioral note 'Saving re-normalizes the order of sibling tasks,' which is not in annotations and provides important context about side effects. It could have mentioned what happens to omitted required fields, but it says 'every writable field must be supplied' which covers that.

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 unnecessary words. The first sentence defines the tool's action and constraints, and the second sentence provides a clear usage guideline. It is front-loaded and 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?

Given the complexity (nested object, many fields, no output schema), the description explains the full-update requirement, the re-normalization side effect, and the alternative tool. However, the claim that 'every writable field must be supplied' may conflict with the schema which only requires 'title' in the body; this could cause confusion. Still, for a PUT endpoint, this is conventional, so it's a minor gap.

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

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

The description does not add specific meaning to the parameters beyond what the input schema provides. The schema already includes descriptions for many fields (e.g., parent, sprint, priority, description, datetime fields), so the baseline is 3. The description only mentions 'title' explicitly but no other parameter 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?

The description clearly states 'Full update (PUT) of a task' and specifies that every writable field must be supplied, including 'title'. The title 'Replace a task' reinforces this. This distinguishes it from the sibling 'partial_update_tasks' tool, which is mentioned explicitly.

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

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

The description explicitly advises when to use this tool vs. the alternative: 'To change only a few fields, prefer the partial-update tool.' It also implies that the full update is appropriate only when all writable fields are supplied.

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 indicates a PUT operation (idempotent, not read-only), consistent with annotations. It adds that 'every writable field required', but lacks detail on side effects, authorization, or response 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?

Two sentences, front-loaded with key operation type, no unnecessary words. Could be structured slightly better but is 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?

No output schema, and sibling tools include partial update. The description implies the difference but does not fully explain return values or all writable fields, leaving some 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?

With 0% schema coverage, the description clarifies that company_id and tag id are required and their roles. However, it does not elaborate on additional fields within the body object.

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

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

The description clearly states it is a 'Full update (PUT)' of a task tag, differentiating it from a partial update. However, it does not explicitly mention the sibling tool 'partial_update_tasktags' for contrast.

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) but does not provide explicit guidance on when to use this tool versus alternatives like partial_update_tasktags.

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