mFlow

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

Annotations already set readOnlyHint=false and destructiveHint=true, and the description confirms this with 'May create, modify, or delete data through mFlow's agents.' It adds valuable extra context beyond annotations: the tool 'can take a while to respond (up to 60s) since it may call several tools internally before answering.' This latency and internal-tool-calling behavior is not captured in the annotations and helps the agent set expectations. No contradiction exists between description and 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 slightly longer than minimal but every sentence serves a purpose: it defines the tool's role, mentions semantic search and multi-step actions, warns about latency and potential data changes, and gives explicit routing advice. The core purpose is front-loaded, and the usage guidance appears early. While it could be tightened, the length is justified given the tool's flexible nature and the need to clarify when to use it versus structured alternatives.

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 catch-all tool with no output schema, the description covers the essential aspects: purpose, usage conditions, behavioral caveats (latency, data modification), and routing preferences. It names specific sibling tools as alternatives, which aids decision-making. The only minor gap is that it doesn't describe the output format, but given the tool's open-ended nature, that is not critical. The description is comprehensive enough for an agent to call it correctly.

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

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

The input schema has 100% description coverage: every parameter (question, projectId, connectedAgent) has a clear description. The tool description itself does not add significant meaning beyond the schema—it mentions the question is natural language, which the schema already states, and it doesn't elaborate on projectId or connectedAgent beyond what the schema provides. Since the schema carries the parameter semantics fully, the description adds minimal value here, aligning with the baseline of 3 for high coverage.

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

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

The description clearly states the tool's purpose: to ask mFlow's AI assistant natural-language questions or requests for anything not covered by structured tools, including semantic search, multi-step actions, or ambiguous requests. It explicitly distinguishes itself from the structured siblings by framing itself as the catch-all fallback. This provides a specific verb ('ask'), resource ('mFlow's AI assistant'), and scope ('anything not covered by structured tools'), making it easy for an agent to understand when this is the right choice.

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: 'Prefer a structured tool whenever one covers the request' and lists concrete examples (list_standalone_tasks, create_standalone_task). It then states the conditions for using this tool: 'when the request needs semantic search, spans several steps, or doesn't map to a single structured tool.' This is a clear when-to-use/when-not-to-use with named alternatives, leaving no ambiguity for the agent.

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

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

Annotations only give readOnlyHint=false and destructiveHint=false, which are minimal. The description compensates by disclosing that the call returns immediately with codeAgentTaskId and queued status, does not stream or wait, and that queuePosition appears while waiting for a sandbox. It also tells the agent to poll the status separately. This goes beyond annotations, though it doesn't mention potential side effects on the task object itself (e.g., state changes), which are implied but not explicit.

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

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

The description is compact and well-structured. It leads with the primary purpose and async behavior, then gives usage context, then the prerequisite. Every sentence earns its place, and there is no filler or redundancy. It front-loads the most critical facts for an agent deciding whether to call this tool.

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

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

For a tool with 7 parameters, no required params, and no output schema, the description is remarkably complete. It explains the asynchronous return, the need to poll via get_coding_agent_status, the prerequisite of an existing task, and clarifies parameter selection (taskId vs taskKey, extraPrompt vs instructions). An agent has all the information needed to invoke it correctly without further investigation.

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 100%, so every parameter is described in the schema. The description adds valuable context beyond the schema: it clarifies mutual exclusivity ('Provide exactly one of taskId or taskKey'), explains the lookup behavior for taskKey, notes that extraPrompt and instructions are aliases, and mentions tier default when omitted. This enriches parameter understanding without repetition.

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

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

The description states a specific verb and resource: 'Assign a standalone task to mFlow's autonomous coding agent for asynchronous execution.' It clearly distinguishes itself from siblings by specifying the task must already exist (create_standalone_task first if it doesn't) and by referencing polling get_coding_agent_status separately, so an agent can tell it apart from create and get 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?

It provides explicit when-to-use guidance: 'Use this once you've decided a task is ready for implementation and want to delegate the "how" rather than doing it yourself.' It also names the prerequisite (task must exist, create_standalone_task first) and the alternative for status (poll get_coding_agent_status), leaving no ambiguity about when to invoke 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?

Goes well beyond the readOnlyHint=false / destructiveHint=false annotations: it discloses that repeat calls duplicate rather than overwrite, that "__global__" is rejected as read-only, that accepted ADRs are auto-synced into a repo and injected into every agent's context, that accepted ADRs are effectively immutable, and that malformed ADR content is rejected outright. These are exactly the behavioral traits an agent must know before invoking.

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?

Front-loaded with purpose and prerequisites, then a clearly delineated ADR paragraph — the ordering respects how an agent reads. It is dense and long, and the ADR lifecycle (supersede, sync, immutability) is somewhat repeated, but nearly every sentence carries operational information rather than filler.

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

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

For a 7-param write tool with no output schema and only title/readOnlyHint/destructiveHint annotations, the description supplies the missing context: failure/duplication behavior, the read-only project guard, subtype-specific content contracts, and post-creation side effects. Nothing an agent needs in order to call this correctly is absent.

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 100%, so the baseline is 3, but the description adds real meaning on top: the required ## Context / ## Decision / ## Consequences shape for content, what "accepted" triggers for adrStatus, and the multi-repo semantics of repoUrl including the guidance to omit it as the safe default. It clarifies the constraints the enum values imply rather than restating them.

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?

States a specific verb and resource ("Create a knowledge/documentation entry for a project") and immediately enumerates the concrete artifact types (convention, workflow note, metric definition, reference guide, ADR). It distinguishes itself from list_knowledge_docs, delete_knowledge_doc, and update_knowledge_doc by name, so an agent can route without opening sibling schemas.

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?

