Server Quality Checklist

Tool Scores

• mcp_kanban_card_managerD
  1.7/5.0
  Behavior1/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate which actions are read-only versus mutative, what permissions might be required, whether operations are atomic or batched, or what happens on failure. For a tool with 9 different actions including destructive ones like 'delete', this lack of behavioral context is critically inadequate.

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

  Conciseness2/5

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

  While technically concise (one sentence), this is under-specification rather than effective brevity. The single sentence fails to convey necessary information about the tool's scope, behavior, or usage context. Every sentence should earn its place, but this sentence provides minimal value beyond the tool name itself.

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

  Completeness1/5

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

  For a complex tool with 13 parameters, 9 different actions, no annotations, and no output schema, the description is completely inadequate. It doesn't explain the tool's multi-action nature, how actions differ, what each action returns, or how to handle the various parameters across different operations. The agent would struggle to use this tool correctly based solely on this description.

  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%, so the schema already documents all 13 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain how parameters interact across different actions, clarify conditional requirements, or provide examples. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose2/5

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

  The description 'Manage kanban cards with various operations' is tautological - it essentially restates the tool name 'mcp_kanban_card_manager' without specifying what 'manage' entails. While it mentions 'various operations', it doesn't distinguish this tool from its siblings like 'mcp_kanban_task_manager' or 'mcp_kanban_list_manager', leaving the agent unclear about the specific scope of card management versus other kanban components.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus its siblings. With multiple kanban-related tools available (comment_manager, label_manager, list_manager, etc.), the agent receives no indication about what operations are specific to cards versus other entities, nor any prerequisites or contextual cues for selecting this multi-action tool over more specialized alternatives.

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

• mcp_kanban_label_managerD
  1.7/5.0
  Behavior1/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 but provides almost none. 'Manage' implies both read and write operations, but there's no indication of which actions are destructive, what permissions might be required, whether operations are atomic, what happens on failure, or what the tool returns. For a tool with 8 parameters and multiple action types, this is critically insufficient.

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

  Conciseness3/5

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

  The description is extremely concise (5 words) but under-specified rather than efficiently informative. While it's front-loaded with the core concept, it lacks the necessary detail to be genuinely helpful. Every word earns its place, but there aren't enough words to provide meaningful guidance for a tool with this complexity.

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

  Completeness1/5

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

  Given the tool's complexity (8 parameters, 6 distinct actions, no annotations, no output schema), the description is completely inadequate. It doesn't explain the relationship between actions and required parameters, doesn't describe return values, doesn't warn about destructive operations, and provides no operational context. For a multi-action mutation tool, this leaves the agent with dangerous gaps in understanding.

  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 schema has 100% description coverage, so all parameters are documented in the structured schema. The description adds no additional parameter semantics beyond the generic 'various operations' phrase. However, since the schema comprehensively describes each parameter's purpose and includes enum values for actions and colors, the baseline score of 3 is appropriate - the description doesn't need to compensate but also adds no value.

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

  Purpose2/5

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

  The description 'Manage kanban labels with various operations' is tautological - it essentially restates the tool name 'mcp_kanban_label_manager' with slightly different wording. It doesn't specify what 'manage' entails or what 'various operations' are, though the input schema reveals these are CRUD and card association operations. It doesn't distinguish this label-focused tool from its sibling tools like mcp_kanban_card_manager or mcp_kanban_list_manager.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose label operations over other kanban tools, no prerequisites for using different actions, and no context about which actions require which parameters. The agent must infer everything from the parameter schema alone.

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

