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

With no annotations, the description discloses key behavior: it adds a single label and preserves existing labels. This covers the main behavioral traits. It does not mention error handling or idempotency, but for a simple mutation it is fairly 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?

The description is extremely concise: two sentences and a bulleted list of arguments. No extraneous information, and the structure is easy to parse. Every sentence serves a purpose.

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

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

Given the tool's simplicity, the description covers all necessary information: what it does, how to call it, and where to find the label ID. No output schema is present, but the return value is likely implied. The description is complete for effective use.

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

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

Schema coverage is 0%, so the description must compensate. It provides clear parameter descriptions: card_ref format with a concrete example, and label_id usage referencing list_labels(). This adds meaning beyond the schema's type-only definition.

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: 'Add a single label to a card, preserving existing labels.' It specifies the verb (add), the resource (card), and the effect (preserving existing labels), which distinguishes it from the sibling 'remove_card_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 mentions 'Use list_labels() to find ids,' guiding the agent on how to obtain the label_id parameter. However, it does not explicitly state when to use this tool versus alternatives or provide conditions for avoidance. Given the tool's simplicity, this is acceptable but not exemplary.

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

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

With no annotations, the description partially compensates by noting return value and Markdown rendering. However, it lacks detail on error cases, permissions, or side effects.

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

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

Concise and well-structured: two sentences for purpose, then clear parameter descriptions. No filler.

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

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

For a simple 2-param tool with no output schema, it covers purpose, parameters, return value, and formatting. Lacks error handling or prerequisite context, but sufficient for basic usage.

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

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

Schema coverage is 0%, but the description adds examples for card_ref and explains Markdown rendering for body, adding significant meaning beyond the schema's type-only definitions.

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 the action 'post a comment on a card' and mentions Markdown support. Distinguishes from siblings like list_comments and delete_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?

Implies usage for adding comments but provides no explicit guidance on when to use versus alternatives, nor any when-not 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?

Discloses that card is hidden but recoverable, which is key. But no annotations exist, so description carries full burden; missing details on permissions, side effects, and recovery process.

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 efficient sentences convey purpose and key behavior. The Args section is redundant with schema but not harmful.

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

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

Adequate for a simple tool with one parameter, but lacks error handling, return value (no output schema), and comparison to similar siblings like move_card_to_iteration.

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 adds a format example ('ON-914') for card_ref, which the schema lacks. However, with 0% schema coverage, the minimal example only partially compensates; it doesn't explain where to find the reference.

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

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

Clearly states it archives a card by moving to Archive iteration, distinguishing it from deletion. However, it doesn't fully differentiate from sibling 'move_card_to_iteration'.

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

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

Implies usage when you want to hide but keep recoverable, but no explicit alternatives or when-not-to-use 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?

With no annotations, the description discloses the key behavioral fact that the tool replaces current assignees, which is a destructive update. This is sufficient for a simple mutation tool, though it omits details like authentication requirements or rate limits.

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 no wasted words. The main purpose is front-loaded in the first sentence, followed by parameter explanations in a clean list format.

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 or annotations, the description covers the tool's core function and parameters adequately. It lacks information about return values or error handling, but for a simple mutation, 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?

The description fully compensates for the 0% schema coverage by explaining each parameter: card_ref as 'Card reference, e.g. 'ON-914'' and assignee_ids as 'List of user IDs. Pass an empty list to unassign all.' This adds essential meaning beyond the bare schema types.

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 assignees on a card, replacing any current assignees.' The verb 'set assignees' and resource 'card' are explicitly mentioned, distinguishing it from sibling tools like 'add_card_label' or 'update_card'.

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

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

The description implies usage by stating 'replacing any current assignees' and provides guidance for unassigning ('Pass an empty list to unassign all'). However, it does not explicitly state when to use this tool versus alternative tools (e.g., 'update_card' might also set assignees) or provide any 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?

With no annotations provided, the description carries the full burden. It discloses that multiple blockers exist and that the card remains blocked until all are resolved, and returns an id for unblocking. However, it does not mention failure cases, required permissions, or side effects. The transparency is adequate but not complete.

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 one-line summary, a brief behavioral paragraph, a clear Args list, and a return note. No unnecessary words; every sentence adds value.

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

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

Given no output schema, the description mentions the return includes an 'id' needed for unblocking, which is sufficient. It covers all 4 parameters and the core behavior. It could mention that card_ref must reference an existing card, but overall it is complete for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must explain parameters. It provides an Args section with clear explanations: card_ref example ('ON-914'), reason as 'human-readable explanation', and flags for is_show_stopper and external with defaults. This adds significant meaning 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 action ('Mark a card as blocked with a reason') and the outcome ('Creates a blocker record on the card'). It also explains key behavior (multiple blockers, card remains blocked until all resolved), distinguishing it from siblings like unblock_card and list_blockers.

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 (to block a card) and hints at the process (multiple blockers, need id to unblock). It lacks explicit when-not-to-use or direct comparisons to alternatives, but the context of siblings and the mention of unblock_card indirectly guide 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?

No annotations provided, and the description does not disclose behavioral traits like destructiveness, side effects, or permission requirements. It only states the action without additional 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 very short and to the point, with a clean structure. Could be slightly more compact, but efficient overall.

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 no annotations, the description is incomplete. It lacks information on return values, error handling, and behavioral context, which is insufficient for a tool with two required parameters.

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

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