Gives explicit preconditions ("Call list_knowledge_docs first"), the replacement path (delete_knowledge_doc the stale one), and per-subtype guidance for when to use adrStatus "proposed" vs "accepted". However, it asserts "there is no update tool yet" while later referencing "update_knowledge_doc's adrStatus" and "supersede later via update_knowledge_doc" — an internal contradiction that could steer an agent toward delete+recreate when an existing update tool would do.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds valuable behavioral constraints not in the schema: the 25MB size limit and the list of supported file types. This goes beyond what annotations provide.

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

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

The description is two sentences with no redundancy. It front-loads the core purpose, then packs constraints and the alternative tool reference into the second sentence. Every sentence earns its place.

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

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

For a simple file-attachment tool with rich annotations and a fully-described schema, the description covers purpose, size/type constraints, and sibling routing. It omits return-value details, but since there is no output schema and the action is straightforward, the description is sufficiently complete for correct invocation.

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

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

Schema coverage is 100% and the schema describes each parameter, so the baseline is 3. The description adds semantic value by explicitly listing supported MIME types (which the schema only references as 'one of the supported types') and adding the critical 25MB size constraint relevant to contentBase64. This enriches parameter understanding 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 states exactly what the tool does: 'Attach a document or image to a standalone task.' It uses a specific verb and resource, and explicitly distinguishes itself from create_standalone_comment by saying that tool is for plain text notes. An agent can clearly tell this from 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 provides explicit guidance: 'Use create_standalone_comment instead for plain text notes — this tool is for actual files.' This tells the agent when to choose an alternative and when to use this tool, leaving nothing to inference.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, which only partially cover the safety profile. The description adds no behavioral context beyond that — no mention of side effects, what happens on success/failure, required permissions, or return behavior. For a mutating create operation with sparse annotations, the description carries a burden it does not fulfill.

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 zero wasted words. The core purpose is front-loaded, and the routing guidance to the sibling tool follows immediately. Every sentence earns its place.

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

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

For a simple two-parameter create tool with full schema coverage and no output schema or nested objects, the description covers purpose and routing adequately. The main gap is behavioral detail (return/error behavior), but the tool's simplicity keeps this from being a critical omission.

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 100%, so the schema already documents both parameters (text = comment body, taskId = task to comment on, with a source hint). The description adds no syntax or format detail beyond this, so baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb ('Add') and resource ('free-text comment/note to a standalone task'). It clearly distinguishes this from the sibling create_standalone_attachment by explicitly noting this tool is text only, so an agent can tell them apart without opening schemas.

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

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

The description explicitly names the alternative (create_standalone_attachment) and the condition that selects it ('for files/images — this tool is text only'). This is clear routing guidance, though it doesn't cover positive selection criteria beyond the obvious 'add text to a task' case.

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=false and destructiveHint=false, so the description doesn't need to restate that. It adds context about the label's role (attachable to tasks) but does not disclose return values, idempotency, or error conditions. Since annotations cover the safety profile, the description provides adequate but not rich behavioral context.

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

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

The description is two sentences with zero waste. The primary action and purpose are front-loaded, and the alternative is placed at the end. 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 creation tool with full schema coverage and no output schema, the description tells the agent what the tool does, when to use it, and how to integrate it (via labelIds). It lacks return-value details, but that is often optional and not critical for a create operation. The description is complete enough for an agent to call it correctly.

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

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

