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

No annotations are provided and the description carries the full behavioral burden, yet it discloses nothing about required permissions, whether the comment is attributed to the calling user, rate limits, or failure modes on an unknown card ID. The only behavioral signal is the word 'Add', which implies a non-idempotent mutation without confirming it.

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

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

A single front-loaded sentence with zero filler, appropriately sized for a three-parameter tool. It is efficient but borders on under-specification rather than being a model of tight writing.

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 100% schema coverage and an output schema cover parameters and return values, so the description does not need to restate them. However, with no annotations the description should have covered the mutation's side effects and permission requirements, which it omits entirely.

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

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

Schema coverage is 100%, so the schema already documents card, board, and comment in detail, including the name-lookup caveat for board. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The verb+resource pair ('Add a comment to a card') is unambiguous and tells an agent exactly what the tool does. It does not, however, differentiate itself from any sibling or state scope limits, which is unnecessary here since no sibling also adds 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention that the card must already exist. The agent must infer everything from the sibling list and schema.

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 behavioral burden. It discloses that the operation is bidirectional (assign or unassign), which is useful, but omits permission/auth requirements, whether the operation is idempotent, what happens when the user is already assigned, and any side effects on notifications.

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

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

A single front-loaded sentence with no filler or redundancy. It is arguably too terse given the tool's dual behavior, but nothing wasteful is present.

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?

An output schema exists so return values need not be explained, and the parameters are documented. However, for a mutation tool with zero annotations, the description should have covered permissions, idempotency, and the board-lookup dependency, all of which are absent.

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

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

Schema description coverage is 100%, so all four parameters (card, user, board, remove) are already fully documented in the schema. The description contributes no additional parameter semantics beyond restating the verb, so the baseline 3 applies.

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

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

The description states a specific verb (assign/unassign) and resource (user-to-card) that lets an agent distinguish it from siblings like tag_card or add_comment. It does not explicitly differentiate from other card-mutation tools, but the scope is 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of the board-resolution requirement even though the schema flags it as needed for name lookups. The 'remove' flag implies a dual purpose but the description leaves usage entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about permissions, side effects, what happens if board/column are omitted, or whether creation is reversible.

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 single sentence is technically concise but under-specified rather than appropriately sized. It lacks the structure and front-loaded detail needed for a seven-parameter mutation 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?

An output schema exists and the input schema is fully described, which reduces the required burden. However, for a create mutation tool with no annotations, the description omits prerequisites, defaults, and behavioral context that an agent would still benefit from.

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 seven parameters, including defaults and constraints. The description adds no parameter meaning beyond that baseline.

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

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

The description states a clear verb and resource: 'Create a new card.' An agent can distinguish it from read or update siblings, but the description offers no scope or differentiation beyond the name and title.

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

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

There is no guidance on when to use this tool versus alternatives like update_card, move_card, or add_comment. The description gives no context, 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions required, whether the column is appended by default, whether the operation is reversible, or what happens on name collisions. For a mutation tool with zero annotation coverage this is a notable 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?

A single short sentence that is front-loaded with the action and resource, with no wasted words. Its brevity is efficient, though it borders on under-specification for a mutation 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?

An output schema exists so return values need not be explained, and the input schema is fully documented. However, with no annotations and a thin description, the agent gets no safety, permission, or side-effect context that a create operation warrants.

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 of name, board, and position documented including defaults and fallback behavior, so the schema does the heavy lifting. The description adds no parameter detail beyond what the schema already provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Create a new column') plus the scope ('on a board'), which distinguishes it from rename_column, move_column, and delete_column. It stops short of naming those siblings or explaining how creation differs from them, so it is clear but not fully differentiated.

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 rename_column, move_column, or list_columns, and no mention of prerequisites such as needing a board context or existing column names to avoid duplicates. Usage must be inferred entirely from the verb.

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 behavioral burden. It does not state that deletion is destructive/irreversible, what happens to associated data (comments, attachments), whether it requires special permissions, or how the 'everywhere' option affects scope. For a destructive mutation tool this is a significant gap.

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

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

It is a single sentence with no filler, but it is under-specified rather than concise. The sentence does not earn its place by adding any information beyond the tool name, so brevity here reflects a lack of substance.

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?

