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 without explaining side effects, permissions needed, or any return value, even though an output schema exists.

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, efficiently front-loaded sentence. It is concise but could be slightly expanded to include behavioral details without harming conciseness.

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

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

Given the lack of annotations, the description omits important context such as when the optional 'board' parameter is necessary, any constraints on comment text, or the structure of the output. This is insufficient for a complete understanding.

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 has 100% description coverage, clearly explaining each parameter (e.g., 'card' accepts ID, sequential ID, or name). The description adds no further semantic value 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 'Add a comment to a card.' uses a specific verb ('add') and resource ('comment' to a 'card'), clearly distinguishing it from sibling tools like 'assign_card' or 'create_card'.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as updating a card or using other interaction tools. No exclusions or conditions 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?

With no annotations provided, the description carries full burden. It covers the basic behaviors of assignment and unassignment but does not disclose potential side effects, error conditions, or required permissions.

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 of 12 words, front-loaded with the essential action. Every word is meaningful.

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 few parameters and an output schema (not shown), the description covers the main action adequately. Missing details about error handling are minor given the tool's straightforward nature.

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

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

Schema coverage is 100% with descriptions for all four parameters. The description adds little beyond the schema, essentially summarizing the operation, so it meets the baseline for high 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 'Assign or unassign a user from a card' clearly specifies the verb (assign/unassign) and resource (user, card). It distinguishes this tool from siblings like create_card or update_card by focusing on user assignment.

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 or removing user assignments but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions 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?

With no annotations, the description must disclose behavioral traits but only says 'Create a new card.' It omits whether the operation is idempotent, permission requirements, or side effects like overwriting. The agent receives no behavioral insights beyond the name.

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

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

The description is extremely concise at three words, but this under-specification sacrifices completeness. Important context about parameters and behavior is missing, making it insufficiently structured for effective use.

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

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

Given the tool's complexity (7 parameters, output schema exists) and lack of annotations, the description fails to provide sufficient context. No mention of return values, error handling, or operational scope, leaving the agent with inadequate information.

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

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

The input schema has 100% description coverage, providing detailed parameter meanings. The tool description adds no additional semantics beyond the schema. Baseline score of 3 is appropriate as the schema already does the heavy lifting.

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

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

The description clearly states 'Create a new card,' specifying the action and resource. However, it does not differentiate from sibling tools like update_card, though the name itself provides distinction. A moderate score reflects clarity but lack of additional distinguishing context.

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

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

No guidance is provided on when to use this tool versus alternatives such as update_card or assign_card. The description lacks context for usage, prerequisites, or exclusions, leaving the agent without direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the mutation (create) but does not mention side effects, permission requirements, or default behaviors like appending to the end of the board. The output schema exists but is not described in the tool description, so the agent gets no behavior details 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, efficient sentence with no filler words. It front-loads the core action and object, making it easy to scan. There is no redundant information or unnecessary elaboration, so it is highly concise.

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

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

For a relatively simple create operation, the description is partially complete. The schema covers parameter semantics, and the output schema likely describes return values, so those aspects are covered. However, the description lacks usage guidance and behavioral context that would be important for an agent deciding to invoke it, such as whether the board is required or how position defaulting works. It meets the minimum bar but leaves gaps.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters (name, board, position) with their defaults and meanings. The description adds nothing beyond the schema, so it remains at the baseline of 3, neither compensating nor detracting from the schema information.

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

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

The description clearly states the verb 'create' and the resource 'column on a board', making the core purpose unambiguous. However, it does not explicitly name sibling tools like rename_column or delete_column, leaving some differentiation to inference from the name itself. It is more specific than a generic 'process' but less explicit than examples that include sibling references.

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 like renaming, moving, or deleting a column. It does not mention any prerequisites, such as requiring an active board, or when not to use it. An agent must infer the appropriate context from the tool name alone.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states 'Delete a card' without mentioning whether deletion is permanent, whether it affects other boards (the 'everywhere' flag), or what happens to associated data like comments or attachments. This is minimal disclosure for a mutation tool.

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

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

