tomatrello-mcp

list_comments

Retrieve the most recent comments on a Trello card using its ID or short link. Set an optional limit to control how many comments are returned.

Instructions

List the most recent comments on a Trello card

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cardId": "<cardId>"
    },
    "name": "list_comments"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`cardId`	Yes	Trello card ID or short link

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 5, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the ordering concept ('most recent') and the targeted resource, but it does not describe return shape, whether comments include authors/timestamps, or any error/auth considerations. For a simple read-only list, this is acceptable 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 concise sentence that front-loads the verb and object. There is no redundant filler or repetition of schema details. 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 tool with no output schema and no annotations, the description should do more to explain what a caller gets back. It identifies the resource and the required cardId, but omits return value details and any note about comment content. Given the low complexity, it is minimally adequate 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 50%: cardId has a description, but limit does not. The description adds no parameter-level detail beyond what the schema already provides, though the limit parameter's constraints (default 50, max 1000, min 1) give reasonable meaning. The word 'most recent' loosely implies the limit applies to recency.

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 a clear resource ('comments on a Trello card'), and explicitly scopes to 'the most recent' comments. This makes it immediately distinguishable from the sibling tools add_comment, update_comment, and delete_comment, which all imply mutation.

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 it clear this is the read operation for comments, which contrasts with the mutation verbs in sibling names. However, it provides no explicit guidance on when to use this tool versus alternatives, no mention of pagination or ordering considerations, and no exclusions or caveats.

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

Deploy Server