An output schema exists so return values need not be explained, and the schema covers parameters well. However, for a destructive tool with no annotations, the description omits essential context: irreversibility, cascading effects, permission requirements, and the semantics of the 'everywhere' flag.

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

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

Schema description coverage is 100%, so all three parameters (card, board, everywhere) are already documented in the schema. The description adds no parameter meaning beyond that, which matches the baseline of 3 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 states a clear verb+resource ('Delete a card'), so the basic action is unambiguous. However, it adds nothing beyond the tool name/title and gives no differentiation from other card-mutating siblings like update_card or move_card, making it the minimum viable statement of 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?

There is no when-to-use guidance, no mention of alternatives (e.g., archive vs. delete), and no prerequisites or exclusions. The agent gets no help deciding whether this tool is the right choice.

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

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

With no annotations, the description carries the full burden, and it does disclose the critical cascading effect: deleting the column also deletes all its cards. That is the most important non-obvious behavior. It stops short of stating irreversibility, required permissions, or whether the deletion can be undone.

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

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

Two sentences, zero waste, with the destructive warning isolated and emphasized rather than buried. Front-loaded purpose followed by the risk is the right ordering for a delete 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?

Return values are covered by the output schema and parameters by the schema, so the remaining burden is behavioral. The cascade warning covers the main risk; only permissions and reversibility are left unstated, which is a minor gap for a straightforward delete.

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

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

Schema description coverage is 100%, so both 'board' and 'column' are already documented, including the name-lookup requirement for board. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (delete) and resource (column from a board) in one crisp sentence. The resource is naturally distinct from the other destructive sibling (delete_card), so an agent can select correctly without opening either schema.

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 on when to use this versus rename_column, move_column, or delete_card, and no prerequisites (e.g., board resolution for name lookup). The description only states the operation, not the selection conditions.

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 behavioral burden. It mentions columns are included but says nothing about permissions, read-only nature, latency, or error behavior. For a read tool with no annotations, 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?

A single sentence, front-loaded with the core action and resource, with zero 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?

With one parameter fully documented and an output schema present, the tool is callable. However, with no annotations and no usage guidance, an agent lacks context for when to choose this over get_current_board or list_boards.

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

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

Schema coverage is 100%, so the schema already documents board_id as a widget_common_id. The description adds no parameter meaning beyond what's in the schema. Baseline 3 applies.

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

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

States a specific verb (get) and resource (board) with scope ('including its columns'). It doesn't explicitly differentiate from siblings like get_current_board or list_boards, though the requirement of a board_id makes its identity reasonably 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?

No guidance on when to use this versus get_current_board or list_boards. The agent must infer from the required board_id, but no explicit when/when-not is provided.

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. 'Get' implies a safe read, but nothing is said about permissions, whether the card must exist, or what happens on a miss. 'Detailed information' is the only hint about return scope, and the output schema covers the rest.

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 short sentence, front-loaded with the verb and resource, with no wasted words. It is efficient but perhaps overly terse for a tool with lookup-mode nuances.

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 an output schema present, return values need not be explained, and the input schema is fully documented. However, with no annotations and no usage guidance, the description leaves the agent to infer that this is a safe read and when to prefer it over list_cards.

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

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

Schema coverage is 100%, so both parameters (card and board) are already documented in the schema, including the note that board is needed for name lookups. The description adds nothing beyond the schema, which is the expected baseline.

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?

States a specific verb (Get) and resource (card details), and 'specific card' implies single-item retrieval rather than listing. It doesn't explicitly distinguish itself from list_cards or get_board, but the resource 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?

There is no guidance on when to use this versus list_cards (to browse) or update_card (to modify). The description simply restates the operation without context or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool may return 'a message if none is selected', which is useful non-obvious behavior. However it does not state whether this requires an active session/auth, whether it mutates anything, or any other operational constraint.

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

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

Two short sentences with the purpose front-loaded and the edge case in a separate 'Returns' block. No wasted words, though the 'Returns' framing is slightly redundant given an output schema exists.

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 an output schema present, return-value detail is unnecessary, and for a zero-parameter read tool the description is nearly sufficient. It does leave a small gap by not clarifying the relationship to get_board, the most likely alternative for the same task.

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?

