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

With no annotations, the description carries the full burden. It only states 'Add a new card' without disclosing side effects, required permissions, reversibility, or what the response contains. For a mutation tool without annotations, this is insufficient.

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 avoids redundancy and gets straight to the point. It does not waste words and is 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?

For a simple add operation with fully documented parameters, the description is minimally sufficient. However, with no output schema and no annotations, it doesn't address return values, error conditions, or the optional nature of boardId (which defaults to active board). It could do more but remains adequate.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond the schema; it only mentions list and board as context but doesn't explain any parameter behaviors or constraints.

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

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

The description clearly uses the verb 'Add' with the resource 'card' and specifies the destination ('to a specified list on a specific board'). It distinguishes itself from sibling tools like move_card and update_card_details by explicitly stating 'new 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 (when creating a new card in a list) but provides no explicit guidance on when not to use or alternatives. No exclusions or prerequisites are mentioned, so usage is inferred from the name and description.

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 states the mutation but does not explain side effects, error conditions, whether the tool creates a checklist if missing, or any required permissions. This is a minimal statement with no additional behavioral context.

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

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

The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the core action, which is ideal for conciseness.

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?

As a mutation tool with no annotations and no output schema, the description is incomplete. It lacks context about required inputs beyond the schema, potential side effects, or what happens if the checklist does not exist. The description provides the bare minimum without helping the agent understand the full operational context.

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

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

Schema description coverage is 100%, so all three parameters have descriptions in the schema. The tool description adds no parameter-level detail beyond what the schema provides, but it does not need to since the schema is complete. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Add a new item') and the target resource ('a checklist'), which directly matches the tool name. While it doesn't explicitly distinguish from sibling tools, the clear verb-resource pair and the read-focused siblings make its purpose obvious.

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

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

The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., existence of the checklist or board), and no exclusions. It simply states the action without contextual use cases.

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

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

No annotations are provided, so the description must carry the burden. It only restates the operation without disclosing side effects, permissions, idempotency, or return behavior. This is nearly tautological with the title.

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, clear sentence with no filler or redundant content. It is appropriately sized for a simple action tool.

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

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

The tool is a simple two-parameter mutation with no output schema or annotations. The description provides the basic action and target, but does not mention possible return values or any caveats. It is minimally adequate but not rich.

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

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

Schema description coverage is 100%, so both 'cardId' and 'text' are fully explained in the input schema. The description adds no extra parameter guidance, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('add') and the resource ('a comment to a card'). It is specific enough to distinguish from all sibling tools, none of which deal with comments 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: when you need to add a comment to a card, use this tool. However, it provides no explicit context, prerequisites, or exclusions, and does not mention any alternative tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning return values, prerequisites (e.g., board must exist), or side effects. For a mutation tool, this is 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, concise sentence with no wasted words, and it's front-loaded with the primary action and target.

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, but with no annotations and no output schema, the description lacks critical context like return behavior or error conditions. The schema covers parameters, but the overall context is incomplete for an agent to fully anticipate the tool's effects.

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

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

Schema coverage is 100%, so both parameters have descriptions. The tool description adds no extra parameter semantics beyond the schema's detailed explanation of boardId, making the baseline of 3 appropriate.

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

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

The description clearly states the action ('Add'), the resource ('a new list'), and the target ('to the specified board'). It distinguishes this tool from siblings like archive_list and get_lists, which have different actions and 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 implies when to use it (when adding a list to a board) but provides no explicit guidance on exclusions or alternatives. It doesn't mention that it's not for adding cards or archiving lists, though sibling names suggest those are separate tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not disclose any side effects, such as whether the card is removed from the board, whether the action is reversible, or whether any confirmation is needed. The description only restates the obvious effect without adding insights about permissions, permanence, or interaction with the board state.

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 immediately states the action and scope. There is no redundant information, and the sentence is front-loaded with the core purpose. It effectively uses the limited space to convey the essential function.

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 action like archiving a card, the description is minimally viable. However, given the absence of annotations and an output schema, the description could provide more context about the card's fate after archiving, the optional boardId behavior, or how this tool fits into the broader Trello workflow. The tool is straightforward, so a complete description might not need much more, but there is 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 covers both parameters (cardId and boardId) with descriptions, achieving 100% schema description coverage. The tool description itself adds no additional parameter semantics, but the baseline is 3 due to the high schema coverage. The schema clarifies that boardId is optional and falls back to the active board, which is useful but not in the description.

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

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

