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 says 'Add a comment'—implying a write operation without detailing side effects, permissions, error behavior, or how the comment is appended. No additional behavioral context is provided beyond the obvious mutation.

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, short sentence with no filler or redundancy. Every word earns its place, making it maximally concise and easy to process.

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 low complexity, the description is missing crucial context: no mention of return values, error handling, authentication requirements, or the fact that the comment body supports HTML (though schema notes it). With no annotations or output schema, this minimal description leaves significant gaps for a mutation tool.

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

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

Schema description coverage is 100%, with both 'body' and 'card_id' documented in the schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate—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 'Add a comment to a card' uses a specific verb ('Add') with a clear resource ('comment') and target ('card'), fully differentiating it from sibling tools like add_tag or create_card. It precisely 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 provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., card must exist), and no exclusions. It simply states the action without contextual cues for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals the auto-create behavior ('Creates the tag if it doesn't exist'), which is valuable. However, it does not address idempotency or what happens if the tag is already on the card, leaving minor 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, succinct sentence that is easy to parse and front-loads the primary action. It contains no extraneous words or repetition of schema fields, earning a perfect score 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?

For a simple two-parameter tool with no output schema, the description is mostly complete. It covers the main action and side effect, and the schema handles parameter details. It lacks minor context like board/global scope of tags and duplicate behavior, but these are not critical for a basic add 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 schema already provides 100% coverage for both parameters with clear descriptions. The tool description does not add any additional parameter-level detail beyond what the schema offers, 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 ('Add') and resource ('a tag to a card'), making the action unmistakable. It also distinguishes itself from sibling tools like fizzy_remove_tag by clearly stating the operation. The side effect of creating the tag if needed adds further specificity.

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 adding tags but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, leaving context to be inferred. This is acceptable but not exemplary.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or return values. It merely restates the create intent without adding context about what happens upon execution.

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 gets straight to the point. It is front-loaded and free of unnecessary words, though it adds little beyond the tool name.

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

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

For a simple two-parameter tool, the description gives the basic purpose but omits information about return values or post-creation behavior. There is no output schema, and sibling tools suggest a workflow but no guidance 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?

The input schema already provides 100% coverage with descriptions for both parameters ('Name of the board' and 'Optional description of the board'). The tool description adds no further semantic value to 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 'Create a new Fizzy board' uses a specific verb (create) and resource (board), clearly indicating the tool's function. It differentiates from sibling tools like create_card by targeting the board resource, though it does not explicitly mention alternatives.

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

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

There is no guidance on when to use this tool, prerequisites, or alternatives. The description only states the action, leaving the agent without context for choosing it over other board-related 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 of behavioral disclosure. It only states the action 'Create a new card' without mentioning permissions, return values, side effects, or idempotency. 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, focused sentence with no filler or redundant information. It is front-loaded and optimally 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 no annotations and no output schema, yet the description only says 'Create a new card'. It does not explain what the tool returns, whether it requires specific permissions, or any post-creation behavior. For a simple create tool, this is 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?

Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description adds no additional parameter-level information, 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 'Create a new card on a Fizzy board' clearly states the action (create), the resource (card), and the context (Fizzy board). It distinguishes this tool from siblings like fizzy_update_card, fizzy_move_card, and fizzy_list_cards by specifying 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 usage: use this when you want to create a new card. However, it does not explicitly mention when not to use it or provide alternatives (e.g., use fizzy_update_card for modifications). The context is clear but not elaborated with exclusions or 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 must disclose behavioral traits. It states 'Get details' implying a read operation but does not explicitly confirm non-destructiveness, permissions, or the shape of the response. It adds minimal behavioral context beyond the basic action.

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

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

The description is a single, front-loaded sentence with no redundant information. Every word contributes to the purpose, and it is appropriately sized for the tool's simplicity.

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

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

Given the tool has only one parameter and no output schema, the description is minimally acceptable but lacks detail about the return value structure or error conditions. For a simple get operation, however, it conveys the essential function. Without annotations, more transparency would improve completeness.

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

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

The input schema already describes board_id as 'The ID of the board' with 100% coverage, so the baseline is 3. The description's phrase 'specific Fizzy board' adds little semantic meaning beyond the schema, as it does not explain the format, source, or constraints of board_id.

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

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

The description 'Get details of a specific Fizzy board' uses a specific verb ('Get') and resource ('specific Fizzy board'), clearly distinguishing it from siblings like fizzy_list_boards (which lists all boards) and fizzy_get_card (which gets a card). It precisely identifies 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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is for fetching a single board by ID, nor does it exclude cases where list_boards might be more appropriate. No when-to-use or when-not-to-use context is given.

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

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

With no annotations provided, the description carries the burden. 'Get details' clearly indicates a read-only operation with no side effects, but it does not disclose behavior such as error handling, return format, or what happens if the card_id is invalid.

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 and contains no redundant words. Every word is meaningful and directly states the action.

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

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

For a simple single-parameter read tool, the description is sufficient. It lacks an output schema, so mentioning what 'details' includes could be helpful, but the low complexity makes this a minor gap rather than a critical omission.

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 by describing card_id as 'The ID of the card'. The description adds no additional meaning beyond that, 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 uses a specific verb 'Get' with a clear resource ('details of a specific card'), distinguishing it from list operations like fizzy_list_cards. It precisely indicates a singular fetch by ID.

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 'specific card' clearly implies this is for retrieving one card rather than listing all cards, giving clear context. However, it does not explicitly state when not to use it or mention alternatives like fizzy_list_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?

There are no annotations, so the description carries full responsibility for disclosing behavior. It only states the action without mentioning read-only nature, return format, pagination, ordering, or authentication requirements. This is a significant gap for a tool with no annotation fallback.

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 short sentence that precisely conveys the tool's function with no redundant words. It is appropriately front-loaded 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 list operation, the description is adequate but lacks detail about the return format or any pagination behavior. Since there is no output schema, the agent must rely on the description, which only says 'List all boards' without specifying what information is returned or whether the result is truncated. This is a minor but real gap.

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

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

The tool has zero parameters, so the schema fully describes the input. The description adds no parameter-specific meaning, but none is needed; the baseline of 4 applies as per rubric for empty parameter sets.

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 a specific verb 'list' with a specific resource 'Fizzy boards' and scope 'in the account'. It distinguishes from sibling tools like list_cards and list_columns by naming the resource type, and from get_board by indicating it returns all boards rather than one.

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 makes the tool's purpose self-evident, implying it should be used when the agent needs to enumerate all boards. It does not explicitly mention alternatives or when-not-to-use, but the sibling tool names provide the context that list_cards and list_columns are for other resources, so there is no real ambiguity.

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 disclose behavior, but it only repeats what the schema states. It does not explicitly confirm that omitting board_id returns all cards, nor does it mention sorting, pagination, or return structure. The read-only nature is implied by 'List' but not stated.

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 consists of two short, direct sentences: 'List cards. Optionally filter by board ID.' Every word is necessary, and it is efficiently front-loaded with the core action.

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

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

For a simple tool with one optional parameter and no output schema, the description is minimally adequate. However, it omits clarity on the default behavior (all cards vs. none) and lacks any supplemental context about expected results or limitations. It is sufficient but has clear 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's mention of 'filter by board ID' adds no new meaning beyond the schema's own parameter description. There is no additional semantic value 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: 'List cards.' It specifies the primary action and resource, and the optional board_id filter distinguishes it from sibling tools like fizzy_list_boards or fizzy_get_card. The scope is unambiguous.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The description only says 'Optionally filter by board ID,' which hints at filtering behavior but does not state when to use this over get_card or other sibling tools. No exclusions or prerequisites 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 burden. It only states 'list all columns' without disclosing any behavioral details such as read-only nature, pagination, ordering, error handling, or response format. This is minimal and provides no extra context beyond the name and 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 concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no unnecessary filler.

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

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

This is a simple one-parameter tool, so the description is largely adequate. However, without an output schema or annotations, the description does not clarify the return format (e.g., column objects, names, ordering) or any potential edge cases. For a low-complexity tool, this is acceptable but not 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?

Schema description coverage is 100% for board_id, which is described as 'The ID of the board'. The description adds minimal extra meaning by connecting board_id to the board whose columns are listed, but this is effectively redundant. Baseline 3 is appropriate as 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 'List all columns on a Fizzy board' uses a specific verb ('list') and resource ('columns') with a clear scope ('on a Fizzy board'). It clearly distinguishes from siblings like fizzy_list_cards and fizzy_list_boards by naming the specific resource being listed.

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 list columns on a board) but does not provide explicit guidance on when to use this tool versus siblings or any exclusions. There are no alternatives for listing columns among siblings, so a simple implication may suffice, but it lacks explicit context.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action and scope, with no mention of read-only status, ordering, pagination, error handling, or side effects. This is minimal 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, direct sentence with no unnecessary words. It is front-loaded with the action and clearly scopes the resource, achieving maximum conciseness for a simple 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 description is adequate for a basic list operation with one parameter, but it lacks usage context, exclusions, or return behavior. Given no output schema and no annotations, it is minimally complete but not thorough.

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 only parameter 'card_id' with a clear definition. The description adds no additional parameter semantics, but since schema coverage is 100%, 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 the action ('List') and the resource ('all comments on a card'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like list_cards and add_comment by specifying the exact object type (comments on a 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?

There is no guidance on when to use this tool versus alternatives such as get_card (which might include comments) or add_comment. The description provides no context for selecting it over other 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 must carry the full burden of behavioral disclosure. It implies a mutation operation but does not explain side effects, permissions, or what makes the columns 'special' in terms of behavior. The mention of 'special columns' raises questions that are left unanswered.

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 (~20 words) that front-loads the action and contains no redundant or extraneous 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 incomplete. It does not explain what happens when moving a card to 'done' or 'not_now' (e.g., archiving, closing, or other side effects), nor what the tool returns after the operation. The agent is left to infer critical 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?

The input schema already provides 100% coverage with clear descriptions for both parameters (card_id and column). The tool description adds minimal semantic value beyond reinforcing the special column options, meeting the baseline of 3 for high 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 the specific verb 'move' with resource 'card' and destination 'column', clearly distinguishing it from sibling tools like update_card or get_card. The added detail about special columns ('done'/'not_now') further clarifies the tool's specific 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 clear context: it is for moving a card to a different column, with explicit guidance for using 'done' or 'not_now' for special columns. However, it does not mention when to use this tool over alternatives such as update_card, nor exclusions for when not to use it.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. However, it only states the action without explaining side effects, idempotency, behavior on missing tags, or return values.

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 with no wasted words. The description is immediately understandable 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?

For a simple two-parameter tool, the description covers the basic action, but lacks behavioral context such as idempotency or tag existence handling, which would be expected for a mutation tool with no annotations.

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

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

Input schema already describes both parameters (card_id and tag) with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides.

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 resource ('tag from a card'), clearly distinguishing from sibling tools like fizzy_add_tag. It conveys the core operation 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention related operations like adding tags or updating cards, or any prerequisites for removing tags.

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 must disclose behavioral details. It only states 'Update an existing card' without mentioning whether it performs a partial or full update, whether it requires special permissions, what it returns, or any side effects. This is insufficient for an update 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 one concise sentence with no waste. However, it is under-specified, lacking the detail needed for a mutation tool. It is concise but not richly informative; still, it earns a decent score for avoiding 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?

Given the lack of annotations, output schema, and the mutation nature of the tool, the description is too sparse. It does not explain update semantics, error conditions, or return values, and does not help the agent understand behavior beyond the schema. The description is incomplete for reliable 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 input schema covers 100% of parameters with clear descriptions ('New title for the card', 'The ID of the card', 'New description for the card'), so the schema already provides needed semantics. The description adds no additional parameter detail, 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 uses a specific verb ('Update') and identifies the resource ('an existing card'), which clearly distinguishes it from creation tools like 'fizzy_create_card'. However, it does not explicitly differentiate from other mutation tools like 'fizzy_move_card' or 'fizzy_add_comment', so the scope is slightly underspecified.

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 context on when to use this tool versus alternatives. It does not mention that it is for editing card fields like title or description, nor does it exclude operations like moving or commenting. There is no explicit 'when to use' guidance.

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