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

Annotations already provide readOnlyHint false and destructiveHint false, so the description's job is easier. It adds value by disclosing the internal batch call behavior and default backlog behavior. No contradictions; openWorldHint true is not elaborated but not contradicted.

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

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

The description is well-structured with a header, bulleted Args list, and examples. It is concise, front-loaded, and every sentence provides value. No redundancy.

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

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

The description thoroughly covers parameters and usage examples, but it omits the output/return value of the tool. Since there is no output schema, the agent is left guessing what the tool returns (likely the created card). Side effects beyond the open world hint are not mentioned.

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

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

Schema description coverage is 0%, so the description carries the full burden. It defines every parameter with type, purpose, constraints (e.g., label must be configured), and examples. This significantly adds meaning beyond the bare schema.

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

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

The description clearly states 'Create a single card on a board' with a specific verb and resource. It distinguishes from sibling tools like create_checklist and create_comment, as those are for different entities. The internal batch call detail adds specificity.

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

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

The description implicitly conveys when to use (to create a card) via its name and examples, but lacks explicit guidance on when not to use (e.g., for updating cards) or alternatives. There is no contrast with related tools like update_card or move_card.

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

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

Beyond annotations (which indicate mutation but not destructive), the description clarifies that task position is based on array index and that any 'position' field is ignored. It also explains optional prepopulation. However, it does not disclose potential side effects or required permissions, which would elevate it further.

Agents need to know what a tool does to the 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: a clear intro, argument list with formatting, and illustrative examples. Every sentence adds value, and the front-loading of the primary action aids quick understanding.

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

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

The description covers usage and parameter behavior but omits the return value (e.g., created checklist ID) and does not mention prerequisites (e.g., card must exist). Given the absence of an output schema, these gaps reduce completeness for a creation tool.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose (card ObjectId, title, checklistTemplate ObjectId, tasks array with description). It adds critical behavioral detail about task ordering via array index, which the schema alone lacks.

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

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

The description explicitly states 'Create a checklist on a card' with specific verb+resource. It also mentions optional prepopulation with tasks, distinguishing it from sibling tools like kanbanzone_create_task (which creates standalone tasks). The examples reinforce the purpose.

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

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

The description provides examples but no explicit guidance on when to use this tool versus alternatives (e.g., when to create a task instead of a checklist). Usage context is implied but not clearly delineated, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage 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 write. The description adds that it appends a comment to a card, but does not disclose any additional behavioral traits (e.g., if comments are limited, or if the comment is appended to a thread). It does not contradict annotations.

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

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

The description is extremely concise: two lines of purpose and a brief example. It is front-loaded with the action and lists arguments clearly. No superfluous text; every sentence is necessary.

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

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

For a simple tool (no output schema, two mandatory parameters), the description covers the core purpose and parameters. It could be slightly improved by explicitly stating that the card must exist or that the comment is appended immediately. However, the example and clarity make it fairly complete.

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

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

The schema lacks descriptions for the parameters (coverage 0%), but the description provides meaningful context: 'card ObjectId' and 'the comment body'. This clarifies the meaning beyond the schema's pattern and length constraints, which is especially valuable given the lack of schema descriptions.

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

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

The title and description clearly state the tool creates a comment on a card ('Add a comment to a card'). The verb 'create' and resource 'comment on a card' are specific and distinct from sibling tools like kanbanzone_create_card or kanbanzone_create_checklist.

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

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

The description provides no guidance on when to use this tool versus alternatives like updating a card or adding a checklist. It does not specify prerequisites (e.g., the card must exist) or when not to use it. The example is helpful but insufficient for decision-making.

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

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

Adds important behavioral detail about default label uniqueness and auto-clearing of existing defaults. Annotations provide readOnlyHint=false, so creation is expected. No further side effects documented.

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

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

Well-structured with heading, bullet list, and examples. Every sentence is useful; no wasted words.

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

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

Covers inputs and usage well but lacks output description. No output schema exists, so return value (e.g., created label ID) is omitted. Adequate for a basic create tool.

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

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

