Server Quality Checklist

Tool Scores

• analyze_board_healthB
  3.1/5.0
  Behavior3/5

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

  The description discloses an importante behavior: it returns counts and offending cards rather than a verdict, and calls out handling of small boards. However, because no annotations are provided, the description carries full burden and still does not mention read-only status, side effects, or error behavior.

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

  Conciseness5/5

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

  Two terse sentences carry signal: the first lists the assessment dimenions, the second clarifies output shape and interpretive nuance. No filler or repetition of schema titles.

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

  Completeness3/5

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

  For a read-only analysis tool with an output schema, the description is mostly adequate: it names inputs dimenions and output nature. The main gap is parameter semantics for stale_after_days, and there is no guidance about required input form or sibling selection, leaving the agent to infer important invocation details.

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

  Parameters2/5

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

  Schema description coverage is 0%, but the description does not explain the board parameter or stale_after_days. The title 'Stale After Days' hints at its purpose, but the description never connects it to the 'staled cards' metric, and does not clarify default semantics or units.

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

  Purpose4/5

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

  The description uses a specific verb ('assess') and resource ('a board') and lists concrete metrics: per-list load, overdue cards, unassned work, staled cards. It is clear about what the tool does, though it does not explicitly differentiate it from detect_bottlenecks or generate_standup_report.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this tool instead of a sibling like detect_bottlenecks or list_cards. The instruction 'Read the numbers and say what they imply' is about post-processing output, not about when to invoke the tool.

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

• detect_bottlenecksA
  3.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It does disclose an important trait: the pressure score is a 'crude volume-plus-age heuristic' and is returned with its own formula so it can be questioned. This is useful epistemic context beyond the basic function, though it does not discuss read-only semantics, permissions, or data freshness.

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

  Conciseness5/5

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

  Two succinct sentences with the core purpose front-loaded and the heuristic caveat placed second. Every sentence adds either functional or interpretive value; there is no filler.

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

  Completeness3/5

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

  The output schema presumably covers the return details, so the description does not need to. But the board parameter remains ambiguous, and 'non-done lists' is not formally defined. For a single-parameter analysis tool this is adequate but leaves an agent guessing on invocation details.

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

  Parameters2/5

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

  The input schema has a single 'board' parameter with 0% documentation coverage, and the description never explains what board value is expected (ID, name, or URL) or how it should be formatted. Because the schema provides no meaning, the description needed to compensate and did not.

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

  Purpose4/5

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

  The description states a specific action and resource: 'Rank the non-done lists by how much work is piling up and ageing inside them.' It clearly communicates the tool's analytical function and distinguishes it from generic card/list tools, though it does not explicitly contrast it with the similar-sounding analyze_board_health sibling.

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

  Usage Guidelines3/5

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

  Usage is implied from the verb 'Rank' — the tool is for identifying bottleneck lists on a board. However, it gives no explicit when-to-use guidance, no mention of alternatives, and no statement of when not to use it, leaving the agent to infer suitability.

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

• get_cardA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries behavioral disclosure. It does state what is included in the returned card (description, labels, due date, checklists, recent comments) and implicitly presents this as a read-only operation, but it doesn't mention permissions, error behavior, rate limits, or how 'recent' is determined.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler; the colon-delimited list efficiently conveys the response scope. Every word earns its place.

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

  Completeness3/5

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

  For a one-parameter read operation, the description plus output schema is mostly sufficient. The main gaps are an explicit usage-rule statement and clarification of the 'recent' limit, but these are minor given the simple scope.

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

  Parameters2/5

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

  The input schema only provides name/type/required for card_id and has 0% description coverage. The tool description never explains the card_id parameter, how to obtain it, or its accepted format; the agent must rely on the self-explanatory name.

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

  Purpose5/5

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

  The description uses a clear verb ('Get') and identifies the exact resource ('one card') while enumerating the payload ('description, labels, due date, checklists and recent comments'). This distinguishes it from sibling list_cards (which returns many) and get_board_info (a different resource).

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

  Usage Guidelines3/5

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

  The intended use is implied: call this when you need the full detail of a single card. However, it never explicitly says when to prefer this over list_cards/search_trello or when not to use it, so the agent must infer the context.

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

