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

With no annotations, the description carries the full safety burden and does so: it declares read-only behavior and explicitly denies the four mutation capabilities an agent might otherwise assume (create, refresh, revoke, manage). It does not cover failure behavior for an already-expired or insufficiently-scoped token, which is the main remaining 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?

One sentence, front-loaded with the usage mode, then the payload, then the negative boundaries. No filler and nothing an agent must read twice.

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-optional-parameter, no-output-schema tool, the description supplies enough: what is inspected, what is returned conceptually, and that nothing is mutated. Only the sibling overlap with auth_whoami keeps it from being fully self-sufficient for tool selection.

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

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

Schema description coverage is 100% for the single optional 'fields' parameter, so the baseline is 3. The description gestures at the field set (owner, expiration, permissions) but adds no detail on syntax, defaults, or the 'all' keyword beyond what the schema already states.

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

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

The description names a specific verb ('inspect') and a precise resource ('the configured Trello token'), and enumerates the inspected attributes (owner, expiration, permissions). It is clear on its own, but it never distinguishes itself from the sibling auth_whoami, which an agent would reasonably see as an overlapping identity 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?

'Use as a read-only credential diagnostic' gives an explicit usage context, and the closing clause ('does not create, refresh, revoke, or manage tokens') sharply bounds when not to reach for it. It stops short of naming an alternative, so the auth_whoami vs auth_token_info choice 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 provided, the description carries the full burden and does disclose the key traits: it is read-only, it uses the server-configured API key and token rather than per-call credentials, and its output is a member identity. It stops short of saying what happens when credentials are invalid (error vs empty), which would round this out.

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 with no filler, front-loaded with the usage cue and ending on the precise object of the call. Nothing could be removed without losing information.

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

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

For a one-optional-parameter read tool with no output schema, the description covers what it does, its read-only nature, and the fact that it reads server-configured credentials. Only the failure behavior and the distinction from auth_token_info are 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?

There is one optional parameter and schema description coverage is 100%, so the schema already explains the comma-separated fields list and the 'all' option. The description adds nothing about it, which is acceptable at baseline but leaves no surplus value.

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

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

States a concrete verb ('confirm') and a concrete resource ('which Trello member the configured API key and token authenticate as'), which is far more specific than a restatement of the name. It does not, however, distinguish itself from the sibling auth_token_info, leaving the agent to infer which auth diagnostic to pick.

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?

'Use as a read-only credential diagnostic' implies the usage context (verifying that the configured key/token are valid and belong to which member). There are no explicit when-not conditions and no named alternative such as auth_token_info, so the agent must infer the routing between the two auth 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 carry the behavioral burden. It discloses that histories should be bounded with filters/limits/paging, but does not explicitly state read-only behavior, permissions, rate limits, or return semantics.

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 compact sentence with the use case and key invocation guidance front-loaded. It contains no filler and is appropriately sized for a retrieval tool.

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

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

The schema richly documents all 11 parameters, which compensates for the short description. However, with no annotations and no output schema, the description does not fully explain expected return shape or safety profile, leaving some contextual 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 coverage is 100%, so parameter documentation is already strong. The description groups filter, limit, page, since, before, and fields as history-bounding controls, but adds little detail beyond the schema and omits the member-related toggles.

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 identifies the resource scope as board-level activity/comments and implies retrieval for auditing. It is clear enough to distinguish board-wide history from card- or list-level actions, though it does not explicitly name those siblings.

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?

It gives a clear use case: auditing recent board activity or comments. It also directs the caller to use filtering and pagination controls for large histories, but does not state when to use sibling tools like card_actions instead.

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 only gives a use case and does not explain read-only behavior, pagination, filtering, field selection, or what happens with the limit/since/before parameters.

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

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

The description is a single front-loaded sentence with no redundant text. It is appropriately sized, though it could be slightly more informative without becoming verbose.

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 six-parameter retrieval tool with no annotations and no output schema, the description is minimal but the schema is rich. It identifies the board-wide card scope but does not explain return behavior or pagination, leaving some contextual 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 schema already documents all six parameters thoroughly. The description adds only the board-wide scope implied by 'across all lists' and does not supplement 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 that the tool retrieves cards across all lists on a known Trello board, which is a specific resource and scope. It does not explicitly distinguish itself from siblings such as list_cards or member_cards, 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?

The phrase 'Use when you need cards across all lists on a known Trello board' gives clear usage context. However, it does not mention when to prefer alternatives like list_cards, member_cards, or search, nor does it state 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 burden. It does disclose meaningful behavior: boards default to private, workspaceId places the board in an org, and visibility is restricted to enumerated values. It says nothing about permission requirements, whether the creator becomes an admin, or rate limits 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 front-loaded sentence that opens with the usage trigger and then layers the behavioral constraints. It is slightly run-on with three comma-joined clauses, but there is no filler or repetition.

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 and no output schema, the description should carry more of the operational burden. It covers visibility and workspace placement adequately but leaves auth requirements, what the created board response contains, and failure modes unaddressed for a 4-parameter mutation.

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 reinforces the private default and the workspaceId placement, but that information is already present in the schema's own parameter descriptions; it adds no new syntax, format, or edge-case detail beyond it.

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 ('creating a new Trello board') and immediately scopes it by describing the default visibility and workspace placement. An agent can distinguish it from the read-oriented board siblings (board_get, list_boards, workspace_boards) without inspecting 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 'Use when creating a new Trello board' trigger is explicit, and the clause about only supporting explicit private/workspace/public visibility sets a constraint on invocation. However, it names no alternative path (e.g., creating a board from a template or moving an existing board) and gives no prerequisites such as required auth scope.

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 adds one genuine behavioral note — that dropdown/list options are included only 'when Trello returns them', signalling conditional/incomplete payloads — but says nothing about read-only semantics, auth requirements, rate limits, or the shape of returned definitions.

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?

