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 states that it creates a card, which implies a mutation, but it does not mention required permissions, reversibility, or what the response will contain. For a write operation, 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 that immediately conveys the action and purpose. It is front-loaded and wastes no 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?

The schema is thorough, covering all 9 parameters with descriptions, which compensates somewhat. However, with no output schema, the description does not mention what the tool returns or any post-condition, leaving some contextual gaps for a creation tool.

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

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

Schema description coverage is 100%, so the schema already explains all parameters. The description adds no new parameter information beyond contextualizing the overall purpose, which is the baseline score for full 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 uses a specific verb ('Create'), names the exact resource ('a new card in a Trello list'), and states the intended use ('add tasks, ideas, or items to your workflow'). This distinguishes it from sibling tools like create_board 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 phrase 'Use this to add tasks, ideas, or items to your workflow' provides clear context for when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, which would warrant a 5.

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

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

With no annotations, the description must convey behavioral expectations. It states the tool returns 'including its lists and cards', but the schema shows includeDetails defaults to false, meaning lists/cards are not included by default. This is misleading. The description also omits any mention of read-only safety, auth requirements, or rate limits, leaving transparency 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 two sentences, immediately states the core purpose, and avoids filler. The information is front-loaded and every clause contributes meaning. It is appropriately concise for the tool's complexity.

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

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

No output schema is present, so the description should describe what the tool returns and under what conditions. It does not mention the response format, which fields are included, or the dependency of lists/cards on the includeDetails parameter. For a tool with four parameters and no annotations, this falls short of necessary 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% for all four parameters, including descriptions for apiKey, token, boardId, and includeDetails. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate. It does not clarify that includeDetails is required to receive lists/cards.

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', targets a specific Trello board, and specifies the scope ('including its lists and cards'). This distinguishes it from sibling tools like list_boards, get_lists, and trello_get_board_cards by presenting an aggregated view of board structure and 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 phrase 'Useful for understanding board structure and content' implies a use case but does not explicitly state when to use this tool instead of alternatives such as get_lists or trello_get_board_cards. No exclusions or alternative references are provided, so 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?

With no annotations, the description carries the burden of behavioral disclosure, but it is vague. It claims members and attachments are included, while the includeDetails parameter indicates these are optional additions, creating ambiguity. No mention of return structure, default behavior, or side effects.

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

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

A single sentence that is front-loaded and concise, with no filler. It efficiently conveys the core purpose, though brevity sacrifices some needed 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?

For a read tool with no output schema and no annotations, the description is incomplete. It does not explain the effect of includeDetails, differentiate from sibling tools, or describe the response shape. The ambiguity about included fields is a notable 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 coverage is 100%, so the description need not explain parameters in detail. However, it does not clarify how includeDetails changes the output, and the mention of members/attachments could mislead about default behavior. Adds minimal value beyond the schema.

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

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

The description uses a specific verb ('Get') and identifies the resource ('specific Trello card') while listing content categories. It is clear but does not explicitly distinguish from sibling tools like trello_get_card_attachments or trello_get_card_checklists, so it misses the top score.

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 trello_get_board_cards, trello_get_card_actions, or trello_get_card_attachments. No prerequisites, exclusions, or scenarios are mentioned.

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

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

No annotations are provided, so the description must carry the full transparency burden. However, it states 'Get all lists' without mentioning that the default filter is 'open', which could mislead an agent into expecting closed lists. It also doesn't explicitly state that this is a read-only operation (though implied by 'Get'), but the filter ambiguity is a more 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 sentence that is front-loaded with purpose and includes a helpful illustrative use case. No 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?

The tool is simple and the schema covers all parameters, but the description omits the default filter behavior and return format. The phrase 'all lists' conflicts with the default 'open' filter, leaving an agent uncertain about expected results. This is a notable completeness gap given no output schema is provided.

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 each parameter described independently. The description adds no additional parameter-specific details, so it relies fully on the schema. 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 tool retrieves lists from a Trello board, with a specific verb ('Get'), resource ('lists'), and scope ('in a specific Trello board'). It also provides a concrete use case (seeing workflow columns), distinguishing it from sibling tools like get_board_details or trello_get_list_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 explicitly says to use it to see workflow columns in a board, giving clear when-to-use context. It doesn't mention alternatives or exclusions, but the use case is sufficient for this simple listing tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the operation is 'List all' which implies read-only, and adds scope ('accessible to the user'). However, it does not mention the default filter behavior (which the schema says is 'open'), nor any pagination or rate-limit considerations. This 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 one sentence, front-loaded with the core purpose. Every word earns its place, and it is highly scannable. It avoids unnecessary detail while still conveying the main use case.

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

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