The description clearly identifies the action (archiving a card) and the resource (a card), using the verb 'send' which is specific enough. It distinguishes from sibling tools like archive_list (which archives a list) and move_card (which moves a card to a different list), though not explicitly. The phrase 'on a specific board' hints at the boardId parameter, but the wording 'send to the archive' is slightly less direct than 'archive'.

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. It does not mention that archive_list should be used for archiving entire lists, nor does it explain the relationship to move_card. No prerequisites, exclusions, or preferred contexts 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?

No annotations are provided, so the description must convey behavioral context. It only states the action (archive a list) but does not disclose side effects such as what happens to cards in the list, reversibility, or permission requirements. This is a minimal level of 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 a single concise sentence that is front-loaded with the action and resource. No wasted words; it effectively communicates 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?

For a simple tool with one required parameter and no output schema, the description is adequate but missing behavioral context like what happens to the list's cards or whether the action is reversible. With no annotations, this leaves a gap in completeness.

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

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

Schema coverage is 100%, so the schema already documents both listId and boardId. The description mentions 'specific board' but adds no additional meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool archives a list on a specific board. The verb "send" is less precise than "archive" but the title clarifies it. It distinguishes from siblings like archive_card and add_list_to_board by specifying the resource (list) and destination (archive).

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. There is no mention of sibling tools like move_card or get_lists, or when archiving is appropriate. The description only states what it does, not when it should be used.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not explain what happens if the member is already assigned, whether permissions are required, or what the return value is.

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, clear sentence with no filler or redundant information. It is appropriately concise for a simple two-parameter 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?

The tool is low-complexity with only two required parameters, and the schema fully documents them, making the description minimally viable. However, with no annotations or output schema, the description omits behavioral details such as error conditions, side effects, and expected response, leaving some contextual gaps.

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

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

The schema already provides descriptions for both parameters (cardId and memberId) with 100% coverage, which meets the baseline. The description itself adds no additional parameter semantics beyond what the schema already specifies.

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 'assign', the resource 'member', and the target 'card'. It also differentiates from the sibling tool 'unassign_member' by specifying the direction of the action (assign vs unassign).

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, such as using 'unassign_member' to remove a member. It also omits any prerequisites or context, like whether the member must already belong to the board.

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 carries full responsibility for behavioral disclosure. It indicates a mutation (attaching) but provides no details about side effects, prerequisites, URL-fetching behavior, or error handling. This is comparable to the 'update_drive' example, which scored 2 for similar lack of 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 a single sentence that is concise and front-loaded with the action and resource. It contains no extraneous words and communicates 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?

For a relatively simple tool, the description covers the essential action, and the schema fully documents parameters. However, with no annotations and no output schema, it omits operational nuances like return values or prerequisites, making it adequate but not fully comprehensive.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it only restates the 'URL' aspect already captured in the imageUrl parameter description. No additional parameter-level insights are provided.

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

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

The description clearly identifies the action (attach), the resource (an image or any file), the source (URL), and the target (a card on a specific board). It distinguishes this from sibling tools that retrieve, delete, or download attachments by explicitly indicating an add/attach 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 implies the usage scenario—attaching a file from a URL to a card—but it does not explicitly state when to use this tool versus alternatives like get_card_attachments or delete_attachment. No exclusions or alternative tool references are provided, so guidance is only implicit.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action without noting consequences like permanence of deletion, error behavior, or authorization requirements. This is a significant gap for a destructive 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 extremely concise: a single sentence with no wasted words. It is front-loaded with the verb and resource, and every word 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, the description is minimally viable: it states the action and the schema covers parameters. However, it omits any side-effect or irreversibility warning, and there is no output schema to clarify returns, leaving some ambiguity for a delete 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?

The input schema provides full descriptions for both parameters (cardId and attachmentId), so the schema already covers the needed semantics. The description adds no additional parameter detail, but the high coverage means a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Remove') with a clear resource ('attachment') and location ('from a card'), making it obvious what the tool does. It distinguishes itself from sibling tools like attach_image_to_card, get_card_attachments, and download_attachment.

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 or exclusions. It is left to the agent to infer that deletion requires an existing attachment ID and that other attachment operations are better suited for different tasks.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses authentication handling, return types (image block for images, otherwise base64 + metadata), and size-related behavior (larger files return metadata only). It lacks error scenarios and metadata field details, but the coverage is substantial for a download 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 two sentences, front-loaded with the primary purpose, and every clause adds value: authentication nuance, return format, and size limits. There is no waste or repetition of schema fields.

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

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