One sentence, front-loaded with the 'Use when' trigger and no redundant restatement of the tool name. It is efficient, though the qualifier 'when Trello returns them' is slightly ambiguous about whether options are opt-in.

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-parameter read tool with no output schema, the description does convey the gist of the return (definitions plus conditional options). It still leaves the agent guessing about what a definition contains and whether assigned field values are included, which matters given no output schema to fall back on.

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

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

Schema description coverage is 100% for the single boardId parameter, so the schema already documents its meaning. The description's phrase 'known Trello board' reinforces that boardId must reference an existing board but adds no format, ID source, or validation 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?

The description gives a specific verb ('inspecting') and resource ('custom field definitions on a known Trello board'), so the agent knows this lists board-level custom field definitions rather than field values. It does not name or differentiate against close siblings such as custom_field_get, board_field_get, or custom_field_options, which is exactly where confusion is likely.

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 'Use when inspecting custom field definitions on a known Trello board' clause establishes a clear trigger condition. However, it offers no when-not guidance and does not route the agent away from custom_field_options, even though it explicitly mentions returning dropdown/list options — an overlap that invites misselection.

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 explicitly state that this is a read-only operation, mention permissions or side effects, or describe what the tool returns for the requested field.

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 unnecessary exposition. Its examples are useful, though some overlap with the enum and include labels that do not exactly match schema enum values such as 'desc' and 'url'.

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

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

For a simple two-parameter read tool with full schema coverage, the description is adequate for selection and invocation. It is less complete about the return value, since there is no output schema and the description does not explain what reading a field returns.

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 both parameters and the field enum. The description adds example field names, but this largely duplicates the enum and does not add syntax or constraints 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 identifies a specific resource and scope: retrieving one board field. It distinguishes this from broader board retrieval by emphasizing a single field, though it does not explicitly name the sibling tool board_get.

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

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

The phrase 'Use when you need one specific board field' gives implied usage guidance. However, it does not explicitly name alternatives such as board_get or explain when to use this tool versus retrieving the full board.

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 load. It communicates that this is a read of a known board, but doesn't state safety/read-only nature explicitly, permissions required, or response shape, leaving gaps that annotations would normally cover.

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 clause (details, prefs, label names, pre-summary context) contributes. Nothing wasted and nothing buried.

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 only two well-documented params and no output schema, the definition is largely sufficient, but the absence of annotations means the description could do more to characterize the read behavior and what the returned 'preferences' and 'label names' represent. It's minimum-viable 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 boardId and fields are fully documented in the schema, including the default field list. The description adds no syntax or format detail beyond that, so the 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 names both the verb (get) and the concrete resources returned — board details, preferences, and label names — for a known board. It's clear what the tool fetches, though it doesn't explicitly differentiate itself from close siblings like board_field_get or board_labels.

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

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

It specifies the condition to use it ('before listing or summarizing' a known board), giving a clear operational context. It stops short of naming alternatives or exclusions (e.g., when to prefer board_field_get for a single field), so it's clear but not exhaustive.

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 yet says nothing about read-only semantics, the 50-item default/cap, or the fact that 'fields' controls response shape. Only the implicit 'discovering' hints at a safe read; nothing about pagination or rate limits 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 well-formed sentence with the usage trigger front-loaded and no filler. It is efficient but slightly under-specified rather than over-long.

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 3-parameter read tool with no annotations and no output schema, the description should mention the returned shape at least in outline (names, colors, uses) and that results are capped. As written, an agent can call it but cannot predict the response.

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% - each of boardId, limit and fields is documented in-schema, so the baseline is 3. The description adds no extra meaning about parameter behavior or interactions.

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 conveys a clear verb (discovering) and resource (labels available on a board), so an agent knows this returns a board's label set. It does not differentiate from nearby siblings such as label_get or card_labels, which could also surface label data.

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?

'Use when ... before creating or updating cards with labels' gives a concrete trigger context. It stops short of naming an alternative (e.g. label_get for a single label) or stating when not to use it.

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

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

With no annotations, the description must carry behavioral context. It implies a read-only retrieval and mentions the 'known board' precondition, but it omits permissions, error behavior, and other operational details, leaving it at minimum viable.

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, front-loaded sentence with no filler. The use case and downstream purpose are both expressed without 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?

For a low-complexity read tool with full schema coverage, the description gives enough context to call it correctly and tells the agent what to extract (the list id). It does not explain return fields, but the narrow purpose makes that a minor 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 the schema already fully documents boardId, fields, and filter. The description only reinforces the board scope and adds no parameter syntax or meaning beyond the schema, making 3 the appropriate 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 identifies the resource as lists on a known Trello board and ties it to a concrete outcome: finding the right list id. It distinguishes the tool from card-level siblings through the board/list scope, though it does not explicitly name an alternative 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?

It says exactly when to use it ('when you need the lists on a known Trello board') and what downstream actions it supports ('before listing or creating cards'). It stops short of explicit when-not guidance or naming sibling alternatives like list_cards or card_create.

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 it does disclose an important access prerequisite: 'requires token visibility of private boards.' However, it does not state that this is a read-only operation, describe the return shape, or mention pagination, leaving meaningful behavioral gaps.

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

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

The description is a single, front-loaded sentence that packs the use case and permission requirement without wasted wording. It is appropriately sized for a simple two-parameter read 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?

For a simple read tool with complete schema descriptions and no output schema, the description covers purpose, usage context, and an access precondition. It is nearly complete, though it could mention that the result is a member list and whether pagination applies.

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 boardId and fields are already documented in the input schema. The description adds only the notion of a 'known Trello board' and does not explain field selection or any semantics beyond what the schema provides.

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

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

The description clearly identifies the resource as 'the members who can access a known Trello board,' giving a specific retrieval target. It does not explicitly distinguish this from close siblings such as board_memberships or workspace_members, so it falls 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?

