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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, permission requirements, or what happens on failure. The mutation implied by 'add' is obvious, but nothing else is disclosed.

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

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

The description is a single sentence with no filler, making it appropriately concise. However, it may be too terse to be fully useful, but for a simple tool, the brevity is acceptable. The key information (action and target) 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?

While the tool is simple and an output schema exists (which may cover return values), the description is incomplete for a 3-parameter tool. It doesn't explain what each parameter does or any constraints, and it lacks usage context such as 'requires an existing card.' The minimalism leaves too much to inference.

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 adds no meaning to the parameters beyond their names. board_name, card_name, and comment are self-explanatory, but the description doesn't clarify formats, uniqueness constraints, or how they relate. For a tool with 0% coverage, the description must compensate but fails to.

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

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

The description states a clear verb ('Add') and resource ('a comment to a card'), which is specific and actionable. It doesn't explicitly name sibling tools, but the action is unambiguous and distinct from operations like create_card 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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as the card needing to exist. There is no mention of when not to use it or how it differs from update_card or create_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?

No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects (e.g., whether the label is added to the card's label list, whether it overwrites existing labels, idempotency, or permission requirements). The mutation nature is implied but not elaborated.

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

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

The description is a single, efficient sentence with no wasted words. It front-loads the action and resource. However, it is so brief that it sacrifices necessary detail, though conciseness itself is well-executed.

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

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

With no annotations, 0% parameter coverage, and no mention of return values or error conditions, the description is incomplete for a mutation tool. It does not explain what happens if the label does not exist, whether the operation is idempotent, or what the output schema contains. The agent lacks 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 description coverage is 0%, so the description must compensate. It clarifies that label_name is used by name, but board_name and card_name are not explained beyond their names. No format, constraints, or relationships between parameters are provided, leaving the agent to guess.

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

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

The description states a specific verb ('Add'), a resource ('label to a card'), and a key constraint ('existing label' and 'by label name'). This clearly distinguishes it from create_label and other card-related tools. The purpose is unambiguous.

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

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

The description implies the label must already exist but does not explicitly state when to use this tool versus create_label, nor does it mention prerequisites like ensuring the label exists on the board. No alternative tools are referenced, leaving the 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?

With no annotations provided, the description carries the full burden. It adds useful behavioral context by clarifying that archiving means 'close' and that archived cards can be restored in Trello, implying reversibility. However, it does not disclose permissions, idempotency, or behavior when the card is already archived.

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 short sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence adds a meaningful behavioral note about restoration.

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 archive action, the description is mostly adequate and an output schema exists, so return values need not be explained. However, it omits edge-case guidance such as handling duplicate card names, and it does not reference the sibling archive_list tool to disambiguate 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 description coverage is 0%, so the description must compensate, but it only indirectly references the parameters via 'a card on a board.' It does not explain whether names must be exact, how duplicate card names are handled, or any other semantic detail about board_name or card_name.

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

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

The description uses a specific verb ('Archive') and a clear resource ('a card on a board'), with the parenthetical '(close)' removing ambiguity. It differentiates from the sibling archive_list by explicitly targeting cards rather than lists.

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

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

The description states what the tool does but gives no guidance on when to choose it over alternatives such as archive_list, move_card, or update_card. There is no mention of exclusions, prerequisites, or conditions that would route an agent to a different sibling 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 provided, the description carries the behavioral disclosure burden. It adds one useful consequence—archived lists can be restored in Trello—but it does not mention effects on cards, permission requirements, or whether restoration via the API is possible.

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 front-loaded: the first sentence states the action and object, and the second adds a relevant consequence. No words are wasted, though it is terse to the point of leaving gaps in other dimensions.

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

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

The tool is simple (two string parameters, no nesting) and has an output schema, so return-value documentation is unnecessary. However, the description omits parameter semantics and does not provide enough context for an agent to confidently distinguish when to select this tool rather than a sibling mutation tool.

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

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

Schema description coverage is 0%, and the description does not clarify the meaning, format, or relationship of board_name and list_name. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema itself.

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

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

The description uses a specific verb ('Archive') with a parenthetical synonym ('close') and a clear object ('a list on a Trello board'). It also distinguishes itself from the sibling tool archive_card by explicitly targeting lists, not 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 implies this tool is for archiving lists identified by board and list name, but it gives no explicit guidance on when to choose this tool over alternatives like archive_card, nor any exclusions or prerequisites. The usage context is inferable 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 provided, the description must carry the full burden of behavioral disclosure. It merely states the action without revealing side effects, permissions, idempotency, or return value. The agent learns nothing about what happens on success or failure, making this a significant gap.

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

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

The description is a single, front-loaded sentence that immediately states the action. It is concise and free of filler. However, it omits critical context that would justify a 5, but for being a simple one-liner it is appropriately sized.

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 create operation with four parameters (three required) and an output schema, the description is far too sparse. It does not explain the meaning of required fields, the optional description purpose, or what the tool returns. Even a minimal agent would struggle to use it correctly without external knowledge.

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

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

Schema description coverage is 0%, so the description should compensate by explaining the parameters (board_name, list_name, card_name, description). It does not mention any of them. The agent must rely solely on the parameter names, which is inadequate for correct invocation.

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

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

The description clearly states the verb 'Create' and the resource 'card', and it narrows the scope with 'in a list on a board.' This differentiates it from siblings like create_list (list creation) and update_card (modification). It lacks an explicit contrast with those siblings, so it doesn't fully earn a 5.

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?

There is no guidance on when to use this tool versus alternatives like update_card or move_card. The description does not mention prerequisites (e.g., board and list must exist) or exclusions. An agent has to infer usage solely from the name and description, which is insufficient.

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 behavioral burden. It discloses the create operation and the valid color set, but it does not mention potential duplicate-label behavior, required permissions, or failure handling. This is adequate for a simple additive create tool but leaves some behavioral context unstated.

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

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

Two short sentences with no filler. The core action is front-loaded, and the color constraint is the second essential piece of information. Nothing is redundant or wasteful.

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 3-parameter create tool with an output schema, the description covers the only non-obvious input constraint (color values) and specifies the target resource (a Trello board). It lacks explicit sibling differentiation, but that is largely a usage-guidance concern rather than a completeness gap for invoking 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 add meaning. It provides the full valid color enumeration and clarifies that an empty string means no color. The other parameters, board_name and label_name, are reasonably self-explanatory given the tool's purpose.

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

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

The description clearly states the verb ('Create'), the resource ('a new label'), and the scope ('on a Trello board'). It is distinct from sibling create_card/create_list, though it does not explicitly differentiate itself from the similarly named add_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?

No guidance is given about when to use this tool versus alternatives such as add_label, which likely serves a different purpose (e.g., attaching an existing label to a card). The intended usage is only implied by the tool's name and generic create phrasing.

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 of behavioral disclosure. It only says 'Create a new list' and does not mention side effects, duplicate handling, permission requirements, or failure behavior. For a mutating tool, this is a notable transparency gap.

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

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

The description is a single, well-structured sentence with no filler. It front-loads the action and resource, and every word contributes to understanding what the tool does.

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

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

The tool is simple with only two required string parameters and no nested objects, and an output schema exists, so return-value documentation is unnecessary. However, the lack of behavioral context such as duplicate policy or error cases leaves room for improvement.

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

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

The input schema has 0% description coverage and only lists parameter names (board_name, list_name). The description echoes these concepts with 'list' and 'Trello board' but adds no format, constraints, or guidance beyond what the parameter names already imply.

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 ('Create'), the resource ('a new list'), and the context ('on a Trello board'). It is distinct from siblings like create_card without needing explicit contrast, though it does not name or differentiate itself from related list operations.

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

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

The description implies use when the agent wants to create a list on a board, but it gives no explicit when-to-use/when-not-to-use guidance and does not reference alternatives such as get_lists or archive_list. Usage context is inferable but not stated.

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

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

No annotations are provided, so the description carries the full burden. It states the action (list) and scope (open, accessible boards), which implies a read-only operation. However, it does not disclose potential behavioral traits such as authentication requirements, pagination, or rate limits. For a simple list tool this is acceptable but not exhaustive.

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

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

A single, front-loaded sentence with no redundancy. It immediately states the action and scope, making it easy to parse and act upon.

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 output schema exists, the description need not explain return values. The tool has no parameters, and the description fully captures its purpose and scope. There is nothing missing for an agent to call it correctly.

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

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

There are zero parameters, and schema coverage is 100% (trivially). The description adds meaningful context by specifying 'open' and 'user has access to', which clarifies the filtering criteria beyond the empty schema. This exceeds the baseline for a parameterless tool.

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

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

The description uses a specific verb ('List') and a clear resource ('open Trello boards') with an explicit scope ('the user has access to'). It unambiguously distinguishes itself from sibling tools like get_lists and get_cards, which operate on different resources.

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

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

The description clearly implies when to use this tool (when you need boards), but does not explicitly name alternatives or exclusion conditions. Given the clear resource focus, an agent can infer the appropriate context without further guidance, though explicit routing would be more helpful.

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 burden. 'Get' implies a read-only operation with no side effects, but this is not stated explicitly. It also does not disclose any authentication requirements, rate limits, or failure behaviors. For a simple retrieval tool this is acceptable but not fully 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 a single, front-loaded sentence with no filler. Every word contributes to specifying the action and scope.

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 output schema is present (though not shown here), so return format is covered. However, the description omits any error scenarios, prerequisites (e.g., existence of board and card), or behavior when multiple cards share the same name. For a straightforward retrieval, this is minimally adequate.

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

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

The schema provides only parameter names with zero description coverage. The tool description does not elaborate on what 'board_name' and 'card_name' mean, their format, or how to find them. Since the schema gives no guidance and the description adds none, the agent must rely on naming conventions alone, which is insufficient.

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

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

The description states a clear verb ('Get') and resource ('full details of a specific card') and explicitly lists included fields (description, due date, comments). It implies a single card vs. the sibling 'get_cards' which likely lists cards, though it does not name the sibling directly.

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 retrieving detailed information about one card, but provides no explicit guidance on when to choose this over get_cards or search_cards. No exclusions or alternatives are mentioned, leaving the selection to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get all cards' without mentioning whether this is read-only (likely but not stated), whether it returns card details or summaries, pagination, or any side effects. For a read operation, the lack of explicit safety confirmation is a gap.

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

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

The description is a single, concise sentence that is front-loaded with the action and resource. It earns its place with no waste, though it could add a bit more context without becoming bloated.

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

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

Given there is an output schema, return values are covered, but the description lacks guidance on parameter semantics, behavioral expectations, and usage context. For a tool with no annotations and 0% schema coverage, this is incomplete. An agent would need to infer how to specify board_name and list_name and what 'all cards' means in terms of output.

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 for the two parameters. It mentions 'board' and 'list' in the text, which maps to board_name and list_name, but doesn't explain what values are expected (e.g., exact names vs IDs) or how they relate. The description adds minimal 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 states a specific verb ('Get') and resource ('all cards in a specific list on a board'), which clearly distinguishes it from siblings like get_boards and get_lists. It doesn't explicitly name a sibling alternative, but the scope is clear enough to differentiate it from get_card_details and 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 implies when to use it: when you need all cards in a specific list. It doesn't explicitly state when not to use it or mention alternatives like get_card_details for a single card or search_cards for filtered results. The context is clear but exclusions are 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 provided, so the description carries the full burden. It transparently discloses that the operation retrieves only open lists and is scoped to a board, and the 'Get' verb implies a read-only behavior. It omits details like ordering or result shape, but those are partially covered by the presence of an output schema.

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

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

One compact, front-loaded sentence that conveys the verb, resource, scope, and board context without any filler or redundancy.

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

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

For a simple read-only tool with one required parameter and an output schema, the description provides essential call context. Minor gaps include lack of explicit guidance on board_name format and what happens when no open lists exist, but overall the definition is 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 schema only defines board_name as a string with no description. The tool description compensates by clarifying that the parameter represents the Trello board whose open lists should be fetched. It does not specify whether a name or ID is expected, but the single self-describing parameter makes the meaning reasonably clear.

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 identifies the action ('Get'), the resource ('open lists'), and the scope ('on a Trello board'). This distinguishes it from sibling tools like get_boards, get_cards, and list-mutation tools.

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

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

The description clearly states when to use the tool: when the agent needs open lists for a particular board. It also implicitly excludes archived lists via 'open lists', though it does not explicitly name sibling alternatives or state when not to use them.

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 behavioral disclosure. It only states the action without revealing side effects, prerequisites (e.g., card and list must exist), failure modes, or reversibility. The verb 'move' implies mutation, but that's minimal; an agent lacks information about what happens if the target list doesn't exist or if the card isn't found.

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

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

The description is a single, front-loaded sentence that states the action and its scope. It contains no fluff or redundant phrasing, earning its place by conveying the core purpose 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?

Given the presence of an output schema (which reduces the need to describe returns) and a simple 3-string-parameter schema, one might expect a compact description to be sufficient. However, the lack of annotations and absence of behavioral details (e.g., does it validate existence, does it move within the board only, what errors occur) makes it incomplete for an agent to invoke correctly without risk of failure. The description is too sparse for a mutation operation.

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 by explaining parameter meaning. It does not mention any parameters at all. While the parameter names (board_name, card_name, target_list_name) are somewhat self-explanatory, the description adds no semantics about their expected format, required identifiers, or how they relate. The agent must rely solely on names, which is insufficient for a tool with no 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 'move' applied to a 'card', with a specific destination ('different list on the same board'). This distinguishes it from siblings like create_card, archive_card, and update_card, which have different actions. The phrasing is concise and unambiguous.

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

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

The description implies usage: if you need to move a card to another list on the same board, use this tool. It does not explicitly contrast with alternatives or provide when-not-to-use guidance, but the constraint 'same board' gives some context. No exclusions or alternative routing are mentioned, so it falls short of a clear usage guide.

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 carries the full burden. It discloses a meaningful behavior: the result limit of 20 and the cross-board scope. However, it does not mention which card fields are searched (name, description, etc.), ordering, or failure behavior, leaving some uncertainty for an agent.

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

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

The description is a single sentence with no filler. The verb and resource are front-loaded, followed by the scope and limit. Every word adds value, making it an exemplary concise definition.

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 param, no annotations), the description covers the essential context: scope, search mechanism, and result cap. The output schema exists, so return structure is handled elsewhere. A minor gap is lack of detail on which fields are searched, but this is unlikely to prevent 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 schema provides only a required string 'query' with no description, so coverage is 0%. The description compensates by specifying that the parameter is a keyword, directly clarifying its semantic meaning. For a single simple parameter, this is sufficient; no further format details are critical.

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

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