Schema has 0% description coverage; description fully explains each parameter (board, color, description, is_default, position) with defaults and examples, adding significant 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?

Description clearly states 'Create a label on a board' with specific action and resource. Distinguishes from sibling tools that create other entities (e.g., cards, checklists).

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

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

Description indicates when to use (creating labels) but does not explicitly exclude cases or compare with alternatives like update_label. Basic guidance present.

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

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

Annotations indicate it is a write operation (readOnlyHint=false) and not idempotent. The description adds value by noting the position behavior (appended if omitted), but lacks details on authorization or other behavioral traits.

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

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

The description is concise with a clear opening sentence, a bulleted argument list, and an example. It is front-loaded and easy to scan, though the 'Args:' block is slightly verbose.

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

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

The description covers all parameters and provides an example, but it omits the return value format and error conditions. Given the absence of an output schema, some behavioral 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, format, and optionality, including examples. This adds substantial meaning beyond the schema's type constraints.

Input schemas describe structure but not intent. Descriptions should explain 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 'Add a task to an existing checklist,' providing a specific verb-resource combination that distinguishes it from sibling tools like 'kanbanzone_create_checklist' and 'kanbanzone_move_task.'

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

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

The description does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as needing a valid checklist ObjectId.

Agents often have multiple tools that could apply. Explicit usage 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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that it fetches a single board and includes optional includes, but does not elaborate on behavioral traits beyond what annotations provide. No contradiction.

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

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

The description is well-structured with a header, args list, and example. It is front-loaded with the main purpose. However, the Args list largely duplicates schema information, which could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 6 parameters (1 required) and no output schema, the description covers the essential functionality: fetching a board with optional includes and an example. It does not mention error handling or response structure beyond the format, but the parameter descriptions and example provide reasonable completeness.

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

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

The description re-iterates each parameter with brief notes, including the default for response_format and explaining the difference between markdown and json. This adds value beyond the schema, which had only 33% description coverage. The example shows usage with an optional include.

Input schemas describe structure but not intent. Descriptions should explain 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 'Fetch a single board by its publicId,' which is a specific verb+resource+identifier. This distinguishes it from sibling tools like kanbanzone_list_boards (which lists all boards) and other get tools. The example reinforces the purpose.

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

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

The description provides a clear context for fetching a single board by publicId, but does not explicitly state when to use this tool versus alternatives such as kanbanzone_list_boards or other get tools. The name and example imply the usage, but explicit exclusions are missing.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description additionally explains that the 'board' parameter is required for mirror cards to disambiguate, providing useful behavioral context beyond annotations.

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

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

The description is very concise with two short paragraphs and an example. Every sentence adds value, no filler. Front-loaded with the main purpose.

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

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

For a simple read tool, the description covers the core functionality (fetch by ID), disambiguation for mirror cards, and output format options. No output schema is needed; the description is complete given the tool's complexity and rich annotations.

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

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

Schema description coverage is low (33%), but the description adds meaning for all three parameters: 'id' (card ObjectId), 'board' (optional, for mirror cards), and 'response_format' (markdown/json). This compensates for the schema gaps.

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

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

The description clearly states 'Fetch one card by its ObjectId', specifying the verb, resource, and method. It distinguishes from sibling tools like list_cards and search_cards by focusing on a single card retrieval by ID.

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

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

The description provides an example ('Show me card 6700...') implying usage context, but does not explicitly state when to use this tool versus alternatives (e.g., search_cards) or when not to use it. The guidance is 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 readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by listing the types of events (column moves, edits, comments) and the date constraint, which are not in annotations.

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

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

Very concise with two-line description, args list, and example. Every sentence adds value with no fluff.

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

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

Covers tool purpose, all parameters, and provides example input. Does not explain return structure or pagination, but output schema is absent and the description gives a reasonable overview given the tool's simplicity.

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

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

Description explains each parameter beyond the schema: id as 'card ObjectId', start as 'ISO date', response_format with format meanings. Schema coverage is 67%, so description compensates well.

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

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