The description adds minimal parameter information (example for card_ref, source hint for task_id) beyond the input schema, which has 0% coverage. While helpful, it does not fully compensate for the low 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 'Mark a task as complete' uses a specific verb ('Mark') and resource ('task'), clearly distinguishing it from siblings like 'reopen_task' and 'delete_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 guidance on when to use this tool versus alternatives such as 'reopen_task' or 'delete_task'. Lacks context on prerequisites or conditions.

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?

No annotations provided. The description only states it creates a card and returns the object, but misses behavioral traits like permissions needed, side effects (notifications), or constraints (e.g., maximum number of cards).

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?

Description is brief with a clear first sentence followed by a well-organized list. Every line adds value, though the list could be slightly more compact (e.g., grouping optional params).

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 9 params, no output schema, and no annotations, the description covers param semantics and return value adequately but omits prerequisites, error scenarios, and integration with sibling tools like list_boards or list_members.

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%, so the description carries the burden. It adds meaningful details like 'due_date: YYYY-MM-DD format', 'assignee_ids: use list_members()', and 'extra_fields: {field_id: value}'. A few params (cell_id, iteration_id) are minimally explained, but overall it significantly supplements 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 'Create a new card on the board.' with a specific verb and resource. It unambiguously distinguishes from siblings like update_card, find_card, or archive_card.

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

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., board existence) or scenarios where other tools like update_card would be more appropriate.

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

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

Description states it creates a task and returns the object, but no annotations exist to provide additional safety or side-effect info. Lacks details on permissions, errors, or idempotency.

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

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

Concise description with purpose first, then parameter list. The 'Args:' line is slightly redundant but overall 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?

Covers all parameters, return value, and basic purpose. For a simple creation tool with no output schema, it is adequately complete.

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

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

With 0% schema coverage, the description adds value by explaining each parameter, including example for card_ref and optional nature of assignee_id.

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

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

The description clearly states the tool creates a new task on a card, with specific verb and resource. It easily distinguishes from sibling tools like delete_task or complete_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 guidance on when to use this tool versus alternatives (e.g., update_task, complete_task). No context about prerequisites or 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?

With no annotations, the description must carry full burden. It indicates creation (mutation) and mentions the return of the object with id and optional secret. However, it does not disclose any side effects, permissions, or rate limits. Adequate but not detailed.

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 including an Args block. Every sentence is valuable and front-loaded with 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?

Despite no output schema, the description mentions the return value. It covers key aspects for a creation tool, though could mention validation or project scope. Complete enough for its purpose.

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

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

Schema description coverage is 0%, and the description compensates fully by explaining each parameter: url as HTTPS endpoint, events with examples, secret as optional HMAC secret. This adds significant meaning 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 clearly states 'Create a new webhook on the project,' which is a specific verb+resource. It distinguishes from sibling tools like delete_webhook and list_webhooks by focusing on creation.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied (to create a webhook), but alternatives or exclusions 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?

With no annotations, the description should disclose behavioral traits. It only states the action (deletion) but does not mention irreversibility, permissions, or consequences. The output schema exists but is not described.

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: one sentence plus two clear parameter descriptions. No wasted words, and the purpose 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 delete tool, the description covers purpose and parameter meanings adequately. Minor gaps remain in usage guidelines and behavioral transparency, but overall it's mostly complete given the tool's simplicity.

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

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

Schema coverage is 0%, so the description adds needed meaning: card_ref format via example and comment_id source via list_comments(). It adds substantial 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 'Delete a comment from a card,' specifying the verb and resource. It distinguishes from sibling tools like add_comment and list_comments, and provides examples for the parameters.

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

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

The description implies usage context by mentioning that comment_id comes from list_comments(), but does not explicitly state when to use this tool vs alternatives or provide 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?

Without annotations, the description carries full burden but only states 'Delete a task from a card'. It fails to disclose permanence, side effects, or permission requirements for this destructive action.

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 for purpose and two lines for parameters. Every word earns its place, with no redundancy.

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

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

Adequate for a simple delete operation, but missing output schema expectations and error conditions. Could be improved by mentioning typical return values or failure scenarios.

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

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

The description adds concrete meaning to both parameters: card_ref gets an example format, task_id is explained as coming from list_tasks. This compensates for the input schema having zero property 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 uses the specific verb 'Delete' with the resource 'a task from a card', clearly distinguishing it from siblings like 'complete_task' or 'update_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 guidance on when to use this tool versus alternatives such as 'complete_task' or 'reopen_task'. The description only provides parameter details without 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?

No annotations provided. The description only states 'Delete', indicating mutation, but does not disclose permanence, side effects, or required permissions. Minimal disclosure.

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

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

Two sentences with no wasted words. Properly structured, front-loading the core action.

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 one parameter and an output schema, the description is adequate. It provides the parameter source, but could mention irreversibility. Still complete enough given tool simplicity.

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

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

Schema coverage is 0%, so description must compensate. It adds context by specifying 'Webhook id from list_webhooks()', indicating the source of the parameter, which is helpful beyond the bare type and title in the schema.

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

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

The description clearly states 'Delete a webhook by id.' with a specific verb (delete) and resource (webhook). Among siblings, create_webhook and list_webhooks are present, making this distinct.

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?

Implied usage: use when you have a webhook id from list_webhooks(). No explicit when-to-use or when-not-to-use, nor 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?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions needed, or error handling. For a lookup tool, stating it is read-only would improve transparency.

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

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