It explicitly frames the use case as 'before assigning cards or reviewing collaboration,' which tells the agent when this tool is appropriate. It does not name alternatives or state when not to use it, so it lacks full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a retrieval operation but does not state read-only behavior, authorization requirements, response shape, pagination, or other operational traits.

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 compact sentence with the primary usage condition front-loaded and no wasted wording.

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 four-parameter retrieval tool with full schema coverage, the description covers purpose and filter usage adequately. However, with no annotations and no output schema, it leaves behavioral gaps around read-only status, auth, and return behavior.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds useful context for the admins filter, but says nothing additional about member, memberFields, or boardId 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 identifies board membership records, member roles, and permission context for a known Trello board. It does not explicitly distinguish this tool from the sibling board_members tool, so sibling differentiation is missing.

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?

It provides clear usage context: use it when you need board membership records or permission context, and use the admins filter for board-admin-only operations. It does not name an alternative tool or state when not to use this one.

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. 'Auditing' implies a read-oriented operation, and it discloses that filter, limit, page, since, before, and fields support paging large histories, but it does not explicitly confirm read-only behavior, permissions, or result shape.

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 compact sentence with the primary use case front-loaded and no wasted text. The paging guidance is also placed where it is immediately useful.

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

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

The tool has 11 parameters and no output schema, but the description only covers the auditing use case and basic paging. The schema fills in parameter details, yet the description does not explain the return payload or the member/memberCreator expansion options, leaving some contextual 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 schema already explains the parameters in detail. The description names several paging/filtering parameters but adds little semantic depth beyond what the schema 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?

The description clearly scopes the tool to card-level activity/comment auditing, which distinguishes it from board_actions, list_actions, and workspace_actions. It does not explicitly state a verb like 'list' or 'retrieve', but the intended operation is still easy to infer.

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?

It gives a clear use case: auditing recent activity or comments for a card. It also points to paging-related parameters for large histories, but it does not mention when to choose card_actions over sibling activity tools such as board_actions or list_actions.

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 usefully discloses recoverability and non-permanent deletion, but it does not explain permissions, what archiving changes on the board, or what the call returns.

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, front-loaded sentence with the usage condition first and the exclusion second. There is no wasted wording.

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

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

For a simple two-parameter card operation with a fully documented schema and no output schema, the description supplies the key selection and safety context. The remaining gap is minor: it does not describe side effects such as how the card appears after archiving.

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 schema fully documents cardId formats and the closed=true/false meaning. The description only implies archive versus unarchive and adds no parameter 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?

The description states a specific verb and resource: archive or unarchive a card. It also explicitly distinguishes this from permanent deletion, which lets an agent separate it from sibling tools like card_delete.

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?

It gives an explicit trigger: use when the user wants to archive or unarchive a card while keeping it recoverable. It also gives an explicit exclusion: do not use for permanent deletion, which clearly routes the agent toward deletion elsewhere.

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, but it only discloses that local files are not uploaded. It says nothing about permissions/auth requirements, mutation side effects, what happens when setCover is true, or what is returned. The one constraint given is useful but insufficient 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?

One sentence, front-loaded with the usage condition and ending with the key exclusion. Every clause 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?

The schema fully covers the parameters and there is no output schema, but the tool is a mutation with zero annotations. The description could have mentioned permission needs or attachment side effects; as written it is 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 all four parameters are already documented in the schema. The description adds no parameter-level meaning beyond the schema, which is acceptable but not additive.

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 ('attaching an existing public URL to a card') and explicitly distinguishes the tool from the sibling upload tool by noting it 'does not upload local files.' An agent can select this tool with 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?

It clearly states when to use the tool ('attaching an existing public URL') and gives an exclusion ('does not upload local files'). It stops short of naming the sibling alternative (card_attachment_upload) or describing prerequisites, so it is strong but not exhaustive.

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 does so well: it states the action is permanent, cannot be undone, and deletes Trello's stored file for uploads. Those are the critical side effects an agent needs before invoking a destructive 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?

Two sentences, both front-loaded: the destructive action is stated first, followed by the safety-relevant alternative. There is 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?

For a simple two-parameter delete tool with full schema coverage and no output schema, the description supplies the essential context: permanence, unrecoverability, file deletion, and the safer sibling operation for cover removal.

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 both required parameters are documented in the schema. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

States a specific verb and resource: permanently delete an attachment from a card. It further clarifies that uploads include Trello's stored file, which distinguishes this from merely unlinking or clearing a cover.

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 alternative for a related operation: use card_cover_set to clear a cover without deleting its attachment. It does not spell out broader when-not-to-use conditions, but the key sibling distinction is 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 exist, so the description carries the full burden: it does signal this is a read ('inspecting') and honestly notes that upload metadata is only present 'when Trello returns it,' which is useful conditional-return context. It says nothing about permissions, behavior for a missing/invalid attachment id, or whether fields affect the payload size.

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; the use-condition comes first and the conditional-return caveat follows. It could be marginally denser with one clause about return shape, but nothing is wasted.

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 and no output schema, the description is the only place to learn what comes back, and it only gestures at 'upload metadata when Trello returns it.' For a 3-parameter read tool it is adequate, but the caller still doesn't know the response shape or whether fields='all' materially changes cost.

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 cardId, attachmentId, and the fields parameter are already documented in the schema. The description reinforces the attachment-id lookup and hints that responses can include upload metadata, but adds no syntax or format guidance 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 a specific verb and resource — inspecting a single existing card attachment by id — and scopes it to one item, which is distinguishable from the sibling card_attachments list tool. It stops short of naming that sibling as the fan-out alternative.

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 'Use when inspecting one existing card attachment by attachment id' clause gives a clear trigger condition for retrieval of a single attachment. It offers no explicit exclusions (e.g., when to prefer card_attachments for listing) but the context is unambiguous.

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 behavioral load. It correctly implies a read-only listing and discloses that results can be narrowed, but says nothing about pagination, result size, permission requirements, or what happens when a card has no attachments.

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 states the trigger condition first and the optional modifiers second. Nothing is wasted.

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 three-parameter read-only listing tool with full schema coverage, the description gives an agent everything needed to select and invoke it correctly. The only gap is the absence of any hint about the return shape, which matters slightly since no output schema exists.

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 are already documented in structured form. The description's phrase "narrowed by Trello attachment fields or filter" merely restates the fields and filter params without adding format or default guidance, 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 (listing) and resource (files or links attached to a card), which clearly separates it from the singular card_attachment_get sibling. It is clear about what is returned without naming that sibling explicitly.

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

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

