Server Quality Checklist

Tool Scores

• get_board_listsA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, and the description discloses no behavioral traits beyond the basic operation. It does not mention that closed lists are excluded by default, do not indicate permissions, error behavior, or that it is a read-only operation. The identifier options are parameter semantics rather than behavioral transparency.

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

  Conciseness5/5

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

  The description is a single sentence that directly states the tool's purpose and key input flexibility. It is concise, front-loaded, and contains no filler or redundancy.

  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 the simple purpose, complete input schema, and presence of an output schema, the description is adequately complete. It states the core function and identifier options, while parameter details are covered by the schema. It does not add usage context relative to siblings, but the overall context is sufficient for a basic getter.

  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 100%, with both parameters already documented in the schema. The description repeats the board identifier options but adds no new meaning beyond what the schema already provides, meeting the baseline for high schema 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 ('lists on a Trello board'), and explicitly mentions that the board can be identified by ID, shortLink, or URL. This distinguishes it from sibling tools like get_board_cards or get_boards, which target different resources.

  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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or alternative tools. Usage is implied by the purpose but not articulated, leaving the agent to infer when this tool is appropriate.

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

• get_board_membersA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, placing the full burden on the description. The description only restates the core function and board identifier options. It does not disclose what exactly is returned (e.g., full member objects vs. IDs), how errors are handled, or whether all members or only active members are included.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the essential information with zero wasted words. It is concise and well-structured.

  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 single-parameter read tool with an output schema, the description is adequate. It clearly identifies the input and what is retrieved. However, it could be slightly more complete by mentioning edge cases like missing boards or whether all members are returned, but overall it fulfills the basics.

  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 100% and the description adds no new meaning beyond the schema—it simply repeats the board identifier options. The baseline for high coverage is 3, and the description does not go beyond that.

  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?

  Description uses a specific verb ('Get') and resource ('members on a Trello board'), making the tool's purpose unmistakable and clearly distinguishing it from sibling tools like get_board_lists, get_board_cards, and get_board_actions.

  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 states that the board can be identified by ID, shortLink, or full URL, which is useful context. However, it does not explicitly explain when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

• get_boardsA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only restates the tool's purpose without detailing what 'accessible' includes (e.g., archived boards), the return format, authentication requirements, or potential rate limits. It adds no behavioral context beyond the name.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity and directly communicates the core function.

  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 tool with no parameters and an output schema, the description is sufficiently complete to inform an agent when to use it. It does not explain edge cases or the meaning of 'accessible,' but the output schema covers return values, so the overall package is minimal but adequate.

  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 tool has zero parameters, which sets a baseline of 4. The description does not need to explain parameter syntax, and it adds no parameter-related detail, which is appropriate given the schema.

  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 tool fetches Trello boards accessible to the configured account, with a specific verb ('Get') and resource ('Trello boards'). It distinguishes from sibling tools that target lists, cards, or members, and the 'accessible to the configured account' scope adds clarity.

  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 this tool is used to retrieve all accessible boards, and the context is clear from the name and sibling tools, but it does not explicitly state when to use it vs alternatives or mention any exclusions or prerequisites. Usage is implied rather than explicitly guided.

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

• get_overdue_cardsA
  3.8/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 burden. It discloses filtering criteria and sort order, which is helpful, but it does not mention whether the operation is read-only, requires permissions, or has pagination limits.

  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 a single, front-loaded sentence that communicates scope, filtering criteria, and sort order without 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 description covers the core purpose and sorting, and an output schema exists for return values. It lacks explicit mention of optional filters listId/memberId and pagination behavior, but the schema covers the filters, so the description is adequately complete for this tool's complexity.

  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?

  All three parameters already have descriptions in the schema (100% coverage). The tool description adds no additional meaning to the parameters, meeting the baseline for high schema 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 defines overdue cards as past-due, incomplete, non-archived, based on current card state, and sorted most-overdue first. This distinguishes it from sibling tools like get_upcoming_due_cards and get_stale_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 implies usage for retrieving currently overdue cards but does not explicitly state when to prefer this over siblings. It does provide a key exclusion ('not action history') that hints at alternatives but stops short of naming them.

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