The description is extremely concise, with no unnecessary words. Two sentences plus an arg spec cover the essential information efficiently.

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

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

The description covers the basic purpose and parameter but lacks information about the return value (e.g., card object) or behavior when the card is not found. Given no output schema, this gap reduces completeness.

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

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

The schema has 0% description coverage, but the description adds meaning by giving an example ('ON-914') and calling it a reference ID, which helps the agent understand the parameter format.

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 finds a card by its reference ID, provides an example, and explicitly identifies it as an alias for get_card, differentiating it effectively 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 indicates when to use this tool (when you know the ID string) and that it's an alias for get_card, but does not explicitly list alternatives or when not to use it.

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

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

No annotations provided, so description carries full burden. Only states it returns matching members, but lacks details on matching behavior (partial/case-sensitive), potential multiple matches, or error handling.

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

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

Concise and well-structured; four lines with no wasted words. Efficiently conveys purpose and parameter usage.

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

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

Adequate for a simple lookup tool with one parameter and output schema present, but lacks behavioral context such as matching rules or response format details.

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?

Adds meaning beyond schema by specifying that the query can be a fragment of name, username, or email. Compensates for 0% schema description coverage.

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

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

Clearly states action (find), resource (member), and criteria (name/username/email). Distinguishes from siblings like 'list_members' by specifying a search query.

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

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

Implies usage when needing to find a specific member via query, but no explicit when-to-use/when-not-to-use or comparison to alternative tools like 'list_members' or 'search_cards'.

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

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

With no annotations provided, the description must disclose behavioral traits. It states that results are newest-first and that only log_activity entries are included. However, it does not mention that this is a read-only operation or provide details about rate limits or pagination.

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

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

The description is concise and well-structured, with a summary sentence followed by a clear Args block. No unnecessary words, and the primary 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?

Given that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, filtering options, and ordering, making it complete for its 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?

Although schema description coverage is 0%, the description thoroughly explains each parameter in the Args section, specifying formats (e.g., 'ON-914' for card_ref), filter types (substring vs exact), and case sensitivity. This adds significant meaning beyond the null descriptions in the schema.

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

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

The description clearly states it gets the structured activity log for a card, distinguishing it from related tools like get_workspace_activity (workspace-level) and list_comments (plain comments). It explicitly says it only returns entries from log_activity(), excluding plain 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 provides clear context for when to use the tool (to retrieve activity log for a card) and what is excluded (plain comments). It does not explicitly mention alternatives like get_workspace_activity, but the distinction is implied.

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?

No annotations provided, and the description only states it returns values. It does not disclose error handling (e.g., missing card, no custom fields) or side effects, but the operation is simple read-only.

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 no wasted words: purpose, return description, and parameter in three lines.

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 low complexity (1 param, simple output) and presence of an output schema, the description is nearly complete. It could mention that only card-specific fields are returned, but the context 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?

With 0% schema coverage, the description adds an example format for card_ref (e.g., 'ON-914'), providing meaningful guidance beyond the type-only 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 it gets all custom field values on a card, differentiating it from siblings like get_card_field (single field) and list_custom_fields (field definitions).

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 using this tool to retrieve all custom field values for a card, but does not explicitly state when to avoid it or mention alternatives like get_card_field.

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?

No annotations are provided, so the description must carry the burden. It indicates the tool retrieves board data (likely read-only) but does not explicitly confirm idempotency, rate limits, or any side effects. The description is adequate but not rich in behavioral detail beyond the operation type.

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 plus a parameter description. It is front-loaded with the main action. However, the parameter description could be integrated for even tighter structure. Overall, it is efficient 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 no output schema, the description explains the return values (board, cells, custom fields, statistics). It provides enough context for a simple one-parameter tool. Could elaborate on the format or exact fields, but completeness is good for the tool's complexity.

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

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

The input schema has 0% description coverage, so the description compensates by explaining the 'project_slug' parameter: 'Board slug to fetch. Defaults to the configured project.' This adds meaning beyond the schema's type and default, helping the agent understand 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 verb 'Get' and the resource 'board (project)' along with what is returned (cells, custom field definitions, and key statistics). This distinguishes it from siblings like list_boards (which lists boards) and get_board_cells (which only fetches cells).

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

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

The description mentions the purpose but provides no explicit guidance on when to use this tool versus alternatives. It does not state when not to use it or point to siblings like list_boards for listing or get_board_cells for just cells. Usage is implied but not clarified.

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

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

With no annotations, the description carries full burden. It explains the output (id, name, position) and indicates a read operation. However, it does not disclose any limitations, rate limits, or authorization needs. The behavioral context is minimal but adequate for a simple 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 exceptionally concise with two clear sentences and an args section. No wasted words; every sentence adds value. Front-loaded with the main action.

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

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

Given the tool's simplicity (one optional parameter, output schema exists), the description covers purpose, output fields, and a usage hint. No significant gaps remain 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 coverage is 0%, but the description adds meaning: 'project_slug: Board slug. Defaults to the configured project.' This clarifies the parameter's purpose and default behavior beyond the schema's title. Since only one parameter exists, the 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?

The description clearly states it lists columns (cells) of a board, with specific fields id, name, position. It distinguishes from siblings like get_board or list_boards by targeting cells specifically. The mention of using the id for moving cards adds practical 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 implies usage for moving cards but does not explicitly state when to use this tool versus alternatives like list_cards or other board tools. No exclusions or alternatives are mentioned, providing only implicit 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?