Zero parameters, so the baseline is 4. There is nothing for the description to document and it correctly adds no parameter noise.

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?

States a specific verb and resource ('Get details of the currently selected board'), and the word 'currently selected' distinguishes it from get_board and list_boards. However, the distinction from get_board is left implicit; the agent must infer that this one requires no id and operates on session state.

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?

Usage is implied by 'currently selected' but the description never explicitly says when to use this versus get_board (which presumably needs a board id) or list_boards. The alternative is adjacent in the sibling list but not named, so routing is left to inference.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral edge case: returns organization details or a message if none is selected. The verb 'Get' clearly implies a read-only, non-destructive operation, though it doesn't explicitly state safety or auth requirements.

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

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

Two sentences, front-loaded with purpose and immediately followed by the return behavior. Every sentence earns its place with no 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?

Given the tool is a zero-parameter getter with an output schema, the description is nearly complete. It covers the no-selection edge case, but does not mention sibling alternatives or usage context, leaving a small gap for an agent choosing between it and set_organization.

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 takes zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed.

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

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

The description states a specific verb (Get) and resource (details of the currently selected organization), and the qualifier 'currently selected' distinguishes it from list_organizations and set_organization. An agent can tell what this tool returns without opening the schema.

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 'currently selected' implies the context—use this when you need the active organization—but the description never names alternatives or states when not to use it. No prerequisites or routing to set_organization or list_organizations are given.

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

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

With no annotations, the description carries the full burden. 'Look up' strongly implies a non-mutating read, which is useful, but it never states read-only behavior explicitly, nor what happens when the identifier matches no user or multiple users. For a simple lookup this is acceptable 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?

Two short sentences, zero filler, with the core action front-loaded and the usage rationale immediately after. Every sentence 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?

For a one-parameter read tool with an output schema (so return values need no explanation), the description covers purpose and usage adequately. It leaves minor gaps around not-found/ambiguous-match behavior and read-only confirmation.

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

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

Schema description coverage is 100% and the single 'user' parameter is fully documented in the schema as 'User ID, name, or email address'. The description repeats this without adding format, precedence, or ambiguity-resolution detail, so baseline 3 applies.

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

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

States a specific verb ('look up') and resource ('user'), and enumerates the accepted identifier forms (ID, name, email). It does not explicitly name or contrast with the sibling 'list_users', so the singular-lookup-vs-list distinction is left implicit rather than stated.

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 gives concrete usage context: resolving user IDs surfaced in card details (assignments, comments) into human-readable info. This is clear when-to-use guidance, but it names no alternative (e.g. list_users for bulk retrieval) and offers no 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the critical non-obvious trait that results are scoped to top-level boards by default, but does not mention pagination, result limits, or whether an empty result means 'no boards' vs 'no top-level boards'.

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?

Front-loads the scope constraint in the first line, then uses a short numbered list for the workflow. Every sentence earns its place with zero 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?

An output schema exists, so return-shape detail is unnecessary, and the description covers both scope and the collection traversal path. The only remaining gap is pagination/limit behavior, which is a minor omission for a list tool.

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

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

Schema coverage is 100% and the single 'collection' parameter is fully documented in the schema, so the baseline is 3. The description reinforces the param's meaning (name or ID, default = top-level) and adds workflow context, but introduces no syntax or format detail 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?

States a specific verb and resource ('List boards in the organization') and immediately clarifies scope: top-level by default, not inside collections. This distinguishes it cleanly from the collection-oriented siblings and an agent can tell what it returns without opening the schema.

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?

Explicitly describes default behavior (top-level only) and provides a concrete two-step workflow routing through list_collections to reach boards inside a collection. This is exactly the when/when-not/alternative guidance the dimension asks for.

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 behavioral burden. It discloses pagination, which is useful, but omits anything about permissions/auth, ordering defaults, or rate limits for a list operation. With zero annotation coverage and an output schema present, the description still leaves key behavioral context unstated.

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

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

A single efficient sentence with the resource and scoping front-loaded and no wasted words. It is arguably too terse for the tool's complexity, but as pure conciseness it is clean.

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?