For a simple list tool with three parameters and no output schema, the description is mostly complete. It tells the agent what the tool does and when to use it. It does not describe the return format or default filter, but these are less critical given the simplicity. It could benefit from a note about the default filter being 'open'.

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 a high-level phrase 'filter by status' that paraphrases the filter parameter but does not add information beyond the schema. It adds no additional meaning for apiKey or token beyond their schema descriptions.

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

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

The description clearly states the tool lists all Trello boards accessible to the user, with an optional filter by status. This is a specific verb+resource+scope combination. However, it does not explicitly distinguish itself from the sibling tool trello_get_user_boards, which may serve a similar purpose, so it does not 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?

The description provides clear usage context: 'Use this to see all boards you have access to, or filter by status.' This tells the agent when to use the tool. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for a simple listing operation.

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

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

With no annotations, the description carries the full disclosure burden. It fails to mention potential side effects, default position behavior if pos is omitted, permission requirements, or the shape of the response. As a mutation tool, this lack of detail 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 two sentences long, front-loaded with the core action, and includes a helpful example. Every word earns its place with no fluff.

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

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

The description and schema cover the basics, but the lack of annotations and output schema leaves gaps around operational behavior (e.g., default position, idempotency, return value). The example is helpful but does not fully compensate for missing behavioral details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides, but the schema itself is descriptive (e.g., explaining how to obtain ids).

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

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

The description clearly states the tool's function with a specific verb and resource: 'Move a card to a different list.' It also provides an example of workflow status change, distinguishing this from sibling tools like update_card or create_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 explicitly states when to use the tool: 'Use this to change a card's workflow status.' It provides a clear use case without explicitly listing alternatives, which is acceptable for a single-purpose action.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It clearly indicates a write operation ('Add'), which lets the agent know the tool mutates data. However, it does not mention permissions, side effects, or response behavior, though for a simple 'add comment' operation these may be less critical.

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 exactly two sentences, with the first stating the action and the second offering usage context. There is zero redundancy or extraneous information, making it 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?

This is a relatively simple tool with four parameters fully described in the schema and no output schema. The description sufficiently covers purpose and usage context. It does not explain return values, but that is not required given the simplicity of the action and the absence of an output schema.

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 description coverage is 100%, so the schema already documents all four parameters. The description adds no additional parameter-level detail beyond what the schema provides, which is why the 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 action: 'Add a comment to a Trello card.' This is a specific verb+resource that is unambiguous. It does not explicitly differentiate from sibling tools like update_card or create_card, but the action is distinct enough that no confusion should arise.

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

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

The second sentence, 'Use this to add notes, updates, or discussions to cards,' provides clear context for when to use the tool. It does not mention alternatives or exclusions, but it gives practical guidance on appropriate use cases, which is more than many tool descriptions offer.

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 disclosing behavioral traits. It only states that it creates a list, without mentioning side effects, required authentication (though apiKey/token are in schema), potential errors, or whether the operation is destructive. This is minimal disclosure for a write 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 two sentences long, front-loads the primary action, and includes practical examples. Every word earns its place, with no fluff or repetition of schema details.

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 and the schema covers all parameters, but the description does not mention return values, success/failure behavior, or any prerequisites like needing a board ID. Given no output schema and no annotations, a bit more context would be helpful, but it is adequate for a straightforward create 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 100%, so the schema already fully documents each parameter. The description adds examples for 'name' but those also appear in the schema. The description does not provide additional meaning beyond what the schema already conveys, 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 ('Create') and resource ('a new list in a Trello board'), and provides concrete examples of use cases ('To Do', 'In Progress', 'Done'). It clearly distinguishes from sibling tools like get_lists or create_card, which address 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 explicitly states when to use the tool: to add workflow columns. This gives clear context for its intended use. It does not enumerate when not to use it or mention alternatives, but given its focused purpose, the guidance is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'optional filtering' and 'detailed information like attachments and members', but it does not disclose key behavioral traits such as the default filter being 'open' (contradicts 'all cards'), potential pagination limits, or the exact return format. This is a significant gap for a read tool with no 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?