The description is a single, direct sentence with no unnecessary verbiage. It is front-loaded with the essential action and resource, making it easy to scan. However, it is so brief that it borders on under-specification, though that is more a completeness concern than a conciseness one.

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

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

Despite having output schema (content unknown) and full parameter coverage, the description fails to explain the operational context: irreversible deletion, potential cross-board impact via 'everywhere', or any side effects. For a destructive tool with no annotations, this is inadequate. An agent would need to infer critical safety information from the schema or external docs.

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 three parameters ('card', 'board', 'everywhere') with clear meaning. The description adds no additional parameter context beyond what the schema provides, so the baseline of 3 is appropriate. It neither enhances nor detracts from the schema info.

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 ('Delete') and resource ('a card'), making the tool's purpose immediately understandable. It does not explicitly contrast with sibling card tools like 'update_card' or 'move_card', but the action is distinct enough that a capable agent can infer it. However, it lacks detail on whether deletion is permanent or moves to trash, which prevents a top score.

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

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

The description offers no guidance on when to use this tool relative to alternatives, nor does it mention prerequisites like the need for a current board context. It does not explain the 'everywhere' flag or caution about irreversibility, leaving the agent to infer usage from the schema alone. This is a significant gap for a destructive operation.

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

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

Explicitly warns that deleting a column also deletes all cards in it, which is critical behavioral context not inferable from the name. However, it doesn't mention irreversibility or permission requirements, so it's not fully comprehensive.

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-load the purpose and then the important warning. No superfluous content, and the structure is 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?

Covers the key destructive side effect, which is essential for an agent to understand the consequences. Lacks note about irreversibility or confirmation steps, but given the output schema exists and the warning is clear, it's fairly complete for a destructive action.

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 already describes both parameters with meanings (board/column ID or name), including the note that board is required for name lookup. The description adds no new 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?

States the exact action (delete) and resource (column from a board). This clearly differentiates from siblings like rename_column and move_column, and the warning about cards makes the scope unmistakable.

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 tool versus alternatives like delete_card or archive column. No mention of exclusions or prerequisites beyond the schema's note on name lookup.

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 correctly implies a read-only operation ('Get details') but does not disclose potential side effects, authentication requirements, or error conditions. However, for a simple retrieval tool, the description adequately conveys the main behavior without contradictions. The lack of explicit read-only declaration is a minor gap, not a severe one.

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 efficiently conveys the tool's purpose and key output detail ('including its columns'). There is no redundancy or extra text, making it well-structured 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?

The description is adequate for a simple get tool. It indicates the primary purpose and even highlights that columns are included in the response. The presence of an output schema means return format details are covered elsewhere. The single parameter is documented. While it doesn't explicitly address sibling distinctions, the simplicity of the tool makes the description sufficient for an agent to call correctly.

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

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

The input schema provides full coverage (100%) for the single parameter, with a description stating 'The board's widget_common_id'. The main description adds no extra semantic detail about the parameter beyond referencing a 'specific board'. Since schema already explains the parameter sufficiently, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and resource 'details of a specific board', including that columns are returned. This distinguishes it from sibling tools like list_boards (which lists all boards) and get_current_board (which targets a specific current board). The 'specific' qualifier and ID parameter make the tool's purpose 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 explicit guidance on when to use this tool versus alternatives. No mention of conditions like 'use when you have a board ID' or exclusions like 'for simple board listing, use list_boards'. The description only states what the tool does, not when it is the preferred choice. This leaves the agent to infer usage from the parameter and sibling names.

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 provided, but 'get' implies a read operation. Output schema exists, so return value details are covered. No additional behavioral traits 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?

Extremely concise single sentence with no unnecessary words; front-loaded with action and resource.

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

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

Given output schema existence and high schema coverage, the description is adequate for a simple retrieval tool, though it could mention the board requirement for name lookups.

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 covers 100% of parameter descriptions; description adds no extra meaning beyond the schema.

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

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