• get_list_changesA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries burden. It discloses the type of changes reported and optional filters, but doesn't mention pagination behavior, response format, rate limits, or authentication needs. Adequate but not rich.

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

  Conciseness5/5

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

  Single sentence that packs purpose, scope, and filtering options. No filler or redundancy.

  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?

  With an output schema present, no need to describe return values. The description covers scope and intent well, but omits behavioral details like pagination limits that are only partially in the 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 coverage is 100%, so parameters are already well-documented. Description adds context on date range and list scoping, but doesn't add format or usage details beyond schema descriptions.

  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?

  Specific verb 'audit' plus concrete actions (created, renamed, archived, unarchived) and scope ('on a board', date range, single list). Clearly distinguishes from sibling tools like get_board_actions and get_list_flow.

  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?

  Labels itself the 'main structural audit tool', indicating primary use for list lifecycle events. Implies when to use, but doesn't explicitly contrast with siblings like get_board_actions.

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

• get_member_activityA
  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 transparency burden. It discloses significant behavioral traits: the feed is 'normalized', includes specific event types, and rejects ambiguous/non-matching memberName with a clear error. However, it does not mention pagination, rate limits, or the fact that it scans across pages (maxActions), leaving some 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.

  Conciseness5/5

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

  The description is concise: two sentences, with the core purpose front-loaded in the first sentence and resolution logic in the second. No redundant or filler text.

  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?

  With a full input schema, an output schema, and a clear description of the tool's scope and behavior, the description is sufficiently complete for a getter tool. It could explicitly mention time-filtering parameters (since/before/days) but those are well-documented in the schema, so this is a minor gap.

  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?

  The input schema already provides 100% parameter coverage with detailed descriptions for all 7 parameters. The description adds a marginal clarification about memberId vs. memberName resolution, but the schema already conveys this. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 what the tool does: provides a normalized chronological activity feed for one board member, listing specific event types (card movements, list structural changes, creation, archival). This specific verb-resource pairing distinguishes it from sibling tools like get_board_actions or get_card_movements, which are broader or focus on different aspects.

  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 usage context: it is for member-specific activity, and the resolution note ('Resolve by memberId when known; memberName is looked up') gives parameter-selection guidance. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

• get_board_cardsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns raw card data with specific fields (list, members, due date) and states it does not perform overdue/analytics computation. This adds behavioral clarity beyond the schema, though it omits details like pagination or default closed-card 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?

  The description is a single, front-loaded sentence that conveys purpose, input, and return characteristics without redundancy or fluff. Every clause contributes meaningful information.

  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 2-parameter tool with an output schema and no annotations, the description adequately covers purpose, input identification, return data, and scope exclusions. Minor omissions like pagination or ordering are not critical for this tool's complexity.

  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?

  The input schema has 100% coverage with both parameters (board, includeClosed) described in detail. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline score of 3 applies.

  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 tool 'Get the cards on a Trello board' with specific identification methods (ID, shortLink, URL) and return content (list, members, due date). The explicit 'no overdue/analytics computation' distinguishes it from sibling analytics tools like get_overdue_cards and get_upcoming_due_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 implies usage for raw card retrieval by stating it returns raw data and explicitly excludes analytics. This provides a clear context for when to use it, though it does not explicitly name alternative tools or provide exhaustive when-not scenarios.

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