• create_cardA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It earns credit for the explicit 'This writes to the real board' warning, which conveys real-world side effects beyond the tool's name, plus the ISO-8601 format constraint for `due`. However, it does not disclose permission/auth requirements, reversibility, duplicate-card behavior, or what happens when the named list isn't found, leaving significant gaps for a mutation tool.

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

  Conciseness5/5

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

  Three short, front-loaded sentences with zero filler. The primary action comes first, followed by the safety-relevant write warning, then the parameter format note. Every sentence earns its place.

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

  Completeness3/5

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

  The output schema covers return values, so that omission is acceptable. For a 5-parameter, 3-required mutation tool with real side effects and zero annotations or schema descriptions, the definition covers the essentials (action, write warning, date format) but lacks operational context: how to resolve board/list_name to valid values, whether the action can create duplicate cards, and dependency on sibling read tools. Complete enough for a basic call, but an agent could produce invalid invocations for board or list_name.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does add genuine value for `due` by specifying the ISO-8601 format with a concrete example, which is the most error-prone parameter. It also ties 'named list' to list_name and 'a board' to board. But it fails to clarify whether board and list_name take IDs or human-readable names, and offers no hints for the remaining parameters (name, description), leaving an agent to guess.

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

  Purpose5/5

  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 card on a board, in the named list') with an explicit location scope. It clearly distinguishes this from the sibling operations (list_cards, move_card, update_card, add_comment) since creation is the only write-to-add action in the family.

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

  Usage Guidelines3/5

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

  Usage is implied but never stated explicitly. The warning 'This writes to the real board' hints that this tool should not be used for exploratory or dry-run purposes, and the domain (creating vs moving/updating/comments) is inferable from the name and siblings. However, there is no explicit when-to-use guidance, no exclusions, and no pointer to list_boards/list_board_lists as prerequisites for valid board and list_name values.

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

• move_cardA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the responsibility for behavioral disclosure. It explicitly says 'This writes to the real board,' which is useful context for a mutating tool. But it does not disclose prerequisites, reversibility, or other side effects beyond the move itself.

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

  Conciseness5/5

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

  The description is tightly written: operation first, then a meaningful side-effect warning, then the only parameter format detail that needs explanation. Every sentence earns its place and there is no filler.

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

  Completeness3/5

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

  For a simple move operation with an output schema, the description covers the core action, same-board scope, and position format. The main gap is the ambiguity of `to_list`—an agent may not know it needs a list ID—and there is no mention of what the response will contain, although the output schema mitigates that.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. It does clarify the `position` parameter's allowed values ('top', 'bottom', or numeric string), but `card_id` and `to_list` are not elaborated beyond their schema titles, and it does not confirm that `to_ist` expects a list ID rather than a list name.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Move a card to a different list on the same board.' This clearly identifies what the tool does and distinguishes it from siblings like update_card, create_card, and list_cards.

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

  Usage Guidelines3/5

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

  The description gives a clear usage context—moving cards within the same board—and warns that it writes to the real board. However, it does not explicitly mention when to use this versus alternatives such as update_card, and it leaves the 'when not to use' cases to implication.

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

• add_commentA
  3.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It clearly discloses that this operation writes to the real board, a meaningful side-effect warning, and identifies the authenticated user as the actor. It does not mention rate limits, permissions, or rollback, but the core mutation behavior is transparent.

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

  Conciseness5/5

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

  Two short sentences carry the essential information with no filler. The main action is front-loaded, and the important real-world side effect is stated immediately after.

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

  Completeness4/5

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

  For a two-parameter mutation tool with an output schema, the description is mostly complete: it states the action, actor, and live-write behavior. It does not mention how to source card_id or how this differs from update_card, but those details are reasonably inferable from the sibling list and schema.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It indirectly maps text to the comment body and card_id to the target card, and 'authenticated user' clarifies attribution. However, it does not explicitly explain constraints, formats, or how to obtain a valid card_id.

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

  Purpose5/5

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

  The description states a specific action and resource: 'Post a comment on a card.' It also adds actor context ('as the authenticated user') and emphasizes a real side effect, which visually separates it from the read-only sibling tools and from card creation/update operations.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to use this tool versus alternatives, no reference to sibling tools, and no prerequisites such as 'requires an existing card_id.' The description provides context but leaves usage routing entirely implicit.

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