For a moderately complex 3-parameter tool with no output schema and no annotations, this description is complete. It covers purpose, authentication requirements, output types, and size cap. An agent has sufficient context to select and invoke the tool correctly without major gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about authentication and return format, but the maxBytes behavior is already captured in the schema description. It does not meaningfully extend the meaning of cardId or attachmentId 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 begins with 'Download the binary content of a card attachment', using a specific verb and resource that clearly states the tool's function. It distinguishes itself from sibling tools like get_card_attachments (which lists attachments), attach_image_to_card (which uploads), and delete_attachment (which removes).

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 a clear use case: when a plain URL fetch would fail with 401 due to authentication on private boards, this tool provides the correct credentials. It gives contextual guidance even though it doesn't explicitly name alternative tools.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention match semantics (exact vs partial, case sensitivity), whether it returns only matching items, or any limitations. The description adds little beyond the title.

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, succinct sentence that effectively conveys the core purpose. It is appropriately sized and front-loaded, with no unnecessary words, though it lacks any structural enhancement like usage tips.

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 a search operation, but the description does not mention expected output, search behavior, or how it differs from related tools. With no output schema and no annotations, the description is too minimal to be fully complete for an agent to confidently use it.

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

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

Schema description coverage is 100% and both parameters have clear descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool searches for checklist items by text in their description, using a specific verb and resource. It distinguishes from sibling tools like get_checklist_items or get_checklist_by_name, though not explicitly. The phrase 'containing specific text' clarifies the 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?

No guidance is provided on when to use this tool versus alternatives like get_checklist_items or get_checklist_by_name. The description simply states what it does without mentioning exclusions or when it is the preferred choice.

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 disclosure, but it only states the basic function. It does not mention what happens if the 'Acceptance Criteria' checklist does not exist, the return format, or any side effects.

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

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

The description is a single, appropriately sized sentence that front-loads the primary action. 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 one-parameter tool, the description is adequate but incomplete. It lacks behavioral details such as error handling, return structure, or what happens when boardId is omitted (though the schema covers this). It is a minimum viable description but leaves gaps.

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

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

The schema covers 100% of the parameters with a clear description for boardId, so the baseline is 3. The description does not add any additional 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 the action clearly: 'Get all items from the "Acceptance Criteria" checklist'. It identifies a specific verb (Get), resource (items), and the specific checklist, distinguishing it from generic checklist tools like get_checklist_items.

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

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

The description gives no guidance on when to use this tool versus siblings such as get_checklist_items or get_checklist_by_name. There is no mention of alternatives, exclusions, or context for when this tool is preferred.

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 of behavioral disclosure. It only says 'get information' without noting read-only safety, potential errors, or what happens if no active board is set. The verb 'get' implies a read operation, but no further behavior is 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 a single, concise sentence with no wasted words. It fully states the tool's purpose in minimal space, making it highly scannable and appropriate 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?

The description is too sparse to be contextually complete. It does not explain what 'active board' means, how it is set, or what information will be returned. With no output schema or annotations, the agent lacks essential context for using the tool correctly, especially in the context of sibling tools like set_active_board.

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

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

The tool has zero parameters, and the baseline for 0 params is 4. The description adds the concept of 'currently active board,' which clarifies that the tool uses a global state rather than taking an explicit board identifier. No parameter details are 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 action ('get') and the specific resource ('currently active board'), which distinguishes this tool from siblings like list_boards and set_active_board. It is unambiguous about what information is retrieved.

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. It does not mention that it depends on a prior set_active_board call or contrast with get_board/list_boards, leaving the agent to infer usage context from the tool name alone.

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

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

The description offers no behavioral details beyond the operation itself; there is no mention of return format, read-only nature, or potential side effects. With no annotations provided, the description does not compensate for this gap, leaving the agent without critical 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 a single, clear sentence with no extraneous content. Every word earns its place, making it an example of concise and well-structured documentation.

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 operation with one optional parameter, the description is functional but lacks context about the output (e.g., whether labels include IDs, names, colors). Since there is no output schema or annotations, this missing context makes it only minimally viable for an agent to fully anticipate the tool's behavior.

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 single parameter 'boardId' is fully documented in the schema (100% coverage), including the default behavior when omitted. The description adds no additional parameter semantics, so the schema carries the burden, warranting the baseline score.

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' with a clear resource ('all labels defined on a board'), which accurately distinguishes it from sibling tools that focus on cards, lists, or boards. No ambiguity exists about what the tool does.

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

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