The description is a single sentence that front-loads the primary action and resource. It is efficient with no wasted words, and every phrase contributes meaning. The length is appropriate for an MCP tool summary.

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 6 parameters, no annotations, and no output schema. The description provides a high-level overview but omits details about default filter behavior, pagination, and the structure of returned card data. The schema compensates for parameter semantics, but the overall context is only minimally complete for an agent to fully understand 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?

Schema description coverage is 100%, with clear descriptions for each parameter. The tool description adds minimal value beyond the schema, only summarizing that filter/attachments/members are optional and provide detailed info. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description uses a specific verb ('Get') and resource ('all cards from a Trello board'), clearly indicating the board-level scope. It distinguishes from sibling tools like get_card (single card) and trello_get_list_cards (cards from a list), though it doesn't name them explicitly.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention 'use trello_get_list_cards for cards in a list' or 'use get_card for a specific card'. The only implied usage is for retrieving all cards from a board, which is insufficient for selecting among siblings.

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 states the read action and the scope, but does not mention any side effects, authentication requirements (though schema handles that), or response format. The description is truthful but minimal, offering no additional behavioral context beyond what is already obvious from the verb 'Get'.

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 action and resource, and it omits all extraneous details. It is concise and every word contributes meaning.

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, the absence of an output schema, and the schema covering all required parameters, the one-sentence description provides sufficient information for an agent to understand what the tool does and what is needed to invoke it. It is complete for this simple read 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 already documents all three parameters (apiKey, token, boardId) with 100% coverage, including boardId's pattern and purpose. The description adds no additional parameter-level information beyond referring to a 'specific Trello board,' 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 clearly states the action ('Get all labels'), the resource ('labels available on a specific Trello board'), and the purpose ('for categorizing cards'). This distinguishes it from sibling tools like trello_get_board_cards or get_board_details, as it specifically targets board labels.

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 categorizing cards' gives some context on when labels would be needed, but it does not explicitly state when to use this tool versus alternatives like get_board_details or explicitly exclude other scenarios. Usage is implied rather than explicitly guided.

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. While 'Get' implies a read-only operation, it does not disclose return format, pagination, required permissions, or error behavior. The description adds no behavioral context beyond the verb itself.

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 redundant information. It front-loads the key action 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 read-only tool, the description is adequate but minimal. It does not mention what fields the returned members will include, whether pagination is involved, or when to prefer this over sibling tools. Given no output schema, a bit more detail would improve completeness, but the tool's simplicity keeps it at a passable 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?