An output schema exists, so return values need not be explained. The 100% schema coverage documents parameters well, but for a 4-parameter list tool with no annotations, the description does not address filtering behavior or usage context sufficiently to be fully complete.

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

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

Schema description coverage is 100%, so the schema already documents board, column, page, and archived with clear semantics (0-indexed pages, archived tri-state, column ordering). The description adds nothing beyond this, so the baseline 3 is correct.

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?

States a specific verb 'List' and resource 'cards', and scopes it to 'a specific board with pagination', so an agent can distinguish it from sibling single-card tool get_card_details. However, it doesn't position itself against other list tools (list_boards, list_columns), so sibling differentiation is only implicit.

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 what the tool does but gives no when-to-use/when-not guidance and names no alternatives. It never indicates that get_card_details should be used for a single card or that list_columns can be used to discover columns for filtering.

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 discloses the return shape (IDs and names) and implies a harmless read, but says nothing about pagination limits, permission requirements, or whether all collections are always returned. Adequate for a trivial read, but with clear gaps it cannot fully compensate for the missing annotations.

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?

Front-loaded with the core purpose, then the disambiguation, then a usage hint. Slightly verbose and the trailing 'Returns: A list of collections with their IDs and names' partially duplicates the output schema, but every sentence is short and carries a clear signal.

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?

An output schema exists, so describing return values is not strictly necessary, though the description's restatement is harmless. For a zero-parameter listing tool with sibling disambiguation and a follow-up hint, the description is essentially complete; only edge-case behavior (empty collections, permissions) is unaddressed.

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 takes zero parameters, so the baseline is 4. The description adds no parameter detail because there is none to add, and the only argument syntax mentioned (collection="name") belongs to the sibling list_boards, not this tool.

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

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

States a specific verb+resource ('List all collections (folders) in the organization') and immediately disambiguates from the sibling list_boards by explaining that collections are folders containing boards. An agent can distinguish it from list_boards, list_organizations, and list_tags without opening any schema.

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?

Gives explicit when-to-use context ('If you're looking for a board but can't find it with list_boards, it may be inside a collection') and names the follow-up call with its argument form, list_boards(collection="name"). Nothing about routing between these two tools is left to inference.

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

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

No annotations are provided, so the description carries the full burden, but it only implies a safe read via 'List'. It discloses nothing about ordering, pagination, or whether archived columns are included. For a simple enumeration tool with an output schema, the implicit read-only semantics cover most of the practical risk.

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

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

A single front-loaded sentence with no filler. Every word earns its place, and the resource and scope come before any qualifier.

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 one required parameter with full schema coverage and an output schema, so return values need no explanation. The remaining gap is the absence of any note on how to obtain the board identifier or whether results are paginated, which is minor for a tool this simple.

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 that 'board' accepts a widget_common_id, name, or ID. The description adds no extra meaning about that identifier or about ambiguity when a name collides. Baseline 3 applies 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?

States a specific verb (List) and resource (columns) with the scope qualifier 'on a specific board', which is enough to distinguish it from write siblings like create_column, rename_column, and delete_column. It does not explicitly contrast with list_lanes or list_cards, which also enumerate board sub-resources, so it stops short of 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?

The description never says when to use this tool versus alternatives such as list_lanes (the other nested board collection) or get_board, nor does it state prerequisites. The only context is a restatement of the required parameter.

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 behavioral burden and delivers very little beyond scope. It does not say whether results are paginated, whether org membership or admin rights are required, or how large the result set can get; only the org-wide scope is disclosed.

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

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

A single front-loaded sentence with zero filler, which is appropriate for a simple list tool. It is efficient, though the extreme brevity means nothing about filtering or result behavior is surfaced.

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?

An output schema exists, so return values need not be described, and both parameters are documented in the schema. The description still leaves the two filters entirely unmentioned and says nothing about pagination or access requirements, making it minimally adequate rather than 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%, so both optional filters (case-insensitive substring name match, field_type) are already fully documented in the schema. The description adds no filter syntax or semantics beyond that, which is the expected baseline 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 names a specific verb ('List') and resource ('custom fields') plus the scope ('in the organization'), so the agent knows exactly what it returns. No sibling in the list overlaps with custom fields, so the lack of explicit sibling differentiation is not a real gap here.

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?