No annotations provided, so description shoulders full burden. It says 'get a card's full detail' implying read-only, but fails to explicitly confirm non-destructive behavior or disclose any side effects, permissions, or 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?

Two brief sentences: first states purpose and return content, second details the argument. No filler, front-loaded, every sentence earns its place.

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

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

Adequate for a simple read tool with one parameter. Lacks mention of whether it's read-only (though implied) or any prerequisites. With no output schema, the list of returned fields helps but could be more explicit.

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?

Only one parameter, card_ref. The description adds an example format ('ON-914' or 'Q1-42') which the schema (0% coverage) lacks. This provides meaningful guidance 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?

Description uses specific verb 'Get' and resource 'card' with explicit list of included details (custom fields, task list, etc.), distinguishing it from siblings like find_card or get_card_field.

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/when-not to use or alternatives. The purpose is clear from name and context, but no guidance on preferring this over siblings like get_all_card_fields or find_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?

Clearly describes the return format including both success case and null case when the field is not set. No annotations provided, so the description fully handles behavioral disclosure for a read-only 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?

Extremely concise, covering purpose, args, and return values in three lines. No unnecessary information.

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

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

Given no output schema, the description fully documents the return structure. It covers both parameters and the two possible return cases, making it complete for a simple getter 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 provides meaningful examples and source for both parameters: card_ref gets an example (ON-914), field_id identifies its source (list_custom_fields()). This adds substantial 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?

Specifies exactly what it does: 'Get the current value of a single custom field on a card.' Distinguishes itself from siblings like 'set_card_field' and 'get_all_card_fields' by focusing on a single field and read-only operation.

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

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

Mentions that field_id comes from 'list_custom_fields()', implying a prerequisite. However, it does not explicitly state when to use this tool versus alternatives like 'get_all_card_fields' for retrieving all fields at once.

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

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

With no annotations provided, the description takes on the full burden. It explains aggregation of log_activity entries from all cards, sorting newest-first, and notes that it scans recent cards (though 'recent' is not precisely defined). This is sufficient transparency, though a bit more clarity on the time window would improve it.

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 main sentence, examples, parameter details, and a usage note. It is slightly longer than necessary but remains focused and easy to parse.

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

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

Given the presence of an output schema, the description need not detail return values. It covers filtering, scope, and alternative tools. Some details about pagination or time limits are missing, but overall it provides adequate context for the tool's complexity.

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

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

Schema description coverage is 0%, but the description includes a detailed 'Args:' section explaining each parameter's filtering behavior (e.g., substring vs exact match, default limit). This adds significant value beyond the property names.

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 'Get the activity log across ALL cards in the workspace,' specifying the verb and resource clearly. It distinguishes itself from the sibling tool get_activity_log, which is a per-card view, by emphasizing the workspace-level 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 includes explicit guidance: 'for large boards use per-card get_activity_log() for targeted queries.' It also provides example questions that illustrate common use cases, helping the agent decide 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?

With no annotations, the description carries the burden. It discloses that only active (unresolved) blockers are listed and enumerates the returned fields. However, it does not mention side effects, prerequisites, error handling, or pagination behavior.

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

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

The description is extremely concise: three sentences covering purpose, return fields, and argument definition. It is front-loaded with the core action and avoids all extraneous text.

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

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

Given the simple tool (one parameter, output schema present), the description covers the essential purpose, argument, and return fields. It could mention behavior on invalid card_ref or if no blockers exist, but overall it is sufficient for an AI agent to understand the tool's usage.

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

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

The input schema has 0% description coverage, but the description provides a clear definition for card_ref: 'Card reference, e.g. ON-914'. This adds meaning beyond the schema, explaining the format and usage. The single parameter is well-addressed.

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 'List all active (unresolved) blockers on a card', providing a specific verb and resource. It distinguishes from siblings like block_card and unblock_card, which are mutating actions. The list of returned fields further clarifies 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?

No explicit guidance on when to use this tool versus alternatives such as block_card or unblock_card. The description implies usage for viewing blockers, but lacks direct comparisons or conditions 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?

No annotations are provided, so the description must bear the full responsibility for behavioral disclosure. It correctly indicates the tool returns board metadata without side effects (no destructive hint), but it does not mention authentication requirements, response format beyond fields, or performance characteristics. It is adequate but not exceptional.

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 at three sentences, front-loading the main action in the first sentence, then listing returned fields and providing a usage alternative. 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 parameters and the presence of an output schema (which likely defines the return shape), the description is complete. It tells the agent exactly what the tool does and what it returns, and it provides a pointer to a related sibling for deeper detail.

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 zero parameters (schema description coverage 100%), so the baseline is 4. The description does not add parameter information because none is needed.

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

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

The description clearly states the tool lists all boards (projects) in the organisation, specifying the returned fields (slug, name, description, member count). It also distinguishes itself from the sibling tool get_board() by directing users to that tool for full detail on a specific board.

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 alternative: 'Use get_board() for full detail on a specific board.' This guides the agent on when to prefer this tool over a sibling. However, it does not explicitly mention when not to use it, though the guidance is sufficient for most cases.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It describes the return format (dict with count, next/previous page URLs, items list) and details item fields, implying a read-only operation. It could be more explicit about non-destructiveness, but overall it provides useful behavioral context.

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

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