The description implies the tool's purpose but does not explicitly state when to use it relative to alternatives or provide caveats (e.g., default board behavior is left to the schema). No exclusions or alternate tool recommendations are given, so guidance is minimal.

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. 'List' implies a read-only operation, but it does not disclose the default board behavior (boardId optional), response format, or any permissions. This is minimal but not misleading.

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 superfluous words, perfectly concise and front-loaded with the core action and resource.

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 parameter and no output schema, the description covers the basic purpose but omits context like the active board fallback (though present in schema) and what a 'member' list contains. It is adequate but not complete.

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

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

Schema description coverage is 100% because boardId has a description explaining it uses the active/default board if not provided. The tool description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description 'List all members of a board' uses a specific verb ('List') and resource ('members of a board'), clearly distinguishing it from sibling tools like get_my_cards or list_boards. It is precise 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?

No usage guidelines are provided. The description gives no indication of when to use this tool vs alternatives, nor any prerequisites or exclusions. The only implicit guidance is the tool name and description.

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 'Get detailed information,' which conveys a read operation, but does not mention response structure, what fields are included, error handling, or that includeMarkdown alters the response type. No side effects or authorization needs are 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, concise sentence with no redundant words. It is front-loaded with the verb and resource, making the purpose immediately clear.

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

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

For a simple get tool with two parameters and full schema coverage, the description is adequate but leaves gaps: there is no output schema, so the agent cannot know the return format or fields, and the description does not mention the markdown option. However, the tool's simplicity mitigates these issues.

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 (cardId and includeMarkdown) are fully described in the input schema, so the schema already covers their meaning. The description adds no additional parameter context, but baseline 3 is appropriate due to 100% 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 specifies the action ('Get') and the resource ('detailed information about a specific Trello card'). This distinguishes it from sibling tools like get_my_cards or get_cards_by_list_id, which target different scopes.

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 a single card by saying 'a specific Trello card,' but provides no explicit guidance on when to use it instead of alternatives. No alternative tools or exclusions are mentioned, leaving the agent to infer from 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, the description carries the full burden of disclosing behavior. It clearly states the tool returns metadata, not content, and implies a read-only, non-destructive operation. It could add more about pagination or auth, but for a simple list tool, this is sufficient.

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

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

The description is two sentences, front-loaded with the main purpose and immediately following with the key alternative. There is zero redundancy or irrelevant detail.

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

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

The tool is simple with one parameter and no output schema. The description compensates for the missing output schema by listing the metadata fields (id, name, url, fileName, mimeType, bytes) and explicitly contrasting with download_attachment. This makes the tool fully self-explanatory for its intended use.

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

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

The schema already provides 100% coverage for the single parameter, describing cardId as 'ID of the card to list attachments from'. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'attachments on a card', and enumerates the metadata fields returned. It distinguishes itself from download_attachment by explicitly noting the tool returns metadata only, not the actual file content.

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

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

The description explicitly names download_attachment as the alternative for fetching actual file content, providing clear guidance on when to use this tool vs. the sibling. This satisfies the 'when and how' requirement fully.

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 states the operation is a fetch, but does not disclose whether it is read-only, any side effects, pagination behavior, or what exactly is returned. For a read operation, the description should at least note that it does not modify data.

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 directly communicates the tool's purpose without unnecessary words. It is front-loaded with the action verb and resource, making it efficient 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?

For a simple tool with two parameters, full schema coverage, and no output schema, the description is adequate. It clearly explains what the tool does and the schema covers the parameters. However, the lack of any behavioral caveats (e.g., whether boardId is required when listId is globally unique) could be considered a minor gap.

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

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

Schema description coverage is 100%: both listId and boardId have clear descriptions in the schema. The description adds little beyond the schema, only reiterating that the fetch is for a specific board. Since the schema already documents the parameters, a baseline of 3 is appropriate.

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

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