• list_cardsA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It usefully discloses that only open cards are returned and that each card is trimmed to a specific triage digest of fields, which goes beyond the raw schema.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the core purpose appears in the first sentence, with the digest detail in a brief second paragraph. Every sentence adds value and there is no redundancy.

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

  Completeness3/5

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

  The digest detail and optional filter are helpful, but the description omits usage guidance relative to sibling tools and does not clarify the limit parameter's effect. Since an output schema exists, the return shape is less of a gap, but overall the description is not fully complete for an unannotated tool.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning for list_name ('filtered to one list by name') and suggests board as the scope, but it does not explain limit behavior or any constraints on list_name matching.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'List open cards on a board', distinguishes from siblings like list_board_lists and get_card, and adds the optional list filter. It is immediately clear what the tool produces.

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

  Usage Guidelines3/5

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

  The description implies usage through 'optionally filtered to one list by name', but it does not explicitly state when to prefer this over search_trello, get_card, or list_board_lists. No alternatives or exclusion criteria are provided.

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

• generate_standup_reportA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden, and it does so well by disclosing the data sources and scope: activity feed events plus current overdue and stalled work. It does not explicitly address side effects or permissions, but as a read-only report generator, the described behavior is sufficiently transparent.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the core purpose, and every sentence adds value: the first states the outcome, the second details the inputs and intended use. No filler or repetition.

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

  Completeness3/5

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

  The description covers purpose, input signals, and output use case, and an output schema exists so return values are covered. However, with no annotations and no parameter descriptions, details like how to identify the board and what window_days controls are left underspecified.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only vaguely references 'a board' and 'recently'. It never explicitly explains the board parameter format or the window_days semantics, defaults, or valid range, leaving the agent to infer too much.

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

  Purpose5/5

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

  States a specific verb ('Summarise') with a clear resource ('what actually happened on a board recently') and a concrete synthesis activity: combining card movements, new cards, comments, overdue work, and stalled work. This clearly separates it from sibling tools like list_cards or analyze_board_health on intent.

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

  Usage Guidelines4/5

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

  Provides clear usage context: the output is suitable for a standup update or weekly status note. It does not explicitly name alternatives or state when not to use it, but the described purpose is strong enough to guide an agent.

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

• get_board_infoA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates the tool retrieves metadata and exposes the returned fields, which implies a non-mutating read, but it does not explicitly confirm side-effect-free behavior, auth requirements, or error behavior when the board is not found. This is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is concise: two sentences, no filler. The purpose and returned metadata are front-loaded, and the parameter clarification is placed on its own line, making it easy to parse.

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

  Completeness4/5

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

  For a simple one-parameter get-metadata tool with an output schema present, the description covers what the tool does, what it returns, and the accepted input format. It lacks explicit sibling differentiation and edge-case behavior, but overall it is complete enough for an agent to invoke it correctly.

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

  Parameters4/5

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

  The input schema only provides a bare 'board' string with no description, so this description must compensate. It does so by explaining that 'board' accepts either a board id or a board name, which is essential, actionable semantic information that goes beyond the schema. It stops short of giving examples or format details, but for a single parameter this is strong coverage.

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

  Purpose5/5

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

  The description clearly states the action ('Get') and the resource ('metadata for one board'), and it lists the specific metadata fields returned (name, description, URL, visibility, last activity). The phrase 'one board' distinguishes it from sibling tools like list_boards and get_card.

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

  Usage Guidelines3/5

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

  The description implies that this tool is for retrieving a single board's metadata, but it does not explicitly state when to prefer this over list_boards or other siblings. There is no when/when-not or alternative-tool guidance, so the usage context is only implicit.

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

• list_board_listsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It discloses that closed lists are excluded, results follow board order, and card counts are included. It does not mention auth requirements or error behavior, but for a simple read/list operation the described behavior is unusually specific and useful.

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

  Conciseness5/5

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

  One sentence, under 15 words, front-loads the verb and resource, and packs three useful qualifiers: open, board order, card counts. No waste.

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

  Completeness4/5

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

  The tool is simple (1 parameter) and has an output schema, so return details need not be described here. The main missing piece is the accepted format/value of the 'board' parameter, which weakens completeness for actually invoking the tool correctly.

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

  Parameters2/5

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

  The single param 'board' has no description in the schema (0% coverage), and the tool description only says 'on a board'. It does not specify whether the board identifier should be an ID, URL, shortLink, or name, so the description fails to compensate for the complete lack of schema-level parameter guidance.

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

  Purpose5/5

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

  The description states a specific verb ('List'), a precise resource ('lists/columns on a board'), and adds scope ('open'), ordering ('in board order'), and content ('with card counts'). This clearly distinguishes it from siblings such as list_boards, get_board_info, and list_cards.

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

  Usage Guidelines4/5

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

  The context is clear: use this tool when you need the open lists/columns for a specific board with their card counts. It does not explicitly name alternatives or spell out when not to use it, so it falls just short of full guidance.

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