Description clearly states it gets detailed information about a specific card, distinguishing it from sibling tools like list_cards (list all) or create_card.

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

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

No guidance on when to use this tool vs alternatives; no mention of prerequisites or exclusions beyond what the schema implies.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It does add one key piece: 'or a message if none is selected,' which informs the agent about an edge-case return. However, it does not mention whether the operation is read-only, requires authentication, or has any side effects. Given the simplicity, this is adequate but not rich.

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

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

The description is two clear, short sentences with no fluff. It front-loads the core purpose and immediately states the return behavior. Every word earns its place, making it highly concise and well-structured.

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

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

For a no-parameter getter with an output schema, the description covers the essential purpose and the notable 'no selection' edge case. It does not explain what 'currently selected' means or how it is set, but that is inferable from sibling tools like set_board. The output schema presumably defines the return structure, so the description is sufficiently 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?

This tool has zero parameters, and the schema coverage is 100% (trivially). The description does not need to elaborate on parameters. The baseline for 0 parameters is 4, and the description adds nothing that would lower it, nor is any additional parameter context necessary.

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

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

The description clearly states the action: 'Get details of the currently selected board.' The verb 'Get' and resource 'details of currently selected board' are specific and understandable. It distinguishes from get_board by the qualifier 'currently selected,' though it does not explicitly name the sibling, so it's not fully differentiating.

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 like get_board or list_boards. It simply states what it does without explaining the context of 'currently selected' or when to prefer it over other retrieval tools. The usage is implied but not explicit.

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 provided, so description carries full burden. It only mentions return value (organization details or message) but does not disclose any behavioral traits like idempotency, authentication needs, or side effects. For a read operation, minimal but still lacking.

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?

Description is extremely concise with two sentences, front-loading the core purpose. Every sentence adds value without waste.

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

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

Given zero parameters and presence of an output schema, the description adequately states what the tool does and what it returns. It could mention that no input is required, but overall complete for a simple getter.

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?

No parameters exist in schema, and schema coverage is 100%. Baseline is 3 per rules. Description adds no parameter-level information, which is acceptable since there are none.

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

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

Description clearly states it retrieves details of the currently selected organization, using a specific verb and resource. It distinguishes from siblings like list_organizations and set_organization by indicating the 'currently selected' scope.

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

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

Usage is implied but not explicitly stated. No guidance on when to use versus alternatives like list_organizations or set_organization. Context from sibling names helps but description lacks explicit when/when-not advice.

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 transparency burden. It implies a read-only operation but does not explicitly state side effects or authentication needs. However, for a simple lookup, this is adequate.

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 concise sentences: first defines the action, second gives a practical use case. No redundant information, front-loaded with the core purpose.

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

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

Given the simple nature of the tool (single parameter, has output schema, no nested objects), the description is complete. It tells the agent everything needed to decide when and how to use it.

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

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

The input schema already describes the parameter adequately (100% coverage). The description restates the same information without adding new details about format or constraints, so it meets the 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 clearly states the action 'Look up a user' and the resources (by ID, name, or email). It distinguishes from sibling tool 'list_users' by focusing on single user lookup with specific identifiers.

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

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

The description provides a clear use case: resolving user IDs from card details. While it does not explicitly exclude alternatives, the context is sufficient for an agent to understand when to use 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?

No annotations are provided, so the description must carry the burden. It discloses the key behavioral nuance: default returns only top-level boards, and passing a collection changes results. It does not mention pagination, ordering, or error behavior, but the output schema likely covers the return format. The core behavioral difference is transparent.

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

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

Three concise sentences front-load the purpose, then outline default behavior and usage steps. No filler or redundancy; 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?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description fully covers its usage context. It explains when to use it and the necessary prerequisite step (calling list_collections), which is key for correct invocation.

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

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