The description clearly states 'Fetch cards from a specific Trello list on a specific board' with a specific verb ('Fetch') and resource ('cards from a specific Trello list'). It distinguishes itself from siblings like get_card (single card) and get_lists (lists themselves).

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. It does not mention exclusions, prerequisites, or scenarios where a different tool like get_my_cards or get_card would be more appropriate. The description is purely functional.

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 of disclosing behavior. It reveals that the response includes all items and a completion percentage, which is useful. But it does not mention error behavior (e.g., what happens if the checklist name is not found), the fact that boardId can override the default board, or any other side effects or limitations, leaving gaps in 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 a single, effective sentence that packs essential details (complete checklist, items, completion percentage) without redundancy. Every word adds value, and it is easily scannable for an agent.

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 (2 params, no output schema), the description sufficiently outlines the primary output (complete checklist with items and completion percentage). However, it omits details about error handling and the optional boardId behavior, which would improve completeness. Still, for a simple retrieval tool, the description provides a solid summary of what to expect.

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 covers both parameters (name and boardId) with clear descriptions, so parameter semantics are already well-defined. The description adds no additional parameter details beyond what the schema provides, such as constraints or format expectations. Thus a baseline score of 3 is appropriate because the schema handles the semantic load.

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

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

The description clearly states the verb 'Get' and the resource 'a complete checklist' with the added specificity of 'by name' and includes the output details (all items and completion percentage). This distinguishes it from sibling tools like get_checklist_items, which retrieves items separately, and find_checklist_items_by_description, which searches by item text rather than retrieving the checklist by its name.

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 used to retrieve a full checklist with aggregated data (items and completion) rather than a partial view, which provides some context. However, it does not explicitly state when to prefer this tool over alternatives like get_checklist_items or get_acceptance_criteria, nor does it mention any exclusions or prerequisites such as needing an active board.

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 states the action and does not mention behaviors like error handling, default board usage, ordering, or side effects. For a read-only operation this is a moderate shortfall.

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 wasted words. It is concise and clearly states the tool's 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?

The tool is simple with full schema coverage. The description states the core behavior and method, which is sufficient for basic use. However, it lacks usage alternatives and any behavioral context, making it not fully complete but adequate for a straightforward retrieval 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 coverage is 100% with descriptive parameter definitions. The description adds no extra meaning beyond 'by name', which duplicates the name parameter. Baseline 3 is appropriate since schema already documents the parameters.

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

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

The description clearly states the action: 'Get all items from a checklist by name'. It uses a specific verb and resource, and the 'by name' qualifier distinguishes it from siblings like find_checklist_items_by_description and get_checklist_by_name.

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

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

The description implies usage (when you need all items from a checklist by name) but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over find_checklist_items_by_description or get_checklist_by_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?

With no annotations, the description carries the full burden. It states the tool retrieves all lists, which is straightforward. However, it does not disclose nuances like whether closed lists are included, ordering, or pagination. For a simple retrieval, it is adequate but not rich.

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

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

The description is a single sentence that is front-loaded with the verb and resource. Every word contributes meaning 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?

For a tool with one optional parameter and no output schema, the description is reasonably complete. It states the action and scope, and the schema covers the parameter. However, it does not describe the return structure, but this is a minor gap for such a simple list retrieval.

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

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

Schema description coverage is 100%, with boardId clearly documented as 'ID of the Trello board (uses the active/default board if not provided)'. The tool description adds no additional parameter meaning beyond this, so a baseline of 3 is appropriate.

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

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

The description uses a specific verb 'retrieve' with a clear resource 'all lists' and scope 'from the specified board'. It clearly distinguishes from sibling tools like get_cards_by_list_id (cards, not lists) and add_list_to_board (creation).

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

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

The description implies when to use it: whenever you need all lists from a board. It provides clear context but does not explicitly name alternatives or exclusions, such as using get_cards_by_list_id for cards. This is a minor gap for a simple read 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?

No annotations are provided, so the description carries the full burden. 'Fetch all cards' clearly indicates a read-only operation, but it does not mention authentication requirements, whether cards come from all boards/workspaces, or any pagination/limits. For a simple getter this is adequate but not richly transparent.

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

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

Single sentence, front-loaded with action and scope, zero unnecessary words. It earns every word.

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

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

For a zero-parameter, no-output-schema retrieval tool, this description is sufficiently complete. It clearly states the operation and scope, though it omits optional details like output format or board/workspace scope.

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

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

Tool has zero parameters and 100% schema coverage, so the schema is trivially complete. Baseline 4 applies because no parameter explanation 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?

