Trello MCP Server - Optimized

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation2/5
Several tools overlap in purpose: add_label, add_label_to_card, and create_label_on_card are nearly identical; archive_card/close_board and archive_list/unarchive_list use synonyms for the same operations. This creates confusion for an agent selecting the right tool.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (get_, create_, update_, delete_, archive_, unarchive_). However, there are inconsistencies such as close_board vs archive_card, get_cards_in_list vs get_board_lists, and verbose names like update_checkitem_state_on_card.
Tool Count2/5
76 tools is excessive even for a comprehensive Trello integration. The sheer number will likely overwhelm an agent trying to select the appropriate tool, despite the domain's complexity.
Completeness4/5
The surface covers boards, lists, cards, labels, checklists, members, comments, attachments, due dates, and notifications with CRUD operations. Missing operations like comment editing/deletion and unsubscribe from list are minor gaps, but overall the coverage is strong.
Average 3.6/5 across 74 of 76 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 29, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 disclosing behavior. It does not mention that color can be null to remove a color, how the fields/detailLevel parameters affect the response, or any side effects. The description offers no behavioral insight beyond the obvious.
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?
The description is brief but redundant: both sentences convey the same information. It wastes space restating the tool's purpose instead of providing useful details, making it under-specified rather than concisely helpful.
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?
This simple 4-parameter tool has no output schema and no annotations, so the description should explain behavior and parameters. It does neither—ignoring fields/detailLevel, the null color option, and response implications. The description is inadequate for an agent to use the tool 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?
The input schema covers 100% of parameters with descriptions, including the nullable color enum and field filtering options. The description adds no additional meaning, so a baseline score of 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the color of a label' is essentially a tautology of the tool name. It states the verb and resource but adds no scope or differentiation from sibling tools like update_label or update_label_name, making it minimally informative.
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?
No usage guidance is provided. The phrase 'Use this tool to change the color of a label' is a restatement, not a guideline. There is no mention of when to choose this over update_label or update_label_name, nor any prerequisites or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that the tool 'creates' a checkitem, which is tautological with the tool name. It does not discuss permissions, idempotency, error handling, return values, or side effects, making it highly opaque 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, but the second sentence ('Use this tool to add a new item to a checklist') is redundant with the first, adding no new information. It is concise but not optimally economical.
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 8 parameters, no output schema, and no annotations, the description is minimal. It does not mention what the tool returns, any prerequisites (e.g., checklist must exist), or expected failure modes. The description is functionally minimal but lacks necessary context for an agent to use it confidently.
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 description coverage is 100% (all 8 parameters have descriptions), so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema already provides, but it does not need to since the schema is comprehensive.
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 ('Create') with a clear resource ('checkitem') and context ('on a checklist'), distinguishing it from sibling tools like update_checkitem, get_checkitem, and delete_checkitem. The purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this tool to add a new item to a checklist,' which merely restates the purpose without providing when-to-use guidance or exclusions. It does not mention alternatives like update_checkitem or delete_checkitem, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it only repeats the verb 'delete' without disclosing consequences such as irreversibility, permission requirements, or effects on associated data.
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 short but contains redundancy; the second sentence adds no new information and could be removed. It is not as concise as a single sentence would be.
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?
The tool is a simple delete operation, but the description lacks key context such as return value, irreversibility, or any caveats. Given no annotations and no output schema, more detail is needed for a complete picture.
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 all parameters are already documented. The description adds no additional meaning beyond what the schema provides, warranting the baseline score.
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 (delete) and the target resource (a checkitem from a checklist), distinguishing it from sibling tools like delete_checklist or update_checkitem_state_on_card.
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 given on when to use this tool versus alternatives. The second sentence merely restates the function rather than providing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Update an existing list with new properties' without disclosing side effects, permissions, idempotency, error behavior, or what happens if the list does not exist. This is insufficient 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?
The description is extremely concise—two short sentences that front-load the core purpose. There is no filler or redundancy, earning a top score for efficiency.
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?
Despite having 8 parameters and no output schema, the description provides almost no contextual guidance. It lacks usage context (e.g., when to use this versus dedicated list update tools), behavioral details, or any sense of return values. The schema covers parameters, but the overall tool context remains under-specified.
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 for all 8 parameters, each with meaningful descriptions (e.g., 'pos' explains accepted values, 'fields' explains dot notation). The description adds no extra parameter semantics, but the schema fully compensates, so a baseline of 3 is appropriate.
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 action ('Update') and the resource ('an existing list') with some scope ('new properties', 'list details or settings'). However, it does not differentiate from sibling tools like update_list_name or update_list_position, which are more specific variations.
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 phrase 'Use this tool to modify list details or settings' provides minimal guidance but does not explain when to choose this generic update over specialized siblings such as update_list_position or update_list_name. No explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparency burden. It only says 'get,' implying a read-only operation, but it does not disclose return format, behavior when the checkitem is not found, authentication needs, or any side effects. For a simple read tool, this is minimal but still a gap.
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?
Two sentences, but the second ('Use this tool to get details about a particular checkitem') largely repeats the first. It is short but contains redundancy. A single sentence would be more concise.
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 'get by ID' operation, the description is acceptable but not complete. There is no output schema, so the description does not clarify what details are returned or how detailLevel influences the response. It relies on the schema for parameter information and does not explain the relationship between checklistId and checkItemId.
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 all parameters described. The description adds no additional meaning beyond the schema, such as how to obtain the IDs or how fields/detailLevel affect the response. Baseline 3 is appropriate when schema does the heavy lifting.
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-resource combination: 'Get a specific checkitem on a checklist.' This distinguishes the tool from siblings like get_checkitems (which lists all) and other checkitem operations. However, it does not explicitly name alternatives, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this tool to get details about a particular checkitem,' which provides basic context. But it does not state when not to use it or compare it to get_checkitems, create_checkitem, etc. 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.
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. It discloses that this is a write operation, but does not mention whether a due date must already exist, any side effects, permissions, or response behavior. This is a notable gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and is quite brief. The second sentence largely restates the first in different words ('update the status of a deadline' vs 'mark as complete or incomplete'), which is mild redundancy, but overall there is minimal waste.
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?
Despite having four parameters and no output schema or annotations, the description only offers a high-level statement. It does not explain the return value, behavior when a card has no due date, or how fields/detailLevel affect the response, leaving the agent without enough context for edge cases.
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 description coverage is 100%, so all parameters are fully documented by the schema. The description's reference to 'complete or incomplete' aligns with the dueComplete boolean but adds no additional meaning beyond what the schema already says. A baseline of 3 is appropriate.
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 marks a card's due date as complete or incomplete, which is specific and uses a clear verb and resource. However, it does not explicitly distinguish from the sibling tool set_due_date, which sets the date itself, so it lacks explicit sibling differentiation.
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 phrase 'Use this tool to update the status of a deadline' gives a clear context for when to use it, but it does not mention when not to use it or name alternative tools like set_due_date. Guidance is implied rather than explicit with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of explaining behavioral traits. It states that the tool 'updates' but does not disclose whether updates are partial or full replacements, whether changes are reversible, if special permissions are required, or what the response contains. This is a significant gap for a mutation tool with many optional parameters.
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 front-loads the primary action and resource, but it is arguably too generic, missing useful contextual details that would make it more informative.
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?
This is a complex tool with 23 parameters, no output schema, and no annotations. The description fails to explain update semantics (e.g., partial vs. full update), return behavior, or edge cases. The schema provides parameter details, but the description does not adequately support an agent in understanding the overall behavior and appropriate 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 23 parameters in detail. The description adds no additional meaning beyond saying 'new properties,' which is vague. The baseline of 3 applies because the schema does the heavy lifting.
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 action ('Update an existing board') and the resource ('board'), and indicates the scope ('modify board details, preferences, or settings'). It does not explicitly distinguish from specialized sibling tools like close_board or reopen_board, but the general-purpose nature is evident.
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 when to use the tool ('to modify board details, preferences, or settings') but provides no explicit guidance on when not to use it or which alternative tools to prefer. For example, it doesn't mention that closing/reopening can be done via close_board/reopen_board, though update_board also supports the 'closed' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to characterize safety or side effects, so the description carries the full burden. It only states the action without disclosing behavioral traits such as whether the operation is persistent, requires specific permissions, or returns the updated checklist. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the action. However, the second sentence ('Use this tool to rename a checklist') is largely redundant with the first, making it slightly less efficient than ideal. Still, it is concise and well-structured.
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?
With four parameters including response-controlling fields and detailLevel, and no output schema, the description is incomplete. It does not explain what the tool returns, how to interpret the response, or how to customize it via the optional parameters. The presence of these parameters suggests a response, but the description omits any mention of it, leaving the agent under-informed.
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 documents all four parameters with descriptions, so coverage is 100%. The description adds no additional meaning beyond the schema; it only mentions 'name' in the text but does not elaborate on the fields or detailLevel parameters. Baseline of 3 applies because 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 the tool's action: 'Update the name of a checklist.' It uses a specific verb (update) and resource (checklist name), and distinguishes itself from sibling tools like update_checklist by focusing solely on renaming. The second sentence reinforces the purpose without ambiguity.
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 says 'Use this tool to rename a checklist,' which is essentially a restatement of the purpose. It provides no guidance on when to prefer this over alternatives like update_checklist, nor any exclusions or prerequisites. No explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the add action, omitting any details about idempotency, error behavior, required permissions, or return value. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is clear and direct, but the second sentence 'Use this tool to assign someone to a card' is redundant and adds no new information. It could be condensed to a single sentence, making the description more efficient.
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 no output schema and no annotations, the description should explain the response format or side effects. It does not, and it also ignores the optional fields and detailLevel parameters that control response content. The description is incomplete for a 4-parameter 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 coverage is 100%, with each parameter having a meaningful description (e.g., 'ID of the card'). The tool description adds no additional parameter information, so the schema carries the semantics. Baseline 3 is appropriate given full 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 specifies the action: 'Add a member to a card.' This directly distinguishes it from sibling operations like remove_member or get_card_members. The verb 'add' and resource 'member to a card' are 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 phrase 'Use this tool to assign someone to a card' restates the purpose but provides no explicit guidance on when to choose this over alternatives like remove_member, nor does it mention prerequisites or exclusions. It implies a use case but does not differentiate it clearly from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply states the action without mentioning that archiving is destructive/irreversible, any permission requirements, or potential bulk operation limits (e.g., rate limits). This is a significant gap for a bulk 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but the second sentence largely repeats the first, adding only the word 'quickly.' It could be condensed to one sentence without losing meaning, but it remains short and clear.
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?
The tool has no output schema and no annotations. The description only states the action and does not explain return values, error conditions, or prerequisites (e.g., valid list ID). For a bulk destructive operation, this is insufficient 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 listId, fields, and detailLevel all having descriptions. The tool description adds no additional parameter context, but the schema already adequately documents the parameters, so this is baseline adequate.
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 archives all cards in a list, using a specific verb ('Archive') and resource ('all cards in a list'). This distinguishes it from sibling archive_card, which archives a single 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 says 'Use this tool to quickly archive all cards in a list,' implying usage for bulk archiving. However, it does not explicitly mention alternatives or when not to use it, such as using archive_card for single-card operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral disclosure burden. It only states the action ('update') without mentioning side effects, required permissions, error cases, or response behavior, leaving agents with insufficient transparency for a mutating operation.
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 efficiently conveys the tool's purpose. Every word earns its place, and it avoids unnecessary elaboration.
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 presence of sibling tools with overlapping functionality and the lack of annotations or an output schema, the description is incomplete. It does not explain how this tool differs from update_label_name or update_label_color, nor does it mention response format or operational details beyond the basic update action.
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 five parameters. The description adds no new semantic detail beyond the parameter names already visible, so it meets the baseline but does not exceed it.
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 updates an existing label and specifies the primary properties (name or color). However, it does not differentiate itself from sibling tools like update_label_name and update_label_color, which have overlapping purposes.
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 says 'Use this tool to modify a label's name or color,' providing some usage context. It lacks guidance on when to prefer this tool over the more specific update_label_name or update_label_color siblings, so the usage is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning permissions, idempotency, side effects on other resources, or return values—essential context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the second sentence is redundant with the first ('Update the name of a label' vs 'Use this tool to rename a label'). This redundancy wastes a sentence that could have been used for more valuable context.
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?
The description is minimal for a simple operation, but given no annotations or output schema, it should provide more context about response behavior or when to choose this over the generic update_label tool. It lacks completeness for an agent to fully reason about invocation.
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 provides 100% coverage of all four parameters with clear descriptions (e.g., 'New name for the label', 'ID of the label'). The tool description adds nothing beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a label's name, using both 'Update the name' and 'rename a label'. This specific action is distinguished from sibling tools like update_label_color and generic update_label by focusing solely on the name field.
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 second sentence 'Use this tool to rename a label' conveys the intended usage context, but it simply restates the purpose. There is no explicit guidance on when not to use this tool or how it compares to the generic update_label tool, so the usage signal is present but not robust.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the tool's function ('Add a label to a card') and adds no details about side effects, prerequisites, idempotency, or error conditions. With no annotations provided, this is a significant gap 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?
Two short sentences that effectively convey the core action and a use case without redundancy. 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?
The description is adequate for a simple 2-required-param mutation, but it lacks behavioral context and fails to address the existence of sibling 'add_label_to_card', making it incomplete for an agent choosing between similar tools.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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 'Add a label to a card' with a clear verb and resource, and adds a use case 'categorize a card'. However, it does not differentiate from sibling tool add_label_to_card, which appears to have the same function, so it's not fully distinct.
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?
Provides a usage context ('Use this tool to categorize a card') but no exclusions or guidance on when not to use it, nor does it distinguish from the similarly named sibling 'add_label_to_card'. This leaves ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does state that deletion is permanent and cannot be undone, which is a critical trait. However, it does not mention side effects on cards using the label, any required permissions, or the purpose of the 'confirm' parameter, leaving gaps in 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 extremely concise: one clear action statement and a short caution. Every word earns its place, and the caution adds important context without 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?
For a simple deletion tool with no output schema, the description covers the core purpose and permanence but lacks context about when to choose this over 'remove_label' and the operational side effects on cards that use the label. It is adequate but not fully complete.
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 describes all four parameters (fields, confirm, labelId, detailLevel) with full coverage, so the description does not need to add parameter details. The schema itself is sufficient, yielding a baseline score of 3.
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 'Permanently delete a label' uses a specific verb and resource, making the tool's purpose clear. However, it does not explicitly differentiate from the sibling tool 'remove_label', which could be confused with removing a label from a card, so it misses the top score.
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 includes only a caution 'Use this tool with caution as deletion cannot be undone', which is a warning rather than usage guidance. It provides no explicit when-to-use vs alternatives, no prerequisites, and no exclusions, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose safety/behavior details. It only states the high-level removal action and does not mention whether the label definition is unaffected, if the operation is reversible, or any side effects or required permissions. This is a significant gap for a mutation operation.
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 short sentences. The first front-loads the action, and the second adds a purpose. Every word contributes to clarity without 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 tool has no annotations or output schema, and the description provides minimal context. It does not explain response behavior, side effects, or how to choose between this and the sibling 'remove_label_from_card'. While the schema covers parameters, the overall description leaves gaps for a complete 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?
Schema description coverage is 100%, with all parameters already described in the schema. The tool description adds no extra meaning about parameters (e.g., cardId, labelId, fields, detailLevel). Baseline 3 is appropriate since the schema already carries the parameter semantics.
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 action with a specific verb and resource: 'Remove a label from a card.' It distinguishes from label deletion (delete_label) and addition (add_label) by specifying the card context. However, it does not differentiate from the similarly named sibling 'remove_label_from_card', which may cause ambiguity.
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 sentence 'Use this tool to update the categorization of a card' provides a general usage context, indicating when to apply it (when changing a card's labels). Yet it lacks explicit exclusions or mention of alternatives, especially given the near-duplicate sibling tool, so guidance is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the high-level action and does not mention required permissions, that a card must exist, or the response format. This leaves the agent without crucial side-effect information 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The second sentence 'Use this tool to add notes or feedback to a card' partially restates the first but adds the clarification of 'notes or feedback.' It is concise and front-loaded, though not entirely free of 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?
For a simple add-comment tool, the description covers the core purpose. However, with no annotations and no output schema, it does not explain what the response will be or any prerequisites (e.g., valid cardId). The high schema coverage for parameters mitigates the gap, but the tool remains under-specified for behavioral 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?
The input schema describes all four parameters (cardId, text, fields, detailLevel) with 100% coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Add a comment to a card.' It further clarifies the use case with 'notes or feedback.' While it doesn't explicitly compare to sibling tools like add_attachment or get_comments, the 'comment' terminology sufficiently distinguishes it.
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 includes an explicit usage directive: 'Use this tool to add notes or feedback to a card.' This provides a clear context for when to invoke the tool. However, it does not mention alternatives or exclusions, such as using add_attachment for non-text content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only clarifies that archiving is not deletion, but omits what archiving actually does (e.g., hides the list, reversibility, effects on cards) and lacks permission or side-effect context.
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 short sentences, immediately states the action and the key qualification. No filler, information is front-loaded and every word earns its place.
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?
The tool has optional response-control parameters (fields, detailLevel) and no output schema, yet the description does not mention response customization or return behavior. It also lacks detail on the operation's side effects, making it incomplete for confident agent 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 each parameter already has a description. The tool description itself adds no parameter-level meaning beyond the schema, which is the baseline expectation; thus a score of 3 is appropriate.
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 the specific verb 'archive' plus the resource 'list', and explicitly notes the operation is non-destructive ('without deleting it'), which distinguishes it from delete tools and the sibling archive_card. This is clear and specific.
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 phrase 'Use this tool to archive a list without deleting it' implies the intended context (archiving rather than deleting) but does not mention alternatives like unarchive_list or when not to use it. Basic implied guidance, no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It only states 'Delete' without mentioning side effects (e.g., whether associated checkitems are also removed), permissions required, irreversibility, or response behavior. A destructive operation with no annotations needs more detail.
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 short and front-loaded, but the second sentence 'Use this tool to remove a checklist from a card' largely restates the first. It is not zero-waste; combining them would improve 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?
The tool has 3 parameters, no output schema, and no annotations. The description fails to mention consequences (e.g., deleting the checklist likely deletes its checkitems), prerequisites, or return behavior. Minimal for a delete operation but still incomplete for safe usage.
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 each parameter (checklistId, fields, detailLevel) already has clear descriptions in the schema. The tool description adds no extra param context, so a baseline of 3 is appropriate.
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 specifically states 'Delete a checklist' and 'remove a checklist from a card,' clearly identifying the verb and resource. This distinguishes it from sibling tools like delete_checkitem (which deletes an individual check item) and update_checklist.
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 'Use this tool to remove a checklist from a card,' giving clear context on when to apply it. However, it does not name alternatives or exclusions, so it stops 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.
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. It only states the action without disclosing side effects, permission requirements, reversibility, or potential impacts of bulk-moving many cards. For a mutation tool, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence ('Use this tool to quickly move all cards from one list to another.') is largely redundant with the first, adding only the adverb 'quickly'. This wastes a sentence without adding new information.
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 bulk operation with no output schema and no annotations, the description is too minimal. It does not explain return values, potential performance considerations, or the broader context of moving all cards (e.g., whether the source list becomes empty or if there are limits). This is inadequate for an agent to fully assess the tool's effects.
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 no extra meaning beyond the schema, which already explains sourceListId, destinationListId, and boardId. The optional fields/detailLevel parameters are not mentioned but are already described in 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 action ('Move all cards in a list to another list') with specific verb and resource. It distinguishes itself from the sibling tool 'move_card_to_list' by explicitly targeting all cards, making the scope unambiguous.
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 for when to use the tool ('Use this tool to quickly move all cards from one list to another'). However, it does not explicitly mention alternatives or exclusion criteria, such as using 'move_card_to_list' for individual card moves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the removal action but does not explain that the label itself is not deleted, that the operation may be reversible, permissions needed, or response/return behavior. 'Update the categorization' hints at a non-destructive change but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The second sentence is somewhat redundant but adds the categorization framing; it is not wasteful enough to lower further.
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 mutation tool, the description plus a fully documented schema covers the basic operation. However, no output schema and no annotations mean the agent still lacks information about return values, error cases, or side effects, leaving a notable 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?
Schema description coverage is 100%, so the schema already documents cardId, labelId, fields, and detailLevel. The description adds no extra parameter details beyond mapping 'remove a label' to labelId and 'from a card' to cardId, which is not sufficient to raise above 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 action with a specific verb and resource: 'Remove a label from a card.' It also distinguishes from siblings like 'remove_label' by specifying 'from a card' and adds the categorization purpose.
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 second sentence gives a use case ('update the categorization of a card'), so there is some contextual guidance. However, it does not explicitly mention alternatives or when not to use this tool, such as pointing to add_label_to_card for adding or remove_label for deleting a label.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only says it updates/renames a list, which implies a write operation, but does not mention side effects, permissions, response behavior, or reversibility. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two sentences, the description is brief and front-loaded, but the second sentence ('Use this tool to rename a list') is redundant with the first. It could be condensed into a single sentence without losing meaning.
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?
The tool has additional parameters (fields, detailLevel) affecting response, but the description does not mention any context about response behavior or side effects. Since there is no output schema, the description should have provided more behavioral context. For a simple rename tool, it's adequate but incomplete.
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 documents all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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 updates a list's name using the verb 'update' and resource 'list name.' It distinguishes itself from sibling tools like update_list by specifically focusing on rename, and the instruction 'Use this tool to rename a list' reinforces this purpose.
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 explicit instruction on when to use the tool: to rename a list. It does not mention alternatives or when not to use it, but the use case is clearly delimited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the action ('Add') without detailing permissions, return value, idempotency, or side effects. This is a minimal disclosure, comparable to the update_drive example.
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 concise with two short sentences, but it is slightly redundant—the second sentence restates the first with URL specificity. It is front-loaded and free of unnecessary words, earning a 4.
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?
The tool has 5 parameters and no output schema, and the description is minimal. It does not explain what the tool returns, any prerequisites (like the cardId), or how the fields/detailLevel parameters affect the response. This leaves a significant gap in context for the agent to invoke it 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides—the 'attach a URL' phrase simply echoes the url parameter description. No extra compensation is needed, hence a 3.
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 with a specific verb and resource: 'Add an attachment to a card' and further specifies it attaches a URL to a card. This distinguishes it from sibling tools like get_attachments and delete_attachment.
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 includes an explicit usage instruction ('Use this tool to attach a URL to a card'), which clearly identifies the intended scenario. However, it does not mention when not to use it or alternative tools, though none exist for adding attachments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates that the tool creates a card, leaving out necessary context like authentication requirements, side effects, or default behavior. This is similar to the update_drive example that scored 2.
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 concise and front-loaded, but the second sentence ('add a new card to a list') largely restates the first, slightly reducing efficiency.
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?
The tool has 17 parameters and no output schema, yet the description gives no information about return behavior, prerequisites beyond the schema, or edge cases. The high schema coverage mitigates parameter documentation, but the description is too sparse for a complex creation 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 coverage is 100%, with each parameter individually described. The description itself provides no additional parameter insight, so the baseline 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 ('Create') with a clear resource ('card') and scope ('on a list'). This distinguishes it from sibling tools like update_card, delete_card, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when-to-use statement: 'Use this tool when you need to add a new card to a list.' However, it does not mention exclusions or alternatives, so it falls 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It mentions 'authenticated user' and 'filters' but does not state that this is a read-only operation, what data is returned, or any limitations. For a tool with no annotation coverage, this is insufficient.
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 concise sentences, front-loaded with the primary purpose and followed by a usage hint. No wasted words, and it reads clearly.
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 list tool with five parameters and no output schema, the description gives a reasonable overview but lacks details about response format, pagination, or any side effects. It is minimally complete for a simple read operation, but the absence of annotations and output schema leaves gaps.
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 five parameters. The description only adds that filters can be used for searching, which is a marginal enhancement. It does not provide additional semantic context beyond the schema.
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 it retrieves a list of boards for the authenticated user, with a distinct verb+resource. It implies a plural list operation, distinguishing it from get_board (singular), though it does not explicitly name alternatives, so it slightly misses the top score.
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 the tool: to get an overview or search with filters. However, it does not mention when not to use it or point to alternative tools like get_member_boards or get_board, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only restates the lookup purpose without mentioning return format, permissions, error cases, or any side effects. It adds no context beyond what the tool name already implies.
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 short and front-loaded, but it contains redundancy: the second sentence essentially repeats the first. Still, it's compact and to the point, losing only a point for the repetition.
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 no annotations and no output schema, the description should explain what gets returned (e.g., the full board object or just its ID). It doesn't mention the return value or how detailLevel/fields affect the response, leaving the tool under-specified.
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 three parameters (checklistId, fields, detailLevel). The description adds no additional parameter-related meaning, so the baseline of 3 is appropriate.
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?
Clearly states the tool's function with a specific verb and resource ('Get the board a checklist is on'). It distinguishes from sibling tools like get_checklist (returns the checklist itself) and get_checklist_card (returns the card containing the checklist).
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?
Explicitly instructs when to use the tool: 'Use this tool to find out which board a checklist belongs to.' However, it doesn't mention alternatives or when not to use, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely restates the tool's name ('Get the card a checklist is on') and does not mention that it is a read-only operation, any permissions required, response format, or error behavior. The description adds no behavioral context beyond what is already implied by the 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but the second sentence 'Use this tool to find out which card a checklist belongs to' is redundant with the first sentence. It does not add new information, so it does not earn 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 tool is simple and the schema is complete, but the description lacks any differentiation from the sibling tool get_checklist_board and does not mention what the response contains. It is minimally viable for an agent to understand the tool's core function, but it could be more complete by clarifying the relationship to get_checklist_board.
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 complete descriptions for all three parameters (fields, checklistId, detailLevel), covering 100% of the schema. The description itself adds no parameter information, 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 'Get' and identifies the resource as 'the card a checklist is on', which clearly states what the tool does. It distinguishes itself from the sibling tool get_checklist_board by explicitly using 'card' rather than 'board'.
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 a clear use case: 'Use this tool to find out which card a checklist belongs to.' This gives context for when to use it, but it does not mention any alternatives or when not to use it (e.g., use get_checklist_board to get the board).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states 'Get members' without any additional context. It does not mention whether the call requires specific permissions, how pagination works, or what the response structure contains. The description adds minimal behavioral insight beyond the name and title.
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 extremely concise, consisting of two short sentences that say exactly what the tool does and when to use it. There is no redundant information, and the structure is front-loaded with the core purpose. It earns a high score for directness and economy of words.
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 straightforward read operation with comprehensive schema coverage, the description is minimally adequate. However, it lacks an output schema, so the agent must infer the return format, and the description does not elaborate on what fields or member details are included. The guidance provided is sufficient for basic use but leaves some ambiguity about the response's richness.
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 all parameters are fully described in the input schema. The description itself adds no parameter-level detail, such as the meaning of organizationId or the effects of fields/detailLevel. This aligns with the baseline of 3 for high schema coverage, as the schema handles parameter semantics.
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: 'Get members of an organization.' It specifies the resource (members) and the scope (organization/workspace), and the phrase 'Use this to see who belongs to a workspace' reinforces the purpose. While it does not explicitly differentiate from siblings like get_board_members or search_members, the distinction is evident from the resource named.
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 for when to use this tool: 'Use this to see who belongs to a workspace.' This is a direct usage guideline, though it lacks an explicit 'when not to use' or mention of alternatives such as get_board_members for board-specific members. The context is unambiguous for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states that the card is moved, without mentioning side effects, permission requirements, or reversibility. This is a significant gap for a mutation tool, as it gives the agent no information about potential impacts or constraints beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action: 'Move a card to a different list.' The second sentence adds a usage framing ('change the status') but is somewhat redundant; still, it is brief and earns its place by reinforcing the semantic intent.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It does not mention response behavior, prerequisites, or any side effects like card position reset. The complete schema helps but does not compensate for the lack of behavioral 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?
The input schema already provides 100% coverage of all parameters, including descriptions for cardId, listId, fields, and detailLevel. The description adds no parameter-specific information beyond the schema, so it meets the baseline of 3 but does not elevate it.
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 a specific action: 'Move a card to a different list.' This distinguishes it from sibling tools like archive_card, create_card, and move_all_cards by specifying the single-card move operation. The second sentence reinforces the purpose by linking it to changing card status.
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: 'Use this tool to change the status of a card.' This implies the tool is appropriate when moving a card between lists. However, it does not explicitly mention alternatives or when not to use it (e.g., versus move_all_cards for bulk operations), so it misses a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only says 'update' without revealing whether updates are partial or full replacements, how missing fields are handled, whether moving lists has side effects, or any permission requirements. For a mutation tool with 20 parameters, this is a significant transparency gap.
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 concise sentence that is front-loaded with the primary purpose and includes useful examples without unnecessary detail. 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?
Given the tool's high complexity (20 parameters, nested objects) and lack of output schema, the description provides only a generic overview. It does not convey the breadth of updatable attributes (cover, labels, members, custom fields, etc.) or clarify overlap with dedicated sibling tools. The rich schema compensates somewhat, but the narrative is not complete enough for an agent to fully understand the tool's scope.
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 all 20 parameters are already well-documented in the schema. The description itself adds little parameter-level meaning beyond broad categories like 'modify card details' and 'move to a different list.' Baseline 3 applies because the schema does the heavy lifting.
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 updates an existing card with new properties, identifies the resource (card), and gives examples of use (modify details, move list, change attributes). It does not explicitly differentiate from sibling tools like move_card_to_list or archive_card, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context on when to use the tool ('Use this tool to modify card details, move it to a different list, or change other attributes'). It does not state exclusions or name alternatives, but the context is sufficiently directive for a general-purpose update tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 simply says 'Update an existing checklist' without detailing permissions, side effects, reversibility, or response behavior. For a mutating tool, this is a significant gap, similar to the under-transparent update_drive example.
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 concise sentences, front-loaded with the action and resource, and contains no fluff. Every word contributes to understanding the tool's purpose and primary usage.
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?
Given 5 parameters and no annotations or output schema, the description is adequate but not complete. It clearly indicates the main use case (name/position updates), but it does not address potential conflicts with sibling tools, the presence of response-control parameters, or expected return values, leaving some gaps for the agent.
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 for all parameters, so the baseline is 3. The description adds minimal context by mentioning 'name or position,' which maps to the 'name' and 'pos' parameters, but it does not explain the response-related parameters (fields, detailLevel) or provide deeper semantics beyond the schema.
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 function: 'Update an existing checklist with new properties' and specifies that it modifies a checklist's name or position. This is a clear verb+resource combination, but it does not differentiate from sibling tools like update_checklist_name and update_checklist_position, which are more specific.
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 the tool: 'Use this tool to modify a checklist's name or position.' However, it does not mention alternatives or explicitly state when not to use this tool in favor of the more specific sibling tools, so it lacks exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the core action and purpose but does not mention side effects (e.g., idempotency, whether duplicates are allowed), required permissions, reversibility, or what the response contains. This is a significant gap 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?
The description is exactly two sentences, front-loaded with the action, and contains no superfluous information. Every word earns its place, making it highly concise and easy to parse.
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?
The tool is simple, but the description does not mention return values (no output schema), error conditions, or clarify the distinction from sibling tools like add_label and remove_label_from_card. Given the many similarly named sibling tools, the description should provide more contextual differentiation to ensure correct selection. The lack of behavioral details also contributes to incompleteness.
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 all four parameters (cardId, labelId, fields, detailLevel) already described in the schema. The description adds only the context of 'existing label', which slightly reinforces labelId semantics but does not provide additional parameter-level meaning. Baseline 3 is appropriate.
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 'Add a label to a card' with a specific verb and resource. The phrase 'with an existing label' differentiates it from sibling tools like create_label_on_card, which creates a new label. This is a specific, distinguishing purpose.
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 for when to use: 'Use this tool to categorize a card with an existing label.' However, it does not explicitly mention alternatives or when not to use it, such as when creating a new label is needed. Thus, it lacks exclusionary guidance but gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the non-destructive nature (without deleting) but fails to mention reversibility (unarchive_card), permissions required, or what happens to the card's visibility. For a mutation tool, this is insufficient.
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 short and front-loaded, but contains slight redundancy by saying 'Archive a card' and then 'Use this tool to archive a card'—repeating 'archive a card.' Still, it's efficient and under two sentences.
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?
Given no annotations or output schema, the description is minimal but adequate for a simple archive action. However, it lacks context about reversibility, response structure, or side effects, leaving gaps that could be clarified with references to unarchive_card or response controls.
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 baseline is 3. The description adds no additional meaning about the parameters (cardId, fields, detailLevel) beyond what the schema already provides.
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 a specific action (archive) on a specific resource (card), and explicitly distinguishes it from deletion by saying 'without deleting it.' This differentiates it from sibling tools like delete_card and aligns with unarchive_card.
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?
"Use this tool to archive a card without deleting it" provides clear context on when to use this tool versus deleting a card. It implies that deletion is the alternative but doesn't explicitly name other alternatives or mention 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.
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. It only states the creation action without mentioning defaults (e.g., defaultLists, defaultLabels, prefs_permissionLevel), permissions needed, or what the response is. This is a significant gap 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?
Two short sentences, front-loaded with the action. Every word earns its place, with no redundant or filler content.
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?
The tool has 18 parameters with 8 enums, but the description provides no guidance on complex features like copying from a source board (idBoardSource), enabling power-ups, or setting permissions. There is no output schema, and the description does not explain return values, leaving the agent without critical context for a non-trivial 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 baseline is 3. The description mentions 'specified properties' but adds no specific parameter meaning beyond what the schema already documents. It does not compensate for or enhance the parameter 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 function: 'Create a new board with the specified properties.' It uses a specific verb and resource, and the phrase 'add a new board to Trello' distinguishes it from update/delete/get board siblings.
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 'Use this tool when you need to add a new board to Trello,' which provides clear usage guidance. However, it does not mention exclusions or alternatives, but for a create operation the context is fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and the verb 'create' transparently indicates a write operation that produces a new list. It does not disclose failure conditions, permission requirements, or response details, but for a simple creation action this is minimally adequate.
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 short and front-loaded, with the core action in the first sentence. The second sentence is largely redundant with the first, making it slightly less concise than it could be.
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 is adequate for basic tool selection but lacks operational specifics such as return values, default position, or board-validity expectations. The schema covers parameters well, and the absence of an output schema heightens the need for more context, but the tool is simple enough that this is a reasonable minimal 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%, with every parameter ('name', 'idBoard', 'pos', 'fields', 'detailLevel') having a clear description. The tool description itself adds no parameter-level detail, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new list on a board' with a specific verb and resource, making the tool's function clear. It does not explicitly mention alternatives, but 'list on a board' distinguishes it from sibling tools like create_board and create_card.
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 'Use this tool when you need to add a new list to a board' provides a direct when-to-use instruction. However, it does not include when-not-to-use conditions or point to alternative tools, 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.
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. It only restates the purpose without disclosing any behavioral traits such as response format, permissions, or side effects. For a read operation, this is minimally informative.
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 two sentences long and front-loaded with the core purpose. The second sentence is redundant ('Use this tool to see the labels applied to a card' repeats the first), but overall it is efficient and not wasteful.
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?
Given the tool's simplicity and the absence of an output schema, the description is minimal but adequate. It does not clarify what label fields are returned or how the generic parameters apply to this specific operation, which is a clear gap for a 5-parameter 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 100%, so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already documents. The generic parameters like fields, maxItems, summarize, and detailLevel are already described in 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 'Get all labels on a card', which uses a specific verb and resource. It distinguishes from sibling tools like get_label (single label) and get_board_labels (board-level labels).
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 'Use this tool to see the labels applied to a card' provides clear context for when to use it. However, it does not explicitly mention alternatives or situations to avoid this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It merely says 'Get all cards in a list' without mentioning default filter (open), response format, pagination via maxItems, or limitations. The schema details parameters, but the description adds no contextual behavior, making it under-disclosing for a read operation without annotation support.
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, both purposeful. The first states the function, the second gives usage intent. No fluff or redundancy, and the key verb+resource is front-loaded.
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?
With no output schema and no annotations, the description should explain what the tool returns (e.g., an array of card objects) and how parameters like filter or summarize affect outcomes. It only says 'Get all cards' without noting default behavior or response structure, leaving a significant gap for a 6-parameter 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 100%, covering all 6 parameters including listId, filter, fields, detailLevel, maxItems, and summarize. The description adds no parameter-specific semantics beyond 'all cards', so it relies on the schema. The baseline of 3 is appropriate because 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 the tool retrieves all cards in a list, with the additional phrase 'Use this tool to see the contents of a list' reinforcing its purpose. The verb 'get' plus resource 'cards in a list' is specific and distinguishes it from list-level operations like get_list.
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 second sentence provides a clear usage context: 'Use this tool to see the contents of a list.' It implies this is the right tool for inspecting list contents, but does not explicitly mention alternatives or when not to use it. Sibling tools like get_list or get_card are not referenced, so it could be stronger with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It only restates the purpose ('Retrieve information') without explaining return format, error behavior, permissions, or whether the operation is read-only. This is a significant gap for a tool with no annotation support.
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 concise at two sentences and front-loaded with the action. The second sentence adds useful scope context ('another Trello user') but is partly redundant with the first sentence. No wasted words overall.
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 getter tool, the description adequately states purpose and scope, but with no output schema and no annotations, it lacks details on return value structure or possible failure modes. The schema covers parameters, so the description only needs to contextualize usage and behavior, which it does minimally.
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 descriptions cover 100% of parameters, including memberIdOrUsername, fields, and detailLevel. The description adds no new meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Retrieve' and the resource 'member' with clear identifier options ('by ID or username'). It also distinguishes from siblings like get_me by specifying 'another Trello user', making its purpose unambiguous.
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 'Use this to get details about another Trello user' provides clear context for when to use this tool, implying it is not for retrieving the current user. However, it does not explicitly name alternatives like get_me or search_members, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It adds minimal behavioral context beyond stating the function; it doesn't disclose what the response looks like, error behaviors, or authentication requirements. The phrase 'has access to' is vague and could imply the caller's access rather than the member's.
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, front-loaded with the core function. No wasted words.
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, no output schema, and no annotations, the description is thin. It doesn't explain when to use the optional parameters, what the response structure is, or address edge cases like member not found.
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 baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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 'Get boards that a member belongs to', specifying the verb and resource. The phrase 'has access to' adds clarity and distinguishes from sibling tools like get_boards_invited.
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?
'Use this to see what boards a member has access to' provides clear context for when to use. However, it doesn't explicitly mention alternatives or exclusions, such as using get_boards_invited for invited boards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action without revealing side effects (e.g., whether cards within the list move, what happens to list position, required permissions, or reversibility). This is a significant gap for a mutating operation.
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 short sentences with no fluff. It is front-loaded with the action and then gives a brief use case, earning its place in every word.
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?
With no annotations and no output schema, the description should provide more context. It lacks information about expected outcomes, side effects, or prerequisites. For a straightforward move operation it covers the basic action, but it is incomplete given the absent structured safety metadata.
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 schema already documents all parameters. The description does not add extra semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 it moves a list to a different board, using a specific verb ('Move') and resource ('list'). This distinguishes it from sibling tools like 'update_list_position' (which likely moves within a board) and 'move_card_to_list' (which moves cards, not lists).
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 a clear use case ('Use this tool to reorganize lists between boards'), giving context for when to use it. However, it does not explicitly mention exclusions or alternatives, 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.
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. It only states the search action without revealing how matching works (e.g., partial vs. exact), whether results are read-only, or any response format details. This leaves significant behavioral ambiguity for an unannotated 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?
The description is extremely concise, consisting of two sentences that immediately and clearly state the tool's purpose. Every word adds value, with no fluff or redundant information.
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?
Despite having 6 parameters and no output schema, the description only covers the basic search action. It does not explain what the response contains, how the search behaves, or how parameters like fields and detailLevel affect results. This leaves notable gaps in understanding the tool's full behavior.
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% parameter descriptions, so the baseline is 3. The description adds no additional parameter-specific meaning beyond what the schema already documents, and it doesn't clarify parameters like limit or detailLevel in the context of member search.
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 the specific verb 'Search' with the resource 'members' and clearly states the search criteria ('by name or username'). This distinguishes it from sibling tools like get_member or get_board_members, which serve different lookup and listing purposes.
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 for when to use the tool: 'Use this to find Trello users by their name or username.' However, it does not explicitly exclude alternatives or mention cases where other tools (e.g., get_member) might be more appropriate, such as when a user ID is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 disclosure. It only lists updatable fields and does not explain behavior such as partial update semantics (whether unspecified fields are preserved), required permissions, or response format. This is a significant gap for an update operation.
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 verb and resource, and contains no redundant information. Every word earns its place.
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?
The tool has 9 parameters and no annotations or output schema. The description only lists the modifiable fields, omitting critical context about partial update behavior, required parameters, or how to remove values (though schema notes null for some fields). It is insufficient for a tool this complex.
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% coverage, so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides; it merely paraphrases the fields without examples or clarifications.
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 ('Update a checkitem on a checklist') and specifies the exact attributes that can be modified (name, state, position, due date, assigned member), distinguishing it from sibling tools like create_checkitem or delete_checkitem.
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 for when to use the tool ('Use this tool to modify...') but does not explicitly mention alternatives or when not to use it. This is adequate but lacks exclusions or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the basic action without disclosing side effects, prerequisites, or edge cases. No information about list visibility, board context, or error behavior is given.
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 short and front-loaded. The second sentence is slightly redundant but adds usage context, making it concise while not wastefully verbose.
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 position-update operation, the description and schema provide the core necessary information. No output schema exists, and the description does not cover return values or error handling, but the tool is straightforward enough that the definition is adequate.
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 all four parameters (listId, position, fields, detailLevel) described in the schema. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('position of a list on a board'), clearly distinguishing it from siblings like update_list or move_list_to_board. The second sentence reinforces the reordering purpose.
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 states 'Use this tool to reorder lists on a board', providing clear when-to-use context. It does not mention alternatives or exclusions, but the stated use is specific enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the basic creation action without mentioning side effects, permissions, idempotency, or return format. For a mutation tool, this is a significant transparency gap.
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 extremely concise—two sentences with no fluff. It front-loads the purpose and immediately gives usage guidance, making every word valuable.
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 tool is simple and has a rich schema, but with no output schema and no annotations, the description should ideally cover return values or behavioral caveats. It provides the core purpose and usage but lacks details on what the response looks like or any side effects.
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 descriptions for all five parameters, so the description doesn't need to add much. The description's reference to 'categorizing cards' gives slight context but doesn't enhance parameter understanding beyond 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 action ('Create a new label on a board') with a specific verb and resource. It distinguishes from sibling tools like create_label_on_card and add_label_to_card by specifying 'on a board' and emphasizing board-level creation.
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 usage context: 'Use this tool when you need to add a new label to a board for categorizing cards.' However, it does not explicitly mention when to use alternatives or when not to use this tool, so it falls 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a safe read via 'Get' but does not disclose response format, pagination, or any side effects. The schema's maxItems and summarize parameters hint at list behavior that the description ignores.
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, direct sentences with no filler. The verb and resource are front-loaded, making the purpose immediately clear.
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 retrieval tool with no output schema and no annotations, the description covers the basic purpose but does not explain how parameters like maxItems, summarize, or detailLevel affect results, nor describe the response shape. It is minimally sufficient but incomplete for complex usage.
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 does not add parameter-specific guidance, but the schema descriptions are detailed (e.g., 'fields' with dot notation). The description's clarification of 'files and links' is not tied to parameters.
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 'Get all attachments on a card' with a specific verb and resource, and further clarifies that attachments are 'files and links attached to a card.' This distinguishes it from sibling tools like add_attachment and delete_attachment.
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 explicit usage context: 'Use this tool to see the files and links attached to a card.' It does not mention alternatives or exclusions, but the sibling list and clear read-only purpose make the appropriate scenario obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparency. It only restates the retrieval action and vague 'comprehensive details' without disclosing response format, potential authentication requirements, or any operational caveats. This is insufficient for a tool that has no output schema to clarify the return value.
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 consists of two concise, front-loaded sentences. The first states the core purpose, and the second adds usage guidance, with no redundant filler or repetition of schema fields.
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 adequately conveys that the tool retrieves a single board's details, which is the core selection context. However, since there is no output schema, the description does not clarify the structure or extent of the returned information, and it lacks any mention of permissions or response shape, leaving some ambiguity for invocation.
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?
With 100% schema description coverage, the input schema already documents boardId, fields, and detailLevel well. The description adds minimal semantic value beyond the schema, only implying that detailLevel affects comprehensiveness. This matches the baseline of 3 where schema handles the parameter documentation.
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 ('retrieve detailed information') and the resource ('a specific board by ID'). It explicitly emphasizes the tool's specificity to a single board, which distinguishes it from siblings like get_boards (plural) and get_board_lists.
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 'Use this when you need comprehensive details about a particular board' provides clear usage context. However, it does not explicitly mention alternatives or when not to use this tool, missing the higher bar of a full when/when-not distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states 'Get members assigned to a card' with no disclosure of return format, pagination behavior, permissions required, or how fields/detailLevel affect results. This is a significant gap for a tool with 5 parameters and rich schema options.
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 primary action, and the second sentence adds practical usage. No wasted words, making it appropriately concise and well-structured.
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 tool with 5 parameters and no output schema, the description is minimal but adequate for a simple getter. It lacks behavioral details like return values or response shape, and does not mention how the various list-related parameters (maxItems, summarize) should be used. However, the schema compensates for parameter semantics, so completeness is borderline adequate.
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 baseline is 3. The description adds no parameter-level meaning beyond what the schema already documents. It does not mention that cardId is required or explain the customization options, but the schema covers them adequately.
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 ('Get') and clear resource ('members assigned to a card'). It distinguishes from sibling tools like get_board_members (board-level) and add_member/remove_member by focusing on retrieval for a specific card. The added purpose ('see who is responsible for a task') clarifies why this tool exists.
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 states a use case ('Use this to see who is responsible for a task'), giving clear context. However, it does not mention alternatives like get_board_members or exclude board-level scenarios, so it stops 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that all comments are returned, without describing ordering, pagination, permissions, or response format. This is a minimal disclosure for a read operation, but it leaves important behavior unstated.
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, front-loaded sentences accomplish the purpose efficiently. Every word adds value, with no wasted content.
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?
While the schema documents parameters well, the description lacks context around the tool's behavior, such as pagination or whether 'all comments' is subject to maxItems. There is no output schema to describe return values, and no annotations to compensate, leaving the agent with an incomplete picture for a 5-parameter 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?
The schema covers all 5 parameters with detailed descriptions, including enum values and nested field behavior. The description adds no additional parameter context, so baseline 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 states a specific action ('Get all comments') and identifies the resource ('a card'), clearly distinguishing it from sibling tools like add_comment or get_attachments. The additional clause about viewing discussion reinforces the purpose.
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 a clear use case ('to see the discussion on a card') but does not explicitly mention alternatives or when not to use it. This gives context without exclusions, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. The description only says 'Get cards assigned to a member' without mentioning response format, pagination, default fields, whether closed boards are included, or any other behavioral nuances. It adds little beyond the 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?
Two short sentences, front-loaded with the core action and purpose. No unnecessary information 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 tool has 5 parameters but only one required, and no output schema. The description explains the high-level purpose but does not clarify the response structure or available options like detailLevel or summarize. Given the richness of the schema, it is somewhat complete but leaves behavioral gaps.
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. The description does not add extra meaning to parameters, only restating 'member' which aligns with memberIdOrUsername. Baseline 3 is appropriate.
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 cards') and the target resource ('assigned to a member'), making it distinct from sibling tools like get_cards_in_list or get_member_boards. The added phrase 'Use this to see what tasks a member is responsible for' reinforces the purpose.
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: 'Use this to see what tasks a member is responsible for.' It implies when to use the tool, though it does not explicitly exclude alternatives or name sibling tools. This is sufficient but not as explicit as naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 clarifies that removing a member means unassigning (not deleting) but does not disclose permissions, reversibility, or error behavior. This is minimal and leaves important context unaddressed.
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 extremely concise at two short sentences, front-loading the action and purpose. Every word serves a function, with no redundant phrases or 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 description covers the core purpose and usage, but lacks information about the response format, edge cases, or required permissions. Given the tool's simplicity and full schema coverage, it is adequate but not thorough.
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 fully describes all four parameters, with 100% coverage. The description adds no additional meaning about parameters, such as edge cases or relationships, so it neither helps nor hurts beyond the schema 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's function with a specific verb ('Remove') and resource ('member from a card'). The second sentence ('unassign someone from a card') reinforces the exact scope, distinguishing it from related tools like add_member or delete_card.
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 explicit guidance to use this tool when unassigning a member from a card ('Use this tool to unassign someone from a card'). While it doesn't mention alternatives or exclusions, the instruction is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the unarchive action without mentioning permissions, side effects on board contents, error conditions, or reversibility. This is minimal 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?
The description is two short sentences with no redundancy. It is front-loaded with the primary action and then provides a usage hint, earning every word's 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 tool is relatively simple with a well-documented schema, but lacks annotations and an output schema. The description covers purpose and usage clearly, but omits behavioral or return details, leaving some gaps in completeness.
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 clear descriptions for boardId, fields, and detailLevel. The description adds no parameter-specific information, but the schema fully documents the semantics, so the baseline 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 action ('Reopen a closed board') and reinforces it with 'unarchive a previously archived board,' giving a specific verb and resource. This distinguishes it from sibling tools like close_board and unarchive_card.
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 instructs when to use the tool ('Use this tool to unarchive a previously archived board'), providing clear context. It doesn't name alternative tools or exclusions, but the context is sufficient for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention that passing null removes the due date, potential overwrite behavior, or response format. No contradiction, but significant behavioral details are missing.
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, front-loaded with the primary action. Every word earns its place, and there is no redundancy or fluff.
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 tool with full schema coverage, the description covers the core function but omits edge cases like null removal and doesn't address response control via fields/detailLevel. Given no output schema and no annotations, it's adequate but not fully complete.
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 baseline is 3. The description adds minimal meaning beyond the schema—'deadline' maps to the 'due' parameter but the optional fields and detailLevel parameters are not explained. It doesn't compensate further, but the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set the due date' on 'a card', and elaborates with 'add or update a deadline'. This specific verb+resource scope distinguishes it from sibling tools like set_due_complete, which handles completion status, and update_card, which is broader.
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: this tool is for adding or updating a card's due date. However, it doesn't explicitly mention when not to use it or suggest alternatives like update_card, leaving some ambiguity for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only restates the action without explaining side effects, reversibility, permission requirements, or how the 'subscribed' parameter toggles state. The description adds minimal insight beyond what the schema already provides.
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, front-loaded with the verb and resource. No redundant or extraneous information; 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?
The tool is simple with a well-described schema, but the description is minimal. It does not mention that subscription is a toggle (though the schema implies it), any prerequisites (e.g., membership), or what the response will contain. While adequate, it could provide more operational 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds no additional parameter context beyond what the schema already provides, and the schema fully explains each parameter including the boolean toggle.
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 ('Subscribe to a list') and its purpose ('receive notifications about changes to a list'). This distinguishes it from sibling list-management tools like update_list or archive_list.
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 a clear use case ('Use this tool to receive notifications'), which serves as guidance for when to use it. It does not mention exclusions or alternatives, but there is no competing subscription tool among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but it only restates the action without revealing side effects, reversibility, permissions, or response format. For a mutation tool, this is a noticeable gap.
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 immediately convey the action and use case. There is no wasted content, and the information is front-loaded for quick parsing.
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 tool is conceptually simple, and the schema is clear, but the description omits any details about expected outcomes, prerequisites, or response behavior. It is minimally viable but leaves gaps around behavioral 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 description coverage is 100%, so the input schema fully documents listId, fields, and detailLevel. The description itself adds no parameter-specific details, but the baseline of 3 applies because the schema handles the load.
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 ('Unarchive a list') and adds a helpful synonym ('restore a previously archived list'), making the purpose unmistakable. It distinguishes this tool from siblings like archive_list by the explicit reversal of archiving.
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 'Use this tool to restore a previously archived list' provides clear context for when to invoke it. It does not explicitly mention alternatives or exclusions, but the intended use case is unambiguous given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It essentially restates the action ('update the position') without disclosing additional traits such as how positions are interpreted, whether the API is idempotent, what the response format is, or any permission requirements. The word 'reorder' adds minimal context but doesn't expose potential side effects or constraints.
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 long, front-loaded with the action and a usage instruction. Every sentence earns its place with 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 description gives the core purpose and when to use it, and the schema handles parameter documentation. However, there is no mention of return values (no output schema exists) or any preconditions, which leaves slight gaps for a tool with no annotations. Still, for a simple update operation, it is reasonably complete.
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 covers 100% of parameters, each with descriptions (e.g., position accepts 'top', 'bottom', or a positive number). The description adds no additional parameter guidance, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'update' with the resource 'position of a checklist on a card', and explicitly states 'Use this tool to reorder checklists on a card.' This clearly differentiates it from sibling tools like update_list_position (which reorders lists) and update_checklist_name (which renames).
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: 'Use this tool to reorder checklists on a card.' This tells the agent when to invoke it. However, it does not explicitly mention alternatives or when not to use it, such as noting that update_list_position handles list reordering, so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It simply says 'Update...' without mentioning side effects, required permissions, response format, or partial-update semantics. For a mutation tool, this is a significant transparency gap.
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 short sentences, front-loaded with the action, and contains no redundant elaboration. It is efficient and easy to parse.
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?
With 8 optional parameters, nested objects, and no annotations or output schema, the description only covers the basic purpose. It doesn't mention return behavior, permission requirements, or partial update semantics. Adequate but with clear gaps.
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% parameter description coverage, so each parameter is well-documented. The tool description itself adds no parameter-level information, but the high schema coverage means the schema carries the weight. Baseline 3 is appropriate.
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 verb 'update' and the resource 'authenticated member's information', then reinforces with 'modify your own profile details'. This distinguishes it from other resource-specific update tools like update_board or update_card.
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 a clear directive to use this tool for modifying one's own profile, giving context for when to use it. It does not explicitly mention alternatives or when-not-to-use scenarios, but the self-scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the operation is archival and non-destructive ('without deleting it'), which is valuable context. However, it does not mention permissions, whether the board can be reopened, or side effects on the board's contents.
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 two sentences and 17 words, with the action stated upfront in 'Close (archive) a board.' The second sentence adds the valuable 'without deleting it' clarification but repeats 'archive,' introducing minor 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?
This is a simple mutation tool with full schema coverage and no output schema. The description covers the core purpose and non-destructive nature, but lacks behavioral details like permissions, side effects, and the reopen path, which is notable given there are no annotations.
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 have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no parameter-specific information, but that is acceptable given the schema already documents each parameter fully.
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 'Close (archive) a board' with a specific verb and resource, and clarifies 'without deleting it,' which distinguishes it from sibling tools like delete_board and archive_card. It unambiguously identifies the action as archiving a board.
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 says 'Use this tool to archive a board without deleting it,' giving clear context for when to use it—when the goal is archival rather than deletion. However, it does not explicitly name alternative tools like delete_board or reopen_board.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral info. It implies a read-only operation ('Get') and adds a small context about access, but it does not disclose response format, pagination, or permissions. This is adequate for a simple read tool but lacks depth.
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 very concise and front-loaded, with no wasted words. The second sentence adds a use case, though it is slightly redundant. It earns its place but could be more informative without becoming verbose.
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 tool is simple, with a fully documented schema, but there is no output schema and no annotations. The description is sufficient for selecting this tool, but it does not explain the response structure or behavior beyond the basic purpose. It is complete enough for a basic get 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 all five parameters are documented. The description adds no additional parameter 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 clearly states the tool's function with a specific verb and resource: 'Get members of a board.' It also adds context with 'Use this to see who has access to a board,' which distinguishes it from sibling tools like get_card_members or get_organization_members.
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 usage context ('Use this to see who has access to a board') but does not explicitly mention alternatives or exclusions. The guideline is simple and direct, though not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 key behavioral trait that it returns pending board invitations (not all boards), which adds value beyond the name. However, it does not explicitly state its read-only nature or other behavioral aspects like authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the purpose front-loaded. The second sentence reinforces the usage context without being overly verbose. It is appropriately sized and well-structured.
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?
This is a simple read tool with no output schema and no annotations. The description gives purpose and usage, but does not describe the return format or behavior of the common list parameters. However, the schema covers all parameters, and the operation is simple enough that the description is minimally complete.
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 does not add any parameter-level meaning beyond what the schema already provides; it merely refers to 'a member' without elaborating on memberIdOrUsername or the common list parameters.
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 clearly states 'Get boards that a member has been invited to' with a specific verb+resource, and adds 'Use this to see pending board invitations', which distinguishes it from sibling tools like get_boards and get_member_boards.
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 context: 'Use this to see pending board invitations.' This tells the agent when to use the tool, though it does not explicitly mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool returns all checkitems, but does not disclose response size, pagination, or how parameters like maxItems or summarize affect behavior. This is a basic read operation, but additional context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence largely restates the first. It is efficient and front-loaded, though slightly redundant.
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 list operation, the description conveys the core functionality. However, with no output schema and no mention of return format, parameter combinations, or list behavior, the completeness is adequate but not robust.
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 each parameter described. The description does not add semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all checkitems on a checklist'), clearly distinguishing it from sibling tools like get_checklist and get_checkitem. The action 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it ('Use this tool to see the items in a checklist'), providing clear context. It doesn't mention exclusions or alternatives, but the context is unambiguous and sufficient for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only says 'Retrieve detailed information', which implies a read operation but does not explicitly state that no changes are made or describe any other behavioral traits like response size or error handling.
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 with no redundant information. It front-loads the core purpose and adds a usage note in the second sentence, making it concise and efficient.
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 relatively simple retrieval tool with no output schema, the description adequately states what it does and when to use it. It does not elaborate on the return structure, but the schema covers parameter details, and the tool's purpose is sufficiently clear.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional meaning about the parameters (e.g., the relationship between fields and detailLevel) beyond what the schema already provides.
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 retrieves detailed information about a specific label by ID, using a specific verb and resource. It distinguishes itself from siblings like get_board_labels by focusing on a single label rather than a board's labels.
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 for when to use the tool ('when you need comprehensive details about a particular label'), which implies a specific use case. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description frames this as a retrieval operation, which is read-only in nature, but does not explicitly state it's non-destructive or address error handling, permissions, or rate limits. Since no annotations are provided, the description carries the full burden, and while 'Retrieve' implies a safe operation, it adds limited behavioral context beyond the obvious.
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 composed of two short sentences and is front-loaded with the action. The second sentence is somewhat redundant with the first but does provide usage context, so there's no significant waste. It is appropriately sized for the tool's simplicity.
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?
This is a simple retrieval tool with no output schema and no annotations. The description covers the purpose and usage but leaves out details like return value shape or behavior when the list does not exist. While the schema fills in parameter details, the description is minimally adequate but not comprehensive.
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 documents all three parameters with descriptions, achieving 100% coverage. The description mentions 'by ID' which matches listId, but does not add meaning to fields or detailLevel parameters beyond what the schema provides. Baseline 3 is appropriate.
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 the verb 'Retrieve' and clearly identifies the resource as 'a specific list' identified by ID. It also says 'detailed information' and 'comprehensive details', making the tool's function unambiguous. While it doesn't explicitly contrast with sibling tools like get_board_lists, the 'by ID' qualifier distinguishes it from list-collection operations.
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 states 'Use this when you need comprehensive details about a particular list,' which is explicit usage guidance. However, it does not mention any alternatives or exclusions, so it only merits a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates the operation is scoped to the 'authenticated member' and uses 'Get' to imply a read-only action. However, it does not disclose whether any side effects occur, permissions required, rate limits, or the scope of notifications (e.g., all boards vs. specific board). For a read operation, this is adequate but minimal.
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 consists of two concise sentences, front-loaded with the verb and resource. It contains zero wasted words and immediately conveys the core purpose and use case.
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?
The tool has 7 parameters and no output schema, yet the description does not explain the return format, default behavior, or what fields are available. It only mentions 'recent activity and updates' without details on pagination, filtering options, or example usage. This under-specification makes it difficult for an agent to fully anticipate the tool's behavior.
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 all 7 parameters having detailed descriptions in the input schema. The tool description adds no additional parameter information. Baseline 3 is appropriate since the schema already provides full semantic 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 tool retrieves notifications for the authenticated member, using the specific verb 'Get' and resource 'notifications'. It distinguishes itself from all sibling tools, none of which handle notifications, and adds the purpose 'to see recent activity and updates.'
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 'Use this to see recent activity and updates' provides explicit context for when to use the tool. However, it does not mention alternatives or when not to use it. Since no sibling tool appears to handle notifications, the lack of exclusions is acceptable, but the guidance could be more explicit about the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing side effects, permissions, or idempotency. The description only says 'Unarchive a card' and 'restore a previously archived card,' which is purely the action itself. It does not reveal whether unarchiving is reversible, if special permissions are required, or what happens if the card is already unarchived. For a mutating operation, this lack of behavioral detail leaves the agent uninformed about potential side effects.
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 exceptionally concise, consisting of two short sentences. The first sentence immediately states the action and resource, while the second adds a brief usage note. There is no filler or unnecessary detail; every word earns its place, 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?
The tool is simple, with three parameters fully described in the schema and a clear action statement. The description adequately tells the agent what the tool does and when to use it. It does not explicitly mention the response format or return value, but given the absence of an output schema and the straightforward nature of the operation, this is not a critical gap. The description is complete enough for the agent to correctly invoke the 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?
The input schema provides 100% coverage of all three parameters, with clear descriptions for 'cardId', 'fields', and 'detailLevel'. The tool description itself adds no parameter-specific insight, but since the schema already fully documents each parameter, the baseline score of 3 applies. The description does not repeat or oversimplify the schema information, which would be redundant.
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 ('Unarchive') and the resource ('a card'), with an added clarification ('restore a previously archived card') that reinforces the purpose. It distinguishes itself from sibling tools like 'archive_card' (the inverse operation) and 'unarchive_list' (different resource) by explicitly naming 'card'.
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 a direct usage instruction: 'Use this tool to restore a previously archived card.' This gives clear context on when to invoke it, though it doesn't explicitly mention what not to use it for or suggest alternatives. The absence of exclusions or alternative tool names is a minor gap, but the context is nevertheless unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does reveal a key non-obvious behavior (labels created this way are not added to the board's label set), which is valuable. However, it does not mention other side effects, permissions, or response behavior, leaving some 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?
The description is two sentences long, front-loaded with the primary action, and contains no redundant or filler content. Every sentence adds value: the first states what it does, the second clarifies the key distinction from related tools.
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 create operation with complete parameter schema, the description covers the core intent and the main behavioral nuance. However, since there is no output schema and no annotations, the description could have mentioned what the tool returns or any prerequisites, making it slightly under-complete for full operational 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?
The input schema has 100% coverage with descriptions for all five parameters, so the baseline is 3. The description adds no additional parameter-specific meaning beyond what the schema already provides, so it neither enhances nor detracts from the schema's clarity.
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 specific action ('Create a new label directly on a card') and distinguishes it from alternatives by noting it does not add the label to the board first. This separates it from tools like create_label or add_label_to_card.
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 states when to use this tool: to add a new label to a card without creating it on the board first. It implies the alternative of first creating a board label, though it does not name sibling tools directly. This provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that deletion is permanent and cannot be undone, which is the critical destructive trait. However, it does not mention side effects like deletion of associated cards/lists or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The key action is front-loaded ('Permanently delete a board') and the warning is secondary. Excellent conciseness.
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 the essential permanent destructive nature, but lacks context about what else is affected (e.g., all cards/lists in the board), the role of the confirm flag, or the alternative of closing a board. Given the schema covers parameters and there is no output schema, this is adequate but not fully complete.
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 baseline is 3. The description adds no additional parameter semantics beyond the schema, but the schema already provides clear descriptions for boardId, confirm, fields, and detailLevel.
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 'delete' and resource 'board', and adds 'Permanently' which clearly distinguishes it from sibling tools like close_board that are non-permanent. The resource and action are 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 implies usage for permanent deletion and includes a cautionary note, but it does not explicitly name alternatives (e.g., 'Use close_board for temporary hiding') or provide when-not-to-use guidance. The usage context is primarily embedded in the word 'Permanently'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does state the core side effect (creating a checklist), which is a mutation. However, it does not disclose permissions, reversibility, or response format. For a simple create tool, this is acceptable but not rich. The description adds the tracking context but lacks deeper behavioral detail.
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 short sentences that immediately state the action and usage context. It is front-loaded with the most important information, and every word earns its place with no redundancy or 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 the simple create operation, the 100% schema coverage, and the presence of sibling tools for context, the description is sufficiently complete. It clearly conveys what the tool does and when to use it. A small gap is the lack of mention of the idChecklistSource copy-from capability, but that is documented in the schema, so this does not significantly detract.
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 all six parameters (pos, name, cardId, fields, detailLevel, idChecklistSource) having descriptions. The tool description does not add further parameter-level meaning, but the baseline for full schema coverage is 3, which is appropriate. The description does not compensate for or extend the schema info.
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 ('Create a new checklist') and the target resource ('on a card'). It also adds purpose ('for tracking subtasks'), which distinguishes it from sibling tools like create_checkitem (which adds items to a checklist) and update_checklist (which modifies an existing checklist).
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 includes explicit guidance: 'Use this tool when you need to add a new checklist to a card for tracking subtasks.' This provides a clear usage context. It does not mention alternatives or exclusions, but the sibling tool list makes the distinction obvious (e.g., create_checkitem for items within a checklist), so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 clearly signals a destructive action via 'Delete' and 'remove,' which tells the agent that this operation is irreversible. However, it lacks additional context such as whether deletion is permanent, permission requirements, or any side effects, so it does not go beyond the obvious.
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 short sentences, front-loaded with the primary action. The second sentence adds useful clarification about files or links, and there is no wasted text. It earns a perfect score for conciseness.
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 delete tool with no output schema, the description is almost complete. It fully clarifies the scope (attachments on cards) and the nature of the action. A minor gap is that it does not hint at the response content or any post-delete behavior, but this is not critical given the simple operation and schema documentation.
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 for all four parameters, so the schema fully documents each parameter. The tool description adds no additional parameter meaning, and per the baseline rule for high schema coverage, a score of 3 is appropriate.
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: 'Delete an attachment from a card' and elaborates with 'remove a file or link from a card.' This is a specific verb+resource combination that leaves no ambiguity about what the tool does, and it is naturally distinct from sibling tools like add_attachment or get_attachments.
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 for when to use the tool: 'Use this tool to remove a file or link from a card.' It does not explicitly mention alternatives or exclusions, but there are no close sibling alternatives for this specific operation, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 disclosing behavioral traits. It clearly states that the deletion is permanent and cannot be undone, which is the most critical safety-relevant behavior for a destructive tool. It does not detail cascading effects or auth requirements, but the core irreversibility warning is well articulated.
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 short sentences with no redundancy. The first sentence gives the action, the second provides a crucial warning. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with a fully described schema and no output schema, the description provides the essential context: permanence and irreversibility. It lacks explicit comparison to archive_card, but the danger of the operation is clearly communicated. Given the tool's simplicity, this is sufficiently complete.
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 for all parameters, so the baseline is 3. The description itself adds no additional meaning beyond the schema; it does not mention the 'confirm' flag or other parameters. Since the schema already documents each parameter clearly, the description does not need to compensate.
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 with a specific verb and resource: 'Permanently delete a card.' It distinguishes itself from sibling tools like archive_card by emphasizing permanence, and from delete_board by specifying 'card' as the target.
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 the warning 'Use this tool with caution as deletion cannot be undone,' but it does not explicitly state when to use delete_card versus alternatives like archive_card. There is no mention of alternative tools or conditions for use, so guidance remains 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses that the output is a URL and implies read-only behavior via 'Get,' but it does not explicitly state that no data is modified, nor does it address permissions or error scenarios. This is adequate but minimal.
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 short sentences, front-loaded with the purpose and immediately clarifying the use case. Every word earns its place with no 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?
For a simple read tool with no output schema, the description covers the essential return value (URL) and scope (authenticated member). It does not elaborate on variations across size/fields/detailLevel, but those are documented in the schema, so the description is reasonably complete.
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 input schema already fully documents all three parameters. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the authenticated member's avatar and specifies it retrieves the profile picture URL. This distinguishes it from sibling tools like get_me or get_member, which return broader member 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 description explicitly says 'Use this to retrieve the profile picture URL,' giving a clear context for when to invoke the tool. However, it does not mention alternatives or exclusions, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It indicates a non-mutating read operation ('get all labels') but does not mention output format, potential pagination, or whether labels include metadata. The description provides basic transparency but misses deeper behavioral details like returned fields or ordering.
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 concise sentences: the first states the action, the second adds usage intent. No redundancy or filler, 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?
For a straightforward read operation with a comprehensive schema (5 parameters, all described), the description sufficiently covers the primary context: what the tool does and when to use it. It lacks explicit mention of return value, but the absence of an output schema and the simple nature of the tool make this acceptable.
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 covers 100% of parameters with descriptions, so the schema already explains each parameter. The description adds no extra parameter guidance beyond what the schema provides, meeting the baseline of 3 without enhancement.
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 'Get all labels on a board' with a specific verb and resource, immediately distinguishing it from sibling tools like get_card_labels or create_label. The phrasing is unambiguous and identifies the exact scope (board-level labels).
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 second sentence, 'Use this tool to see the available labels on a board,' provides clear usage context and implies when to select this tool over alternatives. It lacks explicit exclusions or named alternatives, but the guidance is direct and sufficient for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 transparency burden. It correctly implies a read-only operation, but it states 'Get all lists' while the schema's filter parameter defaults to 'open,' meaning not all lists may be returned. This nuance is not disclosed. The description adds some context ('see the structure') but omits default filter behavior and response shape.
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 with no wasted words. The information is appropriately front-loaded: the first sentence states the core action, the second provides usage context. Extremely 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?
Given the tool's simplicity (no output schema, one required param), the description is adequate. It defines the scope (all lists on a board) and purpose (see structure). It could explicitly mention that it returns lists only, not cards, but the tool name and sibling context make that clear. A minor gap is the lack of reference to get_list for single-list operations, but this does not severely hinder completeness.
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 all six parameters have descriptions. The tool description adds no parameter-specific information beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the full burden.
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+resource pattern: 'Get all lists on a board.' It clearly distinguishes from siblings like get_list (singular list) and get_cards_in_list (cards within a list), and the scope is explicit. This fully clarifies what the tool does.
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 second sentence, 'Use this tool to see the structure of a board and its lists,' provides clear usage context. However, it does not explicitly name alternatives or state when not to use it. Still, the context is sufficient for an agent to infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a safe read-only operation via the verb 'Retrieve', but does not describe output format, possible errors, rate limits, or how detailLevel/fields affect the response. This is a gap, but acceptable for a simple read 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?
The description is two sentences, front-loaded with the verb and resource, with no filler or redundant information. 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?
The tool is a straightforward read operation with fully documented parameters and a clear purpose. The description, combined with the schema, gives the agent enough to select and invoke the tool correctly. The absence of an output schema is a minor gap, but the return value is the card details, which is inferable.
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 all parameters are already well-documented. The description's only param-related phrase, 'by ID', simply restates the cardId parameter. No additional semantic value is added beyond what the schema provides.
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 'Retrieve' and the resource 'specific card by ID', which distinguishes it from sibling tools like get_cards_in_list (which retrieves multiple cards) and update_card (which modifies). This is specific and unambiguous.
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 usage context: 'Use this when you need comprehensive details about a particular card.' It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to select this tool over list-oriented or mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The verb 'Retrieve' implies a read-only operation, but the description does not disclose behavior around missing IDs, auth requirements, or the structure of the response. It adds only minimal context beyond the 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?
Two sentences with no redundant phrasing. It states the action and usage context, earning a top score for conciseness.
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 retrieval tool, the description gives the essential purpose and usage context. The schema covers parameters, and while there is no output schema, the description's reference to 'comprehensive details' gives an idea of the response breadth. It lacks details on error cases or default behavior, but these are not critical given the tool's simplicity.
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 covers 100% of the parameters, and the description does not add any extra meaning beyond stating 'detailed information'. The schema descriptions for fields and detailLevel are sufficient, so the description provides no additional value for parameter semantics.
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 the verb 'Retrieve' and clearly identifies the resource as 'a specific checklist by ID'. It states the purpose is to get 'comprehensive details', which distinguishes it from related tools like get_checkitems or get_checklist_board that focus on other 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?
It explicitly says 'Use this when you need comprehensive details about a particular checklist', providing clear context. However, it does not mention when not to use it or name alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It implies a safe read operation via 'retrieve', but it does not add detail about response structure, default behavior, or any limitations. Given the simplicity of a read-only 'get me' tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and immediately conveying the target user. Every word contributes value with no 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?
For a simple tool with two optional parameters and full schema coverage, the description adequately explains who the tool acts on. While there's no output schema or mention of return values, the description covers the essential context and is unlikely to leave the agent confused about basic usage.
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 'fields' and 'detailLevel' already documented in the schema. The tool description adds no additional parameter 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 retrieves information about the authenticated member/current user, using specific verb+resource. It distinguishes itself from the sibling 'get_member' by explicitly limiting scope to the caller's own account.
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 'Use this to get details about your own account' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusion cases, such as when to use 'get_member' for other users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 accurately describes the read-only nature of the operation but does not elaborate on edge cases such as invalid member IDs, pagination, or default response behavior. This is adequate for a simple read tool but adds minimal value beyond the core function.
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 short sentences with no filler. The second sentence reinforces the first by clarifying the term 'workspaces,' adding value without redundancy. 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 the tool's simplicity and the presence of a fully described schema, the description provides sufficient context for an agent to select and invoke the tool. It could mention that the result is a list, but the name and sibling context already imply that. The description is adequately complete for this complexity level.
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 descriptions for all parameters (100% coverage), so the description does not need to repeat them. The description adds no additional insight into parameter usage or relationships, placing it at the baseline of 3.
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 with a specific verb and resource: 'Get organizations that a member belongs to.' It distinguishes this tool from siblings like get_member_boards and get_member_cards by focusing on organizations/workspaces, making the purpose unmistakable.
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 'Use this to see what workspaces a member is part of' provides a clear context for when to use the tool. However, it does not explicitly exclude alternatives or name sibling tools, so it lacks the explicit when-not-to-use guidance that would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the only behavior (updating state to complete/incomplete) but does not mention any side effects, permissions, reversibility, or response handling. It is adequate but lacks additional context beyond the obvious.
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 concise sentences. The first states the action, and the second reinforces the use case. There is no wasted wording or unnecessary detail.
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 simplicity and the rich input schema, the description provides sufficient context for when and how to use it. It does not describe return values, but with no output schema and a simple state update, this is not a critical 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 covers 100% of parameters with descriptions, including an enum for 'state'. The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a checkitem's state on a card' and specifies the action as 'mark a checkitem as complete or incomplete.' This verb+resource combination is specific and distinguishes this tool from the sibling 'update_checkitem' tool, which likely handles other checkitem properties.
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 includes 'Use this tool to mark a checkitem as complete or incomplete,' which clearly indicates the intended use case. However, it does not explicitly exclude alternatives or mention when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![trello-mcp-server-optimize MCP server](https://glama.ai/mcp/servers/Deepankar1993/trello-mcp-server-optimize/badges/card.svg)](https://glama.ai/mcp/servers/Deepankar1993/trello-mcp-server-optimize)

Score Badge

Copy to your README.md:

[![trello-mcp-server-optimize MCP server](https://glama.ai/mcp/servers/Deepankar1993/trello-mcp-server-optimize/badges/score.svg)](https://glama.ai/mcp/servers/Deepankar1993/trello-mcp-server-optimize)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Deepankar1993/trello-mcp-server-optimize'

If you have feedback or need assistance with the MCP directory API, please join our Discord server