"Use when listing files or links attached to a card" is an explicit trigger condition, and the optional narrowing clause tells the agent how to scope the call. There are no exclusions or named alternatives (e.g., card_attachment_get for a single attachment), which keeps it below 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 behavioral burden well: it discloses the server-local root restriction, the disabled state when the root is missing, and the duplicate-upload side effect. It does not cover authentication or permission requirements, but the key operational caveats for this upload action are present.

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, front-loaded with the core action, then constraints and the alternative. There is no wasted language.

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 five-parameter upload tool with no annotations or output schema, the description covers the critical selection and invocation context: root restriction, disabled state, duplicate risk, and the URL alternative. It does not describe the response or permission requirements, but the main behavioral constraints an agent needs are 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%, so the schema already documents all five parameters, including the root-path behavior for filePath. The description reinforces that files must be server-local and inside TRELLO_ATTACHMENT_UPLOAD_ROOT, but adds little parameter-level 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 uses a specific verb and resource: reading a server-local file and transmitting it to Trello as a new card attachment. It also distinguishes itself from the sibling URL-based attachment tool, so an agent can identify the correct tool without inspecting schemas.

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?

It explicitly states the alternative for public links: use card_attachment_add_url instead. It also provides the prerequisite that the tool is disabled unless TRELLO_ATTACHMENT_UPLOAD_ROOT is configured and warns that repeated uploads can create duplicates.

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 disclosure burden. It never states that this is a read-only lookup, what shape the 'board relationship' comes back in, or whether the optional fields parameter changes the payload — all left to inference.

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, front-loaded with the usage condition and free of filler. It is efficient, though the terseness is part of why purpose and return value stay implicit.

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

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

For a simple two-parameter read lookup with no output schema and no annotations, the description should at minimum say what comes back. It conveys the usage moment but leaves the return value and the effect of 'fields' unexplained, so it is only minimally 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?

Schema description coverage is 100%, with both cardId and fields fully documented in the schema itself, so the baseline is 3. The description adds no parameter meaning beyond what the schema states.

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

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

The description names the resource ('board relationship for a known Trello card'), which is more specific than the bare name 'card_board', but the verb is implicit ('when you need') rather than stating plainly that it returns the board a card belongs to. With sibling tools like card_get, card_list, and board_get available, it does not sharply delineate what this returns versus those.

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?

It gives concrete triggering contexts — before moving, labeling, or summarizing a card's context — which tells an agent when this lookup is warranted. It stops short of naming an alternative or when-not-to-use condition, so it lands just under the top score.

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 states the action but omits critical behavioral details: required permissions, what happens if the card is not found, whether copying includes item states, and what is returned (no output schema). Only the minimal 'this is an add operation' is communicated.

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 entire description is a single front-loaded sentence with zero wasted words. It is efficient and easy to parse, though its extreme terseness 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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It does not cover permissions, error conditions, side effects, or what the response contains, leaving significant ambiguity for an agent that needs to call it safely.

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 parameter definitions already fully document cardId, name, and sourceChecklistId. The description adds only that the copy is 'optional', which is a slight value-add but largely redundant with the schema 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 verb and resource ('adding a new checklist to an existing card') and notes the optional copy source, making the purpose clear. It does not explicitly differentiate from sibling tools like card_checklists or card_checklist_update, but the action is distinct enough to avoid confusion.

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

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

The phrase 'Use when adding a new checklist to an existing card' gives explicit guidance on when to invoke the tool. However, it provides no exclusions or alternatives (e.g., when to use card_checklist_update instead of creating), which prevents 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?

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses the most important behavioral traits: the deletion is permanent, cannot be undone, and removes all checklist items. It does not mention permission requirements or response behavior, but the key destructive semantics are 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?

The description is two tight sentences with no wasted text. The destructive warning and sibling alternative are front-loaded and directly actionable.

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 destructive two-parameter tool with no output schema, the description covers the essential risk and the main sibling distinction. It could be slightly richer about permissions or return behavior, but nothing critical to correct invocation 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 description coverage is 100%, so both required parameters are already documented in the input schema. The description does not add syntax, format, or usage detail beyond what the schema provides, which matches the baseline for fully documented 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 gives a specific verb and resource: permanently delete a checklist and all its items from a card. It clearly distinguishes this from the sibling card_checklist_item_delete, which removes only one item, so an agent can select the correct tool without inspecting 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?

It explicitly states the condition that should route the agent elsewhere: use card_checklist_item_delete to remove only one item. This is a direct when-to-use-this-vs-alternative guideline 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?

No annotations exist, so the description carries the full behavioral burden, and it discloses almost nothing: no mention of required write permissions, default position when 'pos' is omitted, whether assigning a member or due date triggers notifications, or that creation is non-destructive/additive. For a mutation tool with zero annotation coverage 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 front-loaded sentence with no filler, which is efficient. However, for a 7-parameter mutation tool it reads as under-specified rather than genuinely concise — nothing is wasted, but too little is said.

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 seven parameters, no annotations, and no output schema, an agent needs more than one sentence: permissions, default ordering, and what the created item/response looks like are all unaddressed. The definition is not sufficient on its own for correct invocation beyond required IDs.

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 seven parameters including due, pos, checked, and memberId are already documented in structured fields. The description adds no additional semantics such as position defaults or due-date expectations, so it only 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?