The description states a clear verb ('Search'), a specific resource ('cards across all boards'), and a behavioral constraint ('max 20 results'). This distinguishes it from siblings like get_cards or get_card_details, which imply narrower scopes. The agent can immediately understand what this tool does.

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

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

The phrase 'across all boards' clearly indicates the tool is for cross-board keyword search, which gives a usable context for when to invoke it. It does not explicitly name alternatives or exclusion criteria, but the scope is clear enough to avoid obvious misuse.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the important partial-update semantics (empty fields are no-ops) and the ISO 8601 date format requirement, which are real behavioral traits beyond the tool name. However, it does not mention whether updates are destructive, require permissions, or affect other card fields, leaving notable gaps 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 a single, dense sentence that front-loads the verb, resource, and fields, then adds the format and behavior. It contains no fluff and every clause adds value. Slightly more structure could include the identifying parameters, but as written it is efficient and readable.

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 output schema covers return values, but the description leaves major gaps for a mutation tool. It does not explain how the card is identified via board_name and card_name, which are required parameters, nor does it note prerequisites like an existing card/board or error conditions. The description addresses the update fields but not the targeting mechanism, making it incomplete for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'name, description, due date' to new_name, new_description, and due_date, and adds the empty-field meaning. However, it does not explain the required identifiers board_name and card_name, which are essential for the agent to target the correct card. The description covers only 3 of 5 parameters meaningfully.

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 updates a card's name, description, or due date, with a specific verb and resource. It differentiates from siblings like create_card, archive_card, and move_card by explicitly listing the updatable fields, so an agent can identify the correct 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 gives clear context for when to use it: when changing one or more of the three named fields. It also provides a usage rule, 'Leave fields empty to keep them unchanged,' which guides the agent on how to perform a partial update. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.

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