Provides tools for reading Trello boards and analyzing workflow, including board health, bottleneck detection, standup reports, and card management (create, move, update, comment).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Trellis Analyze my Product Board for bottlenecks and stale cards."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that reads a Trello workspace and explains how the work is actually flowing.
Trello tells you what is on the board. Trellis tells you what that means: which column work is piling up in, which cards have not moved in two weeks, what changed since Monday, and what is overdue and unowned. Every capability is exposed as a real Model Context Protocol tool, so the same server works in Claude Code, Claude Desktop, or any other MCP-compatible client.
The analysis tools do not call a language model. They compute counts, ages and outliers from the Trello API and return structured metrics, along with the formula used to rank anything. The client's model reads those numbers and does the reasoning.
That is deliberate. It means the server needs one credential instead of two, it stays cheap and fast, its output is reproducible, and the model can openly disagree with a heuristic instead of inheriting a verdict it cannot inspect.
Related MCP server: Trello MCP Server
Tool | What it does |
| Every board the account can open, with ids and URLs. Start here. |
| One board's metadata: description, visibility, members, last activity. |
| The open lists (columns) on a board, with card counts and an inferred stage. |
| Open cards on a board, optionally filtered to one list, as triage digests. |
| One card in full: description, labels, due date, checklists, recent comments. |
| Search cards and boards, including Trello operators like |
Tool | What it does |
| Per-list load plus the overdue, unassigned and stalled cards by name. |
| Ranks non-done lists by a volume-and-age pressure score, formula included. |
| What moved, what was created and what was discussed in the last N days. |
These change the real board immediately.
Tool | What it does |
| Add a card to a named list, with optional description and due date. |
| Move a card to another list on the same board. |
| Change name, description, due date, due-complete, or archive the card. |
| Post a comment on a card as the authenticated user. |
Boards can be given by id or by name, so analyze_board_health("Sprint Board")
works without looking an id up first.
Go to trello.com/power-ups/admin and create a Power-Up (any name; it exists only to give you an API key).
Open it and copy the API key.
Next to the key, click the Token link, authorize, and copy the token.
The token is tied to your Trello account and grants exactly the access you approve.
Treat it like a password: it is not in git, and .env is gitignored.
python -m venv .venv && .venv/Scripts/pip install -e .On macOS or Linux use .venv/bin/pip instead.
cp .env.example .envThen fill in TRELLO_API_KEY and TRELLO_TOKEN.
.venv/Scripts/python scripts/smoke_test.pyThis hits the real Trello API read-only and prints what it finds, which is the fastest way to confirm your credentials work before wiring up a client.
claude mcp add trellis -e TRELLO_API_KEY=your_key -e TRELLO_TOKEN=your_token -- /absolute/path/to/.venv/Scripts/python.exe -m trellis.serverAdd this to claude_desktop_config.json, then restart Claude Desktop:
{
"mcpServers": {
"trellis": {
"command": "C:\\absolute\\path\\to\\.venv\\Scripts\\python.exe",
"args": ["-m", "trellis.server"],
"env": {
"TRELLO_API_KEY": "your_key",
"TRELLO_TOKEN": "your_token"
}
}
}
}npx @modelcontextprotocol/inspector .venv/Scripts/python.exe -m trellis.serverPORT=8080 .venv/Scripts/python -m trellis.smithery_appServes the MCP streamable HTTP endpoint at /mcp. This is the mode a hosted
deployment uses.
The repo ships smithery.yaml and a Dockerfile for Smithery's container runtime.
Push this repo to GitHub.
At smithery.ai, click Deploy and connect the repo.
Smithery builds the image, sets PORT, and proxies to /mcp.
Users then supply trelloApiKey and trelloToken in Smithery's config UI, which
is declared by the configSchema in smithery.yaml.
Hosted, one process serves many people, so credentials cannot come from the
environment. Smithery passes each caller's config as base64-encoded JSON in a
config query parameter on every request to /mcp.
smithery_app.py decodes that and binds the credentials to a ContextVar,
not a module-level global. This matters: with a global, two users hitting the
server at the same time will overwrite each other's token, and requests get made
with the wrong person's credentials. tests/test_smithery_config.py has a test
that interleaves two requests and fails if their tokens cross.
Environment variables still work and are used when no request config is present, so the same build runs locally over stdio and hosted over HTTP.
Its example stores the API key in a module-level global. Fine for a demo, wrong for anything multi-tenant.
It rewrites /mcp to /mcp/, which was correct for FastMCP 1.x. MCP SDK 2.x
mounts the route at /mcp, and Starlette's redirect_slashes sends /mcp/
back to /mcp, so that rewrite causes an infinite redirect loop. This repo
normalises the other way.
Rate limits. Trello allows 300 requests per 10 seconds per API key. The analysis tools use three or four calls each, so normal use is nowhere near the ceiling, but a 429 is reported back in plain language if you hit one.
Stage detection is name-based. A list is called done, blocked, in-flight or backlog by matching words in its name. A board with unusual column names will have its stages mislabeled, and the card counts are still correct regardless.
404 means invisible, not absent. Trello returns 404 rather than 403 for a board you cannot see, so a 404 may mean the token lacks access rather than a bad id.
Archived cards are excluded from board reads. update_card(archive=true) closes
a card rather than deleting it; nothing in this server deletes anything.
Once it is connected, these all work in plain language:
"Which board has the most stalled work?"
"Give me a standup update for the Sprint board covering the last 3 days."
"What is overdue and unassigned across my boards?"
"Where is work piling up on the Engineering board, and does the data actually support that?"
"Add a card to Backlog called 'Rotate Trello token' due next Friday."
MIT
Post a comment on a card as the authenticated user. This writes to the real board.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| card_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses that this operation writes to the real board, a meaningful side-effect warning, and identifies the authenticated user as the actor. It does not mention rate limits, permissions, or rollback, but the core mutation behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry the essential information with no filler. The main action is front-loaded, and the important real-world side effect is stated immediately after.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with an output schema, the description is mostly complete: it states the action, actor, and live-write behavior. It does not mention how to source card_id or how this differs from update_card, but those details are reasonably inferable from the sibling list and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 indirectly maps text to the comment body and card_id to the target card, and 'authenticated user' clarifies attribution. However, it does not explicitly explain constraints, formats, or how to obtain a valid card_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Post a comment on a card.' It also adds actor context ('as the authenticated user') and emphasizes a real side effect, which visually separates it from the read-only sibling tools and from card creation/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, no reference to sibling tools, and no prerequisites such as 'requires an existing card_id.' The description provides context but leaves usage routing entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess a board: per-list load, overdue cards, unassigned work and stalled cards.
Returns counts and the specific offending cards, not a verdict. Read the numbers and say what they imply, including when the board is simply small.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | ||
| stale_after_days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an importante behavior: it returns counts and offending cards rather than a verdict, and calls out handling of small boards. However, because no annotations are provided, the description carries full burden and still does not mention read-only status, side effects, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences carry signal: the first lists the assessment dimenions, the second clarifies output shape and interpretive nuance. No filler or repetition of schema titles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with an output schema, the description is mostly adequate: it names inputs dimenions and output nature. The main gap is parameter semantics for stale_after_days, and there is no guidance about required input form or sibling selection, leaving the agent to infer important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain the board parameter or stale_after_days. The title 'Stale After Days' hints at its purpose, but the description never connects it to the 'staled cards' metric, and does not clarify default semantics or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('assess') and resource ('a board') and lists concrete metrics: per-list load, overdue cards, unassned work, staled cards. It is clear about what the tool does, though it does not explicitly differentiate it from detect_bottlenecks or generate_standup_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool instead of a sibling like detect_bottlenecks or list_cards. The instruction 'Read the numbers and say what they imply' is about post-processing output, not about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a card on a board, in the named list. This writes to the real board.
due takes an ISO-8601 timestamp such as 2026-09-01T17:00:00Z.
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | ||
| name | Yes | ||
| board | Yes | ||
| list_name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It earns credit for the explicit 'This writes to the real board' warning, which conveys real-world side effects beyond the tool's name, plus the ISO-8601 format constraint for `due`. However, it does not disclose permission/auth requirements, reversibility, duplicate-card behavior, or what happens when the named list isn't found, leaving significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with zero filler. The primary action comes first, followed by the safety-relevant write warning, then the parameter format note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so that omission is acceptable. For a 5-parameter, 3-required mutation tool with real side effects and zero annotations or schema descriptions, the definition covers the essentials (action, write warning, date format) but lacks operational context: how to resolve board/list_name to valid values, whether the action can create duplicate cards, and dependency on sibling read tools. Complete enough for a basic call, but an agent could produce invalid invocations for board or list_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does add genuine value for `due` by specifying the ISO-8601 format with a concrete example, which is the most error-prone parameter. It also ties 'named list' to list_name and 'a board' to board. But it fails to clarify whether board and list_name take IDs or human-readable names, and offers no hints for the remaining parameters (name, description), leaving an agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create a card on a board, in the named list') with an explicit location scope. It clearly distinguishes this from the sibling operations (list_cards, move_card, update_card, add_comment) since creation is the only write-to-add action in the family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but never stated explicitly. The warning 'This writes to the real board' hints that this tool should not be used for exploratory or dry-run purposes, and the domain (creating vs moving/updating/comments) is inferable from the name and siblings. However, there is no explicit when-to-use guidance, no exclusions, and no pointer to list_boards/list_board_lists as prerequisites for valid board and list_name values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank the non-done lists by how much work is piling up and ageing inside them.
The pressure score is a crude volume-plus-age heuristic and is returned with its own formula so it can be argued with rather than trusted blindly.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose an important trait: the pressure score is a 'crude volume-plus-age heuristic' and is returned with its own formula so it can be questioned. This is useful epistemic context beyond the basic function, though it does not discuss read-only semantics, permissions, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with the core purpose front-loaded and the heuristic caveat placed second. Every sentence adds either functional or interpretive value; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema presumably covers the return details, so the description does not need to. But the board parameter remains ambiguous, and 'non-done lists' is not formally defined. For a single-parameter analysis tool this is adequate but leaves an agent guessing on invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'board' parameter with 0% documentation coverage, and the description never explains what board value is expected (ID, name, or URL) or how it should be formatted. Because the schema provides no meaning, the description needed to compensate and did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Rank the non-done lists by how much work is piling up and ageing inside them.' It clearly communicates the tool's analytical function and distinguishes it from generic card/list tools, though it does not explicitly contrast it with the similar-sounding analyze_board_health sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the verb 'Rank' — the tool is for identifying bottleneck lists on a board. However, it gives no explicit when-to-use guidance, no mention of alternatives, and no statement of when not to use it, leaving the agent to infer suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise what actually happened on a board recently.
Combines card movements, new cards and comments from the activity feed with the board's current overdue and stalled work, which is enough material for a standup update or a weekly status note.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | ||
| window_days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does so well by disclosing the data sources and scope: activity feed events plus current overdue and stalled work. It does not explicitly address side effects or permissions, but as a read-only report generator, the described behavior is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and every sentence adds value: the first states the outcome, the second details the inputs and intended use. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, input signals, and output use case, and an output schema exists so return values are covered. However, with no annotations and no parameter descriptions, details like how to identify the board and what window_days controls are left underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it only vaguely references 'a board' and 'recently'. It never explicitly explains the board parameter format or the window_days semantics, defaults, or valid range, leaving the agent to infer too much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Summarise') with a clear resource ('what actually happened on a board recently') and a concrete synthesis activity: combining card movements, new cards, comments, overdue work, and stalled work. This clearly separates it from sibling tools like list_cards or analyze_board_health on intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: the output is suitable for a standup update or weekly status note. It does not explicitly name alternatives or state when not to use it, but the described purpose is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for one board: name, description, URL, visibility, last activity.
board accepts a board id or a board name.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool retrieves metadata and exposes the returned fields, which implies a non-mutating read, but it does not explicitly confirm side-effect-free behavior, auth requirements, or error behavior when the board is not found. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, no filler. The purpose and returned metadata are front-loaded, and the parameter clarification is placed on its own line, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get-metadata tool with an output schema present, the description covers what the tool does, what it returns, and the accepted input format. It lacks explicit sibling differentiation and edge-case behavior, but overall it is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a bare 'board' string with no description, so this description must compensate. It does so by explaining that 'board' accepts either a board id or a board name, which is essential, actionable semantic information that goes beyond the schema. It stops short of giving examples or format details, but for a single parameter this is strong coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('metadata for one board'), and it lists the specific metadata fields returned (name, description, URL, visibility, last activity). The phrase 'one board' distinguishes it from sibling tools like list_boards and get_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single board's metadata, but it does not explicitly state when to prefer this over list_boards or other siblings. There is no when/when-not or alternative-tool guidance, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one card in full: description, labels, due date, checklists and recent comments.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure. It does state what is included in the returned card (description, labels, due date, checklists, recent comments) and implicitly presents this as a read-only operation, but it doesn't mention permissions, error behavior, rate limits, or how 'recent' is determined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler; the colon-delimited list efficiently conveys the response scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation, the description plus output schema is mostly sufficient. The main gaps are an explicit usage-rule statement and clarification of the 'recent' limit, but these are minor given the simple scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides name/type/required for card_id and has 0% description coverage. The tool description never explains the card_id parameter, how to obtain it, or its accepted format; the agent must rely on the self-explanatory name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and identifies the exact resource ('one card') while enumerating the payload ('description, labels, due date, checklists and recent comments'). This distinguishes it from sibling list_cards (which returns many) and get_board_info (a different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the full detail of a single card. However, it never explicitly says when to prefer this over list_cards/search_trello or when not to use it, so the agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the open lists (columns) on a board, in board order, with card counts.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that closed lists are excluded, results follow board order, and card counts are included. It does not mention auth requirements or error behavior, but for a simple read/list operation the described behavior is unusually specific and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, under 15 words, front-loads the verb and resource, and packs three useful qualifiers: open, board order, card counts. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter) and has an output schema, so return details need not be described here. The main missing piece is the accepted format/value of the 'board' parameter, which weakens completeness for actually invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single param 'board' has no description in the schema (0% coverage), and the tool description only says 'on a board'. It does not specify whether the board identifier should be an ID, URL, shortLink, or name, so the description fails to compensate for the complete lack of schema-level parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a precise resource ('lists/columns on a board'), and adds scope ('open'), ordering ('in board order'), and content ('with card counts'). This clearly distinguishes it from siblings such as list_boards, get_board_info, and list_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need the open lists/columns for a specific board with their card counts. It does not explicitly name alternatives or spell out when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Trello board the authenticated account can open.
Returns board ids, names and URLs. This is the entry point for every other tool, which all need a board id or name.
| Name | Required | Description | Default |
|---|---|---|---|
| include_closed | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and discloses key behavior: it only lists boards the authenticated account can open, and it returns board ids, names, and URLs. It does not explain the closed-board behavior behind include_closed, but the listing scope is clear and the operation is evidently read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, action-first sentences with no filler. The entry-point sentence adds real context without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description conveys auth scope, return fields, and its role in the broader workflow. A note about include_closed and the default exclusion of closed boards would make it fully complete, but that is a minor omission given the self-evident parameter name and default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives no guidance about the only parameter, include_closed, and the schema has no description text for it either. Because schema description coverage is 0%, the description should compensate but does not; an agent must infer meaning from the parameter name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation ('List every Trello board'), the resource ('boards'), and the auth scope ('the authenticated account can open'). It also positions the tool as the entry point for all other board-scoped tools, so an agent can distinguish it from siblings like get_board_info or list_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is the entry point for every other tool and that they all need a board id or name. That gives clear when-to-use context, though it does not name 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.
List open cards on a board, optionally filtered to one list by name.
Each card is trimmed to a triage digest: labels, assignee count, due date, overdue flag, days idle, and checklist progress.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | ||
| limit | No | ||
| list_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 usefully discloses that only open cards are returned and that each card is trimmed to a specific triage digest of fields, which goes beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first sentence, with the digest detail in a brief second paragraph. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The digest detail and optional filter are helpful, but the description omits usage guidance relative to sibling tools and does not clarify the limit parameter's effect. Since an output schema exists, the return shape is less of a gap, but overall the description is not fully complete for an unannotated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaning for list_name ('filtered to one list by name') and suggests board as the scope, but it does not explain limit behavior or any constraints on list_name matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List open cards on a board', distinguishes from siblings like list_board_lists and get_card, and adds the optional list filter. It is immediately clear what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally filtered to one list by name', but it does not explicitly state when to prefer this over search_trello, get_card, or list_board_lists. No alternatives or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a card to a different list on the same board. This writes to the real board.
position is "top", "bottom", or a numeric string.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | ||
| to_list | Yes | ||
| position | No | top |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility for behavioral disclosure. It explicitly says 'This writes to the real board,' which is useful context for a mutating tool. But it does not disclose prerequisites, reversibility, or other side effects beyond the move itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written: operation first, then a meaningful side-effect warning, then the only parameter format detail that needs explanation. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation with an output schema, the description covers the core action, same-board scope, and position format. The main gap is the ambiguity of `to_list`—an agent may not know it needs a list ID—and there is no mention of what the response will contain, although the output schema mitigates that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does clarify the `position` parameter's allowed values ('top', 'bottom', or numeric string), but `card_id` and `to_list` are not elaborated beyond their schema titles, and it does not confirm that `to_ist` expects a list ID rather than a list name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Move a card to a different list on the same board.' This clearly identifies what the tool does and distinguishes it from siblings like update_card, create_card, and list_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context—moving cards within the same board—and warns that it writes to the real board. However, it does not explicitly mention when to use this versus alternatives such as update_card, and it leaves the 'when not to use' cases to implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cards and boards across the whole account using Trello's own search.
Supports Trello search operators such as label:bug, due:week, is:open
and @username.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses the important behavioral trait that this is account-wide and relies on Trello's own search syntax rather than simple listing. It does not mention pagination.rate limits, or output format, but the output schema exists and the read-only nature is strongly implied by 'Search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the first sentence states the core purpose and scope, and the second adds valuable query-language examples. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters and an output schema already exists, the description is largely complete. It explains the search scope, the query syntax, and provides examples. The only notable gap is the lack of explicit guidance for the limit parameter, but this is a minor omission for such a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 gives concrete query examples (lavel:bug, due:week, is:open, @username) which explain the query parameter well, but it never explains the limit parameter. The meaning of limit is partially inferable from its name and default, so this is average, not excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('cards and boards'), and a clear scope ('across the whole account'). It also disambiguishes from sibling tools like list_boards and list_cards by emphasizing account-wide search using Trello's own search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for finding cards/boards across the entire account, not within a single board or list, and that it supports advanced Trello search operators. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it over the list-focused siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a card's name, description, due date, or archive it. This writes to the real board.
Only the arguments you pass are changed. archive=true closes the card,
which hides it from the board but does not delete it.
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | ||
| name | No | ||
| archive | No | ||
| card_id | Yes | ||
| description | No | ||
| due_complete | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses that the operation mutates the real board, that it is a partial update, and that archive=true hides rather than deletes the card. This gives the agent a clear model of side effects and semantics beyond the bare tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose, real board warning, and archive semantics. Every sentence earns its place, with critical behavioral details front-loaded. No filler or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nuanced mutation tool with no annotations and 0% schema coverage, the description provides strong context: side effect warning, partial-update behavior, and archive's non-destructive nature. It does not explain due_complete or mention alternative tools for card placement, but output schema covers return values and the core calling contract is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It covers 4 of 6 parameters (name, description, due, archive) with explicit semantics, especially archive's close-vs-remove meaning. It omits due_complete and doesn't explicitly identify card_id's role, but the partial-update statement generically explains how all parameters behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update a card's name, description, due date, or archive it.' This clearly distinguishes the tool from siblings like create_card, move_card, and get_card by naming the exact fields it operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an existing card: 'Only the arguments you pass are changed.' It also marks it as a real write operation ('This writes to the real board'), contrasting it with read-only tools. However, it stops short of explicitly naming alternatives or providing 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_commentanalyze_board_healthcreate_carddetect_bottlenecksgenerate_standup_reportget_board_infoget_cardlist_board_listslist_boardslist_cardsmove_cardsearch_trelloupdate_cardMost tools target distinctly different resources and actions: boards, lists, cards, search, and write operations are clearly separated. The only mild overlap is between analyze_board_health and detect_bottlenecks, both assessing board workflow strain, but their descriptions clarify one is overall health and the other is list pressure ranking.
Every tool follows a lowercase verb_noun pattern: list_boards, get_card, create_card, move_card, add_comment, and so on. Even the more analytical tools like analyze_board_health and detect_bottlenecks fit the same predictable style.
Thirteen tools is within the ideal 3–15 range and every tool earns its place in a Trello-focused server. The set balances read, write, search, and analysis tools without padding or redundant duplication.
The toolset covers core workflows well: board discovery, list and card inspection, card creation/update/move/comment, archiving via update, search, and higher-level workflow analysis. Missing board/list creation and card deletion are minor gaps for a board-management assistant and can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and manage your EasyKanban kanban boards: to-do summaries, create, update, and move cards.
Create and drive KanbanThing kanban boards. No account, no API key, board link required.
Read and update Markboard kanban boards: cards, checklists, labels, comments and files.
Read teams, spaces, lists and tasks; create, update and comment on tasks and track time.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shaheerkhalid04/mcp-trello'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