The input schema already provides 100% coverage of the 'collection' parameter, including its default behavior. The description repeats this but adds a usage flow rather than new semantic meaning. With schema coverage at 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 verb and resource ('List boards in the organization') and specifies the scope with top-level vs. inside collections. It implicitly differentiates from sibling tools like list_collections by focusing on boards.

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 explains the default behavior (top-level only) and provides step-by-step instructions for listing boards inside a collection, prescribing a two-call sequence with list_collections. This gives clear guidance on when and how to use the tool versus alternatives.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or rate limits. The verb 'list' implies read, but this is not explicit.

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, no wasted words. Information is front-loaded and 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?

Given the presence of an output schema and complete parameter descriptions, the description covers the essential purpose. It does not mention optional filters (column, archived) but those are in the schema, making it adequate for this low-complexity 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?

Input schema has 100% description coverage, so the schema already explains parameters. The description adds 'with pagination' which is redundant with the page parameter description. Baseline score of 3 is appropriate.

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

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

The description clearly states the action (list), the resource (cards), and scope (on a specific board with pagination). It is specific and distinct from sibling tools like get_card_details or create_card.

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

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

No guidance on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, leaving the agent to infer usage context.

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

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

With no annotations provided, the description carries the full burden. It states the operation is a list (read-only) and discloses the return format ('a list of collections with their IDs and names'). It does not mention side effects or auth requirements, but for a parameterless read tool the description is adequately transparent.

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

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

The description is front-loaded with the primary purpose, then adds concise explanatory context and a usage example. It is efficient with no wasted words, and the structure flows logically from purpose to usage to return.

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, parameterless listing tool, this description is complete. It explains what collections are, how they relate to boards, when to use this tool vs. list_boards, and what the return contains. The presence of an output schema further covers return details, so nothing necessary 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?

The tool has zero parameters, and schema coverage is trivially 100%. The description correctly adds no parameter-level detail, which aligns with the baseline of 4 for parameterless tools.

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

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

The description states a specific verb and resource ('List all collections (folders) in the organization') and immediately distinguishes it from the sibling tool list_boards by explaining that collections are containers for boards. This makes the tool's purpose 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?

The description explicitly provides usage guidance: 'If you're looking for a board but can't find it with list_boards, it may be inside a collection' and instructs to use list_boards(collection="name") to see boards inside a collection. It clearly says when to use this tool versus the alternative.

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

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

No annotations are provided, so the description carries full burden. It states the operation is read-only but lacks details on pagination, sorting, authentication, error handling, or response format beyond what the output schema may provide.

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 that efficiently conveys the tool's core purpose. It is concise but not overly brief, though it could benefit from expanding on context.

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 25 sibling tools and the absence of annotations, the description is too sparse. It does not explain how this tool fits into a workflow, what the output represents (despite having an output schema), or any behavioral constraints.

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

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

Schema coverage is 100% with the parameter description 'The board's widget_common_id, name, or ID'. The description adds no additional 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 uses a specific verb 'List' and resource 'columns' with scope 'on a specific board', clearly distinguishing it from sibling tools like create_column, delete_column, 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?

No guidance on when to use this tool versus alternatives like list_cards or get_board. The description does not mention exclusions or prerequisites, leaving the agent to infer usage 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 carries the full burden. It clearly implies a read-only listing operation with no side effects, but doesn't disclose pagination, ordering, or whether results are limited to the current organization. This is minimal but not misleading.

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

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

A single sentence that conveys the core purpose without wasted words. It is appropriately concise, though it could briefly mention optional filtering to add value.

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

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

Given an output schema exists and two optional parameters, the description is fairly complete for a simple listing tool. However, it doesn't clarify whether filters are combinable, how organization scope is determined, or whether any authentication or permissions are needed. It is adequate but not rich.

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

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

Schema description coverage is 100%, so both parameters (name and field_type) are already documented in the schema. The description adds no extra 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 description states the verb 'List' and the resource 'custom fields' with scope 'in the organization', making the purpose clear. It is distinguishable from siblings like list_columns or list_lanes because the resource is explicitly named, though it doesn't contrast with them.

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 tool versus alternatives. It doesn't mention that filters are optional or when one might filter by name vs type, nor does it clarify the organizational context (e.g., current organization) which is relevant given siblings like list_organizations and set_organization.

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 fully discloses behavioral traits: lanes are read-only, cannot be created/renamed/deleted, and the tool returns an empty list for boards without lanes.

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 concise (4 sentences) and front-loaded with the main action. Every sentence adds relevant information without redundancy.

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

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