Clearly states 'Fetch the activity history for a card' with specific examples of events (column moves, edits, comments). Distinct from sibling tools like get_card or get_card_metrics.

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

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

Provides clear context with the 'starting from a date' usage and an example query. However, no explicit guidance on when not to use this tool or 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 indicate readOnly, non-destructive, idempotent, and openWorld behavior. The description adds context beyond annotations, such as that the board parameter is required for mirror cards, and that response_format controls output format. No contradictions with annotations.

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

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

The description is very concise: a header line, a bulleted list of three parameters with clear explanations, and a relevant example. Every sentence is purposeful and front-loaded. No unnecessary detail.

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

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

Given the tool has 3 parameters and no output schema, the description covers inputs well and provides an example. However, it does not describe the structure of the returned metrics (e.g., time durations per column). Since annotations are rich, this is a minor gap.

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

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

Schema description coverage is low (only response_format has schema description). The tool description compensates by explaining id (card ObjectId), board (board publicId, required for mirror cards), and response_format (enum with default). This adds significant meaning beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain 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 'Fetch time-in-column and cycle/lead-time metrics for a card.' This uses a specific verb and resource, distinguishing it from sibling tools like kanbanzone_get_card (card details) and kanbanzone_get_card_history (history).

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

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

The description implies usage through an example ('How long has card...been in each column?'), but does not explicitly state when to use this tool versus alternatives like kanbanzone_get_card or kanbanzone_get_card_history. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal extra behavioral context beyond the schema and annotations; it doesn't disclose any additional traits like rate limits or permissions.

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

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

The description is extremely concise with a single purpose line, parameter list, and an example. Every part contributes value, and the key information is front-loaded.

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

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

For a simple read-only tool with clear annotations and a small set of parameters, the description is complete enough. No output schema exists, but the example implies the response format. It adequately covers what an agent needs to use the tool.

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

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

The description lists the two parameters and provides an example, which adds meaning beyond the schema. However, the 'id' parameter's format is only described by a regex pattern in the schema; the description does not elaborate on what a label ObjectId is.

Input schemas describe structure but not intent. Descriptions should explain 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 'Fetch one label by its ObjectId', which is a specific verb-resource combination. It distinguishes from sibling tools like 'list_board_labels' and 'update_label' by focusing on a single fetch by ID.

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

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

The description implies when to use (when you have a label ID) but does not explicitly state when not to use or mention alternatives. The sibling context provides alternatives, but the description itself lacks usage guidance.

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

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

Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. Description adds context that this is an auth check returning organization name, and shows the return structure. It explains the output format parameter. No contradictions; adds value beyond annotations.

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

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

Four short sentences covering purpose, usage, return value, and two examples. No fluff; every sentence serves a purpose. Well-structured for quick comprehension.

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

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

For a simple auth check tool with one optional parameter and no output schema, the description is fully complete. It explains when to use, what it returns, and provides examples. No missing context needed by an AI agent.

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

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

Schema coverage is 100% with a single parameter (response_format) already described in schema. The description does not elaborate on parameter behavior beyond the schema, but provides example usage. Baseline 3 is appropriate as 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?

Specifically states 'Verify the configured API key works and return the organization name.' This clearly identifies the verb (verify/return) and resource (API key/organization name). The title 'Get current organization (auth check)' and description differentiate it from sibling tools like kanbanzone_get_organization, which likely provides more detailed organization info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guides usage: 'Use this first when troubleshooting setup — if it returns the org name, auth is working.' This tells when to use (setup troubleshooting) and implies alternatives (other tools for organization details). Provides clear context for selection.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details such as parameter implications (e.g., include_columns implies include_boards) and the effect of response_format, which are valuable 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?

The description is well-structured: purpose, usage guideline, detailed parameter list, and examples—all in a concise format. Every sentence adds value without redundancy.

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

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

Although there is no output schema, the description explains the response_format options and gives examples. It could be more explicit about the output structure, but it provides sufficient context for an agent to use the tool effectively.

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

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