The input schema covers 100% of the parameters with descriptions (name, color, projectId), so the description adds no additional parameter meaning. Baseline 3 is appropriate given the 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 states a specific verb 'Add' and a specific resource 'a new label to a standalone project'. It further clarifies the purpose ('so it can be attached to tasks via create_standalone_task/update_standalone_task's labelIds') and explicitly distinguishes from update_standalone_label by naming it. This makes the tool's function unambiguous and clearly separable from 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 explicitly names the alternative tool (update_standalone_label) and the exact condition for using it ('rename/recolor an existing one'). It also implies the usage context (creating a new label for later attachment to tasks) by referencing the task tools. This is clear when/when-not guidance.

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

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

Annotations already signal readOnlyHint=false and destructiveHint=false, so the mutation nature is covered. The description adds meaningful behavioral context beyond the schema by disclosing that the project is seeded with default statuses, which tells the agent what side effect to expect. It does not mention permission requirements or duplicate key behavior, but for a simple create tool this is sufficient.

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

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

The description is two sentences with no filler. The core purpose is front-loaded, the unique seeded-status behavior is included, and the usage guidance is appended in a compact second sentence. Every word earns its place.

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

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

For a simple create tool with 100% schema coverage, no nested objects, and no output schema, the description provides everything needed to select and invoke it correctly: the action, the unique initialization behavior, and a clear usage boundary. A return-value format is not required for correct invocation here.

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 100%, so the input schema already documents all three parameters (key, name, description). The description does not add parameter-level detail, but it does not need to: the baseline of 3 applies because the schema carries the semantic load.

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

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

The description states a specific action ('Create a new standalone project') and a concrete resource, and adds a unique behavioral detail: it is seeded with default To Do/In Progress/Done statuses. This clearly distinguishes it from siblings like update_standalone_project, get_standalone_project, and delete_standalone_project, so an agent can confidently select it.

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 says when to use this tool ('work that has no external tracker') and when not to use it ('for work already in Jira or Trello, use that provider's own tools instead'). This is direct, actionable guidance that prevents misuse and names the alternative category.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds that this tool 'only adds a new column,' clarifying it is a non-destructive creation operation with a limited scope. It does not disclose potential side effects like duplicate-name behavior or effects on existing tasks, but for a creation tool with these annotations, the description provides adequate extra context.

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

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

The description is two sentences with no filler. The primary action is front-loaded, and the alternative-tool routing is compactly placed in the second sentence. Every word earns its place.

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

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

For a creation tool with five well-documented parameters and clear sibling differentiation, the description is complete. It tells the agent exactly when to use this tool, what it does, and which tools cover adjacent operations. No critical information needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema, including enums and examples. The description adds no additional parameter-level meaning, which is acceptable given the schema's thoroughness. Baseline 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 opens with a specific verb and resource: 'Add a new custom status (workflow column) to a standalone project.' It also explicitly distinguishes itself from sibling tools by naming what it does not do (rename/recategorize, reorder), making it immediately clear what this tool is for.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: 'Use update_standalone_status instead to rename/recategorize an existing one, or reorder_standalone_statuses to change column order — this tool only adds a new column.' This directly tells the agent which sibling to choose for other operations.

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) that is not destructive (destructiveHint false). The description adds no additional behavioral details such as permissions, reversibility, or side effects, beyond implying the task is mutable. Given the annotations cover the safety profile, a neutral score of 3 is appropriate.

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 redundancy. The primary action is front-loaded, and the guidance on follow-up tools is concise. Every word serves a purpose, making it optimally concise and well-structured.

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

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

For a creation tool with 8 parameters (all described in schema) and no output schema, the description is adequate but lacks a mention of the return value or any side effects. It does not explain what happens on success or how to verify creation, but the schema covers parameters sufficiently. The absence of output schema means return behavior is unspecified, which is a minor gap for an agent.

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

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

Schema coverage is 100%, so every parameter is documented in the input schema. The description does not add any parameter-specific meaning or usage nuances beyond what the schema provides. It merely references other tools, not parameters, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool creates a new task in a standalone project, using a specific verb and resource. It differentiates from sibling creation tools (e.g., create_standalone_comment, create_standalone_label) by targeting tasks specifically, and it names related post-creation tools (update_standalone_task, reorder_standalone_tasks), reinforcing 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?

It explicitly instructs when to use this tool versus alternatives: 'Use update_standalone_task afterward to change any field, or reorder_standalone_tasks to place it precisely within its column.' This gives clear context for subsequent actions and implies this tool is for initial creation, leaving no ambiguity about its role.

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?

Although annotations only give readOnlyHint=false and destructiveHint=false, the description discloses rich behavioral detail: all-or-nothing validation, parents-first creation order, child-skipping on mid-batch failure, per-item results, and non-idempotence. This goes far beyond the annotations and tells the agent exactly what to expect.

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

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

The description is long but every sentence carries essential operational information. It is front-loaded with the core use case, then proceeds through validation, ordering, failure behavior, return shape, and idempotency without filler.

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

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

For a complex batch mutation with 2 required parameters, hierarchy semantics, failure modes, and no output schema, the description is complete. It covers return structure, per-item results, validation rules, ordering, parent-child handling, and retry guidance, so an agent can invoke and interpret the result correctly.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: localRef can be any unique label, parentRef may appear before or after its parent, parentId points to an existing task, and tasks default to the 'todo'-category status. It also clarifies the relationship between the three parent-related fields.

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

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

The description opens with a specific verb and resource: 'Create up to 50 tasks in one standalone project in a single call.' It explicitly distinguishes itself from create_standalone_task by stating when to use this bulk variant, so an agent can immediately tell the two apart.

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

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

It names the alternative explicitly: 'use this instead of create_standalone_task when breaking a plan into several tasks.' It also gives precise guidance for hierarchy construction (localRef vs parentRef vs parentId) and for retry behavior after timeouts, telling the agent to call list_standalone_tasks before retrying.

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 set destructiveHint=true and readOnlyHint=false, so the description doesn't need to repeat basic safety. It adds 'Permanently' (irreversibility) and explains the stale-doc use case, which is useful. However, the false 'no update tool' claim adds misleading context beyond what annotations provide, slightly undermining 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 first sentence is compact and effectively front-loaded. The second sentence attempts to add context but includes an inaccurate statement about update tool availability, making it not only unnecessary but harmful. Overall size is reasonable, but the content earns a middle score due to the misleading extra.

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

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

For a one-parameter delete tool, the core information (what, how, why) is present Specialist. However, the claim about no update tool is a notable contextual error, and there is no mention of return values or idempotency. The description misses the opportunity to correctly route between delete and update, leaving the agent potentially confused when update_knowledge_doc is clearly available.

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 fully documents the single 'id' parameter with a clear source ('from list_knowledge_docs'). Schema description coverage is 100%. The tool description adds no additional parameter-level detail, so the 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 the action: 'Permanently delete a knowledge/documentation entry by id.' It identifies the specific resource type ('knowledge/documentation entry') and the operation (delete), distinguishing it from the standalone delete tools in the sibling list. The mention of create_knowledge_doc also clarifies its place in the create/delete lifecycle.

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 claims 'there is no update tool yet,' but the sibling list includes update_knowledge_doc, making this statement factually wrong and misleading. It incorrectly steers an agent toward delete+recreate when an update tool exists. No alternatives or when-not-to-use scenarios are accurately 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?

While annotations already declare destructiveHint=true and readOnlyHint=false, the description adds the critical detail that the operation cannot be undone. This goes beyond the annotation flags and provides important context about irreversibility.

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 filler. The essential action and a key warning are front-loaded, making it easy to parse quickly.

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

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

For a simple deletion tool with full schema coverage and clear destructive annotations, the description is sufficient. No output schema exists, and it is not necessary to explain return values for a delete operation. The irreversibility warning adds important 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 description coverage is 100%, and both taskId and attachmentId have clear descriptions. The tool description does not add any extra semantic detail beyond what the schema already provides, so the 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 the action (delete), the resource (attachment), and the scope (standalone task). It is distinct from sibling delete tools for comments, labels, projects, etc., making it easy for an agent to select the correct 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?

The description implies usage is for standalone tasks, but does not explicitly state when to use this tool over alternatives or when not to use it. There is no mention of non-standalone attachments or other deletion tools, leaving some inference required.

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 include destructiveHint=true, but the description adds the important behavioral trait that the deletion cannot be undone)Skip. This clarifies permanence beyond the annotation. It does not detail permissions or side effects, but the added irreversibility is meaningful for a destructive 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 short sentences, no filler. The core action is stated firstabb, and the critical caveat about irreversibility is included without bloat. Every word earns its place.

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

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