For a simple tool with one optional parameter and an output schema, the description covers purpose, usage hints, and behavioral specifics completely.

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%, baseline 3. The description adds value by noting that the board parameter defaults to the current board if not specified, which goes beyond the schema's description.

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

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

The description clearly states it lists lanes (swimlanes) on a board, using a specific verb and resource, and distinguishes from sibling tools like list_columns or list_cards.

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

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

The description explains that lanes are read-only, how to use lane_id for other tools, and that a board without lanes returns an empty list. It provides context but does not explicitly compare to sibling tools or state when not to use.

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?

Despite no annotations, the description discloses the return format (IDs, names, member counts) and states it's a list of accessible organizations. For a simple read-only tool, this is sufficient behavioral 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 three sentences: purpose, return details, and usage guidance. Every sentence is necessary and contributes value, with no redundancy.

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

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

Given the tool's simplicity (no parameters, clear output), the description fully covers what an agent needs: what the tool does, what it returns, and what to do next. No gaps identified.

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

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

The input schema has zero parameters, and the description adds meaning by specifying the output structure and the scope of the list, which goes beyond the schema's empty properties.

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

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

The description clearly states the verb 'List' and the resource 'organizations', and specifies the scope 'accessible to the authenticated user'. It effectively distinguishes from sibling tools like set_organization.

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 guidance to use set_organization after listing to select an active organization. However, it does not explicitly exclude alternatives or mention when not to use this tool, which would have made it a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It states the action (list) and return type, but omits details like ordering, pagination, whether archived tags are included, or permissions. It's not misleading, but for a tool that could potentially have large result sets, additional transparency would help.

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 concise and well-structured: a one-line summary followed by a clear 'Returns' section and a practical usage hint. Every sentence earns its place, and the key information is front-loaded.

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 complete for a simple list tool: it states the scope (organization), the return fields, and a follow-up action. It doesn't mention whether the operation is read-only (obvious from the verb) or whether it requires a specific organization to be set, but the existence of set_organization implies a current-organization context. Overall, adequate.

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

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

The tool has zero parameters, so the input schema is empty with 100% coverage. Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter details (there are none) but does describe the return structure, which is useful context.

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 'List all tags in the organization' – a specific verb and resource. It distinguishes itself from siblings like list_cards and list_custom_fields by focusing on tags, and it connects to tag_card for modification. No ambiguity.

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

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

The description gives a clear usage pointer: 'Use the tag name or ID with tag_card() to add/remove tags from cards,' which explains a typical workflow and directs the agent to the relevant sibling. It doesn't explicitly state when NOT to use it, but for a simple list operation the guidance is adequate.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a list of users with IDs, names, emails, and roles, which is adequate for a read-only list. It does not mention ordering or limits, but for a simple list with no parameters, this is acceptable.

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

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

The description is only two sentences, with the action front-loaded in the first sentence. Every word is necessary and there is no fluff. Highly 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 simple parameterless list tool that also has an output schema, the description is complete. It covers purpose, return fields, and scope. No obvious gaps.

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

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

The input schema has zero parameters, so schema coverage is 100% trivially. According to guidelines, baseline is 4 for zero parameters. The description adds no parameter info, but none is needed.

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

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

The description clearly states 'List all users' with a specific verb and resource, and adds 'in the current organization' to define scope. It is distinguishable from siblings like get_user (single user) and list_organizations (orgs).

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

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

The description provides clear context for when to use this tool (to get all users in the current org). It does not explicitly exclude alternatives, but the sibling names (get_user) imply the distinction. Lacks explicit when-not or alternative guidance, keeping it a 4.

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 does disclose that the tool uses 'move' semantics rather than the API's default 'commit' (which looks like a copy), which is crucial behavioral context. It also notes the lane constraint. However, it does not mention error behavior, what happens if both column and lane are omitted (which the schema allows), or any preconditions like needing the correct board context. This is a decent disclosure but not comprehensive.

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 about five sentences and roughly 100 words. It front-loads the core action and then explains key nuances (lane applicability and cross-board move semantics). Each sentence adds value; none are redundant. It is slightly longer than the minimum needed but remains efficient and well-organized.

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

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