With only 17% schema coverage, the description compensates exceptionally well by explicitly detailing each parameter's effect (e.g., 'include_members: include licensed and unlicensed member lists') and noting defaults and implications. This adds significant meaning beyond the bare schema.

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

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

The description clearly states 'Fetch the organization profile' with optional related data, specifying the verb (fetch), resource (organization profile), and scope. It effectively distinguishes from sibling tools like get_board or get_card by targeting the organization context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 specific use case: 'useful for orienting an agent at session start.' While it does not explicitly state when not to use it, the context implies it is for broad overviews, leaving specifics to 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 readOnly, idempotent, and non-destructive, so the description doesn't need to repeat those. It adds value by explaining the response_format parameter and default behavior, which goes beyond annotations.

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

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

The description is concise with two sentences and a list, front-loaded with the purpose. It includes an example and no unnecessary words.

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

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

For a simple list tool with no output schema, the description is adequate. It covers required parameters, optional parameters with defaults, and an example. Could mention return structure but not critical.

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

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

Input schema covers 100% of parameters, but the description adds clarity by providing an example for the 'board' parameter and explaining the response_format enum values. It does not rely solely on schema descriptions.

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

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

The description clearly states the tool lists board columns for a board, using specific verbs and resource. It distinguishes from sibling tools by naming the specific resource (columns) and provides an example call.

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

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

The description provides context for usage via the example and parameter explanation, but does not explicitly specify when to use this tool over alternatives. However, sibling tools have distinct purposes, making usage 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which fully describe the tool's behavioral safety. The description adds minor context about response_format options but does not disclose significant behavioral details beyond what annotations already convey. No contradictions.

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

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

The description is compact and front-loaded: the first sentence states the purpose clearly. It then breaks down parameters concisely and includes a helpful example. Every sentence adds value without redundancy.

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

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

For a simple list tool, the description covers purpose, parameters, and example. While there is no output schema, the description mentions the two response formats (markdown and json), which provides adequate context. It is complete for typical use cases.

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

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

Schema coverage is 100%, meaning the description repeats the schema verbatim. The description adds no new meaning beyond the schema for the 'board' parameter, and for 'response_format' it simply restates the enum and default. Baseline 3 is appropriate as 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 clearly states 'List board custom fields for a board.' It uses a specific verb (list) and resource (board custom fields), and the scope is well-defined. This distinguishes it from sibling tools like kanbanzone_list_board_labels or kanbanzone_list_board_columns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 includes an example query ('What custom fields does this board have?') which implies usage context, but it does not explicitly state when to use this tool versus alternatives (e.g., other list tools) or provide conditions for not using it. The usage guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds useful behavioral details: it accepts a board ID and supports markdown/json output formats. No contradictions; the description complements the annotations without repeating them.

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

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

The description is highly concise: a one-sentence purpose, a structured bullet list of arguments, and an example. Every sentence earns its place; no unnecessary words.

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

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

Given the simplicity of the tool (list labels, no output schema), the description adequately covers input parameters and an example. It does not describe return values, but the response_format parameter hints at the output nature. For a read-only list operation, this is sufficient.

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

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

Schema coverage is 100%, but the description adds significant meaning: it explains the board parameter with an example, clarifies the response_format options and default, and provides a natural language example. This goes well beyond the schema's pattern and enum.

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

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

The description clearly states 'List board labels for a board,' specifying a verb (list) and a distinct resource (board labels). It unambiguously distinguishes from siblings like kanbanzone_get_label (single label) and kanbanzone_create_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 provides clear context for usage: it lists labels for a board with a required publicId. While it does not explicitly exclude alternatives like get_label, the purpose is clear enough, and the example suggests a typical query. No direct comparison to siblings, but the context is adequate.

Agents often have multiple tools that could apply. Explicit usage 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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and side-effect behavior. The description adds parameter details but no new behavioral context (e.g., error handling, output structure).