States a specific verb+resource combination ('adding a new item to an existing Trello checklist on a card'), which is unambiguous and maps cleanly to the tool name. It does not explicitly contrast with close siblings such as card_checklist_item_update or card_checklist_items, but the create-vs-update distinction is inferable from the wording.

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?

'Use when adding a new item' is a stated trigger, but it essentially restates the purpose rather than giving real routing guidance. No mention of when to prefer card_checklist_item_update, how to find a checklistId via card_checklists, or any prerequisite, so alternatives are left implicit.

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 usefully discloses that deletion is permanent and cannot be undone, but it does not mention permission requirements, side effects on the parent checklist, or response behavior.

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

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

Two compact sentences with the destructive nature front-loaded and the alternative immediately following. 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 simple two-parameter destructive tool with no output schema, the description covers the essential risk and routing information. It could still do more on permissions or side effects, but it is largely 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 cardId and checkItemId are already documented. The description adds no parameter-specific syntax or constraints beyond the schema, 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: "Permanently delete one checklist item." It also distinguishes the operation from the sibling alternative card_checklist_item_set_checked, so an agent can tell what this tool does.

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 a clear alternative for the common non-destructive case: use card_checklist_item_set_checked to mark completion while keeping the item. It does not spell out broader when-not-to-use conditions, but the destructive intent is clear.

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 behavioral burden. It only discloses the same-card constraint; it says nothing about required permissions, whether the item is removed from the source checklist, what happens on failure, or what the response contains.

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. The scope constraint is stated immediately and nothing is wasted.

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 unannotated mutation tool with four parameters and no output schema, the description is too thin. It omits side effects, permissions, error behavior, and return semantics that an agent would need to invoke it confidently.

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 (including pos, cardId, checkItemId, checklistId) are already documented in the schema. The description adds no syntax or constraint details 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 specific verb (moving) and resource (Trello checklist item), plus the two supported destinations: another checklist on the same card or a different position. It is clear enough to distinguish from update/delete siblings, though it does not explicitly name those alternatives.

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

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

The phrase 'Use when moving...' gives a clear triggering condition, but there is no guidance on when not to use it or which sibling to choose for related operations such as card_checklist_item_update.

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 disclosure burden. 'Listing' implies a safe read and the default-scope note is useful, but there is no statement about pagination, auth needs, or return shape; the default note also largely restates the schema's filter default of 'all'.

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 the trigger condition first and no waste. It is appropriately sized, though it could have used its brevity to add one differentiating clause.

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 3-parameter list tool with full schema coverage, the description covers purpose and default scope. With no output schema and no note on return fields or pagination, an agent still lacks some information about what it gets back.

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 (checklistId, filter, fields) are already documented, including the filter enum. The description adds no syntax or format detail 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?

States a specific verb ('listing') and resource ('items in one Trello checklist'), which is enough to separate it from siblings like card_checklists (lists checklists, not items) and card_checklist_item_create/update. It does not explicitly name those siblings, so it stops short of full 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 phrase 'Use when listing...' gives implied context, and it clarifies the default scope (complete and incomplete). However, it names no alternatives and gives no when-not guidance, e.g., how this differs from card_checklists.

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 exist, so the description carries the full behavioral burden. It does disclose one behavioral trait — that only the checked field is touched and other item fields are left intact — but says nothing about idempotency, required permissions, or what is returned after the mutation.

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

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

A single front-loaded sentence with no filler. Nothing is wasted, though the sentence is doing very little work beyond the title, which leaves little for the reader who skips 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 a 3-parameter mutation tool with no annotations and no output schema, the description should at least signal the mutation's scope and any preconditions. The 'only changes checked' scope is covered, but side effects, failure modes, and return behavior are all 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 coverage is 100%: cardId (id/short link/URL), checkItemId, and the boolean checked semantics are all documented in the schema. The description adds no parameter detail beyond what is already there, 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?

Names the specific action (checking/unchecking a checklist item) and the resource (Trello card checklist item), and implicitly distinguishes itself from card_checklist_item_update by scoping the mutation to the checked field only. It is not tautological, though it never states the tool's effect in a standalone verb phrase.

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?

Opens with an explicit 'Use when...' trigger covering both directions (check and uncheck). The clause 'without changing other item fields' signals the boundary against card_checklist_item_update, but that sibling is never named, so an agent must infer the routing.

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, but it only implies a mutation via 'editing'. It does not disclose permission needs, partial-update semantics, side effects of moving via checklistId, clearing behavior via null, or what the response contains.

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. Every listed field earns its place by signaling the tool's editing scope.

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 nine-parameter mutation tool with no annotations and no output schema, the description is too sparse. It lists editable fields but leaves out behavioral context, side effects, and guidance on when to prefer the dedicated sibling tools for checking, moving, or deleting checklist items.

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 nine parameters in detail. The description names most editable fields but adds no syntax, caveats, or meaning beyond what the schema provides, and omits dueReminder.

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 ('editing') and resource ('Trello card checklist item') and enumerates the fields that can change. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like card_checklist_item_set_checked or card_checklist_item_move.

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

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

The phrase 'Use when editing...' provides a clear usage context for the tool. However, it gives no when-not guidance and does not name the more specific sibling alternatives for completion state or position changes.

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. 'Viewing' implies a read-only operation, but the description does not confirm side-effect safety, mention permissions, describe pagination, or explain return structure for a tool with no output schema.

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

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

The description is a single front-loaded sentence with no wasted text. It communicates the relevant usage condition and scope directly.

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-parameter read tool with full schema coverage, the description is mostly complete: it explains that the result includes all checklists and checklist items on a card. It could be stronger by noting pagination or return behavior, but the core context 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?