• mcp_kanban_project_board_managerD
  1.9/5.0
  Behavior1/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 but provides none. It doesn't indicate which operations are read-only versus destructive, what permissions are required, whether operations are synchronous or asynchronous, or any rate limits. The generic 'manage' term obscures that this tool includes both read operations (get_projects, get_board) and destructive operations (delete_board).

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

  Conciseness4/5

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

  The description is extremely concise at just 7 words, which could be appropriate if it were more informative. However, this brevity comes at the cost of being under-specified rather than efficiently informative. The single sentence structure is clean but fails to convey necessary information.

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

  Completeness1/5

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

  For a tool with 11 parameters, 8 distinct actions (including both reads and destructive operations), no annotations, and no output schema, the description is completely inadequate. It doesn't explain the tool's scope, differentiate it from siblings, describe behavioral characteristics, or provide any operational context. This is a complex multi-operation tool that needs much more descriptive support.

  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%, so the schema already documents all 11 parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain how parameters relate to different actions, which parameters are required for which actions, or provide any semantic context. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose2/5

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

  The description 'Manage projects and boards with various operations' is tautological - it essentially restates the tool name 'mcp_kanban_project_board_manager' without specifying what 'manage' entails. It doesn't distinguish this tool from its siblings like 'mcp_kanban_card_manager' or 'mcp_kanban_list_manager', which also manage aspects of the kanban system. The description lacks specific verbs and resources beyond the generic 'manage'.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus its siblings. With 7 sibling tools that handle cards, comments, labels, lists, memberships, stopwatches, and tasks, there's no indication of which operations belong to this project/board manager versus those other tools. No context, exclusions, or alternatives are mentioned.

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

• mcp_kanban_comment_managerC
  2.6/5.0
  Behavior2/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 of behavioral disclosure. 'Manage' implies CRUD operations, but it doesn't specify permissions needed, side effects (e.g., if deletions are permanent), rate limits, or response formats. This leaves significant gaps for a tool with multiple actions including destructive ones like delete.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that states the core function without fluff. However, it could be more front-loaded by specifying the exact operations (e.g., CRUD on card comments) to improve clarity immediately.

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

  Completeness2/5

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

  Given the complexity of a multi-action tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'manage' entails, the scope of operations, or expected outcomes, leaving the agent to infer behavior from the schema alone, which is insufficient for safe and effective use.

  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%, so the schema already documents all parameters fully. The description adds no additional meaning beyond implying that parameters relate to comment operations, but it doesn't clarify dependencies (e.g., cardId required for create) or usage patterns. Baseline 3 is appropriate as the schema handles parameter documentation.

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

  Purpose3/5

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

  The description states the tool manages card comments with various operations, which provides a basic purpose but lacks specificity. It mentions the resource (card comments) and general action (manage), but doesn't specify what 'manage' entails or distinguish it from sibling tools like mcp_kanban_card_manager or mcp_kanban_task_manager that might also handle comments indirectly.

  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?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and with siblings like mcp_kanban_card_manager that might handle card-related operations, there's no indication of how this tool fits into the workflow or when it should be preferred.

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

• mcp_kanban_list_managerC
  2.6/5.0
  Behavior2/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. 'Manage' implies both read and write operations, but it doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what happens during deletions. The description is too generic to inform the agent about the tool's behavior beyond basic CRUD operations.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that directly states the tool's purpose. It's appropriately sized and front-loaded, with no wasted words, though it could be more specific to improve clarity without losing conciseness.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, making it inadequate for an agent to fully understand how to invoke the tool correctly in various scenarios.

  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%, so the schema fully documents all 5 parameters, including the action enum and other fields. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions or usage examples. Baseline 3 is appropriate since the schema handles parameter documentation.

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

  Purpose3/5

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

  The description states the tool 'Manage kanban lists with various operations', which identifies the resource (kanban lists) and implies multiple operations. However, it's vague about what 'manage' entails and doesn't distinguish this from sibling tools like mcp_kanban_card_manager or mcp_kanban_task_manager, which also manage different kanban components.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or clarify the scope of 'kanban lists' compared to other kanban-related tools, leaving the agent to infer usage from the action parameter alone.

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