The description is concise and well-structured: a brief opening sentence, an 'Args:' section with clean parameter definitions, and a 'Returns' section. Every sentence serves a purpose with no redundancy or filler.

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

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

Given 7 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all parameters, specifies their types and defaults implicitly, and describes the return structure in detail. No critical information is missing for an AI agent to use 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 description coverage is 0%, so the description must compensate. It does so excellently by providing a clear explanation for each of the 7 parameters, including what each filter does (e.g., 'Filter by board column (cell) id') and defaults/max values for page and limit. This adds significant meaning 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 clearly states 'List cards on the board with optional filters,' which specifies the action (list), resource (cards), and scope (on the board). It distinguishes itself from sibling tools like 'search_cards' and 'find_card' by focusing on listing with filters.

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

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

The description explains that filters are optional and lists available filter parameters, implying usage when listing cards with specific criteria. However, it does not explicitly state when not to use this tool or provide guidance on alternatives like 'search_cards' for full-text search.

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?

No annotations provided, so description carries full burden. It discloses that the tool returns a list of comments with specific fields, and that results are sorted newest first. However, it does not mention error conditions, rate limits, or permissions. For a straightforward list tool, this is minimally 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?

Description is concise, starting with the core purpose and then specifying the argument and return format. It could be slightly more compact, but it is well-structured and easy to parse.

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

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

Given that an output schema exists (though not shown), the description adequately covers the return structure. The single parameter is well explained. For a list tool, this provides sufficient context 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 0%, so description compensates by explaining card_ref: 'Card reference, e.g. ON-914. The card's numeric id is resolved automatically.' This adds meaningful context beyond the schema definition.

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 the action (list all comments), the target (on a card), and the ordering (newest first). Distinguishes from sibling tools like add_comment and delete_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?

Describes when to use (to list comments) but does not mention when not to use or suggest alternatives. For a simple read tool, it's adequate but lacks explicit 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?

No annotations provided. Description explains it lists definitions, not values, and notes default behavior for project_slug. Lacks details on side effects or permissions but adequate for a read-only 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?

Four sentences plus Args section. Front-loaded with main purpose. No unnecessary words. 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 tool with one optional param and output schema existing, description explains output structure (id, name, field_type, choices). Sufficient for agent to use.

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

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

Schema has 0% description coverage. Description adds meaning: 'Board slug. Defaults to the configured project.' Compensates well beyond 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?

Clearly states verb 'list' and resource 'custom field definitions' for the board. Distinguishes from siblings like set_card_field and update_card.

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

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

Provides explicit guidance on using the id with other tools (set_card_field, update_card). Does not mention when not to use, but context is clear.

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

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

No annotations exist, so the description must disclose behavior. It only says 'list all epics,' implying a read operation, but omits details on scope (what is the 'configured project'?), pagination, or side effects. This is insufficient for safe invocation.

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

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

The description is extremely concise with two short sentences. No redundant or irrelevant information is present.

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

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

Given the simple tool (one optional param, output schema exists), the description is moderately complete. It covers the basic purpose and parameter default, but lacks details on result format, filtering, or entity type ('epics'), which could be important for correct use.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains that project_slug is a 'Board slug' with a default behavior, which partially compensates. However, it does not define 'board slug' or clarify the relationship between boards and projects.

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 epics in the project,' using a specific verb and resource. It differentiates from sibling list tools (e.g., list_cards, list_tasks) by naming the resource 'epics', though it does not explain how epics differ from similar 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?

No guidance is provided on when to use this tool versus alternatives. With many sibling list tools, explicit usage context (e.g., when to list epics vs. cards or tasks) would help, but it is absent.

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?

No annotations are present, so the description must disclose behavioral traits. It only states that it lists all iterations, but does not mention whether it is a read-only operation, any side effects, or security considerations.

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

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

The description is extremely concise: two sentences that state the purpose and parameter. Every part serves a clear function with no redundancy.

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

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

Given the simplicity of the tool and the presence of an output schema, the description is largely complete. It covers the main action and parameter, though it could briefly mention what type of iterations are listed (e.g., active or all).

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

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

The description explains the parameter project_slug, noting that it is optional and defaults to the configured project. However, it does not deeply define 'Board slug' or 'configured project', so the added value is moderate.

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

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

The description uses the specific verb 'list' and resource 'iterations' and clarifies that iterations are sprints or milestones. It clearly distinguishes from sibling tools that list other resources like boards or cards.

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

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

No guidance is provided on when to use this tool versus alternatives, nor does it mention prerequisites or context. The description only states the action without any usage advice.

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?

No annotations are provided, so the description bears full burden. It states the operation is a list, but does not mention side effects, authentication needs, or whether all labels are always returned. For a simple read-only tool, this is adequate but not exceptional.

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, including a structured Args section. It is appropriately sized for the tool's simplicity.

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 that an output schema exists (so return values need not be described), the description covers purpose and the single parameter. It is complete for the task complexity and sibling 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?

The description explains the one parameter 'project_slug' with meaning and default behavior, adding value beyond the schema which only has type and title. Schema coverage is 0%, so this compensation is strong.

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 labels defined in the project,' using a specific verb and resource, which distinguishes it from sibling tools like add_card_label and remove_card_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 does not provide explicit when-to-use guidance or compare with alternatives, but the purpose is clear enough for an agent to infer usage context.

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

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

No annotations provided. Description only lists output fields but lacks behavioral traits such as authentication requirements, read-only nature, or pagination. Bare minimum disclosure.

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

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