There is only one parameter and schema description coverage is 100%, with the schema explaining that cardId accepts a Trello card id, short link, or URL. The description adds no parameter-specific meaning beyond the schema, so a 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 states a specific verb-plus-resource: viewing all checklists and checklist items on a card. It distinguishes the tool from item-specific siblings like card_checklist_items by emphasizing that it returns all checklists and their items on a card, though it does not explicitly name an alternative.

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

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

The phrase 'Use when viewing all checklists and checklist items currently on a card' gives a clear context for selecting this tool. It does not state when not to use it or name any specific alternative tool, which keeps it below 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?

No annotations are supplied, so the description carries the full behavioral burden. It never says what a mutation does to existing checklist items, whether the operation is idempotent, what permissions are needed, or what comes back on success or failure.

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, the trigger condition front-loaded and the validation rule trailing. Every clause earns its place with no restatement of the tool name.

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

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

For a simple three-parameter mutation with full schema coverage and no output schema, the purpose and the at-least-one rule cover the essentials. What is missing is any statement of effect or outcome, which matters here because no annotations describe the write semantics.

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 a real cross-parameter rule the schema does not encode: only checklistId is required, yet at least one of name or pos must be supplied. That is genuine value beyond the structured fields.

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?

Names a specific verb set (renaming, changing position) against a specific resource (Trello card checklist), which cleanly separates it from siblings like card_checklist_create, card_checklist_delete and card_checklist_item_update without opening a schema. No sibling is named explicitly, 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?

"Use when renaming ... or changing the checklist's position" gives an explicit triggering condition, and the closing clause states the invocation precondition (at least one of name or pos). It stops short of naming an alternative tool or stating when not to use it.

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

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

With no annotations, the description carries the burden and usefully discloses that the operation is non-idempotent and returns the resulting comment action. It does not mention permissions, notification side effects, or rate limits, so it stops short of full behavioral 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 two tightly written sentences with no filler. The primary action is front-loaded, followed by the key behavioral caveat and sibling routing.

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

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

For a simple two-parameter mutation with complete schema coverage and no output schema, the description covers action, return value, non-idempotency, and the relevant alternative tool. Nothing essential is missing 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?

Schema description coverage is 100%, so both required parameters are already documented in the schema. The description does not add format details or constraints beyond what the schema provides, making the baseline score 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 states a specific verb and resource: adding a comment to a Trello card. It also names the sibling tool card_comment_update for the distinct editing case, so an agent can distinguish the two operations without inspecting schemas.

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?

It explicitly says to use card_comment_update when editing an existing comment. It also clarifies the important usage behavior that repeating this call creates additional comments rather than updating one.

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 disclose the most important trait: the deletion is permanent and irreversible. It does not cover permissions requirements, behavior if the actionId doesn't exist, or the response shape, which keeps it below 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?

Two short sentences, the destructive nature front-loaded and the alternative immediately after. Every clause earns its place with no padding.

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 destructive tool with no output schema, the essential information (irreversibility, correct identifier, sibling alternative) is present. Minor omissions like permission needs or no-op/error behavior keep it at 4 rather than 5.

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 parameter's own description already says 'Trello comment action id to delete.' The description reinforces that the id refers to a comment action but adds no format or sourcing detail beyond the schema, 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 and resource ('Permanently delete a card comment') and disambiguates the target ('by its action id'). This clearly separates it from siblings like card_comment_update and card_comment_add.

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 names the alternative ('use card_comment_update to edit the text instead'), giving the agent a clear when-not-to-use path. The destructive vs. edit distinction is unambiguous.

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 supplied, so the description carries the full burden and does very little: it never says whether only the text changes while other comment fields are preserved, whether edit history or timestamps are affected, what permissions are required, or what happens with an invalid or non-owned action id. Only the 'text-only edit' scope hint adds any behavioral value.

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; the use condition and the identifier requirement come first.

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

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

For a simple two-parameter mutation with no nested objects and no output schema, the description plus a fully annotated schema is enough to select and invoke the tool correctly. The remaining gap is behavioral (permissions, preservation of other comment data), which annotations would normally cover but here 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% and both parameters are documented in-schema ('Updated comment text', 'Trello comment action id to update'), so the baseline of 3 applies. The description restates the same two concepts without adding format, length, or sourcing guidance 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 (editing the text) on a specific resource (an existing Trello card comment) identified by a comment action id. That clearly separates it from card_comment_add and card_comment_delete in the sibling list, though no sibling is named explicitly.

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

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

The opening 'Use when editing the text of an existing...' gives a clear triggering condition and implicitly excludes creation and deletion. It stops short of naming alternatives (card_comment_add / card_comment_delete) or noting prerequisites like needing the action id from card_actions.

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 supplied, so the description carries the full behavioral burden. It discloses the destructive-adjacent case (clearing the cover) and implies the attachment must already exist, but says nothing about the previous cover being replaced, auth/permission requirements, or idempotency of repeated calls.

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; the conditional trigger is placed first and each clause corresponds to a real mode of the tool. Nothing is repeated from 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 a 4-parameter mutation tool with no annotations and no output schema, the description covers purpose and triggers but omits what changed state looks like afterwards, whether prior cover settings (size/brightness) survive a re-set, and error conditions such as an attachment id that isn't on the card.

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 every parameter (cardId, attachmentId, size, brightness) is documented in the schema, including enum meanings and the null-to-clear convention. The description adds only the framing that the attachmentId must reference an existing attachment; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource (setting a card cover) and enumerates the three operations: attaching an existing attachment id as cover, changing display size, and clearing the cover. An agent can identify the action without opening the schema. It stops short of naming the sibling attachment tools that must run first (card_attachment_upload / card_attachment_add_url), so it is clear but not sibling-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?