For a simple delete operation with two fully documented parameters and no output schema, the description is nearly complete. It identifies the resource, confirms irreversibility, and the schema covers the parameters. It lacks only minor practical details like expected return values or failure behavior, but these are not essential for a straightforward deletion.

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 100%, so both taskId and commentId are already documented in the input schema. The description does not add additional parameter semantics beyond restating the resource context, so the baseline 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 states a specific verb ('Delete'), a specific resource ('a comment'), and the scope ('from a standalone task'). This clearly distinguishes it from siblings like delete_standalone_attachment, delete_standalone_task, and the create/list comment tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools like list_standalone_comments for obtaining a commentId. Usage context is only implied by the wording 'Delete a comment from a standalone task.'

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, so the description doesn't need to repeat that. It adds valuable context by explaining the cascade effect: 'Automatically removed from any tasks that had it — no need to update those tasks' labelIds yourself first.' This discloses what gets affected beyond the label itself, which is crucial for an agent to predict consequences.

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

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

The description is two concise sentences. The first states the primary action and scope; the second explains a critical side effect. There is no fluff, and the most important information is front-loaded.

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

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

For a simple tool with two parameters and no output schema, this description is complete. It explains the action, the scope, and the side effect, while the annotations cover destructiveness. Nothing essential is missing for an agent to call it correctly.

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

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

The input schema has 100% description coverage for both parameters, so the schema already fully documents projectId and labelId. The description does not add extra semantic detail about the parameters beyond what is in the schema. Baseline 3 applies.

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

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

The description clearly states the action ('Delete a label') and the resource ('from a standalone project'), and distinguishes it from sibling delete tools by specifying the target. It also adds a key behavioral detail (automatic removal from tasks) that further clarifies its specific purpose.

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

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

The context is clear: this tool is used to delete a standalone label. It does not explicitly mention alternatives or when not to use it, but the name and description make the use case obvious. No exclusions are provided, but the guidance is not misleading.

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

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

While annotations already include destructiveHint=true and readOnlyHint=false, the description adds critical behavioral context: cascading deletion of all tasks and irreversibility. This goes beyond the annotations to warn about the full impact and necessary user confirmation.

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

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

The description is compact and front-loaded: it identifies the action, the cascading effect, and the irreversibility in just two sentences. Every sentence carries important information 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?

For a simple, single-parameter destructive tool, this description is fully sufficient. It covers what is deleted, the cascading behavior, irreversibility, and the required confirmation step. No output schema is needed since the operation is straightforward and the destructive annotation is present.

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

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

The schema already fully describes the only parameter, projectId, and its source (list_standalone_projects). The description adds no additional parameter semantics beyond what the input schema provides, so the 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 states a specific verb ('Delete') and resource ('standalone project'), making the operation unambiguous. It is clearly differentiated from sibling tools like delete_standalone_task or delete_standalone_attachment by naming the exact target entity.

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 context: the tool is for deleting a standalone project appear and includes an explicit instruction to confirm with the user unless already requested. It does not explicitly name alternatives, but the destructive action and confirmation requirement guide appropriate 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?

The annotations already flag this as destructive, but the description adds meaningful behavioral detail beyond that: deletion fails when tasks reference the status unless reassignToStatusId is supplied, and the last status on a project can never be deleted. These are important, non-obvious failure modes that help an agent avoid failed calls.

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

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

A single sentence states the core action and the two most important behavioral constraints. It is front-loaded, free of fluff, and every clause earns its place.

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

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

For a destructive delete operation with complete schema coverage and destructive annotations, the description covers the critical call-affecting conditions: when it fails and when reassignToStatusId is needed. No additional information is required for an agent to decide whether the tool can be invoked correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in detail. The description mentions reassignToStatusId in the context of avoiding failure, but it does not add new parameter-level semantics beyond what the schema already provides. This matches the baseline for fully documented schemas.

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

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

The description opens with a specific verb+resource: 'Delete a custom status.' It is unambiguous about what is being acted on and is clearly distinct from sibling delete tools that target projects, comments, attachments, labels, or 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 gives useful usage context by explaining when the delete will fail and how reassignToStatusId can make it succeed. However, it does not explicitly state when to prefer this tool over an alternative or mention any when-not-to-use conditions, so the guidance is mostly implied rather than explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds meaningfully beyond them: it reveals the cascade behavior ('Also deletes all of its subtasks') and the permanence ('this cannot be undone'). This tells the agent exactly what will be destroyed, which is exactly the kind of behavioral context that annotations do not convey.

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

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

The description is a single imperative sentence with an em-dash addition. It front-loads the core purpose ('Delete a task') and packs the most important caveats (subtask cascade, irreversibility) into a short, scannable string. No filler or redundant phrasing.

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

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

For a one-parameter destructive tool with annotations already covering the safety profile and the schema describing the parameter source, this description is complete. It adds the missing behavioral specifics (cascade, irreversibility) and needs no further explanation of return values or permissions. An agent can invoke it correctly and anticipate the consequences.

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 100%, so the schema already documents that taskId identifies the task from list_standalone_tasks or get_standalone_task_by_key. The tool description adds no parameter-specific meaning, but with full schema coverage the baseline of 3 is appropriate; the schema does the necessary work.

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

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