Three sentences: purpose, output fields, parameter usage. Efficient, front-loaded, no redundant information.

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

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

Adequate for a simple listing tool with one param and output schema present. Could briefly mention it's a read operation but otherwise 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?

Single parameter 'project_slug' is fully explained with conditional behavior (returns project-level vs org members), adding semantic meaning 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?

Description states 'List members of the organisation or a specific project' with clear verb+resource. Distinguishes from sibling 'find_member' by focusing on listing vs searching.

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 guidance on when to use the project_slug parameter to scope to project-level members, but does not explicitly differentiate from sibling tool 'find_member'.

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

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

With no annotations, the description carries full burden. It implies a read operation but does not explicitly state read-only or non-destructive nature, nor any side effects or permissions needed.

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 plus an argument line. Every sentence adds value, no waste. Front-loaded 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 list tool with one parameter and output schema present (implied by description), the description covers key aspects. Missing some detail like ordering or optional parameters, but adequate for its simplicity.

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

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

Schema coverage is 0%, but description adds meaningful context: 'Card reference, e.g. 'ON-914'.' Provides an example and indicates format, though it could clarify source or validation.

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 'List all tasks (checklist items) on a card.' It specifies the verb (list), resource (tasks on a card), and scope (all tasks). Distinguishes from sibling task tools by referencing checklist items and card reference.

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

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

No guidance on when to use this tool versus alternatives like complete_task or create_task. Does not mention prerequisites or context where listing would be appropriate.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation ('list') without mentioning permissions, rate limits, or other behavioral traits. The description is adequate but lacks depth on potential side effects or restrictions.

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

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

The description is extremely concise—two sentences plus a parameter explanation—with no extraneous information. Every sentence contributes value.

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

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

Given the simple tool (one optional parameter, output schema exists), the description covers the main functionality and parameter behavior. It does not specify whether time entries are user-specific or scope of 'project', but this is minor. Overall sufficient for correct invocation.

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

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

The input schema has no descriptions for parameters (0% coverage), so the description compensates by explaining 'card_ref' and providing an example ('ON-914'). This adds significant meaning beyond the schema 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 clearly states the tool lists time entries, optionally filtered by a card reference. It uses a specific verb ('list') and resource ('time entries'), and distinguishes from siblings like 'log_time' which performs a different operation.

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

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

The description explains that omitting card_ref returns all project time entries, implying usage for reading time data. However, it does not explicitly state when to use this tool versus alternatives (e.g., log_time), nor does it provide 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?

No annotations provided, so description carries full burden. States it returns data but omits any behavioral traits like read-only nature, permissions, or side effects. Adequate for a simple list operation but lacks depth.

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

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

Two concise sentences: first for purpose, second for return structure. No wasted words, front-loaded with key action.

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 zero parameters and presence of output schema (as per context), the description covers purpose and output fields adequately. Lacks mention of scoping (e.g., project-wide) but sufficiently complete for a simple list tool.

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

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

Input schema has 0 parameters and 100% coverage, so description does not need to explain parameters. Adds value by describing output fields, meeting baseline for no-param tools.

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 'List all webhooks configured on the project' with specific verb and resource. Differentiates from siblings like create_webhook and delete_webhook by focusing on listing. Also specifies returned fields (id, url, events, active state).

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

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

Implies usage when needing to view existing webhooks, but provides no explicit context for when to use vs alternatives (e.g., create or delete). No when-not or alternative tool mentions.

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?

No annotations provided, so description carries full burden. It clearly states entries are stored as machine-parseable comments, rendered in UI, and filterable. It also documents side effects by specifying it returns the created comment object. However, it does not mention required permissions 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 well-structured with a header line and parameter list, but it includes some redundancy (e.g., 'Args:' could be omitted). Still, it earns its sentences and is front-loaded with the core purpose.

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

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

Given 9 parameters, 2 required, no output schema, and no annotations, the description is comprehensive. It explains what the tool does, how data is stored, and specifies return value. It also provides example values for the 'action' parameter, making it actionable.

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% (no parameter descriptions in schema). The description compensates fully by providing clear, detailed explanations and examples for each parameter, especially 'action' and 'detail', adding significant meaning beyond the schema.

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

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

The description uses specific verbs ('Write') and resources ('structured activity log entry to a card') and distinguishes from siblings like 'add_comment' by noting that entries are machine-parseable and filterable via 'get_activity_log'.

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

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

The description implies use for activity logging with examples for 'action' parameter but does not explicitly state when to use this tool over alternatives like 'add_comment' 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?

No annotations were provided, so the description must fully disclose behavior. It describes parameters and return value but does not mention idempotency, side effects on existing time entries, permission requirements, or error handling. The agent cannot judge if this is a mutation that could overwrite data or if it requires specific scopes.

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 one-line purpose followed by a structured list of args. Each sentence provides necessary information without redundancy. It is front-loaded and well-organized.

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 parameter semantics and return value adequately but lacks context on edge cases, error responses, and behavioral constraints. Given the tool's complexity (5 params, no output schema, no annotations), more completeness would be needed for a fully reliable agent invocation. It meets minimal viability.

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%, so the description fully explains each parameter. It provides formats (e.g., 'ON-914' for card_ref, ISO date), defaults (today for date, token owner for user_id), and meaning (minutes as time spent, description as what was done). This adds substantial meaning 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?