• list_boardsA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden and discloses key behavior: it only lists boards the authenticated account can open, and it returns board ids, names, and URLs. It does not explain the closed-board behavior behind include_closed, but the listing scope is clear and the operation is evidently read-only.

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

  Conciseness5/5

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

  Three short, action-first sentences with no filler. The entry-point sentence adds real context without bloating the definition.

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

  Completeness4/5

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

  For a simple list tool with an output schema, the description conveys auth scope, return fields, and its role in the broader workflow. A note about include_closed and the default exclusion of closed boards would make it fully complete, but that is a minor omission given the self-evident parameter name and default.

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

  Parameters2/5

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

  The description gives no guidance about the only parameter, include_closed, and the schema has no description text for it either. Because schema description coverage is 0%, the description should compensate but does not; an agent must infer meaning from the parameter name and default value.

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

  Purpose5/5

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

  The description names the exact operation ('List every Trello board'), the resource ('boards'), and the auth scope ('the authenticated account can open'). It also positions the tool as the entry point for all other board-scoped tools, so an agent can distinguish it from siblings like get_board_info or list_cards.

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

  Usage Guidelines4/5

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

  The description explicitly says this is the entry point for every other tool and that they all need a board id or name. That gives clear when-to-use context, though it does not name alternatives or 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.

• search_trelloA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the important behavioral trait that this is account-wide and relies on Trello's own search syntax rather than simple listing. It does not mention pagination.rate limits, or output format, but the output schema exists and the read-only nature is strongly implied by 'Search'.

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

  Conciseness5/5

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

  The description is short and front-loaded: the first sentence states the core purpose and scope, and the second adds valuable query-language examples. Every sentence earns its place and there is no filler.

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

  Completeness4/5

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

  Given that the tool has only two parameters and an output schema already exists, the description is largely complete. It explains the search scope, the query syntax, and provides examples. The only notable gap is the lack of explicit guidance for the limit parameter, but this is a minor omission for such a simple search tool.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It gives concrete query examples (lavel:bug, due:week, is:open, @username) which explain the query parameter well, but it never explains the limit parameter. The meaning of limit is partially inferable from its name and default, so this is average, not excellent.

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

  Purpose5/5

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

  The description states a specific verb ('Search'), a clear resource ('cards and boards'), and a clear scope ('across the whole account'). It also disambiguishes from sibling tools like list_boards and list_cards by emphasizing account-wide search using Trello's own search.

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

  Usage Guidelines4/5

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

  The description clearly implies this tool is for finding cards/boards across the entire account, not within a single board or list, and that it supports advanced Trello search operators. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it over the list-focused siblings.

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

• update_cardA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden, and it delivers: it discloses that the operation mutates the real board, that it is a partial update, and that archive=true hides rather than deletes the card. This gives the agent a clear model of side effects and semantics beyond the bare tool name.

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

  Conciseness5/5

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

  Three short sentences: purpose, real board warning, and archive semantics. Every sentence earns its place, with critical behavioral details front-loaded. No filler or repetition of schema data.

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

  Completeness4/5

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

  For a nuanced mutation tool with no annotations and 0% schema coverage, the description provides strong context: side effect warning, partial-update behavior, and archive's non-destructive nature. It does not explain due_complete or mention alternative tools for card placement, but output schema covers return values and the core calling contract is clear.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It covers 4 of 6 parameters (name, description, due, archive) with explicit semantics, especially archive's close-vs-remove meaning. It omits due_complete and doesn't explicitly identify card_id's role, but the partial-update statement generically explains how all parameters behave.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Update a card's name, description, due date, or archive it.' This clearly distinguishes the tool from siblings like create_card, move_card, and get_card by naming the exact fields it operates on.

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

  Usage Guidelines4/5

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

  The description implies use for modifying an existing card: 'Only the arguments you pass are changed.' It also marks it as a real write operation ('This writes to the real board'), contrasting it with read-only tools. However, it stops short of explicitly naming alternatives or providing when-not-to-use guidance.

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