Given the complexity of the tool (cross-board moves, optional lanes), the description covers the essential usage: how to specify targets, lane constraints, and the move-vs-commit behavior. It also points to list_lanes for discovering lanes. An output schema exists (though not shown), so return format is likely covered there. Minor gaps include error handling and the fact that the schema allows calling without any destination, which the description does not explicitly forbid. Overall, it is reasonably complete for correct invocation.

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

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

The input schema already provides 100% coverage with detailed descriptions for all five parameters, so the baseline is 3. The description adds some context about which parameters to use together (e.g., 'Specify a column, a lane, or both') and clarifies that lanes only apply on lanes-enabled boards. However, it largely reinforces the schema rather than adding deep new meaning about parameter values or formats, so it stays at 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 specific action (move a card), the resource (card), and the destinations (column, lane, or board). It clearly distinguishes itself from sibling tools like create_card, update_card, and assign_card by focusing on relocation. It also highlights the important nuance of cross-board move vs copy, which further clarifies its unique 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: specify a column, lane, or both, and notes that lanes only apply to boards with lanes enabled, directing users to list_lanes. It explains the cross-board behavior and that to_board is optional, giving enough guidance for typical usage. It does not explicitly name alternative tools to avoid, but the purpose is clear enough that an agent would know when to use this instead of update_card or assign_card.

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 provided. Description does not disclose side effects, such as impact on column ordering of other columns or potential data loss. No mention of required permissions or immediate effect.

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, no extraneous words. Information is front-loaded and clear.

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

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

Despite having an output schema, the description fails to explain what happens to other columns during a move, or that the move is within the same board. Lacks completeness for a mutation operation with potential side effects.

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

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

Input schema already describes parameters with 100% coverage. Description adds no additional meaning beyond what is in the schema, such as implications of moving on column indices or valid position ranges.

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

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

Description clearly states the action 'move a column to a new position', which distinguishes it from siblings like rename_column or delete_column. It uses a specific verb and resource with clear scope.

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

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

No guidance on when to use this tool vs alternatives, such as move_card or list_columns. No prerequisites or context are 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 of behavioral disclosure. It simply states 'Rename a column' without mentioning that this is a mutating operation, any required permissions, what happens to dependent data, or whether changes are reversible. This is a significant gap for a write operation with zero annotation coverage.

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

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

The description is extremely short and front-loaded, but it does not add value beyond repeating the tool's name. It is concise in length but lacks substance. It is not verbose, but it also does not earn its place by providing any actionable information. A score of 3 reflects the brevity without penalizing for excessive text, but it is barely above the under-specification threshold.

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 behavioral details, the description is inadequate. It does not explain when to use it, what effects it has, or any edge cases. The existence of an output schema covers return values, but the description still fails to provide necessary context for an agent to safely and correctly invoke this tool. This is a significant completeness gap.

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

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

Schema description coverage is 100%, so each parameter has a description in the schema. The tool description adds no additional information about parameters, but the schema already documents 'name', 'board', and 'column' adequately. Baseline 3 is appropriate because the schema handles the parameter semantics.

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

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

The description 'Rename a column' clearly states the verb (rename) and resource (column). It is not a tautology because it combines the name with an action, but it does not distinguish from sibling tools like move_column or delete_column. The purpose is unambiguous, but no effort is made to differentiate it from other column operations.

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

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

There is no guidance on when to use this tool vs alternatives. No mention of prerequisites, exclusions, or recommendations. The agent is left to infer based on the name alone, which is insufficient when sibling tools like create_column, move_column, and delete_column exist with similar naming patterns.

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

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