Usage is only implied: an agent can infer this is the way to enumerate custom fields, and there is no competing sibling to route away from. However, the description never states when to reach for it, whether it is the right tool to discover field definitions before using them elsewhere, or any prerequisites.

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

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

With no annotations, the description carries the full burden and does well: it discloses that lanes are read-only in the Favro API, cannot be created/renamed/deleted, and that a board without lanes returns an empty list. It omits auth requirements and pagination, keeping it just short of full behavioral 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?

Four short sentences, front-loaded with the core purpose, then behavior, then the practical lane_id linkage. No filler or redundancy.

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

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

For a simple one-optional-parameter read tool with a full output schema and 100% schema coverage, the description covers purpose, read-only behavior, edge case (empty list), and the return-value linkage to other tools. Nothing an agent needs to call it correctly is 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?

Schema coverage is 100% and the single `board` parameter is already documented as accepting widget_common_id, name, or ID with a current-board default. The description adds no additional meaning about that parameter, 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?

States a specific verb+resource ('List the lanes (swimlanes) on a board') and clarifies the resource with a synonym. It is easily distinguished from sibling list tools such as list_columns and 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?

Gives concrete downstream usage: take the returned lane_id and pass it to create_card or update_card to place a card in a lane. It does not need to name alternatives since no sibling lists lanes, but it stops short of stating prerequisites or exclusions explicitly.

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 behavioral burden. It establishes that this is a read-only enumeration scoped to the authenticated user's access and describes the returned fields (IDs, names, member counts), but says nothing about permissions requirements or rate limits.

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?

Front-loaded with the core action and tightly sized. The 'Returns' block is somewhat redundant given that an output schema exists, but it is short and does not bury the main statement.

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

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

For a zero-parameter read-only list tool with an output schema, the description covers purpose, access scope, and the natural next step. The main gap is that return format and any pagination behavior are left to the 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 tool takes zero parameters, so the baseline is 4 per the rubric. There is no parameter surface for the description to clarify.

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?

States a specific verb and resource ('List all organizations') plus the access scope ('accessible to the authenticated user'), which separates it from get_current_organization and set_organization. It does not explicitly name a sibling it is not, so it falls short of 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 closing sentence points to set_organization for making an org active, which implies the tool's role in the workflow. However, it gives no explicit when-to-use vs when-not guidance for list_organizations itself, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose pagination, ordering, whether the list is org-wide or per-board, or permission requirements; 'list' only weakly implies a safe read-only 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?

A single short, front-loaded sentence with no filler or redundancy. It is efficient, though nearly too terse to be instructive.

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 (one optional param, output schema present so return values need no explanation) and the description is minimally adequate. With no annotations and no usage context, it is just above the minimum-viable bar.

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

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

Schema description coverage is 100% and the single optional 'name' parameter is fully documented as a case-insensitive substring filter in the schema itself. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb+resource (list tags) scoped to the organization, so an agent can distinguish it from card/board/user siblings. It does not, however, explicitly differentiate itself from other list_* tools or clarify whether tags are org-wide or derived from boards/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?

No when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., tag_card for applying tags vs. this for enumerating them). The agent must infer usage entirely from the name and sibling list.

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 behavioral disclosure burden. It implies a read operation but does not state permissions, pagination behavior, rate limits, or whether inactive users are included.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise for a simple list tool, though it is arguably too sparse given the absence of annotations.

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, has an output schema, and its parameters are fully documented in the schema, so the description need not explain return values. However, with no annotations and no usage guidance, the description leaves meaningful behavioral and selection context unaddressed.

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

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

Schema description coverage is 100%, so both the name and email filters are fully documented in the schema. The description adds no parameter meaning beyond what the schema already provides, which matches the baseline 3 when schema coverage is high.

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

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

The description states a clear verb ('List'), resource ('users'), and scope ('current organization'). It distinguishes the tool from get_user by plural listing, though it does not explicitly name or contrast with any sibling 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 gives no guidance on when to use this tool versus alternatives such as get_user or list_organizations. It only states what the tool does, leaving usage context to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the non-obvious Favro commit-vs-move semantic ('API treats a board change as commit... this tool uses move so a cross-board move actually relocates'). It omits permission/error behavior, so not a 5.

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?