The leading 'Use when...' clause lists three concrete trigger conditions that map cleanly to the tool's three modes, which is real selection guidance. It gives no exclusions or explicit statement of prerequisites (e.g. that the attachment must already exist on the card), leaving the *why-not* side implicit.

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 says the tool creates a card and lists some accepted fields, but it does not describe permissions, side effects, idempotency, required list existence, or what happens on failure.

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 immediately states the usage condition and then summarizes accepted inputs. There is no wasted language.

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 seven-parameter mutation tool with no annotations and no output schema, the description covers the basic purpose and several accepted fields. However, it leaves out required parameters such as listId and name, position handling, permissions, and return behavior, so it is only minimally 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 all seven parameters thoroughly. The description lists title, description, due date, members, and labels, which provides some semantic mapping, but it omits listId and pos and does not add much 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 names a specific verb (create) and resource (Trello card) and scopes it to a known list. It is clear, but it does not explicitly distinguish this tool from sibling mutations such as card_update or sibling creation tools.

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?

It explicitly says when to use the tool: when the user asks to create a new Trello card in a known list. It does not name exclusions or alternatives, but the usage context is clear.

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 meaningful work: it discloses that the operation is value-only (definition survives) and that reversal requires an out-of-band call to card_custom_field_set, effectively flagging the mutation as not self-undoable. It omits permission requirements and response shape, which keeps it from 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?

Two sentences, zero waste. The scope-limiting fact is front-loaded and the recovery path follows immediately; every clause 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 two-parameter mutation with a fully documented schema and no output schema, the description covers purpose, scope, and recovery. Only permission/auth context and the shape of the result are unaddressed, which is a minor gap at this complexity.

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

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

