Trello MCP Server

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation4/5
Most tools target a distinct resource and action, and the single vs bulk variants (e.g., add_member_to_card vs bulk_assign_member) are sufficiently distinct in intent. A few close pairs such as list_trello_cards and list_cards_by_due_date could be confused, but descriptions clarify the difference.
Naming Consistency4/5
Tool names follow a mostly consistent verb_noun snake_case pattern and are readable. Minor deviations exist: the Trello prefix appears inconsistently (list_trello_boards vs list_labels), and close_board/archive_card use different verbs for the same archive concept.
Tool Count2/5
45 tools is well above the 25+ threshold and creates navigation overhead for an agent. The bulk-versus-single duplicate pairs inflate the count without adding distinct tool types; the set would benefit from consolidation.
Completeness3/5
Core board/card workflows are well covered, including lifecycle operations, labels, checklists, attachments, membership, due dates, and bulk actions. Obvious gaps remain: labels cannot be deleted, lists have no update/archive operations, and boards lack update/get-detail tools.
Average 3.4/5 across 45 of 45 tools scored. Lowest: 2.6/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
- No stable releases found
- 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

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 states the core action—creating a board—but does not disclose what a successful call returns (board ID, URL), side effects (e.g., Trello's default lists), or failure/error behavior. Since there is also no output schema, the missing return-value information is a significant gap for an agent that would likely chain this with sibling operations.
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 a single short sentence with no wasted words and the core action front-loaded. However, it is concise mainly by omitting information rather than by efficiently packaging a complete message; it borders on under-specification for a tool with two parameters and no other documentation.
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 create tool with no annotations, no output schema, and roughly 40 sibling tools that likely consume its result (e.g., create_trello_list, create_trello_card), the description is incomplete. It omits return values, parameter meaning, and behavioral side effects, leaving the agent unable to reliably chain this tool into downstream operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but both descriptions are tautological placeholders—"Parameter name" and "Parameter desc"—that convey zero semantic meaning. The tool description does not compensate by clarifying that 'name' is the board's title and 'desc' is the board's description, so the baseline-3 assumption that the schema does the heavy lifting does not hold.
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 "Crée un nouveau board Trello" (Creates a new Trello board) states a specific verb and resource, and the word 'nouveau' implicitly distinguishes this from modification tools like close_board, reopen_board, and delete_board. It is clear and functional, but it does not explicitly name a sibling alternative, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many siblings. There is no mention of prerequisites (e.g., needing a workspace), no exclusion conditions, and no reference to alternatives like create_trello_list or list_trello_boards. The agent is left to infer usage entirely from the tool name.
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?
The description only states the action and nothing else. With no annotations provided, the description carries the full burden of behavioral disclosure, but it does not reveal whether the operation is idempotent, what happens if the member is not assigned, or any side effects such as changes to card history.
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 a single concise sentence with no wasted words. However, it is so minimal that it adds little beyond the tool name, making it efficient but not strongly 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?
For a simple tool with no annotations and no output schema, the description is incomplete. It does not explain the operation's effect, any constraints, or when it should be used, so an agent would have to rely almost entirely on the tool name and sibling tools for 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 baseline is 3. The description adds no parameter semantics beyond what the schema already provides; it does not even clarify that cardId identifies the Trello card and memberId identifies the member, though these are inferable from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retire') and resource ('l'assignation d'un membre d'une carte Trello'), clearly indicating the removal of a member assignment from a card. It is distinguishable from siblings like add_member_to_card because it describes the reverse operation.
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 such as bulk_assign_member or add_member_to_card. It does not mention prerequisites like the member needing to be currently assigned, nor any context that would help an agent decide between this and other member-related 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the basic mutation. It does not mention constraints on the color value (Trello accepts a limited palette), behavior on duplicate label names, error conditions, or what the call returns. For a mutating tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single declarative sentence with zero filler, and the core action is front-loaded. It is appropriately sized for a simple creation tool; it loses one point only because the brevity is achieved by omitting useful content rather than by compressing it.
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 3-required-parameter mutation with no output schema and no annotations, the description should supply context on valid inputs, return behavior, and failure cases. It supplies none of these, and the schema's own descriptions are vacuous. The definition is insufficient for an agent to invoke the tool reliably without external domain knowledge about Trello labels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the descriptions are tautological — 'Parameter name', 'Parameter color', 'Parameter boardId (24 characters)' — and add no meaning beyond the key names. The tool description does not compensate: it never explains what valid colors exist, how boardId is obtained, or how name/color relate to Trello's label model. Effective semantic information for the agent is near zero despite the high coverage percentage.
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 'Crée un nouveau label sur un board Trello' uses a specific verb (create), resource (label), and scope (a Trello board). The create verb distinguishes it from sibling tools like update_label, list_labels, and add_label_to_card, so an agent can identify its basic purpose without opening the schema. It stops short of a 5 because it doesn't explicitly contrast itself with any sibling or clarify the label/board relationship beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus update_label, list_labels, or bulk_add_label, and no mention of prerequisites such as an existing board or how to obtain the boardId. An agent is left to infer usage entirely from the tool name and sibling list, with no stated context or 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 of behavioral disclosure, yet it only restates the search action. It does not reveal whether matching is partial (despite a 'partial' parameter), whether boardIds scopes the search, how results are ordered or limited, or what the response looks like — all critical traits for an agent to invoke it correctly.
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?
A single sentence with zero wasted words and the action verb front-loaded. It is efficiently written and easy to parse, though the brevity borders on under-specification rather than disciplined conciseness, since no supporting context follows the core statement.
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 search tool with four semantically meaningful parameters, no annotations, and no output schema, the description is noticeably incomplete. It omits parameter semantics, result-limiting behavior, board scoping, response shape, and differentiation from the many sibling listing/search tools — leaving an agent to guess at essential invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although context reports 100% schema description coverage, every schema description is a tautological placeholder ('Parameter limit', 'Parameter query', etc.) that adds zero meaning. The tool description clarifies only the query parameter (search by name, description, or other criteria) and says nothing about limit, partial, or boardIds — 3 of 4 parameters remain semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource in French — 'Recherche des cartes Trello par nom, description ou autres critères' — clearly identifying a search operation over Trello cards by name, description, or other criteria. It implicitly contrasts with siblings like list_trello_cards and get_card_details through its search framing, but it never names a differentiating sibling, and 'autres critères' leaves the searchable surface vague.
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 choose this tool over its roughly 48 siblings, particularly list_trello_cards, get_card_details, or list_cards_by_due_date. Whether search is the right operation versus listing/browsing cards must be inferred entirely from the word 'Recherche'; no exclusions or alternatives are stated.
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 conveys only that the operation sets a deadline; it says nothing about overwriting an existing due date, accepted datetime formats, timezone handling, or side effects such as clearing a 'complete' flag. For a mutating 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?
A single front-loaded sentence with zero filler; the verb 'Définit' leads and the object is clear. It is efficient and easily parsed, though its terseness edges toward under-specification, which is already penalized in other dimensions.
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 simple two-parameter setter, the description omits the two things an agent needs to invoke it correctly: the dueDate format and overwrite behavior. There is no output schema to clarify the return value, and the description does not connect to the surrounding due-date workflow siblings (remove_card_due_date, mark_due_date_complete, list_cards_by_due_date).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is nominally 100%, both parameter descriptions are vacuous restatements ('Parameter cardId', 'Parameter dueDate'), so the schema does no real work. The description links cardId to the target card and dueDate to a deadline, but it fails to specify the dueDate format (ISO 8601, timestamp, date-only vs datetime), which is essential for a correct invocation.
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 French description states a clear verb-resource pair: 'sets a deadline on a Trello card.' It is not a tautology of the tool name — it adds the Trello card context and glosses 'due date' as 'deadline.' The action is distinguishable from siblings like remove_card_due_date and mark_due_date_complete by its explicit 'sets' semantics.
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 remove_card_due_date, mark_due_date_complete, or list_cards_by_due_date. It also does not clarify behavior when a due date already exists on the card, leaving the agent to guess whether the call overwrites, errors, or requires removal first.
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 behavioral disclosure. It only reveals that the operation adds an item; it does not mention side effects, return values, failure handling, or what happens if the checklist does not exist.
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 with no filler. It communicates the core operation efficiently.
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 mutating tool with no annotations and no output schema, this description is too thin. It lacks behavioral context, alternatives, and prerequisite details, leaving an agent to infer important invocation decisions from the schema and sibling names alone.
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 does not add meaningful detail about pos or checked, though it clarifies that checklistId refers to the target checklist and name refers to the item being added.
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: adding an item to an existing checklist. This is distinguishable from related siblings like add_checklist_to_card or check_checklist_item, though it does not explicitly name them.
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 gives no guidance about when to use this tool versus alternatives such as check_checklist_item or add_checklist_to_card. The word 'existante' implies a prerequisite, but there is no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals only the core mutation and omits critical bulk-operation semantics: partial-failure behavior if some cardIds are invalid, whether the assignment replaces existing members or adds to them, idempotency, and the return value. For a bulk write operation this is a substantial 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 one compact sentence with no filler and is front-loaded with the action verb. It covers the essential semantics efficiently, though the French language choice is slightly incongruous with the English tool names.
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 two-parameter mutation tool with no annotations and no output schema, this definition is minimally adequate: an agent can infer the happy path but gets no guidance on failure semantics, prerequisites, replacement behavior, or return value. It also fails to explicitly route the agent toward add_member_to_card for single-card scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but each parameter description is tautological ('Parameter cardIds', 'Parameter memberId (24 characters)'). The prose adds meaning by clarifying that memberId is the member to assign and cardIds are the target cards, but it provides no additional format or constraint details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Assigne'), a resource (a member), and a target (multiple cards), clearly conveying the bulk assignment operation. The 'à plusieurs cartes en une fois' phrasing implicitly distinguishes it from add_member_to_card, though it does not explicitly name that sibling.
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 prefer this tool over add_member_to_card (single-card assignment), remove_member_from_card, or other member-related siblings. Prerequisites such as the member being a board member or cards being valid are entirely absent, leaving usage context to be inferred from the tool name alone.
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 states the action and that some card components can be kept selectively, but it does not mention what happens to the original card, whether due dates or other fields inherit defaults, or any side effects of duplication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence communicates the core action and key feature with no filler. The 'etc.' is slightly vague but does not hurt the structural 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?
With 11 parameters, no output schema, and no annotations, the description is too thin for an agent to predict invocation results. It does not explain what happens when keep* flags are omitted, what the response contains, or the relationship between required parameters cardId and targetListId beyond their names.
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, so the baseline is 3. The description adds high-level meaning by naming 'attachments, checklists, labels, etc.' as the domains of the selective options, but it does not clarify individual parameter behavior beyond the schema's own descriptions.
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 names a specific verb ('Duplique'), a specific resource ('une carte'), and the selective options that distinguish this tool from a plain create. It is clear, though it does not explicitly contrast it with create_trello_card or another sibling, so it loses the last point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives like create_trello_card, move_trello_card, or copy-like operations. The only usage signal is the implied verb in the name and description, with no exclusions or alternative routing.
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. 'Modifie' implies a destructive/write operation, but the description does not disclose whether the change is reversible, whether the new name fully replaces the old one, any length constraints, or what happens on failure. This is a meaningful 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?
A single compact sentence that conveys the tool's core purpose with zero filler. The verb and object are front-loaded, making it instantly scannable.
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?
There is no output schema, so the description should explain what the agent can expect as a return value, but it does not. It also omits mutation warnings and error behavior. While the parameter set is small and simple, the absence of any behavioral or return-value context leaves the description incomplete for an agent making an actual call.
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. However, the schema descriptions are weak ('Parameter name' is tautological; 'cardId (24 characters)' gives only length). The description adds minimal meaning beyond the schema, merely confirming that 'name' refers to the card's title.
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 'Modifie le nom/titre d'une carte Trello' states a specific verb (modifie) and a precise resource (the name/title of a Trello card). It is unambiguous and implicitly distinct from sibling update_card_description, though it does not name alternatives explicitly.
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 update_card_description, create_trello_card, or other card-modifying siblings. There is no mention of prerequisites (e.g., that the card must exist) or 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 of behavioral disclosure. It states that a new checklist is created, but it does not mention what the response looks like, whether the operation requires special permissions, whether duplicate names are allowed, or how this mutation affects existing checklist data. This is a notable gap for a tool with no safety-related annotations.
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 with no filler. Every word contributes to conveying the core operation, and it is easy to scan quickly.
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 purpose and is adequate for a simple create operation, but it is incomplete in important respects: there is no output schema, yet the description does not mention what is returned; the 'pos' parameter is not explained; and the distinction from add_checklist_item is not made explicit. Given the sibling context and missing annotation support, the description could do more.
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%, but the property descriptions are tautological ('Parameter name', 'Parameter cardId', 'Parameter pos'). The tool description adds only marginal context by indicating the checklist is added to a card and that 'name' is likely the checklist name. Since coverage is high, the baseline is 3, but the description does not meaningfully enrich the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Crée une nouvelle checklist') on a specific resource ('une carte Trello'), so an agent can understand what the tool does. It does not explicitly distinguish itself from the closely related sibling add_checklist_item, though the word 'nouvelle' and the focus on the checklist itself rather than its items make the distinction inferable.
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 gives no explicit guidance on when to use this tool versus alternatives. With siblings like add_checklist_item, check_checklist_item, and delete_checklist present, the description should at least clarify that this tool is for creating a brand-new checklist, not for adding items to an existing one.
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, but it only states the basic action. It does not mention idempotency, duplicate label handling, required label existence, permissions, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It conveys the core purpose efficiently.
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 two-parameter mutation, the description covers the essential action and parameters. However, the lack of output schema and absence of behavioral details or usage guidance leave some gaps for an agent deciding between this and related bulk/removal 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?
The input schema already documents both parameters, so the description adds minimal semantic value. The parameter names 'cardId' and 'labelId' are self-explanatory in context, but the description does not clarify expected formats beyond the schema's brief '24 characters' notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('ajoute') and resource ('un label à une carte Trello'), clearly conveying the action. It is distinguishable from siblings like remove_label_from_card, though it does not explicitly contrast with bulk_add_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as bulk_add_label or remove_label_from_card. The description only states what the tool does, leaving the agent to infer 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?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'list' implies a read-only operation, but the description does not mention whether any filtering or ordering applies, what the return data looks like, or any side effects. For a tool with no output schema, this leaves a notable 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, direct sentence with no redundant words or filler. It is front-loaded with the action and resource, earning its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no annotations and no output schema, this description is minimally viable. It tells the agent what action to perform and on what resource, but it leaves out details about the return format, attachment types, and potential error conditions, which an agent might need for confident 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?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter information. The schema itself only says 'Parameter cardId (24 characters)', which is weak but technically present. The tool description does not clarify the parameter's meaning 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 clearly states a specific action (list) on a specific resource (attachments) scoped to a card, so an agent can understand what the tool does. However, it does not explicitly differentiate itself from sibling attachment tools like add_attachment_url or delete_attachment, though the action verb makes the distinction fairly obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites or context. The intended use case is implied by the verb 'list' and the card scoping, but nothing is stated explicitly.
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 identifies the mutation ('adds') but does not explain side effects, whether setCover replaces the card cover, URL validity requirements, or any permission 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 a single, efficient sentence with no filler. The key information—what action, what resource, and by what method—is front-loaded and immediately understandable.
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 four parameters, no annotations, and no output schema, this description is too sparse. It does not explain the optional parameters, the effect of setCover, or any expected response/result, leaving the agent to infer important calling details.
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 reported as 100%, so the baseline is 3. However, the parameter descriptions are largely tautological ('Parameter url'), and the tool description only meaningfully clarifies the url parameter via 'via URL'; name and setCover semantics remain unexplained.
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 ('Ajoute un attachment'), the target resource ('à une carte'), and the mechanism ('via URL'). This clearly distinguishes it from siblings like list_attachments, delete_attachment, and set_card_cover.
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 about when to use this tool versus alternatives, such as set_card_cover or adding a file attachment. The description implies its purpose but offers no context, exclusions, or conditions.
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 behavioral disclosure burden. It only restates the basic creation action and does not mention side effects, prerequisites, permissions, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler. It earns its place but could be slightly more informative about usage 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?
For a simple create operation with three scalar parameters, the description plus schema is arguably sufficient to invoke the tool. However, with no annotations and no output schema, the agent is left without information about call results, side effects, or when not to use 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?
Schema description coverage is 100%, but the parameter descriptions are placeholders ('Parameter desc', etc.). The tool description adds only a vague hint that listId refers to a Trello list; parameter names like 'name' and 'desc' are self-evident. Baseline 3 applies due to full 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 a specific action ('Crée une nouvelle carte') and its target resource ('dans une list Trello'). This distinguishes it from sibling tools like list_trello_cards, move_trello_card, or archive_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 provided about when to use this tool versus alternatives. Among the many card-related sibling tools, an agent is given no explicit cue for choosing create_trello_card over update_card_name, duplicate_card, or move_trello_card.
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. 'Liste' implies a read-only operation, but nothing is said about edge behavior such as whether archived labels are included, ordering, pagination, or handling of an invalid boardId, leaving behavioral expectations largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It states the operation, resource, and scope efficiently, and every word contributes meaning.
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 low-complexity tool with one parameter, no output schema, and no nested objects, the description is largely sufficient: it states what is listed and on which board. Minor gaps such as no return-format description and no pointer to list_trello_boards for obtaining board IDs are acceptable for such a simple read 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 coverage is 100%, so the baseline is 3. The schema's parameter description ('Parameter boardId (24 characters)') is nearly a tautology, but the tool description's mention of 'board' provides the semantic link that boardId identifies the target Trello board, partially compensating for the weak schema text.
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 ('Liste') and resource ('labels d'un board Trello'), clearly identifying a read operation that fetches labels for a given board. It distinguishes from close siblings like list_trello_lists and list_trello_cards by naming 'labels' as the target resource, though it does not explicitly contrast with them.
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 such as list_trello_lists, create_label, or update_label. With 44 siblings operating on closely related Trello entities, the absence of any routing cue forces the agent to infer usage purely from the name and one-line description.
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 ('reopens an archived board') without covering side effects, permission requirements, idempotency, or behavior if the board is not archived.
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 short sentence with no wasted words, front-loading the core action. This is appropriately concise for a simple one-parameter tool.
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 too sparse. It omits any behavioral context, expected return value, or relationship to sibling operations like close_board and delete_board, leaving an agent without enough information to handle edge cases 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 input schema already documents boardId as a required 24-character string with 100% coverage. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Réouvre') and a specific resource ('un board Trello archivé'), making it clear that this tool reopens an archived board. It is distinct from siblings like close_board and delete_board without needing to read their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as close_board or delete_board. The intended use is only implied by the tool name and the one-line description; no prerequisites or exclusion conditions are provided.
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 restates the core action and gives no details about side effects, whether assigning an already-assigned member is an error or no-op, permission requirements, or what response to expect. This is a meaningful gap for a mutating 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 a single, front-loaded sentence with no filler words or redundant information. It is as concise as possible while still conveying the tool's purpose.
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 two-parameter mutation with no output schema and no annotations, the description is minimally adequate: it states the operation and the schema defines the inputs. But it lacks any behavioral context such as idempotence, duplicate handling, or result format, leaving an agent without full confidence about 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?
Schema coverage is 100%, and both parameters are documented with their types and character-length constraints, so the schema already handles parameter understanding. The description adds no extra semantic detail about what cardId or memberId represent, so the baseline score 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 a clear, specific action: assigning a member to a Trello card. It is immediately understandable and distinct from label-related or list-related tools, but it does not explicitly differentiate itself from closely related siblings such as bulk_assign_member or remove_member_from_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 purpose implicitly tells an agent to use this tool when a single member should be assigned to a single card. However, there is no explicit guidance about when not to use it, no prerequisites, and no mention of alternatives like bulk_assign_member for batch 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 carries the full burden. It does disclose the mutating nature of the operation, but it does not mention permissions, side effects, idempotence, or what happens if the item is already in the requested state. This is comparable to a generic 'update' description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It directly communicates the core action and object. 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?
For a low-complexity tool with a fully documented schema, the description plus schema is mostly sufficient for invoking the tool. However, the lack of any usage context or behavioral notes leaves some completeness gaps, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters adequately. The description adds minimal semantic context by identifying the item as part of a checklist, but it does not meaningfully enrich the parameter meanings 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 states a specific action ('check or uncheck') applied to a specific resource ('an item of a checklist'), which clearly differentiates it from sibling tools like add_checklist_item or delete_checklist. The verb+resource combination 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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no context such as 'use this after adding a checklist item'. Usage must be inferred entirely from the tool name and schema.
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 available, so the description must carry the full burden, but it only states that a new list is created. It does not disclose whether the board must already exist, whether duplicate names are allowed, where the list is positioned, or what the response will be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler words. Every element contributes to communicating the core operation.
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 two-parameter creation tool this is minimally adequate, but with no annotations and no output schema, the description leaves behavioral and response expectations unstated. It would be stronger with a note on what happens after creation or any required preconditions.
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 the parameters. The description adds a little domain context by explaining that a list is a 'column', but it does not add meaningful detail about the boardId or name parameters 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 states a specific verb ('Crée'), a specific resource ('list/colonne'), and its parent context ('sur un board Trello'). It clearly differentiates from sibling tools like create_trello_board and list_trello_lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any exclusions or prerequisites. The intended use is only implied by the tool name and description.
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 burden. It states the mutation but does not disclose side effects, permissions, reversibility, or what happens when only a position change is intended. This is a significant gap for a mutating 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 a single concise sentence that communicates the core operation without redundancy. It is effectively front-loaded and every word contributes meaning.
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 action, this is minimally viable: the operation and parameters are clear. However, with no annotations and no usage guidance, the description leaves out side-effect context and does not help an agent choose between this tool and the related bulk_move_cards sibling.
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 adds some context by linking targetListId to moving lists and position to changing position, but it does not provide details 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 uses a specific verb and resource: it moves a Trello card to another list and/or changes its position. It clearly distinguishes this single-card operation from siblings like bulk_move_cards.
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 implies the tool is for moving a single card, but it gives no explicit guidance on when to prefer it over alternatives such as bulk_move_cards. There are no exclusions or alternative routing cues.
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 communicates the core mutation (removing a label from a card) but does not clarify whether the label itself is deleted, whether the action is reversible, or what happens if the label is not currently on the card.
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 with no filler. It front-loads the action and resource, making it easy to scan and understand quickly.
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 two-parameter operation, the description plus schema is sufficient for basic invocation. However, because there are no annotations and the tool mutates state, more context about side effects, reversibility, or edge cases would make it more 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 both cardId and labelId are already documented with types and length constraints. The description adds no additional parameter meaning, which is acceptable because the schema handles the 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 states a specific action ('Retire' / removes) applied to a specific resource (a label from a Trello card). It is unambiguous and clearly distinct from siblings like add_label_to_card or delete_label, since it scopes the removal to the card-label relationship.
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 about when to use this tool versus alternatives such as add_label_to_card or delete_label. There is no mention of contexts, exclusions, or related operations, so the agent must infer usage from the tool name and siblings.
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 burden of behavioral disclosure. It does reveal that the tool can both set and remove a cover, but it does not explain the side effects, what happens when attachmentId is omitted, or any permissions or reversibility considerations.
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, focused sentence with no filler. It conveys the essential purpose and mechanism efficiently, making it easy for an agent to parse quickly.
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 two-parameter tool, the description covers the core purpose. However, with no annotations and no output schema, it lacks important detail about how the optional attachmentId affects behavior, especially the removal case, which an agent would need to infer.
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 each parameter has at least a basic description. The tool description adds 'via attachment', which hints that attachmentId is the attachment used as the cover, but it does not clarify the conditional semantics of omitting attachmentId. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Définit ou retire') on a specific resource (a card's cover) and identifies the mechanism ('via attachment'). It distinguishes this tool from card attachment tools like add_attachment_url by focusing on the cover concept.
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 gives no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The cover-specific purpose is implied, but there is no direction about when to choose this over related card or attachment 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 carries the full burden of behavioral disclosure. It conveys that the operation is a mutation but does not state whether the update overwrites the entire existing description, whether it is reversible, whether permissions are required, or what the operation returns. The calibration example for update_drive (a mutation with no annotations) received the same score for similar gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero filler. The action verb is front-loaded and the object is precise. There is no waste, and nothing needs to be moved or trimmed.
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 two-parameter tool this is minimally adequate: it states the action and the schema documents both required parameters. However, with no annotations and no output schema, the description leaves meaningful gaps — overwrite semantics, success/error behavior, and return value are all undocumented. It is not incomplete enough to be unusable, but it does not fully equip an 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?
Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter detail. The schema's own descriptions are thin ('Parameter cardId (24 characters)' and 'Parameter description'), but per the rubric, high schema coverage sets the baseline, and the description does not need to compensate. It also does not exceed the schema's contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Met à jour' / updates) and a precise resource ('la description d'une carte Trello existante' / the description of an existing Trello card). This clearly distinguishes it from the closest sibling, update_card_name, which targets a different field, and from create_trello_card, which creates rather than modifies. The word 'existante' usefully signals that the card must already exist.
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. With over 40 sibling tools including update_card_name, add_card_comment, and set_card_cover, an agent receives no routing hints about which mutation to pick for a given card-editing task. The usage context is only weakly implied by the tool's name and purpose.
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 confirms the mutation but never states whether updates are partial (only supplied fields change), what happens with an invalid or nonexistent labelId, idempotency, or what is returned. This mirrors the update_drive calibration case: a mutation tool with zero annotation coverage must say considerably more.
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?
A single front-loaded sentence with zero filler — the verb and object lead and every word earns its place. However, the extreme brevity borders on under-specification for a tool with no annotations and no output schema, so it falls just short of a 5.
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 omits update semantics, error behavior, return format, and routing among siblings like create_label and add_label_to_card. Even at low-to-moderate complexity, a one-sentence purpose statement is not sufficient on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the schema entries are tautological ('Parameter name', 'Parameter color'), so the description does real work: it maps name to the label's display name, color to the label's color, and clarifies via 'et/ou' that the two fields are independently updatable on an existing label identified by labelId. This raises it above 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 states a specific verb ('Modifie'), a resource ('un label existant'), and the exact scope ('nom et/ou couleur'). The word 'existant' cleanly distinguishes it from create_label, and the (name/color) scope separates it from add_label_to_card / remove_label_from_card, which manage card-label relationships rather than label properties.
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 prefer this tool over sibling alternatives: it never mentions create_label for new labels, nor add_label_to_card / remove_label_from_card for card associations, and no prerequisites or exclusions are stated. The only hint is 'et/ou', which implies either field can be updated, but that is parameter semantics, not tool-selection 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 behavioral disclosure burden. It does disclose the core state change and that the action can be reversed by marking as not completed. However, it does not explain behavior when the optional 'complete' parameter is omitted, whether a due date must already exist, or any 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 a single, front-loaded French sentence with no filler. Every word contributes to conveying the purpose and the two possible states.
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 two-parameter mutation tool, the description is mostly adequate, but gaps remain: default behavior for the optional complete parameter is unclear, and there is no mention of prerequisites or failure conditions. The lack of annotations and output schema raises the burden on the description, which it only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the bare schema: 'd'une carte' ties cardId to the card concept, and 'complétée ou non complétée' clarifies that the boolean complete controls the done/un-done state of the due date. This lifts it slightly above baseline.
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 a specific action: marking a card's due date as completed or not completed. It is semantically distinct from sibling tools like set_card_due_date, which changes the date itself, and remove_card_due_date, which removes it. However, it does not explicitly name or contrast these siblings, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related siblings such as set_card_due_date or list_cards_by_due_date. It implies the use case through the wording but does not state prerequisites, exclusions, or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic move action and batching, but does not mention permissions, reversibility, partial-failure behavior, or effects on card positions beyond the optional 'position' parameter.
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 short sentence with no filler. It front-loads the action, object, destination, and batching intent, making it easy to parse quickly.
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 core invocation details are covered by the description and schema: required cardIds and targetListId, plus optional position. However, for a mutating bulk operation with no annotations and no output schema, it lacks behavioral context such as atomicity or what happens to the source lists.
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 applies. The description adds some semantic value by linking 'plusieurs cartes' to cardIds and 'une liste' to targetListId, but it does not clarify the 'position' parameter or enforce the ID format beyond what the schema already states.
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 ('Déplace'), identifies the resource ('plusieurs cartes'), and states the destination ('vers une liste') plus the batching aspect ('en une fois'). This clearly distinguishes it from single-card move_trello_card and bulk_archive_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies the tool is for moving multiple cards in one batch, and the sibling set includes move_trello_card for single-card moves. However, it does not explicitly name alternatives or state when not to use this tool, so the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a read-only listing operation and mentions authentication-dependent accessibility, which is useful. However, it does not mention response format, pagination, inclusion of closed boards, or error behavior, leaving some ambiguity for a tool with zero 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?
The description is a single, concise French sentence with no wasted words. The action ('liste') and scope are front-loaded, making it easy to parse quickly.
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 zero-parameter list tool with no output schema, the description is largely complete: it states what is returned (boards) and the scope (accessible to the authenticated user). It could mention whether closed boards are included or what fields are returned, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description appropriately avoids inventing parameters and does not need to explain any 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 uses a specific verb ('list') and resource ('Trello boards'), and adds the scope 'accessible to the authenticated user'. It clearly states the operation, though it does not explicitly contrast itself with sibling tools like list_trello_lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as search_trello_cards or list_trello_lists. There are no exclusions, prerequisites, or context that would help an agent choose among siblings.
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?
Aucune annotation n'est fournie, donc la description devrait porter la transparence comportementale. Elle ne fait que reformuler l'action « lister » sans préciser le caractère lecture seule, la pagination, les champs retournés, ou le traitement des cartes archivées.
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?
Une seule phrase, directe, sans mot superflu. L'action principale est placée en tête et la portée est immédiatement compréhensible.
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?
L'outil est simple avec un seul paramètre, et le schéma couvre l'entrée. Cependant, sans annotations ni schéma de sortie, la description devrait au moins évoquer le format ou le périmètre des résultats ; elle reste suffisante pour une invocation de base mais pas totalement complète.
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?
La couverture du schéma est de 100 % et listId est déjà décrit dans le schéma. La description ajoute un léger contexte (« liste Trello spécifique ») mais aucune information supplémentaire sur le format ou la signification du paramètre.
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?
La description énonce clairement l'action « liste » et la ressource visée : les cartes d'une liste Trello spécifique. Elle permet de distinguer l'outil de list_trello_boards, list_trello_lists ou list_cards_by_due_date.
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?
Le cas d'usage est implicite : on utilise cet outil lorsqu'on veut les cartes d'une liste précise, via listId. Aucune alternative n'est mentionnée et aucun cas de non-utilisation n'est indiqué.
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. It does disclose the key behavioral trait that archiving is reversible and reopenable, which is valuable. However, it does not describe side effects on board contents, visibility changes, permissions required, or the nature of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler. The primary action is front-loaded, and the reversibility caveat is efficiently placed in parentheses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation with no output schema, the description is largely sufficient. It names the action, identifies the resource, and clarifies reversibility. It could be more complete by explicitly contrasting with delete_board or mentioning effects on cards/lists, but these are not critical 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 baseline is 3. The description does not add any meaning beyond the schema; the parameter description is minimal ('24 characters') but present.
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 'Archiver' on the resource 'board Trello', which is specific and distinguishable from destructive operations like delete_board. The parenthetical 'réversible, peut être réouvert' reinforces that this is not permanent, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool to archive a board with the option to reopen it later. However, there is no explicit guidance on when to choose this over delete_board or reopen_board, and no when-not-to-use conditions.
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, but 'Liste' clearly indicates a read-only operation and 'optionnellement filtrées par board' is an explicit behavioral qualifier. However, it does not disclose pagination, whether archived cards are included, ordering, or response shape, which are relevant for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that leads with the main purpose and tucks the optional filter into a natural clause. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool, the description is mostly complete: it identifies the required member scope and the optional board filter. The absence of an output schema and any description of the returned card fields leaves a small gap, but it is not a major obstacle to invoking 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?
Schema description coverage is 100%, so the schema already names both parameters; the tool description only maps 'un membre' to memberId and 'board' to boardId. The schema descriptions themselves are minimal ('Parameter memberId'), so the tool description adds only slightly to parameter understanding.
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 'Liste' with a clear resource, 'cartes assignées à un membre', and adds an optional board filter. This makes the tool distinguishable from sibling card tools like list_trello_cards or search_trello_cards, which are not scoped to a member's assigned cards.
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 states what the tool does but gives no guidance on when to choose it over alternatives such as list_trello_cards, get_card_details, or search_trello_cards. No conditions, exclusions, or prerequisite steps are mentioned.
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 transparency burden. It implies a read-only operation by using 'Liste' and clarifies that it returns all lists, but it does not address authentication, inclusion of closed/archived lists, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no redundant content. It is appropriately sized for a simple single-parameter listing tool.
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 tool with one well-documented parameter and no output schema, the description is nearly complete: it names the input scope and the expected output concept. It lacks only minor safety and format context, which is less critical for a non-mutating list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains boardId. The description adds only that the board is Trello and specific, which aligns with the parameter but does not provide meaningful additional 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 states a specific action (Liste), the resource (lists/columns), and the scope (specific Trello board). This clearly distinguishes it from siblings like list_trello_boards and create_trello_list.
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 explicit guidance is provided about when to use this tool versus alternatives, or when not to use it. The sibling set contains related board/list tools, but the description does not mention them or any exclusion conditions.
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 correctly conveys that this is a mutating batch operation, but it does not mention idempotency, duplicate-label handling, partial failure behavior, or authorization requirements. The primary side effect is clear, but important behavioral details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and bulk scope immediately, making it easy for an agent to parse and act on.
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 two-parameter mutation, the description plus schema is minimally viable: the agent knows what action is performed and which parameters are required. However, with no annotations and no output schema, batch-operation context such as what happens if a label is already present, validation of labelId, and error behavior is missing.
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%, which sets the baseline at 3. The schema descriptions are tautological ('Parameter cardIds', 'Parameter labelId'), so the description adds little semantic depth beyond the parameter names. It does at least clarify that labels are being applied to cards.
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 verb and resource: 'Ajoute un label à plusieurs cartes en une fois' means 'adds a label to multiple cards at once.' The bulk scope is explicit and distinguishes it from the single-card sibling 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bulk scope is implied by both the tool name and the phrase 'en une fois', so an agent can infer this is for labeling multiple cards in one operation. However, it does not explicitly name alternatives such as add_label_to_card or state when not to use this tool, leaving the routing decision to inference.
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 mentions 'rate limiting' as a behavioral trait, but it does not disclose whether archiving is reversible, how partial failures are handled, what happens when rate limits are hit, or what the response looks like. This is a significant gap for a mutating batch 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 conveys the core operation and adds a relevant note about rate limiting. There is no redundant wording 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 tool is simple with one parameter, and the description states the operation and batch nature. But because there are no annotations and no output schema, missing details about return behavior, error handling, and rate-limit behavior leave the description only minimally viable.
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 only describes cardIds as 'Parameter cardIds', which is uninformative. The tool description adds that these are cards to be archived, but it does not specify the item type, expected ID format, or limits on batch size. With schema coverage marked at 100%, 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 uses a specific verb and resource: 'Archive plusieurs cartes en une fois' clearly states that this tool archives multiple cards in one batch. This distinguishes it from sibling tools like archive_card (single-card archive) and delete_card (deletion rather than 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 'plusieurs cartes en une fois' and 'batch processing' clearly imply this tool is for archiving multiple cards at once, contrasting with single-card archive_card. However, it does not explicitly name the alternative or state when not to use this tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states the operation is reversible and can be undone, which is the key behavioral trait distinguishing archive from delete. It does not mention permissions or side effects, but for a single-parameter archive action, reversibility is the most important behavioral information.
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 entire description is one short, front-loaded sentence that states the operation and its most important qualifier. There is 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?
This is a simple single-parameter tool with no output schema, and the description provides the essential behavioral context: archiving is reversible. It is slightly thin on when to use versus alternatives, but for the operation's complexity, it is mostly 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 cardId parameter is documented in the schema, albeit only as 'Parameter cardId (24 characters)'. The description adds no additional semantic detail about the parameter, but it does not need to given the schema covers 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 names a specific verb ('archive') and a concrete resource ('une carte Trello'), so the operation is immediately identifiable. The parenthetical 'réversible, peut être désarchivée' also distinguishes it from a permanent delete, especially given siblings like 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a soft-delete operation by noting reversibility, but it does not explicitly say when to choose this over delete_card or how it relates to unarchive_card. There is no direct guidance on alternatives or exclusions, leaving the agent to infer usage context.
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 behavioral disclosure burden. It explicitly warns that deletion is permanent and irreversible, which is the most important safety-relevant trait for a destructive tool. It does not mention permissions or side effects beyond deletion, but the irreversibility is clearly communicated.
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, short sentence with the warning front-loaded. Every word adds value, and the parenthetical reinforcement of irreversibility is useful emphasis rather than clutter.
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 two-parameter deletion tool, the description plus schema provides enough to call it correctly: the action, the irreversible nature, and the required identifiers. It could mention how to obtain an attachmentId or any prerequisites, but those are minor gaps given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the parameter descriptions only repeat the parameter names and character length, adding little semantic value. The names cardId and attachmentId are reasonably self-explanatory, and the description does not add extra meaning, 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: 'Supprime définitivement un attachment' (permanently deletes an attachment), naming both the verb and the resource. It also distinguishes this from sibling tools like delete_card and remove_member_from_card by focusing specifically on attachments.
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 about when to use this tool versus alternatives such as list_attachments or add_attachment_url. The irreversible warning implies caution, but there is no explicit context, prerequisite, or exclusion to help an agent decide when deletion 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, the description carries the burden of behavioral disclosure. It usefully reveals that only cards with a due date are returned and that sorting is by soonest due date first. It does not mention read-only nature, pagination, or what card fields are included, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient, front-loaded sentence that states the resource, filter, and sorting behavior with zero filler. The parenthetical clarifies the sort order without adding bulk.
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 single-parameter read-style tool, the description is sufficiently complete: it identifies the board scope, the due-date filter, and the ordering. It does not describe output fields, but this is acceptable given the simple nature of the tool and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents boardId as a 24-character string. The description adds the semantic context that boardId refers to the board whose due-dated cards are listed, but it does not need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Liste'), a specific resource ('cartes d'un board'), and a clear filter ('qui ont une date limite') with sorting behavior. This clearly distinguishes it from sibling tools like list_trello_cards or set_card_due_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when you need a board's due-dated cards ordered by urgency. However, it does not explicitly state when to prefer this over list_trello_cards, search_trello_cards, or get_member_cards, nor does it mention exclusion cases.
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 explaining behavior. It does clearly state the core mutating effect: the card's due date is removed. But it adds no context about permissions, reversibility, idempotency, or what happens if the card has no due date, which would make the behavior more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It states the action and the target resource immediately, making it easy for an agent to parse quickly.
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 one-parameter, atomic mutation with no output schema, the description and schema together provide enough information to call the tool correctly. It could be more complete by mentioning idempotency or no-op behavior, but that is a minor gap 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?
Schema description coverage is 100%, so the schema already documents cardId as a 24-character string. The tool description adds no additional parameter semantics, which is acceptable under the high-coverage baseline but does not improve on 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 uses a precise verb ('Retire') and a clear resource ('la date limite d'une carte Trello'), leaving no ambiguity about what the tool does. It also semantically distinguishes itself from siblings like set_card_due_date and mark_due_date_complete: this tool removes the due date entirely rather than setting or completing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clearly implied: call this when the card's due date should be removed. However, there is no explicit guidance about when to prefer this over set_card_due_date or mark_due_date_complete, nor about edge cases such as calling it on a card that has no due date.
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. It clearly identifies a write operation (adding a comment), but it does not disclose side effects, permissions, reversibility, or result behavior beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the action and target efficiently and 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?
The description is adequate for a simple operation, but given the lack of annotations and output schema, it does not fully explain what happens after the comment is added or any constraints. The two parameters are required and obvious, but an agent might still lack information about response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the schema descriptions are tautological ('Parameter text', 'Parameter cardId'). The tool description indirectly clarifies that text is the comment content and cardId identifies the target Trello card, adding semantic value 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: add a comment to a Trello card. It uses a specific verb ('Ajoute') and a specific resource (commentaire / carte Trello), which distinguishes it from other card-related siblings like add_label_to_card or add_member_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the name and description: to add a comment to a card. However, there is no explicit guidance about when to choose this over alternatives, no exclusions, and no context about required preconditions.
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 and it clearly discloses the destructive, permanent nature of the operation ('SUPPRIME DÉFINITIVEMENT', 'irréversible'). It does not detail side effects like whether checklist items are also removed, but the key behavioral trait of irreversibility is prominently exposed.
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 one compact sentence with no filler; the warning emoji and parenthetical irreversibility note add meaningful emphasis without bloat. It is appropriately sized for a simple one-parameter destructive tool.
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 one-parameter destructive operation with full schema coverage and no output schema, the description conveys the action, target, and irreversibility clearly. It does not mention how to obtain the checklistId or what the response looks like, but these are minor gaps for a simple delete 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?
The schema already provides 100% coverage for the single parameter, including a note about the 24-character format. The description adds no additional parameter-level meaning, 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 states a specific verb ('SUPPRIME DÉFINITIVEMENT' = permanently deletes) and a specific resource ('une checklist'), making the tool's function unmistakable. It also distinguishes itself from sibling delete tools by naming the checklist resource explicitly.
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 resource type—if you need to delete a checklist, this is the tool—but it does not explicitly mention alternatives or exclusion conditions. No guidance is given on when not to use it or when to prefer a sibling delete tool.
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, and it discharges it reasonably: 'Récupère' clearly signals a read-only operation with no side effects, and the parenthetical enumerates the categories of data the caller can expect back. It stops short of describing error behavior for an invalid or nonexistent cardId or the response format, but for a simple get-by-ID fetch the core behavioral disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a parenthetical list of return categories — zero filler, every phrase carries information. The verb and object come first, followed by the detail enumeration, making it immediately scannable for an agent.
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 tool this simple — one required parameter with 100% schema coverage and read-only behavior — the description covers the essential invocation facts: what it fetches and the categories of data returned. The remaining gaps (explicit usage routing, error semantics, and output format given there is no output schema) are minor for a get-by-ID tool but keep it from a 5.
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 single parameter cardId is already fully documented by the schema (type string, 24 characters), so the high-coverage baseline of 3 applies. The description adds no extra parameter context such as where to obtain the cardId (e.g., from list_trello_cards) or an example value, leaving the schema as the only source of parameter meaning.
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 and resource — 'Récupère tous les détails d'une carte' (retrieves all details of a card) — and enumerates the content categories (members, labels, checklists, dates, attachments). This clearly distinguishes it from sibling tools like list_trello_cards or search_trello_cards, which return card lists rather than comprehensive single-card detail.
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 use case is implied: an agent needing full detail on a single card should call this tool. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives — for instance, nothing tells the agent to prefer list_attachments or get_checklist_progress for narrower queries.
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 available, the description carries the behavioral burden. It clearly indicates a read-only operation and describes what the caller gets: progress for all checklists on the card plus detailed statistics. It does not specify the exact statistics shape, but the core behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The action, resource, scope, and expected output type are all communicated efficiently.
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 one-parameter read-only tool with no output schema, the description is largely sufficient: required input is clear and return content is named. It could be improved by specifying the statistics fields or error behavior, but nothing essential blocks correct 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?
Schema description coverage is 100%, so the baseline is 3. The description confirms cardId refers to a card and the scope is that card's checklists, but it adds no format, source, or example beyond the schema's '24 characters' note.
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 ('Récupère'), a clear resource ('la progression de toutes les checklists d'une carte'), and adds a differentiator ('avec statistiques détaillées'). It is clearly distinct from sibling mutation tools like add_checklist_item or check_checklist_item.
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 tool's purpose implies it should be used when retrieving checklist progress, but the description gives no explicit when-to-use/when-not-to-use guidance and names no alternatives. The usage context is inferable but not stated.
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 behavioral disclosure, and it clearly states the exact mutation: `set closed to false`. It does not cover errors, idempotency, or permissions, but for a one-field mutation this is a honest and useful description.
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 with a precise parenthetical clarification. It contains no filler and every part contributes meaning.
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 one-parameter, no-output-schema mutation, the description provides enough information to select and invoke the tool correctly. It could add a note about expected card state or behavior if the card is already unarchived, but it remains largely complete for this simple 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 coverage is 100%, and the schema already documents `cardId` as a 24-character string. The description adds no parameter-level details beyond the operation itself, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation (unarchive) on a specific resource (Trello card), and the parenthetical `set closed to false` makes the exact effect unambiguous. It is the obvious inverse of the sibling `archive_card`, so it is well distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'Désarchive' — an agent should use it when restoring a card from the archive — but the description does not explicitly state the precondition (card is closed/archived) or contrast it with related tools such as `archive_card` or `bulk_archive_cards`.
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?
No annotations are provided, so the description carries the behavioral burden. 'Liste' clearly signals a read-only, non-mutating operation, and 'tous les membres' defines the scope of the result. It does not discuss authentication or member field details, but it avoids implying any 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 a single, front-loaded sentence with no redundant words. It states the action, the target resource, and the output in one line, making it easy for an agent to parse quickly.
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 one required parameter and no output schema, but the phrase 'avec leurs informations' is vague about which member fields are returned. There is no mention of result format or potential edge cases, so the description 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%, and the only parameter is boardId, which is already documented as a 24-character string. The description adds no new parameter semantics beyond the implicit link to the board, 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 ('Liste') and a clear resource ('membres d'un board Trello') with the expected result ('avec leurs informations'). No sibling tool overlaps with listing board members, so the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: call this when you need all members of a board and their details. It does not name alternatives, but no sibling provides the same function, so the context is sufficient and there are no exclusions to state.
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?
No annotations are provided, so the description bears the full disclosure burden, and it leads with the critical fact that the operation is permanent and irreversible. It does not cover permission requirements or what happens to the board's contained cards, but the single most important behavioral trait for a delete operation is prominently and unambiguously disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A compact warning plus one recommendation, with the irreversibility fact front-loaded in the first clause. Every element earns its place: the danger, the consequence, and the safer alternative — zero wasted words.
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 single-parameter destructive tool with no output schema, the description covers what is destroyed, that destruction is permanent, and the safer alternative. Minor gaps remain such as confirmation behavior or error conditions for invalid boardIds, but nothing an agent needs to make the core call-or-don't-call decision is missing.
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 boardId already documented as a 24-character string, so the schema carries the parameter documentation. The description adds no parameter-level detail beyond the schema, which matches the baseline 3 for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'SUPPRIME DÉFINITIVEMENT un board Trello' (permanently deletes a Trello board). The IRRÉVERSIBLE warning and the contrast with close_board distinguish it from the sibling that archives, so an agent can tell exactly what operation this performs and how it differs.
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 recommends the safer alternative: 'archivez d'abord avec close_board', which tells the agent to prefer archival when permanent deletion is not intended. It stops short of stating an explicit exclusion rule like 'use only when permanent removal is required', but the when-to-use context for a destructive tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of disclosure, and it delivers: it flags the operation as permanent and irreversible, the single most critical behavioral trait for a destructive tool, and adds a ⚠️ visual danger cue. There is no contradiction with any annotation.
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 earning their place: the irreversible-danger warning is front-loaded first, and the mitigation advice (archive first) second. The emoji adds a quick visual signal without bulk; zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description covers the essential picture: what it does, that it is irreversible, and the safer sibling. Minor gaps remain — preconditions like board-close permissions, cascade effects on card content, and the response shape are unmentioned — but none are critical for correct 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?
Schema description coverage is 100% — cardId is already documented with its type and 24-character constraint. The description adds no parameter-level detail beyond the schema, 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 states a specific verb and resource — 'SUPPRIME DÉFINITIVEMENT une carte Trello' (permanently deletes a Trello card) — and the (IRRÉVERSIBLE) marker distinguishes it from softer siblings like archive_card. An agent can tell exactly what the tool does and why it differs from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Recommandation: archivez d'abord avec archive_card' explicitly names the alternative tool and directs the agent toward the safer default, implying delete is only for cases where permanent removal is intended. This is direct when-to-use routing with an explicit sibling reference.
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 MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/JulianKerignard/Trello_MCP/badges/card.svg)](https://glama.ai/mcp/servers/JulianKerignard/Trello_MCP)

Score Badge

Copy to your README.md:

[![Trello MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/JulianKerignard/Trello_MCP/badges/score.svg)](https://glama.ai/mcp/servers/JulianKerignard/Trello_MCP)