Three short paragraphs, front-loaded with the core action, then placement rules, then the edge-case semantic. No sentence is redundant with the schema.

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 an 8-parameter mutation tool with an output schema, the description covers placement, lane applicability, and the cross-board caveat. It does not address failure modes or permissions, but nothing essential to calling it correctly is 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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter constraints the schema does not express: 'at most one of position, before, or after' and the shared ordering rule across lanes.

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?

States a specific verb and resource ('Move a card to a different column and/or lane, optionally on another board') and scopes it against siblings like move_column and update_card. An agent can identify the operation without opening the schema.

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?

Gives clear context for when lanes apply ('only apply to boards with lanes enabled; use list_lanes to see available lanes') and explains the no-target reorder case. It lacks an explicit contrast with update_card or assign_card for adjacent operations, so it falls short of 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?

No annotations are provided, so the description carries the full behavioral burden. 'Move' implies a mutation, but it says nothing about permissions, whether other columns are shifted, how out-of-range positions are handled, or whether the operation is reversible.

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

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

A single front-loaded sentence with zero filler or redundancy. It is appropriately sized for a title-like action, though its brevity is also the source of the contextual gaps noted elsewhere.

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

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

With no annotations, a mutation tool, three parameters, and an output schema, the description is too thin. It omits the board/column-name dependency, the effect on sibling column positions, and any error or permission context an agent needs before calling it.

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

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

Schema description coverage is 100%, so each parameter (board, column, position) is already documented with type and meaning. The description adds no syntax, constraints, or parameter-specific detail beyond the schema; baseline 3 applies.

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

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

States a specific verb ('Move') and resource ('column') plus the intended effect ('to a new position'). The resource is distinct from all siblings (no other move-column tool exists), so an agent can identify it unambiguously, though it doesn't explicitly contrast with rename_column/delete_column.

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 when-to-use guidance, no alternatives, no prerequisites. The description never mentions that the optional 'board' parameter is required when specifying a column by name, which is the main selection/routing nuance for this tool.

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

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

With no annotations provided, the description carries the full behavioral burden, and it discloses nothing: not whether the rename is reversible, whether the board parameter is required for lookup, what happens to existing references, or permission requirements. For a mutation tool this is a complete 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 single sentence is not verbose, but it is not appropriately sized for the task either: it is under-specified rather than concise, providing no front-loaded scope or constraint 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?

An output schema exists so return values need not be explained, but for a mutation tool with zero annotations the description should still cover behavioral basics like permissions, reversibility, and identifier expectations. Virtually none of that is present.

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

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

Schema description coverage is 100% and all three parameters (name, board, column) are documented in the schema, including the note that board is required for name lookup. The description adds no parameter meaning beyond the schema, 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 "Rename a column" restates the tool name and title verbatim with no additional specificity. It does identify a verb and resource, but adds nothing an agent could not infer from `rename_column` itself, and it makes no attempt to distinguish this from siblings like move_column or delete_column.

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 move_column, delete_column, or create_column, nor any stated preconditions. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key side effect (this becomes the default board for subsequent card operations), which is useful mutating-state context. However, it says nothing about whether the selection persists across sessions, whether it requires permissions, or whether switching has any side effects.

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

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

Three short sentences with the primary action front-loaded; nothing is padded. Slight redundancy between the first and second sentences ('active board' / 'default board'), but overall efficient.

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 single-parameter state-setting tool with an output schema (so return values need no explanation) and 100% schema coverage, the description covers the essential effect. It is largely complete, missing only persistence and permission context that would push it higher.

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

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

Schema coverage is 100%, so the schema already documents the single 'board' parameter. The description's note that the board 'can be specified by ID or name' restates and mildly reinforces the schema, but adds no new format or constraint detail. Baseline 3 applies 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?

States a specific verb and resource: 'Select a board as the active board.' An agent can distinguish this from get_current_board or list_boards by the 'sets as active' framing, though it never explicitly names those siblings. Clear and unambiguous, just short of explicit 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?