Schema description coverage is 100% and both parameters are documented in the schema with accepted id/link/URL forms. The description adds no further meaning about cardId or customFieldId, 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 and resource ('clear one card's custom field value') and explicitly bounds the blast radius by contrasting it with deleting the board's field definition. An agent can distinguish it from card_custom_field_set and board_custom_fields 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?

The description establishes the when-to-use condition implicitly — remove a value while preserving the definition — and names the correct alternative for the reverse operation (card_custom_field_set). It stops short of stating explicit exclusions or preconditions, but the routing signal to the sibling is clear.

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 exist, so the description bears the full burden, and 'reading' at least signals a non-mutating operation. It says nothing about permissions, pagination, or whether unset fields are omitted, but for a simple single-parameter read this is a modest gap rather than 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?

A single front-loaded sentence with no wasted words. Efficient, though the 'Use when' phrasing is slightly clipped.

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?

Adequate for a one-parameter read tool, but with no output schema and no description of returned value shape (per-field items, values, types), an agent still lacks a picture of the response.

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?

Only one parameter (cardId) and the schema documents it fully, including short-link and URL forms, so baseline 3 applies. The description adds no 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?

States a specific verb ('reading') and resource ('all custom field item values currently set on a Trello card'), which distinguishes it from mutating siblings like card_custom_field_set and card_custom_field_clear. It does not, however, explicitly contrast with custom_field_get or custom_field_options.

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?

'Use when reading...' gives a trigger condition, implying it is a read path versus the set/clear siblings. No alternatives are named and no when-not guidance or prerequisites 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?

With no annotations, the description carries the disclosure burden, and it does state the key behavioral trait that this overwrites an existing value ('set or replace'). It leaves unstated permission requirements, what happens if the field isn't attached to the card's board, and error semantics for mismatched values.

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

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

Two tight sentences: the core action and the replace semantics come first, followed by the three tool-routing pointers. No restated name, 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?

For an 8-parameter mutation tool with rich enum/schema descriptions and no output schema, the definition covers the main risks: value replacement and how to obtain a valid type. It could go further on failure modes and on whether the field definition must already be attached to the card.

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 earns an extra point by explaining how the type parameter is derived (from the existing definition via custom_field_get), which is workflow guidance the schema alone does not supply. It still adds nothing about cardId formats or the date string constraint beyond the schema.

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

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

The description uses a specific verb pair ('set or replace') on a precisely scoped resource ('one card custom field value'), and implicitly distinguishes itself from the sibling tools it names (card_custom_field_clear, custom_field_options). An agent can tell exactly what this does 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?

It explicitly routes the agent to custom_field_get for the required type, to custom_field_options for list option ids, and to card_custom_field_clear when the intent is removal rather than setting. That is a named alternative plus the preconditions for using it correctly.

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 carry the behavioral burden; it discloses the two most important traits — irreversibility ('permanently') and the safer alternative. It stops short of stating permission requirements or whether deleting a card also removes its attachments, comments or checklists, which matter for a destructive 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?

One sentence, front-loaded with the precondition and followed by the alternative; no filler. It could name card_archive literally rather than just 'archive', but nothing is wasted.

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 destructive tool with no output schema, the description covers the decision that matters (delete vs archive) and the irreversibility. Missing only secondary details such as permission requirements and cascade effects of deleting a card.

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 single parameter cardId has 100% schema description coverage (id, short link, or URL), so the schema already does the work. The description adds no parameter meaning beyond that, which is the expected baseline here.

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 ('permanently delete a Trello card') and explicitly contrasts it with the sibling alternative ('archive instead for reversible removal'). An agent can distinguish card_delete from card_archive 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?

Gives an explicit precondition ('only when the user explicitly asks to permanently delete') and names the preferred alternative for the reversible case. This is a complete when-to-use / when-not-to-use rule in one sentence.

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 behavioral burden. It usefully discloses that only due-date metadata is changed and that at least one of due or dueComplete must be supplied, but it does not mention permissions, side effects, response behavior, or what happens when neither field is provided.

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 tight sentences with no waste. The use condition is front-loaded, and the parameter constraint is placed immediately after it.

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 mutation with fully described parameters and no output schema, the description supplies the key usage and validation context. A minor gap remains around return behavior and the consequence of omitting both due and dueComplete, though the latter is partially addressed.

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 parameter baseline is 3. The description adds a meaningful constraint not enforced by the schema: at least one of due or dueComplete must be provided. It also uses 'clearing' to reinforce the schema's documented null behavior for due.

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: setting, clearing, or marking completion of a card due date. It also scopes the operation to due-date metadata only, which distinguishes it from the broader card_update sibling.

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?

It gives clear triggering conditions: use when setting, clearing, or marking completion of a due date without changing other metadata. It implies the alternative (card_update for other fields) but does not name that sibling explicitly or state exclusions beyond the metadata constraint.

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 disclosure burden. 'Current details' usefully signals a live read rather than a cached snapshot, and the 'before editing' framing implies a non-mutating operation, but there is no mention of access requirements, error behavior for unknown ids, 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?

One front-loaded sentence beginning with the usage trigger, with zero filler. The identifier forms and the intended purpose are packed in 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?

There is no output schema and no annotations, so the description is the only source of behavioral and return context, yet it never says roughly what 'card details' contains (name, description, due date, labels, members, etc.) or whether fields affects that. For a simple two-parameter read tool this is workable but leaves a real gap an agent must discover by 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 both parameters are already documented, including the id/short-link/URL forms and the 'all' fields default. The description restates the identifier flexibility but adds no extra semantics such as valid field names or the cost of requesting all fields; 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 and resource: fetch the current details of one Trello card, and enumerates the accepted identifiers (id, short link, URL). It implicitly contrasts with facet-readers like card_labels or card_actions by promising the whole card, but never names those siblings explicitly, so the boundary is inferred 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?

Gives a clear triggering condition ('when you need the current details of one card') plus the intended follow-on actions ('before editing or summarizing it'), which tells the agent this is the pre-mutation read step. It stops short of naming when to prefer the narrower sibling readers or when to use search instead.

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 reveals only that the label must already exist; it does not disclose authorization requirements, idempotency behavior when the label is already present, or the response shape for this mutation.

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

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

The description is a single front-loaded sentence with no wasted text. It is appropriately sized for a simple two-parameter tool, though the trailing 'by label id' is slightly redundant.

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 mutation with fully documented parameters, the description covers the basic action. Without annotations or an output schema, it should say more about duplicate-label behavior and the result of the call, leaving a meaningful gap.

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

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

Schema coverage is 100%, so both cardId and labelId are already documented in the input schema. The description adds only a light emphasis that the label is identified by id, which is largely redundant with 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 states a specific verb ('applying') and resource ('an existing Trello label to a card'), and the phrase 'existing' distinguishes it from card_label_create_and_add. It does not explicitly name that sibling, but the core operation 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?

It gives a clear when-to-use condition ('when applying an existing Trello label ... by label id'), implying the label already exists. However, it does not state when not to use it or explicitly point to card_label_create_and_add for new labels.

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 behavioral burden and discloses the two-part side effect: creating a board label and applying it to the card. It also warns about duplicate creation, though it does not mention permission requirements or whether label 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?

Two sentences, front-loaded with the action and immediately followed by the usage distinction. There is no redundant or wasted text.

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 three-parameter mutation with no output schema, the description gives enough to invoke the tool correctly and avoid duplicate labels. It does not describe return values or permission requirements, leaving a minor 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 cardId, name, and color are already fully documented in the schema. The description adds no parameter-specific syntax or format details beyond what the schema provides, so the baseline score 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: "Create a new board label and apply it to this card." It also names the sibling tool for existing labels, making the distinction clear without requiring schema inspection.

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?

It explicitly directs the agent to use card_label_add for an existing label and warns that repeating this creation can create duplicates. That gives both the alternative and the condition for choosing it.

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

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

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It never says whether the operation is idempotent when the label isn't on the card, whether it mutates only that card's associations, what permission level is required, or what is returned on success or failure.

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; the trigger condition comes first and the identifier note follows. It is efficient, though so brief that it borders on under-specification rather than tight scoping.

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

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

For a simple two-parameter mutation with a fully documented schema and no output schema, this is close to adequate. However, with zero annotations the description should still cover idempotency and error behavior, and it does neither.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents that cardId accepts an id, short link, or URL. The description only echoes 'by label id' without adding format, constraint, or edge-case detail beyond the schema, which is the expected baseline of 3.

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 and resource ('removing an existing Trello label from a card') and constrains the identifier ('by label id'). It implicitly separates itself from label_delete (removes the label from the board entirely) by scoping the action 'from a card', but never names the sibling explicitly.

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

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

'Use when removing an existing Trello label from a card' gives a usable trigger condition, but offers no when-not guidance and does not distinguish this from card_label_add, card_label_create_and_add, or label_delete. An agent has to infer which of the four label tools applies.

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 disclosure burden. "Listing" implies a read operation and the mention of label ids signals the payload shape, but there is no statement about read-only semantics, behavior for invalid/unknown card ids, or pagination — meaningful gaps for a tool with zero annotation coverage and no output schema.

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

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

One sentence, no waste, and the usage trigger is front-loaded. It is slightly indirect ("Use when listing..." rather than "Lists labels on a card"), which costs a point on directness but not on efficiency.

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

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

This is a simple single-parameter read tool with full schema coverage and no output schema, and the description covers purpose and the add/remove follow-up use case. The main missing piece is an explicit read-only/return-shape statement, which is minor at this complexity level.

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

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

Schema coverage is 100% and the single cardId parameter is fully documented in the schema as accepting an id, short link, or Trello card URL. The description adds no parameter-level 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?

The description states a specific verb and resource: listing the labels currently applied to a card. It adds the useful detail that label ids are returned, which separates it from label_get and board_labels, though it never names those siblings explicitly.

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

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

"Use when listing the labels currently applied to a card" gives a clear triggering condition and the add/remove workflow framing implicitly routes the agent away from card_label_add/card_label_remove. It stops short of naming alternatives or stating when not to use it (e.g., board-wide label catalogs via board_labels).

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