The description starts with a specific action and resource: 'Delete a task.' It also notes the cascade to subtasks, which further distinguishes this from sibling delete tools (e.g., delete_standalone_attachment, delete_standalone_comment) by specifying the affected entity and its nested content. The resource and operation are unambiguous even without opening the schema.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance relative to alternatives. It does not mention other deletion tools, conditions, or prerequisites, leaving the agent to infer usage from the name and schema. The only contextual cue is the irreversibility warning, which is more behavioral than a usage guideline.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable non-blocking behavior and the queuePosition semantics (1 = next, null once started), which go beyond the annotations. It could mention additional status values beyond 'queued', but the provided context is strong.

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 filler. The core purpose is stated first, followed by essential usage nuance (non-blocking, polling) and queue detail. Every sentence contributes to the agent's correct invocation.

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 invocation details: how to identify the task, when to poll, and what queuePosition means. With no output schema, it could have briefly noted the possible status values (e.g., queued, running, completed) to set expectations, but the provided guidance is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so each parameter is already fully documented. The description adds the alternative usage pattern (any of the three identifiers) and the linkage to assign_to_coding_agent, but this is largely redundant with the schema text for codeAgentTaskId and taskId. No meaningful extra value beyond the schema.

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

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

The description clearly states the verb 'Get' and the resource 'current execution status of a coding agent task', with explicit lookup keys (codeAgentTaskId, taskId, taskKey). It distinguishes itself from siblings like assign_to_coding_agent by being the status getter, leaving no ambiguity about its role.

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

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

It explicitly tells the agent to use this after assign_to_coding_agent, clarifies it is non-blocking and should be polled, and provides context on queue behavior. This gives clear when-to-use guidance and sets expectations for repeated calls, differentiating it from a one-shot 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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the constraint that the tool requires the internal ID, which is useful. However, it does not provide additional behavioral details such as error handling, whether the project must be active, or whether it returns nested objects. For a read-only single-entity retrieval tool, this is adequate but not rich, so a 3 is appropriate.

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, consisting of two sentences. It front-loads the core purpose and then provides the usage guidance. Every word adds value, with no filler or redundancy.

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

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

For a read-only tool with a single parameter and no output schema, the description is complete. It covers the purpose, the expected fields, and the prerequisite for using it. The annotations handle safety, and the schema handles the parameter. There is nothing missing that an agent would need to call it correctly.

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

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

The schema already documents the single parameter (projectId) with a description, and coverage is 100%. The description does not add extra semantics about the parameter beyond what the schema provides, but since the schema fully handles it, the baseline of 3 is correct.

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 defines the tool's purpose: retrieving a single standalone project by its internal ID, listing exactly what fields will be returned (name, description, statuses, labels). It also distinguishes from siblings like get_standalone_task and list_standalone_projects, making it easy for an agent to recognize what this tool does.

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 tells the agent when to use this tool and when not to: 'Use list_standalone_projects first if you only have the project's name or key, not its internal id.' This provides direct usage guidance and routes the agent to the appropriate alternative, which is exactly what is needed.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds behavioral context by framing this as a quick health check that returns counts rather than fetching every task. This clarifies the lightweight intent and output scope.

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 filler: the first states the result and purpose, the second provides an explicit alternative. The information is front-loaded and every sentence adds value.

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

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

For a single-parameter read-only summary tool, the description fully conveys what it returns, why to use it, and when to choose an alternative. No output schema exists, but the described counts are sufficient for an agent to understand the response.

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 100% and the sole parameter projectId is already documented as coming from list_standalone_projects. The tool description does not add further parameter-level detail, so it relies on the schema, which is adequate.

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

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

The description states a specific verb and resource: it retrieves task counts for a standalone project, listing the exact statuses included. It also explicitly distinguishes itself from list_standalone_tasks, which is the closest 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 explains when to use this tool versus list_standalone_tasks, saying to use the latter when the actual task list is needed. This gives clear selection guidance without requiring the agent to infer from names alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the internal-id scoping but doesn't describe return format. With annotations carrying the safety burden, the description adds modest behavioral value, consistent with the HIGH calibration example.

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 zero waste; the core action is front-loaded and the routing guidance follows in one compact sentence.

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

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

Complete for a single-param read tool: the id source is documented in the schema, the safety profile is in annotations, and the sibling distinction is stated. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% — the taskId property description already explains it's a Mongo _id from list_standalone_tasks. The description's 'internal id' phrasing mirrors the schema, so it adds little beyond the baseline.

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

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

The description states a specific verb (get), resource (standalone task), and access method (internal id). It also distinguishes from the sibling get_standalone_task_by_key, so an agent can pick the right tool without opening either schema.

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 names the alternative (get_standalone_task_by_key) and the exact condition for choosing it (having the human-readable key like 'MF-12'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the distinction between readable key and internal id, but does not disclose additional behavior such as error handling, return shape, or behavior when the key does not exist. This is acceptable but not richly transparent.

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

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

Two concise sentences: the first states the purpose with an example, and the second provides the routing alternative. There is no redundant wording or filler.

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

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

For a simple single-parameter read-only tool, the description is complete. It specifies what the tool does, how the key is identified, and when to use the sibling alternative. Without an output schema, an agent still knows the operation is a retrieval of one standalone task.

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 100%, so the schema already documents the single 'key' parameter. The description reinforces that it is the 'readable key' with an example, but adds no meaning beyond the schema's own description.

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

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

The description clearly states the tool's action: 'Get a single standalone task by its readable key,' with a concrete example ('WR-12'). It also distinguishes itself from the sibling get_standalone_task by specifying that this tool is key-based rather than id-based.

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 says to use get_standalone_task instead when the internal id is already available. This gives the agent a clear routing rule between the two similar sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful context about projectId semantics (any project id from Jira, Trello, or standalone) and the '__global__' special value, plus that returned ids work with update/delete tools. It does not describe return format, but that's not critical for a list tool.

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

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

The description is informative but slightly verbose, with four sentences. It front-loads the main purpose and special case, then covers usage and caution. The inconsistency about the update tool adds unnecessary confusion but the structure is otherwise logical.

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

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

For a simple list tool with one parameter and no output schema, the description covers the main points: what it lists, the special '__global__' case, relation to other tools, and when to use it. The contradictory statement about update tool detracts from completeness, but the core usage is well covered.

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

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

The schema already describes projectId as a project id or '__global__'. The description adds valuable context: 'any project id you use elsewhere with mFlow — Jira, Trello, or standalone' clarifies accepted values beyond the schema's minimal description. This goes beyond what the schema provides.

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 knowledge/documentation entries) and the resource (for a project), and distinguishes it from siblings by explicitly naming update_knowledge_doc, delete_knowledge_doc, and create_knowledge_doc. The special '__global__' case adds precision.

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

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