Clearly states 'Log time spent on a card.' This is a specific verb and resource that distinguishes it from sibling tools like list_time_entries (reading) and log_activity (general activity logging). No ambiguity.

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

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

No explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites (e.g., card must exist) or scenarios where other tools like list_time_entries would be more appropriate. The only implicit guidance is the required parameters.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states that the tool 'Returns the updated card', but does not mention side effects, permissions, reversibility, or constraints. The description is minimal and leaves significant gaps.

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

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

The description is extremely concise: two sentences plus a structured Args/Returns section. Every sentence adds value, and the main action is front-loaded. No unnecessary words or repetition.

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

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

For a simple tool with two required parameters and no output schema, the description covers the purpose, parameter explanations with examples, and the return value. However, it lacks information about error conditions, such as invalid card_ref or cell_id, which could be important for reliability.

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

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

Schema description coverage is 0%, but the description adds value by providing an example for card_ref ('ON-914') and explaining that cell_id is the target cell ID, along with a hint to use get_board_cells. This goes beyond the raw schema, though more detail on constraints (e.g., valid cell IDs) would improve it.

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

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

The description clearly states the verb 'Move' and the resource 'card to a different column (cell) on the board'. This effectively distinguishes it from sibling tools like archive_card or assign_card, which have different purposes.

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 helpful context by directing users to use get_board_cells() to find cell IDs, which aids correct invocation. However, it lacks explicit guidance on when not to use this tool or how it compares to other move-related tools like move_card_to_iteration.

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?

No annotations are provided, so the description carries full burden. It mentions that the tool returns the updated card, which gives a basic idea of behavior. However, it does not disclose side effects like whether the card is removed from a previous iteration, what happens if the card already belongs to the iteration, or any required 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 very concise: one sentence for purpose, two for parameters, one for return. It is front-loaded with the main action and uses a clear 'Args:' section. Every sentence adds value.

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

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

Given the tool's simplicity (2 required params, no output schema, no annotations), the description covers purpose, parameter hints, and return value. It is missing potential edge cases (e.g., duplicate move) but is mostly complete for its complexity.

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

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

Both parameters are described beyond the schema: card_ref includes an example ('ON-914'), and iteration_id explains how to find it using another tool. This adds significant meaning given the 0% schema coverage.

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

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

The description clearly states the action ('Move a card into an iteration (sprint)') and the resource ('card'). It distinguishes from sibling tools like 'move_card' by specifying the target as an iteration, a different concept than moving to another board column.

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

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

The description provides explicit guidance on how to obtain the iteration_id by using list_iterations(). This helps the agent know a prerequisite. However, it does not explicitly state when not to use the tool or mention alternatives, but the context is sufficient.

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?

No annotations are provided, so the description carries full burden. It states the action but does not disclose any behavioral traits such as side effects, permissions required, or error conditions (e.g., if label not found). The description is minimal for a mutation operation.

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

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

The description is very concise with one sentence and a short parameter list. Every word is necessary and there is no redundancy or fluff.

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

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

For a simple two-parameter tool with no output schema or annotations, the description adequately covers what the tool does and what the parameters mean. It is complete enough for an agent to understand usage, though it could mention return behavior or error handling.

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

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

Schema description coverage is 0%, but the description adds value by providing a concrete example for 'card_ref' (e.g., 'ON-914') and explaining 'label_id' as the label to remove. This compensates well for the missing 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 verb 'remove' and the resource 'label from a card', making the purpose unambiguous. It distinguishes from the sibling tool 'add_card_label' by specifying removal instead of addition.

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

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

The description implies usage for removing a single label, but does not provide explicit guidance on when to use this tool versus alternatives like 'add_card_label' or other removal tools. No exclusions or context are given.

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

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

With no annotations, the description carries full burden. It only says 'reopen (un-complete)', which implies state change but lacks details on side effects, permissions, or reversibility. This is minimal behavioral disclosure for a mutation 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 extremely concise: one sentence defining the action plus a minimal Arg block. No wasted words, and the purpose is front-loaded for 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?

For a simple tool with no output schema, the description is mostly sufficient. It clearly states the action and explains both parameters. However, it could mention that it changes task status from completed to active, and provide a note about prerequisites (e.g., task must be completed). Still, it is usable.

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

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

Schema description coverage is 0%, but the description adds meaningful context: 'card_ref' includes example format (e.g., 'ON-914') and 'task_id' explains its source ('from list_tasks'). This compensates 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 'Reopen (un-complete) a task.' This is a specific verb and resource, leaving no ambiguity about the tool's function. It implicitly distinguishes from the sibling 'complete_task' tool.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'update_task' or 'complete_task'. It only states the action, leaving the agent to infer usage context from the name.

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

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

No annotations provided; description discloses substring matching, case-insensitivity, and limit behavior. Missing side-effect declaration (read-only) and performance/scaling info, but covers core 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?

Description is concise (5 sentences), front-loaded with purpose, and includes well-structured parameter details (Args:). No redundant information.

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

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

Covers purpose, usage context, and parameters. Does not elaborate on return object structure, but output schema exists, so that is acceptable. Sufficient for a search tool with moderate complexity.

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

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

Schema has 0% description coverage but description thoroughly explains all three parameters: field_id (source from list_custom_fields), value (substring, case-insensitive), limit (default 50, scan cap). Adds significant meaning beyond 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 'Find all cards where a custom field contains a given value' with specific examples (branch, PR URL, feature flag), distinguishing it from broader search tools like 'search_cards'.

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 it is useful for custom field searches, but doesn't explicitly list when not to use it or compare with alternatives. The context from sibling tool names helps infer its unique 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?

