Skip to main content
Glama
m0xai

Trello MCP Server with Python

by m0xai

create_card

Add new tasks to Trello lists by creating cards with names, descriptions, due dates, and assignees.

Instructions

Creates a new card in a given list.

Args:
    list_id (str): The ID of the list to create the card in.
    name (str): The name of the new card.
    desc (str, optional): The description of the new card. Defaults to None.

Returns:
    TrelloCard: The newly created card object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payloadYes

Implementation Reference

  • The MCP tool handler function for create_card, which validates input with CreateCardPayload, logs the action, calls the CardService, and handles errors.
    async def create_card(ctx: Context, payload: CreateCardPayload) -> TrelloCard:
        """Creates a new card in a given list.
    
        Args:
            list_id (str): The ID of the list to create the card in.
            name (str): The name of the new card.
            desc (str, optional): The description of the new card. Defaults to None.
    
        Returns:
            TrelloCard: The newly created card object.
        """
        try:
            logger.info(f"Creating card in list {payload.idList} with name: {payload.name}")
            result = await service.create_card(**payload.model_dump(exclude_unset=True))
            logger.info(f"Successfully created card in list: {payload.idList}")
            return result
        except Exception as e:
            error_msg = f"Failed to create card: {str(e)}"
            logger.error(error_msg)
            await ctx.error(error_msg)
            raise
  • Pydantic model defining the input schema (payload) for the create_card tool, including fields like name, idList, desc, etc.
    class CreateCardPayload(BaseModel):
        """
        Payload for creating 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
        desc: str | None = None
        closed: bool | None = None
        idMembers: str | None = None
        idList: str
        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
  • Registration of the create_card tool handler with the MCP server using mcp.add_tool.
    mcp.add_tool(card.create_card)
  • Supporting service method in CardService that performs the actual Trello API call to create a card using POST /cards.
    async def create_card(self, **kwargs) -> TrelloCard:
        """Creates a new card in a given list.
    
        Args
            list_id (str): The ID of the list to create the card in.
            name (str): The name of the new card.
            desc (str, optional): The description of the new card. Defaults to None.
    
        Returns:
            TrelloCard: The newly created card object.
        """
        response = await self.client.POST("/cards", 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 full burden for behavioral disclosure. While 'Creates' implies a write operation, it doesn't mention permissions needed, whether this is idempotent, error conditions, or rate limits. The return type is mentioned but without output schema, more behavioral context would be helpful.

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 well-structured with clear sections (Args, Returns) and uses bullet-like formatting. It's appropriately sized for the basic information it provides, though it could be more comprehensive given the parameter gap.

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 creation tool with 12 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It documents only 3 parameters and provides minimal behavioral context, leaving significant gaps for proper tool usage.

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%, so the description must compensate. It only documents 3 parameters (list_id, name, desc) while the actual schema has 12 parameters in the payload object. The description fails to mention critical parameters like idBoard, closed, due, idMembers, etc., leaving most parameters undocumented.

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

Purpose4/5

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

The description clearly states the action ('Creates a new card') and target resource ('in a given list'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'update_card' or 'create_list', which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage 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 like 'update_card' for modifying existing cards or 'create_list' for creating lists. The description only states what the tool does, not when it's appropriate.

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