trello-mcp

search

Find Trello cards, boards, members, and workspaces visible to your token; scope results by board, card, or workspace and paginate card results.

Instructions

Search Trello and return grouped cards, boards, members, and workspaces visible to the token. Defaults to cards and boards; scope and limit results, and use cardsPage for card pagination. Use search_members for a focused member lookup.

Input Schema

Name	Required	Description	Default
`query`	Yes	Trello search text, trimmed and sent directly to Trello. For search, use Trello operators such as is:open; for search_members, use a member name or username.
`cardIds`	No	Optional card ids to scope search results.
`partial`	No	Whether to match query word prefixes in Trello search.
`boardIds`	No	Use mine to search the current member's boards, or provide one or more board ids.
`cardsPage`	No	Zero-based result page for card search results.
`cardFields`	No	Comma-separated Trello card search result fields to request; use all for detailed follow-up reads. Schema-required fields are added automatically.	name,closed,idBoard,idList,url,shortUrl,due,dateLastActivity
`cardsLimit`	No	Maximum number of Trello search results to return.
`modelTypes`	No	Trello object types to search; use organizations for Trello workspaces.
`boardFields`	No	Comma-separated Trello board search result fields to request; use all for detailed follow-up reads. Schema-required fields are added automatically.	name,closed,idOrganization,url,shortUrl,dateLastActivity
`boardsLimit`	No	Maximum number of Trello search results to return.
`memberFields`	No	Comma-separated Trello member search result fields to request; use all for detailed follow-up reads.	username,fullName,initials,url
`membersLimit`	No	Maximum number of Trello search results to return.
`includeCardList`	No	Whether to include parent list objects with card results.
`organizationIds`	No	Optional workspace ids to scope search results.
`includeCardBoard`	No	Whether to include parent board objects with card results.
`includeCardMembers`	No	Whether to include member objects with card results.
`organizationFields`	No	Comma-separated Trello workspace search result fields to request; use all for detailed follow-up reads. Schema-required fields are added automatically.	name,displayName,url,website
`organizationsLimit`	No	Maximum number of Trello search results to return.
`includeBoardOrganization`	No	Whether to include parent workspace objects with board results.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.4Oct 24, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the key behavioral trait — results are limited to what the token can see — plus defaults and pagination, but says nothing about read-only semantics, rate limits, or failure modes. 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?

Two sentences, zero filler: the capability and return shape come first, then defaults/pagination, then the sibling hand-off. Every clause 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 19-parameter search with no output schema and no annotations, the description orients the agent well (what comes back, what the defaults are, where to paginate). Minor gaps remain around the include* expansions and field-selection parameters, though the schema covers those in 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?

All 19 parameters are documented at 100% schema coverage, so the schema already does the heavy lifting and a baseline 3 applies. The description adds only a little on top: the default modelTypes and the cardsPage pagination mechanism, without explaining partial, the include* expansion flags, or field selection.

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

Purpose5/5

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

States a specific verb and resource ("Search Trello") plus the exact result shape ("grouped cards, boards, members, and workspaces visible to the token"), which tells the agent this is a multi-model search rather than a single-resource list. The final sentence explicitly separates it from the sibling search_members.

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?

Gives concrete operating guidance: defaults to cards and boards, scope and limit results, use cardsPage for card pagination, and route focused member lookups to search_members. It lacks explicit when-not conditions or prerequisite notes, but the alternative is named with the condition that selects it.

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

Deploy Server

search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools