Skip to main content
Glama
m0xai

Trello MCP Server with Python

by m0xai

update_card

Modify Trello card attributes such as name, description, due dates, members, labels, and position to keep project tasks current and organized.

Instructions

Updates a card's attributes.

Args:
    card_id (str): The ID of the card to update.
    **kwargs: Keyword arguments representing the attributes to update on the card.

Returns:
    TrelloCard: The updated card object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
card_idYes
payloadYes

Implementation Reference

  • The main MCP tool handler for update_card. It takes context, card_id, and payload, logs the action, calls the CardService to update the card via Trello API, handles errors with ctx.error, and returns the updated TrelloCard.
    async def update_card(
        ctx: Context, card_id: str, payload: UpdateCardPayload
    ) -> TrelloCard:
        """Updates a card's attributes.
    
        Args:
            card_id (str): The ID of the card to update.
            **kwargs: Keyword arguments representing the attributes to update on the card.
    
        Returns:
            TrelloCard: The updated card object.
        """
        try:
            logger.info(f"Updating card: {card_id} with payload: {payload}")
            result = await service.update_card(
                card_id, **payload.model_dump(exclude_unset=True)
            )
            logger.info(f"Successfully updated card: {card_id}")
            return result
        except Exception as e:
            error_msg = f"Failed to update card: {str(e)}"
            logger.error(error_msg)
            await ctx.error(error_msg)
            raise
  • Pydantic BaseModel schema defining the optional fields for the update_card tool input payload.
    class UpdateCardPayload(BaseModel):
        """
        Payload for updating a card.
    
        Attributes:
            name (str): The name of the card.
            desc (str): The description of the card.
            closed (bool): Whether the card is closed or not.
            idMembers (str): Comma-separated list of member IDs for the card.
            idList (str): The ID of the list the card is in.
            idLabels (str): Comma-separated list of label IDs for the card.
            idBoard (str): The ID of the board the card is in.
            pos (str | int): The position of the card.
            due (str): The due date of the card in ISO 8601 format.
            start (str): The start date of the card in ISO 8601 format.
            dueComplete (bool): Whether the card is due complete or not.
            subscribed (bool): Whether the card is subscribed or not.
        """
    
        name: str | None = None
        desc: str | None = None
        closed: bool | None = None
        idMembers: str | None = None
        idList: str | None = None
        idLabels: str | None = None
        idBoard: str | None = None
        pos: str | None = None
        due: str | None = None
        start: str | None = None
        dueComplete: bool | None = None
        subscribed: bool | None = None
  • Registers the update_card tool handler from the card module with the MCP server instance.
    mcp.add_tool(card.update_card)
  • CardService helper method that makes the actual Trello API PUT request to update the card and returns the updated TrelloCard model.
    async def update_card(self, card_id: str, **kwargs) -> TrelloCard:
        """Updates a card's attributes.
    
        Args:
            card_id (str): The ID of the card to update.
            **kwargs: Keyword arguments representing the attributes to update on the card.
    
        Returns:
            TrelloCard: The updated card object.
        """
        response = await self.client.PUT(f"/cards/{card_id}", data=kwargs)
        return TrelloCard(**response)
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. While 'Updates a card's attributes' implies a mutation operation, it doesn't disclose important behavioral traits: whether this requires specific permissions, whether changes are reversible, what happens to unspecified attributes, rate limits, or error conditions. The return type is mentioned but not explained.

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 efficiently structured with clear sections for Args and Returns. The first sentence states the purpose directly. However, the **kwargs documentation is overly vague given the complexity of the actual payload parameter, representing a missed opportunity for more meaningful guidance.

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 2 parameters (one being a complex object with 12 attributes), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It mentions the return type but doesn't explain it, and provides minimal guidance on the complex payload parameter that represents most of the tool's functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the input schema provides no parameter descriptions. The description mentions 'card_id' and '**kwargs' but doesn't explain what attributes can be updated, their formats, or constraints. The payload parameter with 12 possible attributes is completely undocumented in both schema and description, leaving the agent with insufficient guidance.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Updates a card's attributes' which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'update_checkitem' or 'update_checklist' that also update different Trello entities, leaving room for potential confusion about when to use each update 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing card_id), doesn't differentiate from other update tools (update_checkitem, update_checklist, update_list), and offers no context about when this tool is appropriate versus creating or deleting cards.

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

Install Server

Other Tools

Latest Blog Posts

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/m0xai/trello-mcp-server'

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