No annotations are present, so the description must disclose all behavioral traits. It mentions setting the active board but does not explain side effects, error handling for invalid board IDs, or permission 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 concise sentences, front-loaded with the primary action. No superfluous words.

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

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

Given the simple tool with one parameter and an output schema, the description covers the basic function but lacks details on prerequisites, error states, or the full implication of setting a default board.

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

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

Schema description coverage is 100%, and the description merely repeats that the board can be specified by ID or name, adding no new meaning beyond the schema.

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

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

The description clearly states the verb 'select' and resource 'board', explaining it sets the active board for card operations. This distinguishes it from sibling tools like get_board or list_boards.

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 setting a default board but does not explicitly state when to avoid or mention alternatives. No exclusion criteria or prerequisite conditions are 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 full burden. It states the action (select active organization) which implies a mutable state change, but it does not disclose what happens to previous state, persistency, permissions, or whether it affects subsequent calls. The information is minimal but non-contradictory; it at least indicates a state-changing operation.

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

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

The description is extremely concise—two short sentences with no filler. The primary intent is front-loaded, and the parameter guidance is minimal but sufficient. Every word earns its place; it is appropriately scoped for a single-parameter setter.

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 setter with one parameter and an output schema, the description covers the essential purpose and parameter format. It does not mention side effects or administrative requirements, but given the low complexity and schema coverage, it is largely complete. The absence of such details is 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 a description for the only parameter ('Organization ID or name'), and the tool description repeats the same information ('by ID or name'). Since schema description coverage is 100%, the description adds no additional semantic value beyond what is already documented. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Select' and the resource 'an organization as the active organization'. It distinguishes from list/get organizations by intent (changing vs querying), but does not explicitly name siblings or contrast them. It is clear and specific enough for an agent to understand the core 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 gives no guidance on when to use this tool versus alternatives like 'get_current_organization' or 'list_organizations'. It does not state preconditions, side effects, or exceptions. The intended use case is implied but not articulated, so an agent might call it without understanding the impact on other operations.

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 dual behavior (add/remove via the 'remove' parameter), but does not reveal potential side effects, required permissions, or limitations. 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?

Extremely concise, one sentence with no wasted words. It is front-loaded and clear. However, it could be slightly expanded for completeness without losing conciseness.

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

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

Given the 100% schema coverage and presence of an output schema, the description does not need to explain return values. However, it lacks nuance about edge cases (e.g., tag already present, non-existent tag). Adequate but not complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema; it merely restates the tool's action. No extra context for parameters is provided.

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

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

The description clearly states the action (add or remove) and the resource (tag from a card). It is specific, but does not distinguish itself from sibling tools like 'assign_card' which could also modify card attributes. No explicit differentiation.

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

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

No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description only states 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.

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

With no annotations, the description carries full burden for behavioral disclosure, but it only says 'Update a card's properties.' It does not mention potential side effects, required permissions, or limitations such as rate limits or field constraints.

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

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

The description is extremely concise (one short sentence), but lacks structure and fails to provide necessary context. It is not front-loaded with key information; it is just a minimal 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?

Given the tool has 10 parameters and no annotations, the description is far too brief. It does not explain the overall behavior, return values (though output schema exists), or prerequisites, leaving many gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters.

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

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

The description clearly states the verb (update) and resource (card), indicating it modifies card properties. However, it lacks differentiation from sibling tools like assign_card or tag_card, which also modify 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 guidance on when to use this tool vs alternatives. The description does not specify conditions, prerequisites, or scenarios where this tool is preferred over other card-modifying 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, the description must disclose behavior, but it only states the action. It does not mention success/failure outcomes, side effects, or any constraints beyond what's in the 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, front-loaded sentence that is appropriately concise with no wasted words.

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

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

The description does not explain the output format (despite an output schema existing) or mention prerequisites like the card existing, making it incomplete for an agent to use correctly.

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. The description adds no additional parameter meaning beyond the schema.

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

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

The description clearly states the verb (Upload) and resource (file attachment to a card), distinguishing it from siblings like add_comment or create_card.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned.

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