• get_card_movementsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that only confirmed list-to-list movements are returned and frames results as workflow activity rather than a productivity metric. It does not mention auth, rate limits, or pagination details, but those are standard for a read-only Trello action query and the schema covers pagination via maxActions.

  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 sentences, front-loaded with the action and resource, and a distinct second sentence for semantic nuance. No filler or repetition of schema details.

  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 read-only list tool with a full input schema and an output schema, the description covers the core purpose, filter options, and semantic caveat. It could add more explicit usage guidance, but it is complete enough given the schema and sibling context.

  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 100% with descriptions for all 8 parameters, including examples for board and since. The description only restates the filter categories (member, card, source list, destination list) without adding additional semantics beyond the schema, so the baseline score of 3 applies.

  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 specific verb ('List') and resource ('confirmed list-to-list card movements from a board's action history'), and immediately scopes the operation with optional filters. It distinguishes itself from productivity-oriented siblings by stating 'Workflow activity, not a productivity metric.'

  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?

  It provides clear context for when to use the tool (listing confirmed card movements with optional filters) and explicitly cautions that it is workflow activity, not a productivity metric. It does not name specific alternative tools, but the exclusion of productivity use cases gives some guidance.

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

• get_top_card_moversA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses the default date range and the type of metric (workflow activity), but does not explicitly state that this is a read-only operation or describe the output structure. The lack of mention of side effects or return format is a gap, but the description does add meaningful context beyond the schema.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every word earns its place. The second sentence provides a crucial nuance about the metric's intended use, with zero redundancy.

  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 the tool's complexity (6 parameters, output schema present, no annotations), the description adequately explains the core functionality, date handling, and metric semantics. It leaves out details about pagination limits and exact ranking criteria, but those are partially captured by schema parameter descriptions and output schema. Overall, it provides sufficient context for an agent to select and invoke the tool 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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default behavior when no date range is provided ('default last 7 days') and clarifying that the 'days' parameter is a convenience alternative to since/before. This goes beyond the schema's param descriptions.

  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 tool's purpose: it ranks board members by list-to-list card movements within a date range. The verb 'ranks' combined with the specific resource (board members) and metric (card movements) is precise. It also distinguishes itself from general activity tools by noting it measures workflow activity (cardsMoved) rather than productivity.

  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 provides clear context on when to use this tool: when analyzing card movement activity on a Trello board. It explains the convenience of the 'days' parameter and the default behavior (last 7 days). While it does not name alternative sibling tools, it clarifies the metric's scope, giving adequate guidance for appropriate use.

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

• get_upcoming_due_cardsA
  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 full burden. It discloses that results are based on current card state rather than action history, excludes complete/archived cards, and sorts by due date. It does not mention potential limitations (e.g., cards without due dates) or permission requirements, but the core behavioral traits are well disclosed.

  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 sentences, immediately states the core function, then adds essential qualifiers and sorting. No redundant wording.

  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 4-parameter tool with output schema, the description covers the key behavior: time window, exclusions, data source, and sort order. It lacks discussion of edge cases (e.g., cards without due dates) but is largely sufficient for an agent to invoke correctly.

  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 100%, so the baseline is 3. The description adds the default value context ('default 7') which is also present in the schema, and clarifies filters (not complete/archived), but doesn't add parameter-specific meanings beyond schema definitions.

  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 identifies the tool's purpose: returning cards due within a configurable future window, with explicit exclusions (complete, archived) and sorting ('soonest-due first'). It distinguishes from sibling tools like get_overdue_cards and get_board_cards by noting it uses current board state rather than action history.

  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 communicates the intended use case ('cards due within the next N days') and key filters, but does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to select it over get_overdue_cards, though explicit sibling differentiation is missing.

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

• get_stale_cardsA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals specific recognized activity types, the default staleDays threshold, and critically explains the historyComplete: false fallback when action history cannot be fully scanned. It also clarifies that staleness does not imply blockage, adding important context beyond the raw schema. This is exemplary transparency.

  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 exactly two sentences, with the main action front-loaded. Every sentence adds value: the first defines the tool's purpose, the second clarifies caveats. There is no fluff or repetition of schema information.

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

  Completeness5/5

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

  For a read-only list tool with a rich output schema and 100% parameter coverage, the description is remarkably complete. It covers purpose, default behavior, edge cases (incomplete history), and a key behavioral nuance (stale vs. blocked). No critical information is missing given the tool's complexity.

  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?

  The input schema provides 100% coverage with clear descriptions for all five parameters (board, listId, memberId, staleDays, maxActions). The description adds a little extra context (e.g., default staleDays value and activity types) but does not explain parameters beyond what the schema already conveys. Baseline 3 is appropriate given the schema's completeness.

  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 tool returns open cards with no recognized activity for at least staleDays. It uses a specific verb ('Returns') and resource ('open cards'), and defines what counts as 'recognized activity' (creation, list move, archive/unarchive). While it does not explicitly differentiate from sibling tools like get_overdue_cards, the concept of 'stale' is distinct and the description is unambiguous.

  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 clear context about what the tool does and even cautions that 'stale does not imply blocked,' which helps set usage expectations. However, it does not explicitly mention when to use this tool versus alternatives like get_overdue_cards or get_card_movements, nor does it state any exclusions or prerequisites. Guidance is implied rather than explicit.

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

• get_board_actionsA
  4.4/5.0
  Behavior4/5

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

  Despite no annotations, the description conveys that this is a read-only inspection/debug tool and notes it returns a 'normalized' view, which adds behavioral context beyond the raw definition. However, it does not explicitly mention pagination behavior or potential performance implications, so it falls short of 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.

  Conciseness5/5

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

  The description is only two sentences, front-loaded with the core purpose and then a clear alternative. Every word serves a purpose, with zero redundancy.

  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 the existence of a full output schema and 100% schema coverage for parameters, the description provides sufficient context by clarifying the tool's niche and directing to an alternative. It lacks detailed edge-case guidance, but the schema fills most gaps, making this slightly above-average.

  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?

  The input schema provides 100% coverage of all parameters with detailed descriptions, so the description does not need to add parameter-level semantics. The description's mention of 'raw action history' adds minor context but does not elevate beyond the schema's baseline.

  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 tool returns a compact, normalized view of a board's raw action history, using specific verbs and resource. It explicitly distinguishes itself from sibling tool get_list_changes, making the purpose immediately obvious.

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

  Usage Guidelines5/5

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

  The description explicitly positions this as a low-level historical inspection/debug tool and directs users to get_list_changes for structural list-change auditing, providing clear when-to-use guidance and an alternative.

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

• health_checkA
  4.4/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 that 'Requires no Trello credentials,' which is a meaningful behavioral trait. It doesn't describe return formats or error behavior, but for a simple health check the description is adequate.

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

  Conciseness5/5

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

  Two sentences with no waste. The purpose is front-loaded, and the usage note is secondary. Every word earns its place.

  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 zero parameters and simple scope, the description covers purpose and usage. It lacks explicit return-value info, but the tool is straightforward and the description is otherwise complete.

  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 tool has zero parameters, so per rubric baseline is 4. No parameter explanation needed.

  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 tool's function: 'Checks that the trello-ops-mcp server is running and reachable.' The verb 'checks' combined with the specific resource (server) distinguishes it from sibling tools that fetch Trello data.

  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 phrase 'useful for verifying the MCP connection itself before troubleshooting anything else' provides a clear when-to-use context. It doesn't name specific alternative tools, but the context is strong enough for a health check tool.

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

• get_list_flowA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It discloses the default behavior (last 7 days), the date range options (since/before or days), and the factual scope ('factual movement-flow signal only'). This goes beyond a basic summary, though it does not mention pagination or maxActions behavior that could affect results.

  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 two sentences, front-loaded with the core action and result. The second sentence adds a precise caveat about what the tool does not do. No wasted words; every clause earns its place.

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

  Completeness5/5

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

  Given the tool's moderate complexity and the presence of an output schema, the description covers the essential context: what it returns, how to filter, default behavior, and interpretive boundaries. It is sufficient for an agent to decide when to use it and what to expect, without needing to enumerate return fields since the schema handles that.

  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 100%, so baseline is 3. The description adds value by explaining the convenience relationship between days and since/before, and the default when neither is provided. This is not explicitly in the schema for each parameter, making the description more than just a repeat.

  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 tool's function: 'Returns incoming and outgoing card movement counts by Trello list for a date range.' It specifies the resource (Trello lists), the action (counting movements), and the input (date range). This distinguishes it from sibling tools like get_card_movements (individual movements) or get_list_changes (list modifications) by focusing on aggregate movement flow.

  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 use case: 'Useful for seeing where card movement concentrates.' It also gives an explicit when-not: 'does not identify bottlenecks, throughput, or performance; that interpretation is left to the caller.' However, it does not name alternative tools for those interpretations, so it stops short of a full 5.

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