Agents need to know what a tool does to the 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 short, with a clear main sentence followed by parameter bullet points and an example. It is well-structured and front-loaded, though the parameter section largely duplicates the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 fails to clarify the return format (e.g., list of member objects with names/IDs). The parameter details and example are helpful, but the tool's output remains ambiguous 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% and includes descriptions. The description repeats parameter details almost verbatim, adding only an example value for 'board' and clarifying the default for 'response_format'. No additional semantics beyond the schema.

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

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

The description 'List board members for a board' clearly states the action and resource. It distinguishes from sibling tools like 'kanbanzone_get_board' (board details) and 'kanbanzone_list_boards' (all boards), though it does not explicitly differentiate among all 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 example 'Who can I assign cards to on this board?' provides context for when to use the tool, but there is no explicit guidance on when not to use it or alternatives. The description does not compare with other 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 indicate it is read-only, non-destructive, idempotent, and open world. The description adds context about the optional include parameters and default response format, which is useful but does not address potential pagination or access limitations.

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

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

The description is well-structured with a clear purpose, a list of arguments, and examples. It is concise, though the argument list could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 inputs well but lacks information about the output structure (e.g., markdown vs json format details) and does not clarify the openWorldHint annotation (e.g., potential pagination or incomplete 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 description details all six parameters (include_archived, include_columns, etc.) with clear explanations and examples, greatly supplementing the minimal schema descriptions (only response_format has one).

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

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

The description clearly states 'List all boards in the organization' with optional related data, providing a specific verb and resource. It distinguishes itself from siblings like kanbanzone_get_board (single board) and other list tools for sub-resources.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The examples imply usage contexts ('What boards do I have?'), but alternative tools are not mentioned.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it includes tasks and hints at summarizing outstanding items. No contradiction.

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

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

The description is two sentences plus structured Args and Example. It is front-loaded with purpose, and every part is informative 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?

No output schema exists, and the description does not detail the return format (e.g., list of checklist objects, fields returned). It mentions 'including their tasks' but lacks specifics. Given the simple nature of the tool, it is adequate but could be more complete.

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

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

The schema has 50% description coverage – only response_format is described. The tool description explains id as 'card ObjectId', adding meaning that the schema lacks. For response_format, the schema description is more detailed, so the description adds minimal value there.

Input schemas describe structure but not intent. Descriptions should explain 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 title 'List checklists on a card' and description 'List all checklists on a card, including their tasks' clearly state the verb (list) and resource (checklists on a card). It distinguishes from sibling tools like create_checklist, update_checklist, and list_card_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 does not explicitly state when to use this tool versus alternatives, such as when to use kanbanzone_create_checklist or kanbanzone_list_card_comments. The example provides a use case but no exclusion criteria.

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

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

Annotations already declare readOnlyHint: true, destructiveHint: false, and idempotentHint: true. The description adds that results are ordered oldest first and supports two response formats, which is useful context. No contradictions; however, it does not disclose potential pagination or limits, but given the annotations, the bar is lower.

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

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

The description is concise: a single-sentence purpose, a clear parameter list, and an example. It is front-loaded with the core functionality and contains no extraneous 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?

The description sufficiently covers purpose, parameters, and return order. There is no output schema, but the description gives enough context for an agent to understand what the tool does. It could mention whether pagination exists or the structure of comment objects, but overall it is adequate.

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

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

Schema description coverage is 50% (only response_format has a schema description). The tool description compensates by describing the id parameter as 'card ObjectId' and re-explaining response_format with an example, adding meaningful context beyond the schema.

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

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

The description clearly states the tool's purpose: 'List all comments on a card, oldest first.' It uses a specific verb ('list'), resource ('comments on a card'), and ordering ('oldest first'), effectively distinguishing it from sibling tools like kanbanzone_create_comment.

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

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

The description provides an example query ('What have people said on card 670...?') that implies usage context, but it does not explicitly state when to use this tool vs alternatives (e.g., when to use list_comments vs create_comment), nor does it mention any prerequisites or when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying pagination behavior (page, count, default 20, max 100) and output format options (markdown or json), which are beyond what annotations provide. No contradiction.

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

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

The description is concise with a clear structure: a one-line summary, an Args list, and Examples. Every sentence adds value, and the examples are practical. No unnecessary content.

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

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

Given 10 parameters and no output schema, the description fully explains each parameter's meaning and usage. It includes pagination details, output format options, and illustrative examples, making the tool's behavior complete 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?

With schema description coverage at 30%, the description compensates well. It provides meaningful explanations for all 10 parameters, e.g., 'board publicId', 'comma-separated column ObjectIds', 'account ObjectId or email', 'label ObjectId or description string', 'only cards untouched for N+ days'. This adds significant context beyond the schema.

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

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

The description clearly states 'List cards on a board with optional filters and pagination.' This specific verb-resource pair distinguishes it from siblings like kanbanzone_get_card (single card) and kanbanzone_search_cards (search across boards).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 examples that imply usage contexts, but does not explicitly state when to use this tool versus alternatives like search_cards. Usage guidelines are implied rather than direct.

Agents often have multiple tools that could apply. Explicit usage 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 idempotentHint true, destructiveHint false, readOnlyHint false. The description adds minimal behavioral context beyond the action name. No contradictions.

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

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

Extremely concise: one sentence, a clean args list, and an example. Every element serves a purpose with no wasted words.

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

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

Given the tool's simplicity and annotation coverage, the description is adequate. It covers parameters and has an example. Missing return value info but no output schema exists.

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

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

Schema coverage is 0%, but the description provides clear explanations for each parameter (e.g., id is card ObjectId, board is destination board publicId, column is destination column ObjectId, position is 0-based). Examples further clarify usage.

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

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

The description clearly states the action ('Move a card') and the target ('to a different column and optionally a different board'). It distinguishes from siblings like update_card and move_task.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., move_task, update_card). The description does not provide context for decision-making or exclusions.

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

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