Description uses specific verb 'Fetch' and resource 'cards assigned to the current user', clearly differentiating from sibling tools like get_cards_by_list_id (cards by list) and get_card (single 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 the tool is for retrieving the current user's assigned cards, which gives clear context. However, it does not explicitly mention when not to use it or provide alternative tool recommendations, so usage guidance is only 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 are provided, and the single-sentence description adds minimal behavioral detail. It doesn't disclose whether the operation reads from the active board, whether results are limited by default, or any 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 a single concise sentence with no extraneous detail, making it highly scannable and to the point.

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

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

Given the low complexity of the tool, the description is adequate but not thorough. It doesn't mention the optional boardId behavior or the return format, but these are covered by the schema and the tool's simplicity.

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

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

Both parameters are fully documented in the schema with clear descriptions, and the schema coverage is 100%. The description itself adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly identifies the action (fetch) and resource (recent activity) on a specific context (Trello board). It stands apart from sibling tools that deal with cards, lists, or boards 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 provides no explicit guidance on when to choose this tool over alternatives. It implies usage for viewing activity, but does not mention exclusions or alternatives.

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

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

With no annotations, the description carries the burden of indicating behavior. It states the read-only nature ('list') and the access scope, which is helpful. However, it does not disclose return format, pagination, or whether archived boards are included, leaving some behavioral ambiguity.

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 front-loads the action and resource. Every word earns its place, with no wasted 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 tool's simplicity (no parameters, no output schema), the description sufficiently covers the essential context. It explains what it does and the access scope, though it could mention the return format (e.g., a list of board objects) to be fully complete.

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

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

The tool has zero parameters, and the schema is empty. Per rubric, 0 parameters defaults to a baseline of 4. The description adds nothing about parameters, which is appropriate since there are none.

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

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

The description 'List all boards the user has access to' clearly identifies the verb (list), resource (boards), and scope (all accessible boards). It distinguishes from sibling tools like list_boards_in_workspace by emphasizing the global 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 phrase 'all boards the user has access to' provides clear context for when to use this tool—whenever the user needs a full view of their boards. It does not explicitly name alternatives like list_boards_in_workspace, but the scope implication 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 are provided, so the description carries the burden. It clearly indicates a read-only listing operation, but it does not disclose behaviors such as whether archived boards are included, required permissions, or pagination. The lack of any side-effect warning is acceptable, but the description is minimal.

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 wastes no words. It is appropriately concise for the simplicity of the tool.

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

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

For a simple one-parameter list tool with no output schema or annotations, the description provides the essential context. It is complete enough for an agent to understand the tool's function, though it could be improved by explicitly contrasting with list_boards.

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

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

The schema already provides a complete description of workspaceId ('ID of the workspace to list boards from'), and the description's 'in a specific workspace' simply reinforces that. No additional semantic value is added beyond the schema, so the baseline 3 applies.

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

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

The description is specific: 'List all boards in a specific workspace' clearly states the verb (list), resource (boards), and scope (a specific workspace). This distinguishes it from sibling tools like list_boards, which likely lists boards across all workspaces.

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

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

The description implies the tool is for listing boards within one workspace, but it does not explicitly mention when to use it instead of list_boards or other siblings. There is no clear when-to-use or alternative guidance beyond the scope constraint.

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?

There are no annotations, so the description carries the full burden. It discloses a useful behavioral scope ('user has access to'), but does not mention return format, pagination, ordering, or read-only guarantees. 'List' implies non-destructive behavior, but richer behavioral context is missing.

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 exact action and scope. It contains zero wasted words and is immediately scannable.

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 low complexity (zero parameters, no annotations, no output schema), the description is nearly complete. It clearly covers purpose and access scope, though it leaves the response shape to inference. For a simple list operation, this is acceptable but not fully exhaustive.

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

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

The tool has zero parameters, so the description need not add parameter-level semantics. The schema is empty and already covers 100% of parameters, warranting the baseline score of 4 for no-parameter 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?

The description uses a specific verb 'List' with a clear resource 'workspaces' and scope 'the user has access to'. This clearly defines the tool's function and differentiates it from siblings like list_boards_in_workspace, which focuses on boards within a specific workspace.

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

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

The description implies usage when the user needs to see their accessible workspaces, but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives like set_active_workspace or list_boards_in_workspace. 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, and the description only states the core action without disclosing side effects, permissions, or reversibility. The only added nuance is 'potentially on a different board' which is somewhat useful but minimal.

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, clear sentence with no extraneous words, front-loading the 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?

While the tool is simple and the schema covers parameters, the description lacks usage guidance and behavioral transparency. It is adequate for understanding the basic function but not fully complete for an agent to select confidently among siblings.

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

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

All three parameters (cardId, listId, boardId) have descriptions in the schema, so the description need not add detail. It doesn't mention parameter behavior beyond what the schema states, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Move') and resource ('a card') with clear scope ('to a different list, potentially on a different board'). This clearly distinguishes it from sibling tools like add_card_to_list 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 is provided about when to use this tool vs alternatives. It doesn't mention the relationship to add_card_to_list or note scenarios requiring boardId.

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 of disclosure. It does reveal that the change persists and affects subsequent operations, which is useful context. However, it omits important behavioral details such as whether the board ID is validated, error conditions, or if it overwrites a previously active board.

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 of eight words, front-loaded with the verb and resource. It contains no redundant information and is highly concise.

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

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

