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 the tool adds a card but lacks details on permissions required, whether the operation is idempotent, error handling, or what happens on success (e.g., returns a card ID). This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, return values, or error conditions, which are critical for an agent to use this tool effectively in context with its 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?

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no parameter-specific information beyond what the schema provides, such as explaining relationships between fields or usage tips. 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 clearly states the action ('Add a new card') and target resource ('to a specified list'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'update_card_details' or 'archive_card' beyond the basic verb, missing explicit distinction in scope or purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a list ID), exclusions, or comparisons to siblings like 'update_card_details' for modifying existing cards or 'get_cards_by_list_id' for retrieval, leaving usage context implied at best.

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

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

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't cover permissions needed, whether the list is editable after creation, error conditions, or what happens if a duplicate name is used, leaving significant gaps for a mutation tool.

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

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

The description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, earning full marks 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?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral context, error handling, or return values, making it inadequate for safe and effective use by an AI agent.

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

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

Schema description coverage is 100%, so the schema already documents the 'name' parameter fully. The description adds no additional meaning beyond implying a list is created, aligning with the baseline score when schema does the heavy lifting.

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

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

The description clearly states the verb ('add') and resource ('new list to the board'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_card_to_list' or 'archive_list', which also modify board components, so it misses full sibling distinction.

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 doesn't mention prerequisites (e.g., needing an existing board), exclusions, or comparisons to siblings like 'get_lists' for listing or 'archive_list' for removal.

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 full burden for behavioral disclosure. 'Send a card to the archive' implies a destructive/mutative operation, but it doesn't specify whether this is reversible, what permissions are required, whether it affects related data, or what happens after archiving. The description lacks critical behavioral context 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 perfectly concise at just four words, front-loading the essential action without any wasted words. Every element ('Send', 'a card', 'to the archive') earns its place by conveying core functionality.

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

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

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what 'archive' means operationally, whether the action is permanent or reversible, what the expected outcome is, or how this fits within the broader card management workflow with sibling tools.

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 the single parameter 'cardId' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage but doesn't enhance 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 action ('Send') and target resource ('a card to the archive'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'archive_list' or explain what distinguishes archiving from deletion or other card operations.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., card must exist), when archiving is appropriate versus deleting or moving cards, or how this relates to sibling tools like 'update_card_details' or 'get_my_cards'.

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

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

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether archiving is reversible, requires specific permissions, affects related data, or has side effects, leaving significant gaps for a mutation tool.

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

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

The description is a single, direct sentence with zero wasted words, efficiently conveying the core action. It is appropriately sized for a simple tool and front-loaded with essential 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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, outcomes, error conditions, or integration with sibling tools, failing to compensate for the missing structured data.

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 the single parameter 'listId' clearly documented in the schema. The description adds no additional parameter context beyond implying 'listId' is needed, meeting the baseline for high schema coverage without extra value.

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 ('Send') and target resource ('a list to the archive'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'archive_card' or specify what 'archive' means in this context, preventing a perfect 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?

No guidance is provided on when to use this tool versus alternatives like 'archive_card' or other list-related operations. The description lacks context about prerequisites, consequences, or typical use cases, offering minimal practical direction.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool fetches cards but doesn't describe what 'fetch' entails—e.g., whether it returns all cards, supports pagination, requires authentication, or has rate limits. For a read operation with zero annotation coverage, this leaves critical behavioral traits unspecified.

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 zero wasted words. It front-loads the core purpose ('Fetch cards') and specifies the scope ('from a specific Trello list'), making it efficient and easy to parse. Every word earns its place without redundancy.

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

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

For a simple read tool with one parameter and no output schema, the description is minimally adequate but incomplete. It lacks behavioral details (e.g., response format, error handling) and usage context, which are important given no annotations. However, the purpose is clear, and the parameter is well-documented in the schema, making it functional but with 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 description coverage is 100%, with the single parameter 'listId' documented as 'ID of the Trello list'. The description adds no additional meaning beyond this, such as format examples or where to obtain the ID. Given high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers parameter 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 clearly states the action ('Fetch') and target resource ('cards from a specific Trello list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_my_cards' or 'get_recent_activity' that also retrieve cards or activity data, leaving some ambiguity about when to choose this specific tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for selecting this over siblings like 'get_my_cards' (which might fetch cards across lists), or any constraints on usage. The agent must infer usage from the name and parameters 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what happens if no lists exist. This leaves significant gaps for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., list format, fields included) or address behavioral aspects like pagination or error handling. For a data retrieval tool with no structured support, this leaves too many unknowns for effective use.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add parameter details beyond what the schema provides, earning a baseline score of 4 for zero-parameter tools as per the rules.

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 ('Retrieve') and resource ('all lists from the specified board'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_cards_by_list_id' or 'get_my_cards', which also retrieve data but target 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a board context), exclusions, or comparisons to sibling tools like 'get_recent_activity' for different data types. Usage is implied by the action but not explicitly stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'fetch' implies a read-only operation, it doesn't specify critical details like whether this requires authentication, how results are paginated or sorted, what happens if no cards are assigned, or potential rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, clear sentence that front-loads the essential information ('fetch all cards assigned to the current user') with zero wasted words. It's appropriately sized for a simple, parameterless tool and efficiently communicates the core purpose without unnecessary elaboration.

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 (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks context about the return format (e.g., what data fields are included, if it's a list of objects) and behavioral traits like error handling or dependencies. For a read operation with no structured output documentation, more completeness would be helpful for an agent to use it effectively.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, as it's a parameterless tool. This earns a baseline 4, as the description doesn't need to compensate for any schema gaps.

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

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

The description clearly states the action ('fetch') and resource ('cards assigned to the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_cards_by_list_id' or 'get_recent_activity', which also retrieve card-related data but with different scopes or filters.

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

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

The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'get_cards_by_list_id' when needing all user cards versus cards in a specific list, or how it relates to 'get_recent_activity' for recent updates. Without such context, the agent must infer usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'fetch' implies a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'recent activity' entails (e.g., time range, types of activities). This leaves significant gaps in understanding the tool's behavior.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 annotations and no output schema, the description is incomplete for a tool that fetches data. It lacks details on return format, error cases, or behavioral traits, which are crucial for an agent to use the tool effectively in context with its 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?

Schema description coverage is 100%, with the parameter 'limit' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as constraints or examples, so it meets the baseline for high schema coverage without extra value.

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 ('fetch') and resource ('recent activity on the Trello board'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'get_cards_by_list_id' or 'get_my_cards', which also retrieve data but focus on different resources, so it misses full sibling differentiation.

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. The description doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone, which is insufficient for optimal selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing card's details,' which implies a mutation operation, but fails to mention critical aspects like required permissions, whether updates are reversible, potential side effects (e.g., notifications), or rate limits. This leaves significant gaps for an agent to understand the tool's behavior safely.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.

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 complexity of a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), usage context, and what the tool returns, leaving the agent with insufficient guidance for safe and effective invocation.

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

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

The schema description coverage is 100%, with each parameter clearly documented in the input schema (e.g., 'cardId' as ID, 'dueDate' in ISO 8601 format). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. This meets the baseline for high schema coverage but doesn't enhance 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 verb ('Update') and resource ('an existing card's details'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'archive_card' or 'add_card_to_list' beyond the general 'update' action, which is why it doesn't reach a perfect 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. For example, it doesn't mention prerequisites (e.g., needing the card ID), when not to use it (e.g., for archiving vs. updating), or how it relates to siblings like 'archive_card' or 'get_cards_by_list_id' for retrieval before updating.

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