The description only explains parameters and gives an example, with no additional behavioral context beyond what annotations provide (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). No details about side effects or return value are given.

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

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

The description is concise and well-structured with a clear purpose, parameter list, and example. It is front-loaded and each part adds value.

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

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

The description covers the action and all parameters, but does not mention return values or side effects. Given the tool's simplicity and the presence of annotations, it is minimally adequate but has a gap in return value disclosure.

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

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

Since schema description coverage is 0%, the description compensates by describing each parameter's role. It clarifies that checklistTo can equal checklistFrom for reordering, and provides an example. However, it could explain 'position' semantics (e.g., zero-indexed) more precisely.

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

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

The description clearly states the action ('Move a task') and the resource ('task'), and distinguishes between moving between checklists and reordering within the same checklist. This differentiates it from sibling tools like update_task, which modify other properties.

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

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

The description does not explicitly state when to use this tool versus alternatives like update_task. The purpose is clear enough for inference, but no direct guidance is provided.

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

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

Annotations already indicate readOnlyHint=true, so the tool is safe to use. The description adds useful behavioral details such as relevance sorting, mirror card per-board results, and scope of search. No contradictions with annotations.

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

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

The description is well-structured with a clear summary paragraph, a specific note on mirror cards, a parameter list, and examples. Every sentence adds value without redundancy, 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?

Given no output schema, the description explains return behavior (relevance sorting, mirror cards appearing twice, board field). It covers all parameters and usage notes comprehensively. Minor omission: does not explicitly state the default response format's human-readable structure.

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

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

Schema description coverage is 67%, but the description compensates by providing detailed explanations for all parameters, including board and include_archived which lacked schema descriptions. It also specifies defaults, constraints (min 2 chars, max 100 count), and the response_format enum meaning.

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

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

The description clearly states 'Full-text search across cards' and specifies that it matches card titles and numbers, not task/comment/attachment text. This clearly differentiates it from siblings like kanbanzone_get_card (by ID) and kanbanzone_list_cards (list all).

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

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

The description provides context on when to use the tool (full-text search) and includes limitations (what is not searched). It also explains mirror card behavior and provides examples, but it does not explicitly state when not to use it or compare to alternatives like list_cards or get_card.

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

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