• mcp_kanban_membership_managerC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Manage board memberships' implies CRUD operations but doesn't specify permissions needed, rate limits, whether operations are destructive, or what happens when memberships are created/updated/deleted. The description is too generic to provide meaningful behavioral context.

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

  Conciseness4/5

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

  The description is extremely concise with just 6 words, which is efficient. However, it's arguably too brief given the complexity of the tool (6 parameters supporting 5 different actions). While front-loaded, it lacks necessary detail that would help an agent understand the tool's scope.

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

  Completeness2/5

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

  For a tool with 6 parameters supporting 5 different actions (including destructive operations like 'delete'), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what the different actions do, or provide any behavioral context needed for safe and effective use.

  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%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose3/5

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

  The description states 'Manage board memberships with various operations' which provides a general purpose (managing memberships) but is vague about what 'manage' entails. It doesn't specify the exact operations available or distinguish this tool from sibling tools like mcp_kanban_project_board_manager which might also handle board-level 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?

  No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools or provide context about when board membership management is appropriate versus other board-related operations available in the sibling tools.

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

• mcp_kanban_task_managerC
  2.6/5.0
  Behavior2/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 only states 'manage kanban tasks with various operations,' which doesn't disclose behavioral traits such as whether operations are read-only or destructive, authentication needs, rate limits, or error handling. For a tool with multiple actions including create, update, and delete, 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.

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words. It's appropriately sized for a high-level overview, though it could be more front-loaded with specific details. Every word earns its place, but it lacks depth.

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

  Completeness2/5

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

  Given the tool's complexity (7 parameters, multiple actions including mutations like create/update/delete) and no annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or usage scenarios, making it inadequate for an AI agent to understand the tool's full context and operation.

  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%, so the schema already documents all 7 parameters with descriptions. The description adds no meaning beyond the schema, as it doesn't explain parameter relationships or usage. With high schema coverage, the baseline is 3, but the description doesn't compensate with additional context.

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

  Purpose3/5

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

  The description 'Manage kanban tasks with various operations' states the general purpose (managing tasks) but is vague about what 'manage' entails. It doesn't specify the exact operations available or distinguish this tool from sibling tools like mcp_kanban_card_manager or mcp_kanban_list_manager, which likely manage different kanban entities.

  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?

  No guidance is provided on when to use this tool versus alternatives. The description mentions 'various operations' but doesn't specify contexts, prerequisites, or exclusions. With siblings like mcp_kanban_card_manager, there's no indication of how task management relates to card management, leaving usage unclear.

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

• mcp_kanban_stopwatchC
  2.9/5.0
  Behavior2/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 of behavioral disclosure. 'Manage' implies mutation operations (starting/stopping/resetting), but the description does not specify permissions required, side effects (e.g., whether stopping records time data), or error conditions. It lacks details on what 'get' returns or how time data is stored, leaving significant gaps for a tool with multiple action types.

  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, efficient sentence with zero waste. It is front-loaded with the core purpose and avoids unnecessary elaboration. Every word earns its place by directly stating the tool's function, making it highly concise and well-structured for quick understanding.

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

  Completeness2/5

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

  Given the tool's complexity (multiple actions like start, stop, get, reset) and lack of annotations and output schema, the description is incomplete. It does not explain return values, error handling, or behavioral nuances (e.g., what happens if you start a stopwatch that's already running). For a mutation-heavy tool with no structured output, more context is needed to guide effective use.

  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% description coverage, with clear documentation for both parameters ('action' with enum values and 'id' as card ID). The description adds no additional meaning beyond the schema, such as explaining the relationship between actions or what 'id' refers to in the context of stopwatches. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

  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 clearly states the tool's purpose as 'Manage card stopwatches for time tracking', which includes a specific verb ('Manage') and resource ('card stopwatches') with a clear functional context ('for time tracking'). It distinguishes this tool from siblings like 'mcp_kanban_card_manager' or 'mcp_kanban_task_manager' by focusing on stopwatch functionality, but could be more precise about what 'manage' entails (e.g., starting, stopping, etc.).

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as needing an existing card, or differentiate from potential overlapping tools (e.g., if time tracking is also handled elsewhere). With no explicit usage context or exclusions, the agent must infer usage from the tool name and parameters alone.

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