Trello MCP Server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation4/5
Most tools target a distinct resource and action, and descriptions clarify intent. Some overlap exists among board-listing tools (list_boards, get_member_boards, get_organization_boards) and card-listing tools (get_board_cards, get_list), but the scopes are explained well enough to avoid frequent misselection.
Naming Consistency4/5
The dominant verb_noun pattern is consistent and readable, e.g., get_board_lists, create_card, update_list, delete_comment. Minor deviations like add_member_to_card vs remove_board_member, and list_attachments vs get_board_actions, introduce slight inconsistency but do not seriously undermine predictability.
Tool Count1/5
With 73 tools, this is an extremely large surface area for an MCP server, exceeding the 50+ threshold for a severe mismatch. While Trello is a broad domain, this many tools creates navigation and selection overhead, and many operations could be consolidated or split into separate focused servers.
Completeness4/5
The tool set covers nearly the full lifecycle for boards, lists, cards, comments, checklists, labels, attachments, members, organizations, custom fields, webhooks, and notifications. Minor gaps exist, such as no organization deletion, no custom-field definition update, and no single notification read, but agents can work around these.
Average 3.5/5 across 73 of 73 tools scored. Lowest: 2.9/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 is passing
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 clarifies that the label must already exist and that the operation is additive, but it does not state whether the operation is idempotent, what happens if the label is already on the card, whether board membership is required, or what response is returned.
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, direct sentence with no filler, and the core action is front-loaded. However, it is so terse that it omits useful usage and behavioral context, so it is not a perfect conciseness score.
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 full schema coverage provide enough to identify the call. However, with no annotations and no output schema, the agent is left without information about side effects, idempotency, or expected response behavior, making it minimally sufficient rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents cardId and labelId. The description adds slight nuance by specifying that the label must be an existing label, but it largely repeats what the schema already conveys.
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 ('Add') with a clear object ('existing label') and target resource ('card'), and the qualifier 'existing' implicitly distinguishes it from create_label. However, it does not explicitly differentiate from sibling tools like remove_label_from_card or create_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 given about when to use this tool versus alternatives. It does not mention that the label must already exist, that the label likely belongs to the same board, or that removal is handled by remove_label_from_card. The agent must infer usage from the tool name and sibling list.
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 burden of behavioral disclosure. It indicates the operation is an assignment, but it does not mention side effects, idempotency, what happens if the member is already assigned, required permissions, or any impact on card membership state.
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, clear sentence with no filler. It is appropriately brief for a simple two-parameter operation, though the wording largely repeats the tool name and title rather than adding substantial new information.
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 two fully documented parameters, the description is minimally adequate for invoking the tool. However, it lacks usage guidance, behavioral detail, and any indication of return value, which leaves the agent with a plausible but incomplete understanding of the 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 input schema fully documents both 'cardId' and 'memberId'. The description adds no additional semantic detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Assign a member to a card.' It clearly conveys the core action and aligns with the tool name, making the purpose immediately understandable. It does not explicitly distinguish itself from sibling tools like 'add_board_member' or 'remove_member_from_card', but the member-to-card resource relationship is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as 'remove_member_from_card' or 'add_board_member'. It simply restates the action without situational context, preconditions, 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?
With no annotations, the description must carry full behavioral disclosure. It conveys that the tool mutates state (archives/closes a list) but does not disclose side effects, such as what happens to cards in the list, whether the action is reversible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and the core action is front-loaded. It is appropriately terse for a simple one-parameter tool, though it could have included a brief usage note 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 one-parameter mutation with no output schema and no annotations, the description reaches minimum viability: it identifies the operation and the required ID. However, it omits behavioral context such as side effects on contained cards and reversibility, which would make an agent's invocation fully informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the listId parameter already has a clear description, so the tool description adds no new parameter detail. Baseline of 3 applies because the schema does the documentation work; no format or source guidance is provided.
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 ('Archive (close)') and a resource ('a Trello list'), making the operation identifiable. It differentiates from archive_card by naming the list as target, though it does not explicitly contrast with sibling tools like unarchive_list or archive_all_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 provides no guidance on when to choose this tool over alternatives; it only defines the action. An agent is not told to use it when wanting to close a list, nor to avoid it if they want to archive cards or restore a list via unarchive_list.
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. 'Create' implies mutation, but nothing else is disclosed: no default position behavior when pos is omitted, no mention of the response (the created card object), and no note about reversibility or prerequisites. For a write operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single nine-word sentence with zero filler. The verb and destination are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must carry the operational context, but it only names the action. Missing: what the call returns (the created card with its new ID), how to discover the required idList, and default behavior when optional fields like pos or due are omitted. A 7-parameter tool with no safety net needs more than one clause.
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 phrase 'on a Trello list' adds a mild contextual anchor aligning with the idList property, but the description contributes no parameter-level meaning beyond what the schema already documents.
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?
States a specific verb ('create'), resource ('card'), and destination ('on a Trello list'), which matches the required idList parameter. It is clear and unambiguous, but it does not actively differentiate itself from siblings like create_checklist or update_card — that differentiation is carried by the tool name rather than the description.
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 its 78 siblings, and no prerequisites are stated — an agent must infer that a valid list ID needs to be obtained first (e.g., via get_board_lists) before calling. The only usage signal is the verb 'create,' leaving the when-and-how decision entirely 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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says 'Delete a webhook,' which conveys destruction but does not disclose whether deletion is permanent, whether it affects active triggers, whether it requires specific permissions, or whether it is idempotent. The description adds no meaningful detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy and is front-loaded with the action. However, it is terse to the point of adding little value beyond the title, so it does not earn a 5.
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 single-parameter delete operation with no output schema, the description is minimally viable: the target and action are clear. It omits relevant context such as irreversibility and permission requirements, which matter for a destructive tool, but the simplicity of the operation partly compensates for that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the webhookId parameter is already documented in the input schema as 'The ID of the webhook to delete.' The description adds no parameter-level 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (delete) and resource (webhook) with a clear verb+noun structure. It distinguishes itself from sibling webhook tools (create_webhook, get_webhook, update_webhook) through its deletion verb, though it relies on the tool name for that 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?
No guidance is provided about when to use this tool versus alternatives like get_webhook or update_webhook. There are no prerequisites, no mention of when deletion is appropriate, and no warnings about consequences. The agent must infer usage solely from the sibling names.
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 must disclose behavioral traits, but it only says 'Get all lists' without noting that the default filter is 'open' (so closed lists are excluded unless filter=closed/all). This can mislead an agent into expecting all lists to be returned by default.
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 communicates the core action 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?
Given no output schema and no annotations, the description is too thin. It omits the filter default behavior, does not indicate return format, and lacks context about filter values, leaving an incomplete picture for 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?
The input schema already provides full descriptions for both parameters (boardId and filter with default), so the description adds no extra parameter semantics. The baseline of 3 applies due to the high schema coverage.
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 the specific verb 'Get' and identifies the resource as 'all lists on a Trello board.' This clearly distinguishes it from sibling tools like get_board_cards or get_list, though it does not explicitly name alternatives.
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. There is no mention of get_list for a single list, get_board_cards for cards, or any exclusionary context. The intended use is only implied by the statement.
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 hints at read-only behavior via the verb 'get' and adds the term 'activity feed' as context, but says nothing about pagination, default limits, sorting, authentication, or what the returned actions look like.
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 tight sentence with zero filler and the key scoping information ('for a card') front-loaded. Efficient, though it errs on the side of under-specification rather than being a fully informative concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should state what the agent receives (list of action objects), the default behavior (limit 50), and any caveats about filtering or ordering. None of this is present; the schema carries the only substantive detail.
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 well (default/max for limit, comma-separated filter with example). The description adds no additional parameter meaning, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('the activity feed (actions) for a card'). It implicitly distinguishes from the sibling get_board_actions by scoping to a card, though it never names that alternative 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 alternatives such as get_board_actions or get_card. There are no context cues, prerequisites, or exclusion criteria, leaving the agent to infer appropriate usage 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 fails to state what happens to the cards within the moved list, whether the operation affects the source board, how position is determined, or any side effects. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words, and the key action is front-loaded. However, it overlaps heavily with the title and earns only partial credit for the 'different' nuance it adds.
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 under-specified. It does not disclose side effects on cards, success/failure behavior, or whether the move is reversible. An agent would need to infer the semantics of moving a list from external knowledge rather than from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both listId and boardId already documented clearly in the schema. The description adds only the nuance that the destination is 'a different board,' which is marginal. Since the schema does the heavy lifting, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (move), resource (list), and destination (a different board), making the core operation clear. It is distinct from move_card and move_all_cards at a glance, though it doesn't explicitly name those siblings. The description adds only marginal meaning beyond the title.
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 move_all_cards, archive_list, or update_list. There is no mention of prerequisites (e.g., permission on both boards), no exclusions, and no stated conditions that would route an agent to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing beyond the action itself. It fails to state whether the label is preserved for other cards or deleted, whether the operation is idempotent, what happens if the label is not on the card, or what the return value is. For a mutation-like tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no filler, and the core operation is stated up front. It is appropriately sized for a two-parameter tool, though it sacrifices the chance to add a brief behavioral clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single-sentence description, the agent is left without clarity on side effects, idempotency, permissions, and error behavior. A short clause noting that the label itself remains intact on the board would materially complete the definition.
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 clear descriptions for both cardId ('The ID of the card') and labelId ('The ID of the label to remove'). The description text adds no parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a label from a card.' uses a specific verb, resource, and target, clearly conveying a relationship-removal operation rather than a creation or update. It is easily distinguished from add_label_to_card, but it does not explicitly differentiate itself from delete_label, where the label entity itself is destroyed, so an agent must infer the distinction.
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 siblings such as add_label_to_card or delete_label. There is no context about prerequisites (e.g., the label must already be attached), conditions favoring an alternative, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that properties are updated. It does not disclose whether updates are partial or full replacements, what the return value is, whether authentication is required, or the side effects of setting due to null or toggling dueComplete. Like the bare update_drive calibration, this is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no filler; the verb and resource are front-loaded and it is easy to scan. It earns its place but borders on under-specification given the absence of annotations, which prevents a 5.
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 6-parameter mutation tool with moderate complexity, the fully documented schema covers the invocation details and the description covers the core operation, making this minimally viable. However, with no annotations and no output schema, the description omits return-value behavior and partial-update semantics, which an agent needs to correctly handle the response and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters (cardId, name, desc, due, pos, dueComplete) already carry meaningful descriptions such as Due date (ISO 8601) or null to remove and New name for the card. The description adds no parameter-specific detail beyond the generic word properties, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Update) and resource (existing Trello card), clearly framing the operation as in-place property modification. This separates it from siblings with different verbs like create_card, archive_card, and delete_card. However, it does not explicitly differentiate from move_card, which also mutates a card property (pos), and it leaves which properties are covered to inference.
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 move_card (position changes), update_board (board-level updates), or archive_card/unarchive_card (state changes). There are no prerequisites, exclusions, or explicit conditions for selection, leaving the agent to infer usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It confirms mutation and implies partial-update semantics by listing 'name or position' as independently updatable, but it does not clarify position semantics (what 'top'/'bottom' are relative to), error conditions, permissions needed, or what the tool returns.
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 sentence with zero filler, front-loaded with the action and resource. For a tool this simple with fully documented parameters, the brevity is appropriate rather than under-specified.
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 thin: it does not explain return values, position semantics, or prerequisite/error behavior. The agent must infer the expected behavior of the pos parameter and the outcome of the update from the schema 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 coverage is 100%, so the schema already documents all three parameters (checklistId, name, pos). The description's 'name or position' loosely maps to the name and pos properties but adds no format, constraints, or semantic detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update'), a specific resource ('a checklist'), and a concrete scope ('name or position'). The field scope helps distinguish it from update_checklist_item, which operates on item-level attributes, but the differentiation is implicit rather than explicit.
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 create_checklist, get_checklist, delete_checklist, or update_checklist_item. There are no mention of conditions, exclusions, or sequencing (e.g., checklist must exist 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 disclose behavioral traits itself. It only says 'Update' and lists some fields, without explaining whether the update is partial or fully replaces existing values, what permissions are required, whether the operation is reversible, or what the response contains.
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 tight, front-loaded sentence with no filler, and the parenthetical '(workspace)' adds useful context. It loses a point because the field list is incomplete and slightly ambiguous regarding 'name' versus 'displayName.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations and no output schema, yet the description says nothing about return values, side effects, or prerequisites. It also omits one of the schema's updatable fields, so while the schema rescues parameter documentation, the overall description is only minimally usable on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters and the baseline is 3. The description adds only a high-level paraphrase of some fields and actually omits 'displayName,' so it does not provide meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Update'), a specific resource ('Trello organization/workspace'), and the targeted fields ('name, description, or website'), making the tool's purpose understandable and distinct from nearby create/get organization tools. However, it omits the 'displayName' field present in the schema and uses 'name' without clarifying that it refers to the URL-friendly short name.
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 about when to choose this tool over alternatives such as create_organization or get_organization. The only signal is the imperative 'Update,' which weakly implies modification of an existing organization, but no prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' implies read-only, but the description says 'all cards' while the schema indicates the default filter is 'visible,' which is a meaningful undisclosed behavior. It also does not mention pagination, rate limits, or the effect of the filter parameter on results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is appropriately sized for a simple read 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?
The schema covers parameters and defaults, and the operation is simple, so the definition is minimally viable. However, there is no usage guidance, no explicit statement of read-only behavior, and no description of the return shape, which leaves some gaps for an agent selecting among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both boardId and filter, including the enum values and default. The description adds no extra meaning beyond naming 'a Trello board,' which is not needed for parameter understanding.
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 and resource: 'Get all cards on a Trello board.' It clearly indicates the operation and resource, and partially distinguishes itself from siblings like get_card and get_member_cards by scoping to a board. However, it does not explicitly contrast with any sibling tool.
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 on when to use this tool versus alternatives such as get_card, get_member_cards, or get_board_lists. There is no mention of exclusions, prerequisites, or contexts where another tool would be more appropriate.
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 present, the description must carry the behavioral transparency burden. It only says 'get' and 'authenticated user'; it does not disclose whether fetching notifications affects read state, how results are ordered, or what the response looks like.
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. The verb and resource are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with optional parameters, the description is minimally adequate. However, with no output schema and no annotations, it leaves behavioral details (e.g., read-state side effects, response format) unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both limit and readFilter. The description adds no parameter-level meaning, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('notifications'), and clarifies the scope to the authenticated user. It clearly identifies what the tool does, though it does not explicitly contrast with sibling mark_all_notifications_read.
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 on when to use this tool versus alternatives. While mark_all_notifications_read is a related sibling, the description provides no explicit routing 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 only states the action and does not disclose permanence, side effects, permission requirements, or whether removing a board member also affects their cards. For a mutation tool, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately compact for a simple two-parameter operation, though it lacks any helpful structure such as scoping or alternative routing.
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 minimally adequate but incomplete. It tells the agent what action to take but not the behavioral context, such as irreversibility, error conditions, or relationship to the remove_member_from_card sibling 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 input schema covers both parameters with clear descriptions at 100% coverage, so the description does not need to explain them. However, the description adds no additional meaning about how boardId and memberId relate 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 clearly states the action (remove) and the specific resource (a member from a board). It is distinct from sibling tools like add_board_member and remove_member_from_card, so an agent can identify what this tool does without opening the schema.
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 on when to use this tool versus alternatives, nor does it mention prerequisites such as the member needing to already belong to the board. There is no exclusions or context 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 basic operation and does not disclose behavior such as partial vs. exact matching, case sensitivity, pagination, default or maximum result counts, whether boardId and organizationId can be combined, or what happens when no results are found.
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, compact sentence with no filler words or redundant information. It is well-structured and front-loaded with the core purpose, though it is also somewhat underspecified in terms of behavioral detail.
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 parameters, no annotations, and no output schema, this description is too minimal. An agent would not know what the response looks like, how results are ordered, whether the search is fuzzy, or how the optional board/organization filters affect behavior. This leaves significant gaps for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no new meaning beyond what the schema provides; the query field's parenthetical '(name, username, or email)' already appears in the schema description.
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 verb and resource: 'Search for Trello members' and specifies the search dimensions (name, username, or email). It is understandable on its own, though it does not explicitly differentiate itself from related member lookup tools like get_member, get_board_members, or get_organization_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to find Trello members by matching name, username, or email. However, it gives no explicit guidance about when to prefer this over alternatives like search, get_member, get_board_members, or get_organization_members, and it does not mention any 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 provided, so the description carries the full behavioral disclosure burden. It only states the basic effect of adding an item and does not mention permissions, failure behavior, default item placement, or return values.
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. It front-loads the action and resource, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complete parameter schema coverage, the overall tool context is thin: no annotations, no output schema, and no mention of default behavior for optional parameters like 'pos' or error conditions. An agent could invoke the tool with required parameters but would lack important behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents all four parameters. The description adds no additional semantic detail beyond what the schema provides, so it sits at the 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 states a specific action and object: 'Add an item to an existing checklist.' It is not a tautology and clearly conveys the tool's intent, though it does not explicitly name or differentiate from 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?
The phrase 'existing checklist' implies a prerequisite and situates this as an add operation rather than a create or update operation. However, there is no explicit guidance about when to prefer this over alternatives like create_checklist or update_checklist_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply states the action without explaining side effects, reversibility, or consequences such as the card being hidden from boards. With no annotations provided, the description carries the full burden of behavioral disclosure and does not meet it.
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 clear sentence with no wasted words. It is appropriately sized for a simple tool, though it slightly under-specifies behavioral context.
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 tool with a fully documented schema, the description is minimally sufficient to invoke the tool correctly. However, the lack of annotations and any mention of reversibility or relationship to unarchive_card leaves the context somewhat thin.
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 cardId parameter is already documented as 'The ID of the card to archive'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Archive') and a clear resource ('a Trello card'), and the parenthetical '(close)' adds useful clarification. It is immediately distinct from siblings like delete_card and unarchive_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 archive a card versus using related tools such as delete_card, move_card, or unarchive_card. The intended context is only implied by the tool name and description, not 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses only that an organization is created, but says nothing about permissions, side effects, idempotency, naming behavior, or response format. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundant clauses. The parenthetical 'workspace' adds useful context, but the description largely reinforces the title without adding much new information.
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, all 4 parameters are fully documented in the schema, and there is no nested complexity or required output schema. However, with no annotations and no behavioral or usage context, an agent has to infer important details about permissions and expected outcomes of the creation 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%, and every parameter already has a meaningful schema description. The tool 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?
States a specific action ('Create') and resource ('Trello organization'), with the parenthetical 'workspace' clarifying domain terminology. It is clearly distinguishable from sibling creation tools like create_board and create_card because the resource type 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?
No guidance is given about when to use this tool versus alternatives such as update_organization or get_organization. The word 'new' implies creation, but there are no explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes only what the tool returns (activity feed) but doesn't disclose default behavior (default limit 50 is in schema), pagination, ordering, or whether it's a read-only operation. For a read/list tool this is a moderate gap, not severe, but it adds no behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It earns its place with no fluff. It could add a small usage hint, but as written it's appropriately sized and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 simple parameters, the description is adequate but thin. It clearly states what the tool does and the schema covers parameters, but it leaves out behavioral details like default limit, pagination, and distinction from get_card_actions. For a simple list-type tool this is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no detail about parameters, but the schema already fully documents limit, filter, and boardId. The filter parameter's comma-separated action types are clear from the schema example, so the description doesn't need to compensate.
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 'Get the activity feed (actions) for a board' clearly states a specific verb (get), a resource (board), and the concept of an activity feed. It distinguishes itself from get_board, get_board_lists, etc. However, it doesn't explicitly contrast with get_card_actions, its closest sibling, though the resource scope (board vs card) is implicit.
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: call when you need the activity feed of a board. It doesn't explicitly say when not to use it or mention get_card_actions as an alternative for card-level activity. The schema's filter parameter hints at use cases but the description itself provides no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the mutation and target without explaining side effects, whether duplicate URLs are allowed, or how the attachment is stored/displayed.
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 or redundancy. Every word earns its place in conveying the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with fully documented parameters, the description is minimally viable. However, with no annotations and no output schema, it lacks behavioral caveats and usage context such as duplicate handling or permission requirements.
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 url, name, and cardId. The description adds no additional parameter-level meaning beyond the schema, making the baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add'), a specific resource ('URL attachment'), and a target ('Trello card'), fully identifying the tool's purpose. This clearly distinguishes it from sibling tools such as list_attachments, delete_attachment, and add_comment.
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 like list_attachments or delete_attachment. It also fails to mention any prerequisites, such as card existence or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. While it clearly indicates a mutation ('Add'), it does not disclose whether the member must already exist, how duplicate additions are handled, permission requirements, or any side effects. The phrase 'specified role' also slightly conflicts with the schema's optional type parameter defaulting to 'normal'.
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 action front-loaded and no wasted words. It is immediately parsable and compact, making it ideal for quick agent consumption.
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 three-parameter mutation tool, this is adequate but incomplete. With no annotations and no output schema, it lacks important context such as whether the member must already be a user or organization member, behavior on duplicate membership, and what to expect in the response. These are meaningful gaps for reliable 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 only reinforces that a role can be specified, which the schema already documents; it adds no meaningful detail about boardId or memberId beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a clear resource ('member to a board') and adds role detail ('with a specified role'). It unambiguously distinguishes from the sibling add_member_to_card (board vs card) and directly complements remove_board_member.
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 about when to use this tool versus alternatives. It does not mention that card membership uses a different tool, nor does it state prerequisites or exclusions, leaving the agent to infer usage entirely from the 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 provided, so the description carries the full burden of behavioral disclosure. It states the core mutation but does not mention permissions, reversibility, response behavior, or any side effects beyond 'add a comment'.
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 wasted words. It efficiently conveys the action and the target resource.
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 schema covers the inputs and the description states the operation. However, with no annotations, no output schema, and no usage guidance, some operational context such as return value and permissions remains unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both text and cardId clearly described by the schema. The description adds no new parameter-level 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') with a clear object ('comment') and target ('Trello card'). It clearly distinguishes this tool from siblings like update_comment and delete_comment.
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 update_comment or delete_comment. There are no exclusions, conditions, or context cues beyond the literal action.
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. While 'Create' clearly signals a mutating operation, it does not disclose side effects such as the default creation of lists, whether board ownership or organization context is needed, or what the response contains.
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 wasted words or filler. It is easy to scan and immediately communicates the core operation 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?
The tool is low complexity, the parameters are fully documented, and the purpose is clear enough to recognize when to invoke it. However, with no annotations and no output schema, the agent is left to infer the return value and the default-list side effect, making the description minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents name, desc, and defaultLists with their meanings and defaults. The description adds no parameter-level detail beyond identifying the resource type, which is the baseline expected when the schema is fully descriptive.
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 'Create' and names the exact resource, 'new Trello board', which clearly distinguishes it from sibling tools like create_card, create_list, create_label, and create_organization. It is nearly identical to the title, but the resource specification 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?
There is no guidance on when to use this tool versus alternatives such as create_organization, list_boards, or get_organization_boards. The description states what it does but offers no context about prerequisites, exclusions, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility for disclosing behavior. While 'Delete' conveys that the operation is destructive, it does not mention permanence, irreversibility, permissions, side effects, or whether the operation can be undone.
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 or redundant detail. It is front-loaded with the operative verb and resource, making the tool's purpose immediately scannable.
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, the parameters are fully described, and no output schema exists, but the description omits important context for a destructive operation, such as whether deletion is permanent or requires specific permissions. It is minimally adequate but leaves safety-related details unstated.
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 fully documents both parameters with descriptions ('The ID of the card', 'The ID of the attachment to delete'), so the description adds little beyond restating the card context. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the exact resource ('an attachment from a Trello card'), making the tool's function immediately clear. It also differentiates from sibling tools like add_attachment and list_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 on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The intended use is only implied by the name and short description, with no explicit routing or conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Delete' without disclosing whether the deletion is permanent, whether it has side effects, or what happens to associated data. For a destructive operation, this is 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, efficient sentence with no filler or redundant information. The action is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two well-documented required parameters and no output schema. The description is minimally viable for invoking the tool, but it lacks behavioral context such as return values, irreversibility, or idempotency. Given the absence of annotations, the description is only adequate, not 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 both parameters have clear descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides, 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 ('Delete') and a specific resource ('an item from a checklist'), which clearly distinguishes it from siblings like delete_checklist (which removes an entire checklist). It is direct and not a tautology.
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 on when to use this tool versus alternatives such as update_checklist_item or delete_checklist. It does not mention context, preconditions, or exclusions, so the agent must rely on the 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 explaining behavior. It only says 'delete a comment' and does not disclose irreversibility, side effects, permissions required, or what happens to related data. For a destructive operation this is 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?
A single, clear, front-loaded sentence with no wasted words. It conveys the core action immediately and is appropriately sized for a simple deletion tool.
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 only two parameters and no output schema, so the basic invocation is clear. However, because it is a destructive operation with no annotations, the description should at least signal permanence or side effects to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds no additional meaning beyond 'card' and 'comment action', which is acceptable 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?
States a specific verb ('Delete') and a specific resource ('a comment from a card'). This clearly distinguishes it from related sibling tools like add_comment and update_comment. The description is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as update_comment or remove_label_from_card. There is no mention of prerequisites, permissions, or conditions under which deletion is appropriate.
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 action and gives a parameter hint; it does not mention read-only behavior, default filter behavior, pagination, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The core action is front-loaded and the 'me' usage note is a valuable, compact addition.
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?
Adequate for a simple list-like read tool, but with no output schema and no annotations, the description could usefully state the return shape or default filter behavior. It does not, leaving some ambiguity about what 'all cards' means in practice.
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 both memberId and filter. The description reinforces the 'me' special value, which is already in the schema, adding no meaningful new semantic information.
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 ('Get'), a precise resource ('all cards assigned to a member'), and the member scope. This distinguishes it from sibling tools like get_board_cards or get_card without needing to open 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?
No guidance is given on when to choose this tool over alternatives such as get_board_cards or get_member_boards. The only usage hint ('Use me for the authenticated user') addresses parameter values, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals a read/list operation via 'Get all boards' but does not mention auth requirements, pagination, response shape, or default filter behavior. The description adds little beyond the basic purpose.
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 front-loads the key resource and action, making it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list operation with fully documented parameters, the description is adequate but not rich. It could be more complete by noting read-only behavior, return format, or distinguishing from member-level board retrieval, but the low complexity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters orgId and filter are already fully documented. The description does not add meaningful parameter semantics beyond restating the organization context, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: getting all boards in a Trello organization (workspace). It is concrete and uses the organization scoping to help distinguish it from related board-fetching tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need all boards for an organization. However, it does not explicitly compare against sibling tools like get_member_boards or list_boards, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic mutation but does not mention permissions required, whether card contents like labels and members are preserved, whether the move is reversible, or how position is applied. This is a notable gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It names the action and both possible destinations efficiently, which is appropriately sized for a simple card move tool.
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 schema provides complete parameter documentation, but the description is thin overall. It lacks output expectations, error cases, and any behavioral cautions, and there is no output schema or annotations to compensate. For a low-complexity tool it may barely suffice, but more context would help an agent avoid mistakes when moving cards across boards.
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 fully documents all four parameters. The description adds only a slight clarification that the board change is optional, which is already implied by the schema's 'if moving across boards' note. It provides no meaningful extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('move') on a specific resource ('a card') with explicit destinations: 'to a different list, and optionally to a different board.' This clearly differentiates it from siblings like update_card and archive_card, and the singular 'a card' distinguishes it from move_all_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?
No guidance is given on when to use this tool versus alternatives. It does not mention move_all_cards for bulk moves, move_list_to_board for board-level moves, or any exclusions or prerequisites. The usage context is only implicit in the action described.
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 action. It does not disclose side effects such as reordering impacts, permission requirements, reversibility, or return values. 'Update' implies mutation, but no behavioral detail is provided beyond the stated fields.
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 verb and object, and every word contributes to the core 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 three-parameter update tool with no annotations or output schema, the description is minimally adequate but leaves gaps. It does not explain return behavior, position semantics beyond the schema, or usage context. It is not dangerously incomplete, but it is not richly complete either.
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 listId, name, and pos. The description adds little beyond restating those fields, and the exact semantics of pos (top/bottom versus numeric index) remain ambiguous even with 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 specific verb ('update') and resource ('list'), and narrows the scope to name or position. This distinguishes it from sibling update tools like update_board or update_card, and from list mutations like archive_list or move_list_to_board.
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. It does not mention sibling tools, exclusions, or conditions that would select update_list over other list-related operations. The intended use is only implied by the name and terse 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. 'Create' implies a write operation, but the description does not state whether the operation is idempotent, requires certain permissions, fails if the card does not exist, or has any side effects beyond adding a checklist.
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 action, resource, and target are front-loaded, making it easy for an agent to parse the essential information 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 simple create operation with two well-documented required parameters, no nested objects, and no output schema requirement, the description sufficiently conveys the operation and its target. However, the lack of any behavioral or usage context, given the absence of annotations, is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (name and cardId) are fully described in the input schema (100% coverage), so the baseline is 3. The description adds no additional meaning or usage nuance beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), resource ('checklist'), and target ('on a Trello card'), which clearly distinguishes it from sibling tools like get_checklist, update_checklist, and delete_checklist. It is unambiguous about the operation being performed.
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 such as add_checklist_item or update_checklist. It simply restates the obvious creation operation without any context, conditions, 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 only states that a label is created and gives no information about idempotency, duplicate label behavior, permissions required, side effects, or what happens when invalid data is provided. For a mutation tool with zero annotation coverage, this is a meaningful 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, front-loaded sentence with no filler or repetition. It is appropriately sized for a simple tool, though it could have added a small amount of usage context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully describes its parameters, so an agent can infer the basic call structure. However, because there are no annotations and no output schema, the description leaves out behavioral details like response format, duplicate handling, and permission requirements, making it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (name, color, boardId) and their constraints, including the color enum. The description adds no additional semantic detail beyond what the schema provides, which matches 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 ('create'), a specific resource ('label'), and a clear scope ('on a Trello board'). This clearly distinguishes it from sibling tools like get_label, update_label, delete_label, and add_label_to_card without needing to inspect schemas.
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 the tool should be used when creating a new label on a board, and the verb naturally separates it from label read/update/delete tools. However, it does not explicitly mention when not to use it, what prerequisites exist (e.g., the board must already exist), or any alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses irreversibility via 'Permanently delete', which is a key destructive signal, but it omits consequential side effects such as the removal of all checklist items, which would be important for an agent invoking a destructive 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, information-dense sentence with no wasted words. Permanence, the action, and the object are all front-loaded, making it highly scannable for an agent.
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?
Although the tool is structurally simple (one param, no annotations, no output schema), the description is missing critical context for a destructive operation: it does not mention cascading effects (such as deleting the checklist's items) or any permission/precondition requirements. The bare statement leaves an agent with limited ability to anticipate the full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter checklistId with a clear description. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies since schema coverage is 100%.
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: 'Permanently delete a checklist from a card.' It clearly targets the whole checklist entity, distinguishing it from sibling tools like delete_checklist_item, and provides the card context that anchors the 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?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The distinction from delete_checklist_item is only implied by the name and the word 'checklist', not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It clearly expresses a read-only intent through the verb 'Get', but does not disclose response format, pagination, or potential limitations. This is adequate for a simple read operation but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. The key scope—all members of an organization—is front-loaded and immediately actionable.
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 tool with no output schema and low complexity, the description is nearly complete. It lacks only minor context such as expected return shape or differentiation from board-member lookup, but nothing essential is missing to make a correct 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%, and the schema already documents orgId as 'The ID or name of the organization'. The description adds no additional parameter 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get all') and a clear resource ('members of a Trello organization (workspace)'), so an agent can tell this is an organization-scoped member lookup. It does not explicitly contrast with similar siblings like get_board_members or get_member_organizations, but the org scope 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?
There is no guidance on when to use this tool versus alternatives. With siblings such as get_board_members, get_member_organizations, and search_members, an agent is left to infer the appropriate selection 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 provided, the description carries the full burden of behavioral disclosure. It only restates the core action and gives no information about side effects, reversibility, permission requirements, what happens to archived cards, or the success/failure response. A bulk mutation like 'move all cards' needs more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. Every word earns its place and the core behavior is 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?
This is a bulk mutation with no annotations, no output schema, and no warnings about scale or side effects. An agent would benefit from knowing whether the move is reversible, whether it affects archived cards, or what confirmation/return is expected. The current description is minimal and leaves important operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a clear description (source list, destination board, destination list). The description adds no additional parameter meaning, but the schema sufficiently covers the semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Move'), a specific resource ('all cards'), and the transformation ('from one list to another'). It clearly distinguishes itself from siblings like move_card (single card) and archive_all_cards (archiving instead of moving).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when every card in a source list should be moved to a destination list. However, it does not explicitly mention alternative tools like move_card for individual moves or archive_all_cards for archiving, nor does it state exclusions or preconditions.
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 mentions the Premium/Enterprise requirement but does not disclose what happens on success, whether the operation is reversible, what permissions are needed beyond the plan, or any side effects on the board and its cards. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core action and the key requirement, earning every word.
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 create tool given 100% schema coverage, but it lacks behavioral context such as return value, error conditions, or relationship to other custom-field operations. It meets the minimum viable threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters clearly. The description adds no parameter-level meaning, which is acceptable because the schema covers meaning fully. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a specific resource ('custom field definition on a board'), clearly distinguishing this tool from siblings such as get_custom_field, update_custom_field_item, and delete_custom_field. The scope is explicit and leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Requires Trello Premium or Enterprise' provides a prerequisite but no guidance on when to use this tool versus alternatives. The action phrase 'Create a new custom field definition' implies the use case, but there are no explicit when/when-not conditions or references to related tools like get_board_custom_fields or update_custom_field_item.
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 behavioral disclosure burden. It states the operation is a read/get, which implies no mutation, but it does not mention required authorization, possible 404s, rate limits, or what 'detailed information' actually includes. This is a meaningful gap given the absence of annotation safety signals.
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 clean, front-loaded sentence with no filler. Every word contributes meaning, and the description 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?
Adequate for a simple one-parameter read operation, but with no output schema and no annotations, the description could have specified what fields are returned or how errors are surfaced. It remains usable, but it does not fully cover the context an agent might need.
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 boardId is already described as 'The ID of the board'. The description's 'by its ID' simply reinforces the schema without adding new constraints or format details, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (get), the resource (a specific Trello board), and the lookup key (ID). However, it does not explicitly distinguish board-level data from child resources like get_board_lists or get_board_cards, leaving slight ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the intended use: when you already have a boardId and need board-level details. It does not name alternatives or exclusions such as 'use list_boards to enumerate boards' or 'use get_board_lists for lists', so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It adds useful context about the returned contents, but it does not mention authentication requirements, error behavior, side effects, or response structure. The verb 'Get' implies a read operation, but explicit behavioral detail is limited.
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. The core purpose and key return contents are front-loaded, making it easy for an agent 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 one-parameter tool, the description covers the main purpose and highlights important return fields. However, without annotations or an output schema, it leaves out behavioral details like permissions, error responses, and the full nature of the returned object, so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, cardId, with a clear description. The tool description adds no additional meaning or format guidance beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a specific Trello card'), and names the kind of information returned (checklists, labels, members). This clearly distinguishes it from related tools like get_card_actions, list_attachments, and get_card_custom_fields.
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 use this tool versus alternatives such as get_card_actions or get_card_custom_fields. No exclusions, prerequisites, or context clues are provided, so the agent must infer usage 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.
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 clearly marks this as a read-only retrieval operation, but it does not describe the response format, behavior for an unknown or invalid labelId (e.g., null vs. 404), or any access requirements. These are notable gaps, but the core behavior is unambiguous.
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 or redundancy. The essential scoping detail 'by its ID' is front-loaded, and every word contributes to the 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 one-parameter getter, the description is adequate but minimal. It does not describe the return value or error cases, and since there is no output schema, this information is not provided elsewhere. An agent can invoke the tool correctly but will not know what to expect in the response.
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 fully describes labelId as a required string with the description 'The ID of the label', giving 100% coverage. The description's phrase 'by its ID' only restates this schema information without adding new meaning such as ID format, source, or relationship to other resources.
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 'Get' and resource 'label', scoped by ID, which unambiguously identifies the operation. This distinguishes it from sibling tools like get_board_labels, create_label, update_label, and delete_label, so an agent can select it correctly.
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 such as get_board_labels or search. The description does not mention prerequisites, such as how to obtain a label ID, nor does it state any conditions or exclusions for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the core operation but does not mention potential side effects, whether the operation is idempotent, permission requirements, or what happens if the member is not currently assigned. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero wasted words. It front-loads the verb and direct object, 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.
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 only two well-documented parameters and no output schema, so the basic invocation is covered. However, the description lacks usage guidance and behavioral detail, leaving gaps about when to choose this tool over siblings and what side effects or responses to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for both parameters, so the baseline is 3. The description 'Unassign a member from a card' adds no extra parameter-level meaning; it simply restates the action in terms of the card and member IDs.
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 'Unassign a member from a card' uses a specific verb (unassign) and clearly identifies the resource (member) and context (card). It also distinguishes itself from sibling tools like add_member_to_card and remove_board_member by explicitly stating the scope is a 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?
Usage is implied by the action itself: an agent should use this tool when it wants to unassign a member from a card. However, there is no explicit guidance about when not to use it, nor any mention of alternatives such as add_member_to_card or remove_board_member. The context is clear but exclusions and alternatives are absent.
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 mutation intent and the fields; it does not mention whether the update is partial or full replacement, what happens when 'closed' is set to true, whether background changes require special permissions, or what the response contains. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource, then lists the affected fields. Every word earns its place; there is no filler, repetition, or buried context.
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 5-parameter update tool with no annotations and no output schema, the description is adequate but not complete. The schema covers all parameters, so the agent can construct a valid call, but the description does not clarify update semantics, effects on existing values, or response behavior, which an agent would benefit from knowing.
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 little semantic value beyond the schema. It essentially restates the parameter names ('name', 'description', 'closed', 'background') without offering syntax details, constraints, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Update') with a clear resource ('a board') and enumerates exactly which attributes are affected: name, description, closed status, or background color. This clearly distinguishes it from create_board, delete_board, and other update_* 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?
The description implies when to use this tool: whenever a board's core settings need changing. However, it provides no explicit guidance about when not to use it or which sibling alternative to choose (e.g., update_card, update_list, update_organization), leaving that to the agent's 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 burden of behavioral disclosure. It does reveal the concrete mutation types (state toggle, rename, reposition), which is helpful. However, it does not disclose whether updates are partial, whether multiple fields can be updated at once, permission requirements, reversibility, or what the response contains.
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 a compact parenthetical that lists all supported update modes. There is no redundant wording or unnecessary background information.
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 mutation tool: all parameters are documented in the schema and the description captures the three kinds of updates. However, it lacks usage guidance, behavioral caveats, and any note about return values, which would make it more complete for an agent operating without annotations or 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%, so the baseline is 3. The description adds a useful mapping of operations to parameters (toggle -> state, rename -> name, reposition -> pos), but it does not add meaning beyond what the schema already documents for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a specific resource ('a checklist item') and enumerates the exact operations supported: toggle complete/incomplete, rename, or reposition. This clearly distinguishes it from sibling tools like add_checklist_item, delete_checklist_item, and update_checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to modify an existing checklist item, but it does not explicitly state when to use it versus alternatives such as add_checklist_item for creating items or delete_checklist_item for removing them. No exclusions or decision guidance 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 says 'update the text' and does not mention whether the new text fully replaces the old text, whether the update is reversible, what permissions are required, or what the response looks like.
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 and target resource, making it immediately scannable.
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 three-parameter mutation tool, the description plus full schema coverage is mostly adequate. However, with no annotations and no output schema, it would be stronger if it mentioned that the comment text is fully replaced and how the actionId is obtained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains all three parameters. The description adds no extra semantic detail beyond what the parameter descriptions already provide, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update'), resource ('text of a comment'), and location ('on a card'). This distinguishes it from siblings like add_comment and delete_comment, which have different verbs and purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for editing an existing comment, but it does not explicitly say when to use it versus add_comment or delete_comment. There is no guidance on prerequisites such as needing the card and action IDs from prior API calls.
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 says 'Update a label's name or color', with no mention of whether unspecified fields are preserved, whether the update is partial, what the response looks like, or any permissions/validation requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action, the affected resource, and what can be updated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters, but there are no annotations and no output schema. The description lacks behavioral context and usage guidance, making it minimally adequate but not fully complete for 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 schema fully documents labelId, name, and color. The description mentions 'name or color' but adds no semantic detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a label'), and specifies exactly what can be changed: name or color. This differentiates it from sibling tools like create_label, get_label, and delete_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an existing label's name or color, but it does not explicitly state when to use it instead of create_label or delete_label. There are 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?
With no annotations, the description carries the full behavioral burden. It only lists updatable fields but does not disclose whether updates are partial or full, whether unspecified fields remain unchanged, what validation rules apply, or what the response contains. For a mutating tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. The action and the scope of changes are front-loaded, 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 schema covers parameter meanings well, but the overall definition lacks critical update context: whether calling with only webhookId is valid, whether omitted fields are left untouched, and what the effect of setting active is. The absence of an output schema and annotations further leaves the result and safety profile unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters, including webhookId, active, idModel, callbackURL, and description. The description adds no extra semantic detail beyond that, such as value formats or constraints, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a webhook') and enumerates the specific mutable fields: callback URL, description, model, and active status. This distinguishes it from sibling tools like create_webhook, get_webhook, and delete_webhook without requiring schema inspection.
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 usage is implied by the verb 'update' and the sibling context, but the description provides no explicit guidance on when to use this vs. create_webhook or get_webhook, nor does it mention prerequisites such as the webhook already existing. No alternatives or exclusions 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only restates the creation action implied by the tool name and does not mention permissions, duplicate-name behavior, default position, or what happens after creation.
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 sentence with no filler. The core action and object are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description covers the essential action and target resource, and the schema fully documents the inputs. The lack of an output schema and annotations prevents a perfect score, but nothing critical is missing for basic 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 coverage is 100%, so all three parameters are already described in the input schema. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('a new list'), and a scope ('on a Trello board'). This distinguishes it from siblings like create_board, create_card, and update_list without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need to create a list on a Trello board. However, it gives no explicit guidance about when not to use it or how it compares to alternatives like update_list, archive_list, or move_list_to_board.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It correctly implies a read-only operation but does not mention output format, pagination, permissions, or error behavior. For a simple getter, this is minimally transparent but not richly informative.
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 or redundant wording. The verb and resource are front-loaded, and every word contributes to the 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, read-only tool, the description is essentially complete: it states the resource, the action, and the required input. It lacks an explicit return shape or alternative routing, but the tool's simplicity means nothing critical 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 'The ID of the board.' The description does not need to elaborate on the parameter and does not conflict with the schema; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Get,' and a specific resource, 'all members of a Trello board.' It is clearly distinguished from siblings like get_organization_members because it scopes the operation to a board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over similar member-related tools such as get_organization_members or get_member_boards. The context is only implied by the tool name and phrasing, with no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'Get' implies a read operation, and the phrase 'and its cards' clarifies the response scope. However, it does not mention authentication requirements, potential errors, or any additional behavioral details such as whether the response is nested or includes card fields. It is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The core action, resource, and parameter are front-loaded, and every word contributes to the meaning. It is as concise as possible while remaining informative.
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 read tool, the description covers the essential elements: what the tool does, what it returns, and the input needed. It lacks explicit usage guidance and behavioral caveats, but given the low complexity and rich sibling context (which an agent can infer from), it is nearly complete. A brief note on when to choose this over get_board_lists would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, and the single parameter is documented as 'The ID of the list' in the schema itself. The description repeats the parameter's role without adding extra semantic detail such as the expected format (e.g., Trello's short or full ID), so it does not add value 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 states a specific verb ('Get'), a clear resource ('a Trello list and its cards'), and the identifying parameter ('by list ID'). This clearly distinguishes it from sibling tools like get_board_lists (which retrieves multiple lists per board) and get_card (which retrieves a single card). The scope 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 gives no guidance on when to use this tool versus alternatives. It does not mention that this tool is for retrieving a specific list by ID as opposed to listing all lists on a board, nor does it point to any sibling tools. The usage context is only implied, not stated.
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?
There are no annotations, so the description is the sole source of behavioral context. 'Get' clearly signals a read operation and 'all boards' scopes the results, but the description does not mention authentication needs, default filtering behavior, or any pagination/response details. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the 'Use me' instruction is useful and directly actionable. It is appropriately sized for a tool with only two parameters.
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 read operation with no output schema, the description plus the schema is largely sufficient to invoke the tool correctly. It could strengthen sibling differentiation and mention return format, but no critical information for a basic call 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?
The input schema already documents both parameters with 100% coverage, including the filter enum and the 'me' convention for memberId. The description reinforces the 'me' usage but does not add substantive information 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 the action ('Get') and the specific resource ('all boards a member belongs to'), and it clarifies how to target the authenticated user with 'me'. It does not explicitly distinguish itself from sibling tools like list_boards or get_organization_boards, but the member-scoped purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a direct usage tip for 'me' and implies the tool is for member-scoped board lookups. However, it does not state when to prefer this over alternatives such as list_boards or get_organization_boards, and it provides no exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It conveys a read-only lookup via 'Get information' and hints at an authentication context with 'authenticated user,' but it does not mention required permissions, error behavior, or whether only public fields are returned. This is acceptable for a simple GET but not fully 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 two short, purposeful sentences with no filler or repetition of the title. The core lookup behavior and the 'me' convenience are front-loaded, 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 fully documented parameter, so input side is complete. However, there is no output schema and the phrase 'information about a Trello member' is vague about what fields or shape the response will have, and it does not explicitly clarify that related resources like boards or organizations are excluded. Given the sibling set, a bit more scope clarification would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents memberId with the same meaning: 'The ID or username of the member (use me for yourself).' Because schema description coverage is 100%, the description adds no meaningful parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('information about a Trello member'), and further narrows the operation by saying lookup is by 'ID or username' with 'me' as a self-reference. This clearly distinguishes it from sibling tools that fetch related resources like organizations, cards, boards, or search results.
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 only concrete usage guidance is 'Use me for the authenticated user,' which hints at a relevant scenario. However, the description does not explicitly say when to prefer this tool over search_members or the get_member_* sibling tools, nor does it provide any exclusion criteria. The right usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context itself. It clearly discloses the bulk mutation scope ('all cards in a list'), but it does not mention potential consequences like reversibility, permissions, or that this is a bulk destructive 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 with no filler. Every word contributes to understanding the operation and scope.
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 operation with no output schema, the description is nearly complete: it names the action and the target scope. A small gap is the lack of any statement about return behavior or postconditions, but this is minor 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%: listId is already described as 'The ID of the list'. The tool description adds no additional parameter meaning, 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 ('archive') and a precise resource ('all cards in a list'), making the bulk scope explicit. It is clearly distinguishable from sibling tools like archive_card and archive_list because 'all cards' signals the collective operation.
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: use it when you want to archive every card in a given list. However, it does not explicitly mention alternatives such as archive_card for single-card archiving, nor does it provide exclusion criteria.
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 must bear the full behavioral burden. It discloses irreversibility with 'permanently delete', which is valuable, but it does not mention side effects, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The key behavioral qualifier 'Permanently' is front-loaded, making the destructive nature clear immediately.
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 tool with no output schema, the description is nearly complete: it names the resource, confirms irreversibility, and the schema covers the only parameter. It could be more complete by describing consequences, but nothing necessary for calling 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 coverage is 100%, so the schema already documents labelId. The description adds no parameter-level detail beyond what the schema provides, 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?
States a specific verb ('Permanently delete') and a specific resource ('a label from the board'), and is clearly distinguishable from siblings like get_label, update_label, and create_label by operation. It adds the 'permanently' nuance beyond the tool name.
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 the use case: call when a label needs to be permanently removed. However, it does not explicitly state when to prefer it over other label-related siblings or mention any exclusions, so guidance is only implied.
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 usefully states the Trello Premium or Enterprise requirement and clarifies that the result is definitions rather than values. It does not cover response format, pagination, or error behavior, but the read-only nature is strongly implied by 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is front-loaded and the licensing prerequisite is stated as an important follow-up. Every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description covers the essential purpose and the key constraint (paid plan requirement). It could have added a note about the return shape or the card-level alternative, but nothing critical is missing for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, boardId, is already fully documented in the schema with 100% coverage. The description adds no extra semantic detail about the parameter beyond reinforcing that the operation is board-scoped. The baseline of 3 applies because the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('all custom field definitions on a board'). It distinguishes this tool from sibling tools like get_custom_field and get_card_custom_fields by emphasizing the board-level and definition-focused scope.
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 the intended use: retrieve all custom field definitions at board level. However, it gives no explicit when-to-use guidance and does not mention alternatives for single custom fields or card-level custom field values.
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 behavioral disclosure burden. It clearly indicates a read operation with no side effects, but it does not mention return format, ordering, or any board access 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, clear sentence with no redundant information. Every word contributes to the 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 simple getter with one well-documented parameter, the description is nearly sufficient. It would benefit from stating the expected return shape, but the lack of side effects and clear purpose make it adequate 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 coverage is 100%, with the boardId parameter already described as 'The ID of the board'. The description adds no further parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all labels defined on a Trello board'), clearly distinguishing this from sibling tools like get_label. It directly communicates the operation and its scope.
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 usage is implied: use this when you need all labels for a board. However, it does not explicitly mention when to prefer this over get_label or any other alternative, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does state that this is a read operation and discloses a meaningful access restriction (Premium/Enterprise), but it does not describe the response shape or behavior for missing/empty custom field values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action and resource are front-loaded, and the Premium requirement is the only additional necessary context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, one-parameter read-only tool, the description plus schema is largely sufficient: it covers purpose, resource, prerequisite, and required parameter. The only gap is that with no output schema or annotations, a brief note on the return shape would make it 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 single parameter cardId is already described as 'The ID of the card.' The description adds no new parameter detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get custom field values for a Trello card.' It clearly distinguishes this from sibling tools like get_board_custom_fields by specifying card-level scope, and it matches the tool name and title without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite ('Requires Trello Premium or Enterprise'), which is useful for deciding whether the tool is available. However, it does not contrast with alternatives such as get_board_custom_fields or get_custom_field, leaving when-to-use versus those siblings only implicit.
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 disclosure burden. It clearly communicates that this is a retrieval operation and that the response includes all checklist items, which is valuable given there is no output schema. It does not cover edge cases like not-found behavior or permissions, but the core behavior of a simple getter is transparent enough.
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 names the action, the target, and the key return detail in minimal words, so every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the phrase 'including all its items' is important and helps set return expectations. Given that the tool has only one required parameter and simple read semantics, this is mostly complete, though error behavior is not mentioned.
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% for the single parameter, and the schema already explains that checklistId is 'The ID of the checklist'. The description's 'by ID' only rephrases this without adding format, source, or other semantic detail. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('checklist by ID'), and explicitly notes that the result includes all items. This makes it clearly distinguishable from related siblings like create_checklist, update_checklist, and get_list without needing to inspect 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 guidance about when to use this tool instead of alternatives. It does not say that this is the read-only lookup option, nor does it point to create_checklist, update_checklist, or add_checklist_item for mutations. The use case must be inferred from the tool name and the verb 'Get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It communicates a read-style operation, clarifies the workspace terminology, and explains the 'me' sentinel. Still, it does not disclose authentication needs, response shape, or potential error behavior, which is a meaningful gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary purpose is front-loaded, and the 'me' tip is the only additional information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only lookup, the description is mostly complete: it identifies the resource, the relationship, and the special 'me' value. There is no output schema, so a brief note on the return shape would be marginally helpful, but the description still gives an agent enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers memberId with 100% description coverage, including the 'me' usage. The tool description only paraphrases the schema's use-of-'me' hint and adds no new parameter meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('organizations (workspaces)') and clearly scopes it to those a member belongs to. This differentiates it from sibling tools like get_organization_members, which list members of an organization, and get_organization, which fetches a single organization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: retrieve all workspaces for a member, including 'me' for the authenticated user. However, it does not explicitly contrast this with alternative sibling tools or state when not to use it, leaving the selection logic mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It clearly signals a read-only operation ('Get details') and notes that it accepts either an ID or name, but it does not disclose what 'details' include, authentication requirements, or potential errors.
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 action, resource, and parameter semantics 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 simple single-parameter read tool, the description gives enough to call it correctly: identify the organization by ID or name and retrieve details. It lacks an explicit return-value outline, but the term 'details' plus the resource name provides adequate context in 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 coverage is 100% and the orgId parameter is already described as 'The ID or name of the organization'. The description repeats this same information without adding extra meaning, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and a clear resource ('Trello organization (workspace)') with a defined lookup mechanism ('by ID or name'). This distinguishes it from siblings like get_organization_boards and get_member_organizations, which target different resources or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for fetching organization-level details, but it does not explicitly state when to use it over alternatives or exclude board/member-specific queries. Sibling names provide context but not explicit routing 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?
No annotations are provided, so the description carries the behavioral burden. It clearly indicates a read-only lookup ('Get details'), but it does not disclose auth requirements, not-found behavior, or what 'details' actually includes. This is adequate for a simple get operation but provides no extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. The verb, resource, and lookup criterion are all present and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation, the description is nearly complete. The only gap is that with no output schema, 'details' is somewhat vague about the return shape, but the low complexity makes additional guidance unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the schema already describing webhookId as 'The ID of the webhook'. The description only alludes to this parameter with 'by ID' and adds no additional format, source, or constraint information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get'), a clear resource ('a webhook'), and a precise lookup key ('by ID'). This cleanly separates it from sibling tools like create_webhook, update_webhook, and delete_webhook.
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 retrieval intent is implied by 'Get details' and the single-ID signature, so an agent can infer it is for fetching an existing webhook. However, the description does not explicitly state when to prefer this tool over alternatives or mention any prerequisites or error 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 provided, the description carries the full transparency burden. It states the action and scope ('List all attachments') and thereby implies a non-mutating read, but it does not disclose details like return formatting, pagination, or potential errors.
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 short sentence with no filler or redundant wording. It front-loads the core action and resource without unnecessary context.
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 listing tool, the description is nearly complete: it names the target resource and the single required input. The lack of an output schema is acceptable since 'List' implies returning the attachments, but a bit more detail about the response could make it fully self-sufficient.
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 fully documents the only parameter, cardId, with a description ('The ID of the card'). The tool description adds no additional semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('attachments on a Trello card'), making the operation unmistakable. It clearly distinguishes itself from sibling tools like add_attachment and delete_attachment by indicating a read-only retrieval action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent should call this when it needs to see the attachments on a specific card, rather than adding or deleting them. However, the description does not explicitly mention when to prefer this over alternatives or any exclusions.
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?
There are no annotations, so the description carries the behavioral disclosure burden. It clearly signals a read-only operation by saying 'List' and 'Returns,' and it discloses the output shape (board id, name, description, URL, closed status). It does not mention pagination, rate limits, or token permission scope, but for a simple list operation the behavior is reasonably 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 sentence with no fluff, front-loading the core action and scope before listing return fields. Every word adds value, and it is appropriately sized for a simple list 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 optional parameter, no output schema, and no annotations, the description is mostly complete: it states the resource scope and the returned fields, while the schema covers the filter. It does not explain when to prefer this over sibling board-listing tools, but that gap is more about usage guidance than contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the filter parameter is already fully documented with an enum and default value. The description adds no additional semantics about the filter parameter or how it affects results. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not contradict or enrich 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 uses a specific verb ('List') and names the resource ('all Trello boards for the authenticated user'), giving a clear scope. It also enumerates the exact returned fields, which removes ambiguity about what the tool produces. This distinguishes it from sibling board-related tools like get_organization_boards or get_member_boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as get_organization_boards, get_member_boards, or get_board. It does not mention any exclusions or conditions that would route an agent to a different sibling tool. Usage context is only implicit in the phrase 'for the authenticated user.'
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 states only that the card is reopened, but does not disclose whether the card must already be archived, any side effects, permission requirements, or the shape of the response. This is minimal beyond the tool's name and title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 'Unarchive (reopen) a closed Trello card' conveys the action, target, and state in nine 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 one-required-parameter mutation with no output schema and no annotations, the description covers the essential invocation details: what action is performed and on what. It could add behavioral notes, but the agent has enough to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents cardId with the description 'The ID of the card to unarchive' at 100% coverage. The tool description does not add any additional parameter semantics beyond repeating the schema's definition, so it stays at the high-coverage 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 the specific verb 'Unarchive' with the resource 'card', and the parenthetical 'reopen a closed Trello card' further clarifies the operation. This distinguishes it from sibling tools like archive_card and unarchive_list, which target different states or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use the tool: on a closed Trello card to reopen it. It does not explicitly mention alternatives or exclusions, but the card-specific wording makes the target context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds the plan requirement, and 'get' implies a read-only operation, but it does not mention response shape, error behavior, or any side-effect-free guarantee beyond the verb.
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 clauses with no redundant text; the action and the key eligibility requirement are front-loaded.
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?
Adequate for a simple one-parameter lookup, but with no output schema and no annotations it leaves return-value details and failure behavior unspecified.
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 one parameter is already documented. The description adds no additional semantic detail beyond 'by ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (get) and resource (custom field definition) with an ID lookup. The word 'definition' distinguishes it from siblings like get_card_custom_fields or get_custom_field_options.
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?
Clear context: fetch a single custom field definition when you have its ID, and the Premium/Enterprise requirement signals eligibility. It does not explicitly name alternatives or 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 behavioral disclosure burden. It clearly states the operation (search) and documents query capabilities with operator examples, which is useful. However, it does not mention whether the operation is read-only, what access scope applies, or how results are returned/paginated, leaving some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the resource scope, the second gives operational syntax examples. The most important information (what it searches and how to form queries) is front-loaded.
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 parameter semantics are well covered by the schema, and the description conveys the search scope, but there is no output schema and the description does not describe the shape or grouping of the returned results (e.g., whether boards and cards are returned separately or how match counts are presented). For a 6-parameter search tool, this is a notable gap.
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%, so the baseline is 3, but the description adds genuine semantic value for the key `query` parameter by giving concrete Trello search operator examples (@member, #label, list:name, is:open, is:archived). It does not repeat or contradict the schema; it enhances 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 uses the specific verb 'Search' and names the exact resources ('boards and cards in Trello'), which clearly distinguishes it from sibling tools like get_board_cards (list cards for a known board) and search_members (search members rather than boards/cards). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the search use case via the verb and operator syntax, but it never explicitly says when to choose this tool over list_boards, get_board_cards, or search_members, nor does it state any exclusions. An agent can infer intent but is given no direct routing 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 must carry behavioral disclosure. It discloses a key prerequisite ('Requires Trello Premium or Enterprise') and the mutating nature of the operation via 'Set'. It does not describe overwrite/replace semantics, permissions beyond the plan requirement, or clearing behavior, leaving notable 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?
Two short sentences with no redundant wording. The action is front-loaded and the licensing requirement is a useful second sentence.
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 four-parameter mutation with no annotations and no output schema, the description is functional but thin. The schema covers parameter semantics, and the description adds the premium prerequisite, but it omits behavioral context such as what happens when a value already exists or how to select between value and idValue for different field types. These gaps prevent it from being 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 coverage is 100%; each of the four parameters has an explanatory description in the schema, including the value object and idValue for dropdowns. The tool description itself adds no parameter-level detail, 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?
States a concrete action ('Set') on a specific resource ('the value of a custom field on a card'). This clearly separates it from sibling tools such as update_card (card fields) and create_custom_field (field definitions). No ambiguity about the operation's target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for card custom-field values, not general card updates or custom-field definitions. It does not explicitly name alternatives or state when not to use it, but the scope is specific enough to route an agent correctly.
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 must carry the behavioral disclosure burden. It does this well by warning that deletion is irreversible and that all lists, cards, and data will be lost. This goes beyond the schema and informs the agent of serious 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 two sentences with no wasted words. The critical warning about irreversibility is placed front and center, making it immediately salient to the 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 simple one-parameter destructive tool, the description covers the main operational facts: what it deletes, permanence, and data loss. It doesn't mention return values or error conditions, but given the tool's simplicity and the schema covering the sole parameter, this is a minor gap rather than a critical omission.
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 parameter 'boardId' is already fully documented. The description does not add additional parameter-level detail beyond the schema, which is acceptable given 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 action and resource: 'Permanently delete a Trello board.' This clearly distinguishes it from sibling tools like delete_card, delete_comment, or delete_webhook, and adds the crucial adverb 'permanently' to clarify scope.
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 makes the tool's purpose obvious, but it does not explicitly say when to use it versus alternatives or provide exclusions. Usage is implied rather than stated with alternative routing or 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 provided, the description carries the full burden. It clearly signals a non-mutating read operation via 'Get' and discloses the plan requirement. It does not describe edge-case behavior such as what happens when the field is not of type 'list' or how options are returned, but for a simple getter this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and includes the essential licensing constraint. There is no filler or redundant restatement of the title.
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 read tool with no output schema, the description covers the essential facts: what it retrieves, the field type, and the license requirement. It could mention the shape of the returned options, but this is not critical for selecting and 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% and the single parameter is fully documented in the schema. The description adds no additional parameter-level meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('dropdown options for a list-type custom field'), making the tool's function unmistakable. It clearly distinguishes this from sibling tools like get_custom_field or get_card_custom_fields without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: retrieving dropdown options for list-type custom fields. It also adds a meaningful prerequisite (Trello Premium or Enterprise). It does not explicitly mention alternatives or when not to use it, but the context is unambiguous enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It mentions the authenticated-user scope and the mutating nature of the action, but it does not describe whether the change is reversible, what the response is, or any side effects beyond marking notifications as read.
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 states the operation and scope efficiently, which is appropriate for a zero-parameter 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 simple zero-parameter mutation, the description is nearly complete: it tells the agent what happens and for whom. It could be slightly more complete by noting what is returned or whether this action is reversible, especially since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to document. Schema coverage is 100% and the empty schema is consistent with the description; no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('mark all notifications as read') and the scope ('for the authenticated user'). This distinguishes it from read-only siblings like get_notifications and other notification-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the intent is to clear the unread state for all notifications. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so the usage guidance is mostly inferred rather than stated.
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 itself must carry behavioral disclosure. 'Unarchive (reopen)' clearly indicates a state change from closed to open, but it does not mention prerequisites, permission needs, idempotency, error behavior, or the effect on an already-open list. Some gaps remain for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that earns its place with both a direct verb and a clarifying synonym. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity—one required parameter, no nested objects, no output schema—the description provides enough context to understand the operation. It could mention the return value or behavior when the list is already open, but these are minor omissions for such a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, listId, is already fully described as 'The ID of the list to unarchive'. The description adds no additional parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Unarchive' with a clarifying parenthetical 'reopen' and identifies the exact resource: a closed Trello list. This clearly distinguishes it from sibling tools like archive_list, create_list, and unarchive_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a closed Trello list' gives clear contextual guidance on when to invoke this tool. It does not explicitly name alternatives or list when-not-to-use conditions, but the state-based condition is sufficient for a focused unarchive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses a key external constraint (callback URL must be publicly accessible and respond to HEAD requests), but does not mention side effects, permissions, idempotency, failure behavior, or what happens upon creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool's purpose, followed by a critical constraint. No filler or repetition of values already expressed in the schema.
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 mutation tool with no annotations and no output schema, the description covers the core purpose and a key prerequisite. However, it omits behavioral details like whether creation is idempotent, what response or webhook ID to expect, and whether any authorization is needed beyond normal API access. These are meaningful gaps for an agent invoking the tool.
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 schema already describes all 4 parameters (100% coverage), so the baseline is 3. The description adds meaningful extra meaning by specifying that the callback URL must be publicly accessible and respond to HEAD requests, which is not stated in the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (webhook), and the purpose (receive notifications when a Trello model changes). This makes it immediately distinguishable from sibling tools like get_webhook, update_webhook, and delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to register a webhook for Trello model change notifications. It also gives a prerequisite for successful use (publicly accessible callback URL that responds to HEAD requests). However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It does well by stating that deletion cascades to 'all its values from every card' and adds the Trello Premium/Enterprise requirement. It does not explicitly mention irreversibility or permission requirements, but the destructive cascade is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The action and its cascading effect are front-loaded, and the licensing requirement is added as a second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive operation with no output schema, the description covers the essential context: what is deleted, the scope of impact, and the plan requirement. It could be slightly richer by noting that the operation is irreversible, but the current description is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter customFieldId is already fully documented as 'The ID of the custom field to delete.' The description adds no further parameter-level nuance, which is acceptable given the complete 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 names a specific verb ('delete'), a precise resource ('custom field definition'), and a consequential scope ('and all its values from every card'). This clearly distinguishes the tool from siblings like get_custom_field, create_custom_field, and update_custom_field_item without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: use this when you need to permanently remove a custom field definition across all cards. It does not explicitly name alternatives or exclusion conditions, but the destructive scope and licensing requirement provide clear situational 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 full burden of behavioral disclosure. It clearly states that deletion is permanent and cannot be undone, which is the most critical behavioral trait. However, it doesn't mention side effects on associated resources (comments, attachments, checklists) or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core action is front-loaded, followed by the critical warning and the alternative tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description covers the essential context: what it does, permanence, and the alternative. It is slightly incomplete because it doesn't mention what the caller can expect in response or any prerequisites, but these are minor gaps for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the cardId parameter. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('delete') and resource ('Trello card'), and clarifies that it is permanent. It explicitly differentiates itself from archive_card, which is a sibling tool, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use this tool for permanent deletion, and use archive_card when reversible removal is needed. This directly names the alternative and the condition for choosing it, so no inference is required.
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 MCP server](https://glama.ai/mcp/servers/GabrielRamirez/trello-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GabrielRamirez/trello-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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