The sentence 'This sets the default board for card operations' gives implied context for when this tool matters, but it offers no explicit when-to-use trigger, no when-not guidance, and never points to alternatives like get_current_board. Usage is inferable rather than 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, and it does clearly disclose the core behavioral effect: it sets an 'active organization'. However, it omits failure behavior for an unknown org, whether the change is session-scoped or persistent, and whether other active selections (e.g., board) are affected by the switch.

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

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

Two short, front-loaded sentences with no filler; the purpose leads and the detail follows. The second sentence is largely redundant with the schema, which slightly dilutes the efficiency but does not make the description bloated.

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

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

An output schema exists, so return values need no explanation, and with one well-documented parameter the mechanical information is adequate. For an unannotated state-mutation tool, however, the description should say more about side effects and scope of the switch than it does.

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

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

Schema description coverage is 100% and the single required parameter 'org' is already documented as 'Organization ID or name'. The description's second sentence ('specified by ID or name') restates the schema verbatim, adding no new resolution or formatting detail, 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 states a specific verb and resource ('Select an organization as the active organization'), which is unambiguous about the state-changing nature of the call. It does not explicitly name or contrast with siblings like get_current_organization or list_organizations, but the 'set active' framing makes the distinction inferable.

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?

Usage is implied rather than stated: an agent can infer this is the tool for switching the active organization, but there is no explicit when-to-use, no prerequisites, and no mention of the read-only alternatives (get_current_organization, list_organizations) that would help disambiguate.

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 behavioral burden. It implies a mutation (tag added/removed) but says nothing about permissions required, idempotency, whether removal errors if the tag is absent, or side effects. The dual add/remove behavior is a useful signal but far from complete 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?

A single tight sentence with no filler, front-loading the core action. It is efficient, though arguably so terse that it omits context rather than being concise by design.

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?

An output schema exists so return values need not be explained, but the tool is a mutation with zero annotation coverage and no description of permissions, error behavior, or name-vs-ID lookup implications. For a write tool the description leaves meaningful 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 all four parameters (tag, card, board, remove) are already documented in the schema. The description's mention of add vs remove loosely maps to the 'remove' flag but adds no syntax, format, or lookup detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb pair and resource: add or remove a tag from a card. An agent immediately knows what the tool manipulates, though it does not distinguish itself from the sibling list_tags or explain how it relates to card-mutation tools like update_card.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., that the tag/card must already exist, or that board is needed for name lookups). The add/remove duality is only discoverable by reading the schema's 'remove' parameter.

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 behavioral burden. 'Update' implies mutation, but it says nothing about permissions, reversibility, whether omitted fields are left unchanged, or how archiving via the 'archived' param behaves.

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 single sentence is front-loaded and waste-free, but for a 10-parameter mutation tool it is under-specified rather than genuinely concise. It earns its place but adds little value to the agent.

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

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

Given a 10-parameter tool with no annotations, the description is far too thin; even though an output schema exists (so return values need not be explained), the absence of any behavioral or usage context leaves the agent relying entirely on the 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema, which already documents card identity, lane moves, tasks, tasklists, archiving, markdown restrictions, and custom field payload shapes in 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?

States a generic verb+resource ('Update a card's properties'), which tells the agent it mutates a card. However, 'properties' is broad and gives no hint that this tool also handles lane moves, task/tasklist edits, archiving, and custom fields, nor how it differs from siblings like move_card, assign_card, and tag_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 create_card, move_card, assign_card, or tag_card, and no prerequisites or exclusions are stated. The agent must infer routing purely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose permission requirements, overwrite behavior, error conditions, or any side effects beyond the basic action, leaving significant gaps 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 a single, front-loaded sentence with zero wasted words. It is appropriately sized for the tool's basic purpose.

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

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

An output schema exists and parameter coverage is complete, so return values and parameter details are covered elsewhere. However, for a write tool with no annotations and no usage guidance, the description is somewhat incomplete behaviorally.

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 all three parameters. The description adds no additional meaning about the parameters beyond what is already in 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 names a specific verb (upload) and resource (file attachment) with a clear target (a card). It is unambiguous, though it does not differentiate from any sibling tool because no sibling handles attachments.

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, what prerequisites exist, or how it relates to alternatives. It merely restates the action without any usage context.

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