The tool has only one parameter and no output schema, but the description is sparse. It lacks information about prerequisites (e.g., whether a workspace must be set), error behavior, and the exact scope of 'future operations'. For a state-changing tool with no annotations, more context is necessary.

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

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

Schema description coverage is 100% since boardId is described as 'ID of the board to set as active'. The description adds no parameter-specific meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool sets the active board for future operations, using the specific verb 'set' and resource 'active board'. It distinguishes from sibling set_active_workspace by specifying the board 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 phrase 'for future operations' implies the tool should be invoked before board-specific calls that need an active board, but it does not explicitly state when to use it versus alternatives like set_active_workspace, nor does it provide exclusions or prerequisites.

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

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

The description discloses that the tool affects future operations, which is a key behavioral trait. With no annotations provided, it carries the full burden, but it does not mention persistence, reversibility, or error handling, leaving some 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 a single, focused sentence that is front-loaded with the action and resource. The clause 'for future operations' adds meaningful context without any waste.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately states the core action. However, the lack of explicit usage guidelines and richer behavioral context keeps it at a minimally complete level.

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 fully describes the single parameter with 100% coverage, and the description adds no extra meaning beyond what is already in the schema. The baseline of 3 applies because the schema handles the semantics.

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

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

The description uses the specific verb 'Set' with the resource 'active workspace', clearly distinguishing it from the sibling tool 'set_active_board'. It concisely states the tool's function without ambiguity.

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

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

The phrase 'for future operations' implies that this tool should be used before operations that depend on an active workspace, providing mild usage context. However, it does not explicitly mention alternatives or exclusion 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?

No annotations are provided, leaving the description to carry the full burden. It does not disclose potential side effects, failure conditions (e.g., member not on card), permission requirements, or reversibility. As a mutation tool, this lack of behavioral context is 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 states the action without any extraneous words. It is highly concise and well-structured.

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

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

Given the tool's simplicity and complete schema coverage, the description is minimally adequate. However, it lacks usage context, behavioral details, and return value information (no output schema exists). It does not fully compensate for the lack of annotations, warranting a mid-range score.

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

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

Schema coverage is 100% for both required parameters (cardId and memberId), so the schema already fully documents them. The description adds no extra parameter information beyond the schema, so it earns the baseline score of 3.

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 ('Remove') and identifies the resources (member from a card), clearly distinguishing it from sibling tools like assign_member. It avoids tautology and unambiguously states the tool's function.

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

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

The description implies the tool's purpose but does not explicitly state when to use it over alternatives such as assign_member. There is no mention of exclusions or context like 'use this to undo assign_member,' so usage guidance is only inferred.

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 does not mention whether the update is partial or full, what happens to omitted fields, required permissions, or any side effects. This is a significant gap 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, front-loaded sentence that succinctly states the tool's purpose without any wasted words.

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

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

For a tool with 8 parameters, no annotations, and no output schema, the description is too minimal. It lacks behavioral details, usage context, and return-value expectations, making it incomplete for an agent to invoke confidently.

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

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

Schema description coverage is 100%, so all parameters are already documented in the schema. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

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

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

The description uses the specific verb 'Update' with the resource 'an existing card's details' and scopes it to 'a specific board'. This clearly distinguishes it from sibling tools like add_card_to_list, move_card, and 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?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the action without contextual direction.

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