The description gives explicit guidance to use this tool before create_knowledge_doc to check for duplicates, and explains the consequence of creating again. However, it also states 'there is no update tool yet' which contradicts the sibling list that includes update_knowledge_doc, potentially misleading the agent about available alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read. The description adds value by disclosing that download URLs are short-lived and may expire, and advises re-calling to refresh them—a behavioral trait not captured in annotations or schema. It does not contradict annotations.

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

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

Two sentences: the first states purpose and output, the second gives a practical usage tip. No filler, fully front-loaded, and every sentence earns its place. Ideal length for a simple list operation.

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

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

With no output schema, the description compensates by listing the exact return fields. The single required parameter is fully covered by the schema, and the expiration behavior is disclosed. An agent has all necessary information to invoke this tool correctly and interpret results.

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

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

The schema has 100% coverage on taskId with description 'The task whose attachments to list.' The tool description adds minor clarification by specifying 'standalone task,' but this is largely redundant with the tool name. Since the schema already documents the parameter fully, the description adds little semantic value beyond the baseline.

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

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

The description clearly states the action ('List'), the resource ('attachments'), and the scope ('on a standalone task'), and enumerates the returned fields (fileName, mimeType, size, download url). This distinguishes it from sibling tools like create_standalone_attachment and delete_standalone_attachment, and from other list tools focused on different entities.

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

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

The description implies the primary use case (fetching attachments for a standalone task) and provides a specific re-invocation condition ('Re-call this if a previously fetched url has expired'). However, it does not explicitly mention alternatives or when not to use this tool, though the resource-specific naming 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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating the affected fields and specifying chronological order, but it does not mention pagination, result format, or any access constraints. This is acceptable 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?

Two sentences, no filler. The core purpose and ordering are front-loaded, and the sibling routing is packed into the second sentence. Every word earns its place.

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

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

For a simple one-parameter, read-only list tool, the description covers scope, ordering, and differentiation from the closest sibling. There is no output schema, but the enumerated field list gives the agent a clear expectation of the result content, and no critical calling context is missing.

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

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

Schema coverage is 100% and the taskId parameter is already described as 'The task whose change history to list.' The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('List') and identifies the exact resource (field-change history for a standalone task), enumerates the tracked fields, and states the ordering ('oldest first'). It clearly differentiates from list_standalone_comments.

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

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

The description explicitly tells the agent when not to use this tool and which sibling alternative to use: 'Use list_standalone_comments instead for free-text notes, not field changes.' This is direct and unambiguous guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the scope ('comments/notes') and ordering ('oldest first'), but it does not disclose potential behaviors like pagination or empty results. This is adequate but not exceptional given the annotations.

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

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

Two short sentences with no filler. The main action and ordering are front-loaded, and the alternative routing is stated efficiently. Every word earns its place.

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

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

For a simple one-parameter read-only list tool with no output schema, the description covers what the tool does, the ordering, and the key sibling distinction. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, and the single parameter taskId is already well described in the schema as 'The task whose comments to list.' The description adds no further parameter-level meaning, so the 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 states a specific verb ('List'), a clear resource ('comments/notes on a standalone task'), and adds ordering ('oldest first'). It also distinguishes itself from list_standalone_changelog, making the tool's purpose unambiguous.

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

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

The description explicitly tells the agent when not to use this tool: 'Use list_standalone_changelog instead for field-change history... not free-text notes.' This provides a clear decision rule for choosing between sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds value by specifying the tool returns projects along with their statuses and labels, and that it reveals ids/keys. It does not mention pagination or performance, but for a read-only list tool this is acceptable.

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

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

The description is two sentences with no wasted words. The core action is front-loaded in the first sentence, and the usage guidance is compactly placed in the second. Every sentence earns its place.

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

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

For a zero-parameter, read-only tool with no output schema, the description provides enough context: it lists what is returned (projects with statuses and labels) and mentions the ids/keys. It does not detail the exact return structure or error cases, but given the simplicity, it is sufficiently complete.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description does not need to add parameter information. It appropriately focuses on the tool's output and purpose.

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

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