Annotations indicate non-read-only, non-destructive, idempotent, open world. The description adds that 'Only included fields are changed' and explains board requirement for mirror cards, enhancing transparency without contradiction.

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

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

The description is a well-structured docstring with a clear purpose, parameter list, and examples. Every sentence adds value without redundancy.

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

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

While the description explains parameters and usage, it does not mention the return value or error behavior. Given no output schema, this omission reduces completeness 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?

With 0% schema coverage, the description compensates fully by explaining each parameter's meaning, types (email, ObjectId, ISO date), and providing usage examples for customFields and labels.

Input schemas describe structure but not intent. Descriptions should explain 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 'Update fields on an existing card' with a specific verb and resource. It distinguishes from sibling tools like create, move, and delete operations.

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

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

The description explains when to use this tool (to update an existing card) and includes examples, but does not explicitly state when not to use it or provide alternatives like move_card or update_checklist.

Agents often have multiple tools that could apply. Explicit usage 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 idempotent and non-destructive behavior. The description adds no further behavioral context (e.g., no mention of side effects, permissions, or rate limits). It neither contradicts nor enriches the annotations.

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

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

The description is brief and well-structured with clear sections (Args, Examples). While efficient, it could be more concise by merging the examples into the parameter descriptions.

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

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

For a simple mutation with three parameters and no output schema, the description covers the necessary information: what the tool does, the parameters, and usage examples. However, it omits return value or error handling expectations.

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

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

Schema description coverage is 0%, but the 'Args' section restates parameters with types and constraints, and the examples illustrate real usage (e.g., referencing a checklist by ObjectId). This adds practical meaning beyond the bare schema.

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

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

The description clearly states 'Update title or position of a checklist on a card,' specifying the verb (update), resource (checklist), and scope (on a card). This distinguishes it from siblings like 'create_checklist' (creation) and 'update_card' (different resource).

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

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

The description lacks explicit guidance on when to use this tool versus alternatives (e.g., if the intent is to reorder tasks, use 'move_task'). While the sibling context provides differentiation, the description itself does not preempt misuse.

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

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

The description explains the side effect of setting 'is_default: true' (clears others) and that only included fields are changed. Annotations already indicate idempotentHint and non-destructive nature, but the description adds valuable 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 well-structured with an overview, Args list, and Examples. It is clear but could be slightly more concise (e.g., combining some sentences).

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

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

For an update tool, it covers the main behavior and side effects adequately. However, it does not mention the return value (e.g., whether it returns the updated label or a success status), which could be useful for agents.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: each parameter is explained with type, constraints, and meaning in the 'Args' section, with examples providing practical use cases.

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

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

The description uses specific verbs ('Update') and resource ('label'), and the examples clarify usage. It clearly distinguishes itself from siblings like 'create_label' and 'get_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 tool's purpose is evident from the name and description, but no explicit guidance on when to use this over other update tools (e.g., update_card) is given. The examples provide concrete scenarios.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description reinforces by stating only included fields change. It additionally discloses behavioral constraints like completedOn only honoured when completed=true, adding value beyond annotations.

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

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

The description is highly concise: a single sentence stating purpose, a structured list of parameters with brief explanations, and two clear examples. Every sentence is efficient and front-loaded.

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

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

For a mutation tool with 7 parameters and no output schema, the description covers all inputs thoroughly with examples. However, it lacks information about the return value (e.g., does it return the updated task?), which would enhance completeness.

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

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

Since schema description coverage is 0%, the description's Args list provides essential meaning for each parameter, including constraints (e.g., completedOn conditional, position ≥0) and types (ObjectId, email, ISO date), fully compensating for the schema gap.

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

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

The description clearly states the verb ('Update') and resource ('existing task'), with the specific nuance that only included fields are changed (partial update). This distinguishes it from sibling tools like move_task or create_task.

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

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

The description provides examples of typical use cases (mark complete, reassign) but does not explicitly state when to use this tool over siblings like update_card, update_checklist, etc., nor does it provide exclusions or prerequisites.

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