Schema coverage is 100% with descriptive text for all three parameters (apiKey, token, boardId), including the note that credentials are auto-provided. The description does not add additional parameter meaning, but the schema alone is sufficient, meriting 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 clearly states the action ('Get all members') and the target resource ('a specific Trello board'). It distinguishes from similar tools like trello_get_member (single member) and trello_get_user_boards (user's boards) by specifying that this tool returns all members with access to a given board.

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

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

No guidance is provided on when to use this tool versus alternatives, such as trello_get_member or get_board_details. The description simply states the function without clarifying use cases, prerequisites, or exclusions.

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

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

There are no annotations, so the description carries full responsibility. It implies a read-only operation via 'Get' but does not explicitly confirm no side effects, mention return behavior, or disclose any rate limits. The description adds little beyond the tool name and doesn't clarify what 'activity history' encompasses.

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

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

The description is two concise sentences, front-loaded with the exact action and resource. There is no wasted wording, making it efficient and easy to scan.

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

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

Given no output schema, the description is too brief. It does not clarify that the default filter is 'commentCard', meaning by default only comments are returned, not full activity history. The phrase 'activity history and comments' could mislead users into expecting all actions. It also fails to describe the response structure, leaving important usage context missing.

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

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

The input schema covers all parameters with descriptions (100% coverage), so the description doesn't need to add much. The tool description mentions 'activity history and comments' but does not elaborate on parameter behaviors such as the default filter or limit, leaving the schema to carry 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 tool gets activity history and comments for a specific Trello card, using the specific verb 'Get' and identifying the resource. This differentiates it from sibling tools like get_card (card details) and trello_add_comment (adding comments).

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

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

The description provides a clear use case ('useful for tracking changes and discussions'), indicating when to use the tool. However, it does not explicitly exclude alternatives or mention cases where other tools would be more appropriate, so it lacks full differentiation.

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

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

No annotations are provided, so the description bears the full burden. It clearly states the read-only action ('Get all') and enumerates attachment types (files, links). However, it does not disclose details about the response format, pagination, or field filtering behavior beyond what the schema already indicates.

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, front-loaded with the action and resource. Every word serves a purpose, and there is no redundant information.

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

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

For a simple read operation, the description is short but does not explain the return structure or the effect of the optional 'fields' parameter beyond the schema. It adequately conveys the tool's primary function but leaves room for more detail about output format, making it minimally viable but not 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?

The schema already provides descriptions for all four parameters (100% coverage), including the optional 'fields' parameter. The tool description does not add any additional parameter-specific information, but the baseline of 3 applies since the schema carries the detail.

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 'Get' and clearly identifies the resource ('all attachments') and scope ('for a specific Trello card'). This distinguishes it from sibling tools like get_card or get_card_actions, which retrieve different data types. The clarification that attachments include files and links adds precision.

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

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

The description implies the tool's use case (retrieving attachments for a specific card) but does not explicitly state when to choose this over alternatives, nor does it mention any exclusions or prerequisites. With a name and description that are self-explanatory, the context is clear but lacks explicit guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Get all checklists and their items.' It does not mention that the checkItems parameter can omit items, nor does it explain response structure, error behavior, or permissions. This is minimal transparency for a no-annotation 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, concise sentence of 11 words that gets straight to the point. It is front-loaded and contains zero filler, making it effective and easy to scan.

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

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

Despite having no output schema and no annotations, the description gives only a high-level summary of what is returned. It fails to mention the effect of optional parameters like 'fields' or 'checkItems', nor does it describe the structure of the checklist objects. For a tool with five parameters and no structured output, this is insufficient 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 coverage is 100%, so all parameters already have descriptions. The tool description adds no additional meaning about parameters beyond the schema; it simply restates the overall purpose. Baseline 3 is appropriate since the description does not enhance parameter understanding.

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

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

The description clearly states the tool's function: 'Get all checklists and their items for a specific Trello card.' The verb 'Get' indicates a read operation, and the resource (checklists and items) is specific and distinct from sibling tools like 'get_card' or 'trello_get_card_attachments'. It fully covers the tool's purpose without ambiguity.

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

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

The description implies when to use the tool—whenever you need checklists for a card—but provides no explicit guidance compared to alternatives. There are no exclusionary statements or mentions of when to use a different tool. This is adequate but not enriched, fitting an 'implied usage' score rather than clear guidelines.

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 fails to disclose that the default filter is 'open' (excluding archived cards) despite the schema, and it doesn't mention response format, pagination, or authentication behavior. The phrase 'Get all cards' could mislead agents into thinking closed cards are included by default.

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

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

The description is two concise sentences that both earn their place: one states the core function, the other provides usage context. No unnecessary words or repetition of schema details.

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 5 parameters and no output schema, yet the description doesn't explain the return format or the default filter behavior. While the purpose is clear, important operational details are left to the schema and the agent's 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 coverage is 100% as every parameter has a detailed description (e.g., listId pattern, filter enum with defaults). The description adds no parameter-level semantics beyond the schema, 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 'Get all cards in a specific Trello list' with a specific verb and resource, and the phrase 'workflow column' adds useful context. It inherently distinguishes from sibling tools like trello_get_board_cards, which operate at the board level.

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

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

The description provides a clear use case: 'Use this to see all tasks/items in a workflow column.' This tells the agent when to use it, but it doesn't mention exclusions or alternatives (e.g., when to use trello_get_board_cards for board-level retrieval).

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

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

No annotations are provided, so the description carries full responsibility. It does not disclose whether the operation is read-only, what permissions are needed, how errors are handled, or what the response structure looks like. This leaves significant behavioral ambiguity for a tool with zero annotation support.

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 redundant words. It is front-loaded with the action and resource, making it highly concise and effective.

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 six parameters and no output schema, the description is somewhat minimal but adequate. It covers the core purpose and hints at included data, but lacks guidance on optional parameters, response format, or edge cases. The schema compensates for parameter details, but overall context remains incomplete.

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 100% parameter coverage, so the baseline is 3. The description adds only minimal context by mentioning boards and profile information, but does not explain parameter relationships or default behaviors beyond what the schema already states.

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

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

The description clearly states the tool's function: retrieving details about a specific Trello member, including boards and profile info. This distinguishes it from sibling tools that focus on boards, cards, or searches.

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 fetching member details, but provides no explicit context for when to choose this tool over alternatives like trello_get_user_boards or get_board_members. There are no exclusions or alternative suggestions.

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 disclosing behavioral traits. The description says 'all boards accessible to the current user,' but the schema shows a filter parameter with a default of 'open.' This could mislead an agent into thinking the tool returns all boards regardless of status, when by default it returns only open boards. The description omits any mention of the default filter behavior or how to request closed/all boards, which is a significant 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 elegantly concise: two short sentences that state the purpose and provide context. There is no redundant phrasing or filler. Every word earns its place.

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

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

Given the tool's simplicity and complete schema coverage, the description covers the core purpose and when to use it. However, because there are no annotations and no output schema, the description's omission of the default filter behavior leaves an important contextual gap. The tool is fully usable, but an agent might mispredict defaults without reading the schema carefully. The description meets a minimum viable level but could be more helpful by mentioning the filter default.

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 100% description coverage for all three parameters, including clear descriptions for apiKey, token, and filter. The description adds no additional parameter context beyond what the schema already states. Since the schema fully documents the parameters, the baseline of 3 is appropriate; the description neither enhances nor degrades parameter understanding.

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

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

The description clearly states the tool's purpose: 'Get all boards accessible to the current user.' The verb 'Get' and the resource 'boards accessible to the current user' are specific and unambiguous. The additional phrase 'starting point for exploring your Trello workspace' adds useful context that distinguishes it from more targeted tools like get_board_details.

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

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

The description provides clear context for when to use the tool by calling it 'the starting point for exploring your Trello workspace.' It does not explicitly name alternatives or exclusion criteria, but the starting-point guidance is sufficient for an agent to understand this is the first call to make when orienting in Trello. Since no exclusions or alternatives are mentioned, the score is a 4 rather than a 5.

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

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

With no annotations, the description should disclose behavioral traits like result format, pagination, or read-only nature. It only states the search scope and does not explain what the response contains or how the search behaves, leaving a significant 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 exactly two sentences, front-loaded with the core purpose ('Universal search'), and contains no extraneous detail. Every word earns its place.

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

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

Given 8 parameters, no output schema, and no annotations, the description is under-specified. It fails to mention what the response looks like, how limits apply, or how filters like boardIds and modelTypes affect results, making it insufficient 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 input schema has 100% description coverage, so the baseline is 3. The description adds minimal value beyond the schema, only reinforcing that the query parameter is a search term. It does not clarify limit or filter parameters, but the schema already documents them.

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

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

The description clearly states it is a universal search across all Trello content (boards, cards, members), using the specific verb 'search' and defining the resource scope. This distinguishes it from sibling tools that fetch or modify specific entities.

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

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

The description says 'Use this to find specific items by keywords or phrases,' which provides clear context for when to invoke the tool. It does not explicitly name alternatives or exclusions, but the intent to search rather than directly access known resources is evident.

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 disclosing behavioral traits. It only says 'update properties' without mentioning that changes are mutations, potential side effects like archiving (closed: true), reversibility, permission requirements, or what the response looks like. This is insufficient for a tool that can alter multiple card fields.

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 only two sentences, with the action verb front-loaded. However, the second sentence 'Use this to change card details...' is largely redundant with the first, and the vague 'or status' adds ambiguity. It is efficient but not flawless.

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 10 parameters and no output schema, yet the description only hints at a few fields (name, description, due date, status). It does not cover the full range of capabilities like moving (idList), archiving (closed), due completion, or position. Nor does it describe return values or side effects. The description under-represents the tool's complexity.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description mentions examples like 'name, description, due date' which map to parameters, but it does not add meaning beyond the schema. The vague 'status' does not clearly correspond to any specific parameter, so no extra value is 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 states the tool's purpose: 'Update properties of an existing Trello card' with a specific verb and resource. It distinguishes from sibling tools like create_card and get_card. However, the mention of changing 'status' is ambiguous (could refer to closed, dueComplete, or list position) and overlaps with move_card, so it is not perfectly clear.

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

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

The phrase 'Use this to change card details' provides clear context that this tool is for modifying existing cards. However, it does not explicitly mention when not to use alternatives, particularly move_card, even though update_card can move cards via the idList parameter. No exclusions or alternative recommendations are given.

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