The description states a specific action ('List all of the user's standalone projects') and clarifies the scope ('no-external-tracker'). It also distinguishes itself from sibling tools by specifying it includes statuses and labels, and by indicating it is for discovery of ids/keys. This clearly sets it apart from list_standalone_tasks and other list tools.

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

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

The description explicitly advises 'Use this first to discover project ids/keys and each project's status/label ids' and notes that 'most other standalone tools need one of those.' This provides clear context for when to use it, though it does not explicitly name alternatives or state exclusions (e.g., 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=true and destructiveHint=false, covering the safety profile. The description adds genuine behavioral context beyond those annotations: the result is a flat list (not nested), sorted by status then position, and agents must use parentId to reconstruct the tree. Minor gaps remain (no mention of result limits or whether all statuses are included), but the disclosed behavior is substantive.

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, zero filler. The core purpose and output behavior are front-loaded in the first sentence, and the routing guidance lands in the second. Every clause earns its place.

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

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

For a low-complexity read-only tool with full schema coverage, safety annotations, and no output schema, the description carries the return-semantics burden and does so thoroughly: it explains the flat structure, ordering, and how to rebuild the subtask hierarchy, and routes count-only needs elsewhere. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the schema already documents projectId as 'The project whose tasks to list.' The description adds only the 'standalone' qualifier and implicit scope via its own text, which is marginal. With full schema coverage, the baseline of 3 applies; the description does not substantially deepen parameter meaning.

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

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

The description states a specific verb and resource ('List all tasks in a standalone project') and goes further by specifying output shape (flat list), ordering (status then position), and hierarchy semantics (parentId for subtask trees). It also distinguishes itself from get_standalone_project_summary, so an agent can reliably pick it apart from the closest sibling without opening schemas.

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 second sentence gives an explicit when-not-to-use rule with a named alternative: 'Use get_standalone_project_summary instead if you only need counts, not the full task list.' This is exactly the kind of routing guidance that helps an agent make the correct selection.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral detail by stating that the call replaces the entire order and that statusIds must be the complete existing set. It does not describe error behavior or permissions, but the central behavioral nuance is well disclosed.

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

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

Two sentences with no filler. The primary action is stated first, and the critical requirement is front-loaded in the second sentence, making the most important usage constraint immediately visible.

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 two-parameter reorder operation with complete schema coverage, the description fully conveys the required input semantics and the operation's effect. No output schema exists, and none is needed to use the tool correctly; the return value is not essential for 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?

Both parameters already have schema descriptions, so the baseline is solid. The tool description adds extra meaning by clarifying that statusIds must be 'existing' and that the operation 'replaces the whole order,' which strengthens understanding beyond the schema's phrasing.

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

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

The description states a specific action ('Reorder') on a specific resource ('a project's status columns') and distinguishes the operation from moving a single status. The name and title also align, and the sibling reorder_standalone_tasks makes the resource difference 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 makes it clear what the tool does and emphasizes the complete-set requirement, so an agent can infer when to use it. However, it does not explicitly name alternatives or state when not to use it, such as distinguishing from reorder_standalone_tasks or update_standalone_status.

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

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

Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds valuable context beyond this by stating that the tool replaces the entire column order and 'moves in any task not already on that status,' clarifying the scope of mutation. It does not mention auth requirements or rate limits, but these are not critical for a reorder operation.

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

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

Two sentences with no wasted words. The main purpose is front-loaded, followed by a clear semantic clarification and a note about what it does not do. 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 no output schema and three parameters, the description covers the essential behavior, including the 'replace entire column' semantic and the movement of tasks into the status. A minor gap is that it doesn't explicitly state what happens to tasks currently on the status that are not in taskIds, but the description implies they will no longer have that status. This is adequate for an agent to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that taskIds is 'the full ordered list of tasks that should end up with the given status' and that the operation replaces the whole column order, which is more specific than the schema's description. It also clarifies the status parameter's role.

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

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

The description clearly states the specific action ('Set the complete drag-and-drop order for one status column') and identifies the resource ('one status column'). It distinguishes itself from sibling tools like reorder_standalone_statuses (which reorders columns) and update_standalone_task (which updates task fields) by emphasizing the 'complete' ordering scope.

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

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

The description provides clear context for when to use it: when setting the entire order of a status column, and explicitly contrasts it with single-task repositioning ('it does not reposition a single task relative to its neighbors'). However, it does not name specific sibling tools or provide exhaustive when-not-to-use conditions, so it falls short of a 5.

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

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

The description thoroughly discloses side effects: default copy leaves source untouched, move deletes source after successful copy, conflict strategies skip/overwrite/rename, and the '__global__' restriction. This goes well beyond the annotations, which only indicate non-read-only and non-destructive by default.

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

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

A single well-organized paragraph that front-loads the purpose and then covers defaults and edge cases efficiently. No fluff; every sentence provides 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 bulk transfer tool with no output schema, the description covers the main behaviors and options. It could mention what happens on partial failure or if source docs are missing, but such edge cases are not essential for calling the tool correctly.

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

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

Schema coverage is 100%, so parameters are documented. The description adds context: it clarifies the meaning of 'rename' (adds '(copy)' title) and the constraint on project IDs, which is not in the schema. It adds value without redundancy.

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

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

The description states a specific action (transfer) on a specific resource (knowledge/documentation entries) between projects. It clearly distinguishes from sibling tools that add, list, update, or delete individual docs. The scope is unambiguous.

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

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

It explains the default behavior and options for mode and conflict handling, and specifies a constraint on project IDs. It doesn't explicitly state when not to use it or name alternatives, but the context is clear that this is a bulk transfer tool versus single-doc operations.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description adds genuinely useful behavioral context beyond that: partial-update semantics ('pass only the fields to change') and where the required id originates. It stops short of describing permissions, validation failures, or what a type change does to dependent fields like repoUrl.

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

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

Three tight sentences with the core action front-loaded and the id-provenance note last. No filler, though 'Mirrors delete_knowledge_doc' is only marginally useful since the relationship isn't explained.

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 an 8-parameter mutation tool with 38% schema coverage and no output schema, the description is adequate but thin. It does not explain the type enum, tags replacement semantics, or the interaction between type changes and the ADR-specific fields.

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 low at 38%, so the description carries more of the burden. It enumerates all eight field names, which helps as an inventory, but adds no meaning for tags/title/content/type and does not restate the ADR-only conditionality that the schema itself documents. Baseline-to-slightly-above 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?

States a specific verb and resource ('Update an existing knowledge/documentation entry by id') and distinguishes itself from the create/delete/list siblings by name. An agent can identify the operation without opening the schema.

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?

Gives clear context: pass only the fields to change, and the id comes from list_knowledge_docs. It routes the agent to the right source for the required id, though it never explicitly states when to prefer this over delete_knowledge_doc or create_knowledge_doc.

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

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

Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds the specific mutating actions (rename/recolor) and clarifies it operates on an existing label, which is helpful. However, it does not disclose what happens if both name and color are omitted (e.g., no-op) or any error behavior, but given the annotations cover safety, this is acceptable.

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

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

The description is two sentences with no wasted words. The primary action is front-loaded, and the alternative tool is mentioned succinctly. Every word earns its place.

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

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

For a simple update tool with 4 parameters, no output schema, and annotations covering the safety profile, the description adequately states the purpose, the target, and when not to use it. It does not mention return values or error cases, but those are not expected given the absence of an output schema and the tool's simplicity.

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

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

The input schema provides descriptions for all 4 parameters (100% coverage), including 'New display name' and 'New display color'. The description's phrase 'rename or recolor' adds minimal meaning beyond the schema, so the baseline of 3 applies. It doesn't introduce additional parameter details or clarifications.

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 ('rename or recolor') and the target resource ('an existing label on a standalone project'). It also explicitly distinguishes from the sibling create_standalone_label by naming it, so an agent knows exactly what this tool does without 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 provides explicit guidance to use create_standalone_label instead when adding a new label, which directly addresses the most likely confusion with a sibling. It does not mention other alternatives like delete or update_status, but for this tool's specific purpose the guidance is sufficient and 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 indicate the operation is mutating but not destructive. The description adds useful behavioral detail beyond annotations: only explicitly passed fields are changed化的, and statuses/labels are never affected. It doesn't cover permissions or error behavior, but for this simple update the core behavior is well disclosed.

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

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

Three short sentences deliver the purpose, the partial-update rule, and the alternative-tool routing with no filler. The most important constraint ('only touches name/description') appears early and is reinforced at the end.

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 3-parameter tool with full schema coverage locked, the description covers what the tool does, how partial updates work, and which alternatives to use. The only notable gap is not describing the response shape or invalid-projectId behavior, but given no output schema and the simple nature of the operation, this is a minor omission rather than a blocking one.

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 100%, so the schema already documents projectId, name, and description. The description adds meaningful semantics by stating that omitted name/description fields are left unchangedched and clarifying that this tool does not modify status/label fields, which is value beyond the raw schema.

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

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

The description names a specific verb ('Update') and a specific resource ('a standalone project'), then narrows the scope to 'name or description.' It explicitly says the tool 'only touches name/description,' which clearly separates it from siblings like update_standalone_status and update_standalone_label.

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

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

The description gives explicit when-to-use guidance: use it for name/description changes, and use dedicated status/label tools for statuses or labels. It also clarifies partial-update behavior ('omit a field to leave it as-is'), helping the agent decide what parameters to pass.

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=false and destructiveHint=false, so the agent knows it's a non-destructive mutation. The description adds that it modifies an existing status (not create/delete) but does not disclose side effects like role reassignment implications or permission requirements. Some context is present in the schema (e.g., agentRole behavior), but the description itself adds limited behavioral nuance 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 concise sentences: the first states the core purpose, the second provides alternatives and exclusions. No filler, and the key action 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?

For a mutation tool with 100% schema parameter coverage and no output schema, the description gives sufficient orientation: what it updates, on what resource, and how it differs from siblings. It doesn't mention edge cases like agentRole only applying to in_progress statuses, but the schema covers that. Overall complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the input schema fully documents all six parameters. The description adds a grouping of actions (rename, recategorize, assign role) that maps to parameters, but doesn't offer extra detail beyond what the schema provides. 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 states specific verbs (rename, recategorize, assign role) acting on a specific resource (existing custom status on a standalone project). It explicitly distinguishes from siblings by naming create_standalone_status and reorder_standalone_statuses, making the tool's scope unambiguous.

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

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

The description gives explicit when-to-use guidance and names alternatives: 'Use create_standalone_status instead to add a new one, or reorder_standalone_statuses to change column order without altering name/category.' This directly tells the agent when not to use this tool and what to use instead.

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

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

Annotations only state readOnlyHint=false and destructiveHint=false, so the description carries the burden of disclosing side effects. It adds crucial behavioral context: most fields are merged/partially updated, while labelIds is a full replacement list that the caller must enumerate completely. This prevents a common agent failure mode.

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 tightly packed sentences with no filler. The field list is front-loaded, and the critical labelIds warning is placed immediately after, making the most important caveat easy to notice before calling the tool.

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

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

For an 8-parameter mutating tool, the description plus a fully documented schema leaves the agent with enough to invoke it correctly: taskId source is in the schema, and the label replacement hazard is explicit. A minor gap is that no return value or post-update behavior is described, but nothing essential for selecting and invoking the tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3 because every parameter is already documented. The description adds cross-cutting semantics beyond the schema—only passed fields change, except labelIds which replaces the entire set. That extra operational guidance justifies one point above baseline.

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 ('Update'), identifies the exact resource ('a task'), and enumerates the mutable fields, distinguishing it from sibling tools that update projects, statuses, or labels. The label replacement nuance further removes ambiguity about what this tool does.

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 makes clear that this is the tool for modifying standalone task fields and emphasizes the partial-update behavior. It does not explicitly name alternatives or when-not-to-use conditions, but there is no realistic ambiguity given the tool name and sibling list.

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