No annotations provided, so description must inform behavior. It mentions scope (all cards) and return format, but does not explicitly state it is read-only, discuss rate limits, or authentication needs. Adequate but not detailed.

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: two sentences and a list of return fields. Front-loaded with the primary action. Every sentence provides essential 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?

Covers scope (all cards), search fields, and return elements. Output schema exists but description still usefully summarizes return format. No major gaps for a search 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 coverage, description adds value by describing query as 'Search string. Supports partial matches.' This goes beyond the schema's bare type 'string' and clarifies functionality.

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 'Full-text search across all cards in the organisation' and specifies the fields searched (summaries, descriptions, comments). This distinguishes it from sibling tools like find_card (exact match) and search_by_field_value (field-specific search).

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?

Does not explicitly state when to use this tool versus alternatives like find_card or search_by_field_value. Usage is implied by the full-text scope but lacks explicit guidance 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?

With no annotations, the description carries the full burden; it discloses that it sets a field and returns the updated card, but does not mention permissions, idempotency, or error behavior for invalid inputs.

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 purpose statement and a bulleted list of parameters, no unnecessary words, and front-loaded key information.

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

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

For a simple tool with 3 required params and no output schema, the description covers purpose, parameter details, and return value, but lacks error handling or edge case information.

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

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

The description adds significant meaning beyond the schema (which has no descriptions), providing examples and guidance for card_ref, field_id (with reference to list_custom_fields), and value (always a string).

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 sets a single custom field on a card without affecting other fields, using a specific verb and resource, which distinguishes it from siblings like update_card.

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

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

The description implies when to use it (setting one field at a time) and mentions it doesn't touch other fields, but lacks explicit when-not-to-use or alternatives beyond implicit distinction.

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

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

Despite no annotations, description discloses side effect (clearing blocked flag) and return value (resolved blocker object). Doesn't cover error states or permissions, but adequate.

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?

Five sentences covering purpose, side effect, prerequisite, and parameters. First sentence is clear. No redundant text.

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

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

Covers main behavior, return type, and side effect. Lacks details on error handling or idempotency, but for a simple unlock operation it's 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?

With 0% schema coverage, description adds crucial context: example for card_ref, origin for blocker_id, optional nature of resolution. Helps agent understand usage beyond types.

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 ('Resolve (unblock)') and the resource ('specific blocker on a card'). It distinguishes from sibling tools like 'block_card' by focusing on unblocking.

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 guidance on when to use ('If this was the last active blocker...') and prerequisite step ('Use list_blockers() to find the blocker_id'). Lacks explicit when-not-to-use but sufficient.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions that omitted fields are untouched and that the full updated card object is returned, and it specifies that passing an empty string for due_date clears it. However, it lacks details on side effects, error states, or required 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 concise and well-structured: a brief opening sentence followed by a clear, bulleted Args list. Every sentence adds necessary information, with no verbose or redundant 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 the 9 parameters, no output schema, and no annotations, the description covers all parameters, states the return value, and provides usage hints. It could be more complete by mentioning potential errors or authentication requirements, but it is largely sufficient for an agent to use the tool correctly.

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

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

The schema has 0% coverage (no descriptions for parameters), so the description fully compensates. The Args section explains each parameter's purpose, examples (e.g., card_ref: 'ON-914'), format (due_date: YYYY-MM-DD), and references to helper functions (list_iterations, list_members). The extra_fields parameter's merge behavior is explicitly described, adding significant 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 'Update one or more fields on an existing card,' which is a specific verb+resource. It distinguishes from sibling tools like create_card, archive_card, and move_card. The additional note about omitted fields being untouched further clarifies the tool's behavior.

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

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

The description provides clear context for when to use the tool (updating card fields) and includes hints like using list_iterations() and list_members() to find IDs. However, it does not explicitly state when not to use this tool or compare it to alternatives like assign_card or move_card, which have overlapping functionality.

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?

No annotations are provided, so the description carries full burden. It reveals that setting 'complete' to True completes the task and False reopens it, which is behavioral. However, it does not disclose other behaviors like side effects, permission requirements, or return value, leaving significant gaps.

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

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

The description is concise with a one-sentence purpose statement followed by a clean parameter list. Every line adds value, and the structure is front-loaded. Minor improvement could be merging the purpose line with the argument list into a more seamless sentence, but it is efficient as is.

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 omits the return value or success indicator. For a medium-complexity tool with 5 parameters and no annotations, it covers the 'what' but not the 'what happens after'. Additionally, sibling tools exist but no guidance on when to use them is provided, leaving the agent to infer.

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 adds meaningful semantics: it explains that 'description' is a new description defaulting to None, 'complete' controls completion state, and 'assignee_id' sets a new assignee. This goes beyond the bare schema types and adds actionable guidance for the agent.

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

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

Description clearly states 'Update a task's description, completion state, or assignee' with a strong verb and specific resource. However, it does not differentiate from siblings like 'complete_task' or 'reopen_task' which overlap with the completion state update.

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 via parameter explanations (e.g., 'leave None to keep current'), but it does not explicitly state when to use this tool over alternatives like 'complete_task' or 'reopen_task'. No explicit when-not-to-use or exclusions are provided.

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