Provides read-only operational facts about Trello boards, including board discovery, list history, card movement analytics, workflow flow metrics, staleness signals, and due-date information.
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., "@trello-ops-mcp How many cards moved from To Do to Done in the past week?"
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.
A local, read-only Model Context Protocol server that gives LLM agents (Claude and others) deterministic operational facts about Trello boards — structural history, card movement, workflow flow, staleness, and due dates.
It never writes to Trello. It has no mutation endpoints, no write tools, and no way to change board state, even accidentally.
Trello boards accumulate a lot of operational history that's hard to see from the UI alone: who renamed a list and when, how many cards moved between stages this week, which cards have gone quiet, what's overdue. trello-ops-mcp exposes that history to an MCP-capable agent as a set of small, composable tools — each one answers a narrow, factual question, and each one is deterministic: same input, same output, every time.
The server deliberately stops at facts. It does not decide whether a list is a "bottleneck," whether a card is "blocked," or whether a person is "productive" — those are judgment calls that need context the server doesn't have, so they're left to the agent reasoning over the data. See Design philosophy.
Related MCP server: trello-mcp
Trello already contains most of the operational data a team would want to reason about — who did what, when, and how cards flow through a board. But that data is spread across paginated REST endpoints with inconsistent shapes, and an LLM agent asked to "check the board" has no reliable way to fetch, filter, and combine it correctly on its own, every time it's asked.
This MCP server does that translation once, consistently: it turns raw Trello API responses into small, deterministic, structured operational signals — movement counts, flow numbers, staleness thresholds, due-date facts — that an agent can call directly and compose into an answer, instead of re-deriving the same parsing and pagination logic every time.
Read-only MCP tools across board discovery, structural audit (list history), movement/flow analytics, and due-date/staleness signals.
Board references in any form — internal ID, shortLink, or full board URL, normalized in one place.
Bounded, paginated Trello Actions scanning with an explicit truncated flag — never a silent partial result.
A pure, fixed-clock-tested domain layer for every analytic computation (movement counts, list flow, overdue/upcoming/stale classification) — no HTTP, no side effects, fully unit-testable.
Credential-safe by construction — env-var-only credentials, lazy validation (tools that don't need Trello still work without them), and error messages that are structurally incapable of leaking a key or token.
Zero write surface — the Trello client only ever issues GET requests. There is no code path that can call a mutating Trello endpoint.
Requires Node.js >= 18.
git clone https://github.com/YOUR_GITHUB_USERNAME/trello-ops-mcp.git
cd trello-ops-mcp
npm installgit clone https://github.com/YOUR_GITHUB_USERNAME/trello-ops-mcp.git
cd trello-ops-mcp
npm install
cp .env.example .env # then fill in TRELLO_API_KEY and TRELLO_TOKEN — see Configuration
npm run build
npx @modelcontextprotocol/inspector node dist/index.jsThat last command opens a browser UI where you can call any tool directly and see the response — the fastest way to confirm everything is wired up before connecting a real agent. To use it from Claude Desktop instead, see Connecting to Claude Desktop.
Variable | Required for | Notes |
| All tools except | From trello.com/app-key |
| All tools except | Generate with read-only scope (see below) |
| — |
|
Getting Trello credentials:
Go to trello.com/app-key while logged into the Trello account you want to audit. Copy the API Key.
On the same page, click the Token link to generate a personal token. When prompted for scope, choose read-only. This isn't just a formality — it means that even if this server had a bug, the credential itself physically cannot modify your boards.
Put both values in .env (copy .env.example as a starting point):
TRELLO_API_KEY=your_api_key_here
TRELLO_TOKEN=your_read_only_token_hereCredentials are validated lazily, only when a Trello-backed tool actually runs — so the server starts and health_check works even with no .env at all. Never commit your .env file; it's already excluded via .gitignore.
Build the server first — Claude Desktop launches the compiled output, not the TypeScript source:
npm run buildOpen Claude Desktop's config file:
OS | Location |
macOS |
|
Windows |
|
Linux (community builds) |
|
Add an entry under mcpServers, using the absolute path to your clone:
{
"mcpServers": {
"trello-ops-mcp": {
"command": "node",
"args": ["/absolute/path/to/trello-ops-mcp/dist/index.js"],
"env": {
"TRELLO_API_KEY": "your_api_key_here",
"TRELLO_TOKEN": "your_read_only_token_here"
}
}
}
}Restart Claude Desktop completely (quit, not just close the window). A new MCP tool icon should appear in the chat input, and trello-ops-mcp's tools should be listed there.
Common mistakes:
Relative path in args. Claude Desktop doesn't run from your project directory — it needs the full absolute path to dist/index.js.
Forgetting to build. If dist/index.js doesn't exist yet, Claude Desktop will fail to launch the server silently. Run npm run build first, and re-run it after pulling new changes.
Trailing commas or comments in the JSON config. Standard JSON doesn't allow either — a config that "looks right" but has one extra comma will fail to parse.
Editing the config while Claude Desktop is running. Config changes only take effect after a full restart.
Env vars set in your shell but not in the config's env block. Claude Desktop launches the server as its own process — it doesn't inherit your terminal's environment. Credentials must go in the env block shown above.
Troubleshooting:
Test the server manually first, outside Claude Desktop: node dist/index.js should print trello-ops-mcp server started to stderr and then sit waiting for stdio input (Ctrl+C to exit). If that fails, fix it before involving Claude Desktop at all.
Check Claude Desktop's own MCP logs (accessible from its developer/settings menu on most platforms) for the specific startup error.
Call health_check first from within Claude. It needs no credentials, so if it fails, the problem is the server process/config, not your Trello token.
If health_check works but every other tool fails, the problem is almost always the credentials in the env block — re-check them against Configuration.
MCP Inspector drives the server over stdio from a browser UI — useful for testing tools directly without a full agent in the loop.
npm run build
npx @modelcontextprotocol/inspector node dist/index.jsIn the UI: pick a tool from the list, fill in its inputs (e.g. board — accepts an ID, shortLink, or full URL), and run it. You'll see both the structured JSON result and the human-readable text summary the tool also returns.
Trello REST API
│
▼
Trello Client src/trello — typed, read-only HTTP wrapper (auth, pagination, error mapping)
│
▼
Pure Domain Analytics src/domain — deterministic classifiers & analytics, zero HTTP/MCP imports
│
▼
MCP Tools src/tools — validates input, orchestrates client + domain, formats output
│
▼
LLM Agent (Claude, or any MCP-capable client)Each layer only talks to the one directly below it. In particular, the domain layer never imports the Trello client — every domain function is pure (data in, data out), which is what makes it possible to unit-test all the analytics logic with fixtures and a fixed clock, with no network and no MCP mocking. A tool is the only place these two layers meet: it fetches raw data from the Trello client, hands it to a domain function, and formats the result.
get_list_flow → trello.getBoardActions() → classifyCardMovements() + computeListFlow() → MCP responseThe MCP layer computes and returns facts — movement counts, flow numbers, staleness thresholds, due-date math. It deliberately does not compute a board health score, classify a list as a "bottleneck," decide a card is "blocked," or judge whether someone is "productive." Concretely:
No board_insights, board_risks, what_needs_attention, detect_bottleneck, or recommend_actions tools exist, and none are planned.
get_list_flow reports incomingMoves/outgoingMoves/netFlow per list — never a "bottleneck" label. A list with netFlow: +17 is a fact; whether that's a problem depends on context the server doesn't have.
get_stale_cards reports cards with no recognized recent activity — never "blocked." A quiet card might be low priority, waiting on something external, or genuinely forgotten — Trello data alone can't tell those apart.
cardsMoved (get_card_movements/get_top_card_movers) measures workflow activity, not productivity or performance — a card can be moved by someone other than whoever did the underlying work.
An agent can combine these facts into a real answer (e.g. cross-referencing get_stale_cards with get_overdue_cards), but that interpretation happens in the agent's reasoning, not inside this server.
board accepts a Trello internal board ID, a shortLink, or a full board URL. since/before accept ISO 8601 timestamps. Every historical tool bounds its Trello Actions scan via maxActions (default 1000) and reports truncated: true rather than silently dropping data if the cap is hit.
Tool | Input | Returns |
| — | Server status. No credentials required. |
| — | Boards accessible to the configured account. |
|
| Lists on a board. |
|
| Members on a board. |
|
| Raw cards on a board. |
Tool | Input | Returns |
|
| Low-level, compact view of raw board action history. |
|
| Who created/renamed/archived/unarchived lists, with |
Tool | Input | Returns |
|
| Confirmed list-to-list card movements, optionally filtered. |
|
| Members ranked by movement count (default: last 7 days). |
|
| Incoming/outgoing/net movement counts per list (default: last 7 days). |
|
| One member's chronological activity feed. |
Tool | Input | Returns |
|
| Cards past due, incomplete, not archived (current state). |
|
| Cards due within N days, default 7 (current state). |
|
| Open cards with no recognized activity for N days, default 14. |
Due-date tools read the board's current card state (always complete, always current). Movement/flow/staleness/member tools read Trello's Actions history, which is bounded by maxActions and by however far back Trello itself retains action data — see truncated in each tool's output.
There is no what_should_i_review tool, and there never will be — this question is exactly the kind of subjective synthesis this server leaves to the agent. Here's what actually happens:
User asks: "What should I review today?"
The agent decides which facts it needs and picks tools accordingly — in this case, three:
get_overdue_cards — cards already past due
get_upcoming_due_cards — cards due soon
get_stale_cards — cards with no recent recognized activity
The MCP returns three sets of facts — card IDs, names, dates, thresholds — with no ranking, prioritization, or commentary attached.
The agent reasons over the combined results (e.g. noticing a card that's both overdue and stale) and only then produces a natural-language answer.
Every answer this server participates in takes this shape: user question → agent chooses tools → MCP returns operational signals → agent reasons over them → natural-language answer. Step 3 is where this server's job ends.
"Who moved the most cards this month?"
→ Agent calls get_top_card_movers with days: 30, then reports the ranked list with each member's cardsMoved count.
"What cards haven't moved recently?"
→ Agent calls get_stale_cards (default 14-day threshold), noting which results have historyComplete: false (uncertain) versus true (confirmed).
"Show overdue work."
→ Agent calls get_overdue_cards, presenting cards sorted most-overdue-first with daysOverdue for each.
"Which lists received the most work this week?"
→ Agent calls get_list_flow with days: 7 (or no days at all — that's the default), and reads off the lists with the highest incomingMoves.
"Are there overdue cards that also look inactive?"
→ Agent calls both get_overdue_cards and get_stale_cards, then intersects the results by cardId — a piece of reasoning this server deliberately leaves to the agent rather than doing itself.
Screenshots demonstrating the MCP Inspector and Claude Desktop integration will be added in a future release.
Read-only by construction, not just by convention. src/trello/client.ts is the only code in the project that makes HTTP calls to Trello, and every one of its methods issues a GET request. There is no method, no code path, and no tool that can call a mutating Trello endpoint.
Credentials never leave the environment. TRELLO_API_KEY/TRELLO_TOKEN are read from .env (via dotenv) or the process environment — never hardcoded, never committed (.gitignore excludes .env), and validated lazily so tools that don't need Trello still work without them.
No credential logging, ever. The logger writes only to stderr for operational messages (server start, log level) and never touches request data. Trello API errors are deliberately shaped to include only the HTTP status, the request path (never the query string, which is where the key/token live), and Trello's own error message — verified by dedicated tests.
A read-only-scoped Trello token is still recommended. Even though this server's code can't issue a write, a read-only token means a compromised environment or a future bug still can't touch your boards.
Action history is bounded, and truncation is never silent. Every tool that scans Trello's Actions API reports truncated: true when it stops early due to maxActions, and get_stale_cards explicitly marks a card historyComplete: false rather than asserting confidence it doesn't have.
If you find a security issue, please open an issue on the repository rather than a public discussion of the specifics.
npm run dev # run directly from TypeScript source (tsx), no build step
npm run build # compile to dist/
npm start # run the compiled server (dist/index.js)
npm run typecheck # type-check without emitting output
npm test # run the test suiteProject layout:
src/
index.ts # server bootstrap, stdio transport
config/ # env loading (general config + lazy Trello credentials), version
trello/ # Trello API client: HTTP, auth, board-ref normalization, errors, types
domain/ # pure classifiers/analytics: events, movements, flow, staleness, due dates
tools/ # MCP tool definitions, one file per feature area
utils/ # logger, centralized date-range validation
tests/
tools/ # tool-layer tests (mocked Trello client, real in-memory MCP transport)
trello/ # Trello client tests (board-ref normalization, pagination, mocked fetch)
domain/ # domain logic tests (fixture-based, fixed-clock, no network)
utils/ # date validation/resolution tests
fixtures/ # sanitized Trello payloads modeled on real captured shapesThe tools/domain/client separation is enforced by convention, not tooling — when adding to this codebase, keep domain functions free of HTTP/MCP imports, and keep Trello-shape-specific parsing inside src/trello/.
npm testA focused, high-value behavioral test suite — intentionally kept small rather than exhaustive (coverage percentage is not a goal here). The suite is fully offline — no test ever calls the real Trello API:
Domain tests exercise pure classifiers and analytics against fixture data (modeled on real Trello payloads captured during development, then sanitized) and, where time matters, a fixed injected clock.
Trello client tests mock fetch to verify auth/query construction, HTTP and rate-limit error mapping, and Actions pagination/truncation behavior.
Tool tests mock the Trello client and drive real McpServer/Client instances over an in-memory transport, proving the MCP wiring (validation, orchestration, structured output, safe error formatting) end-to-end for a representative tool from each category.
Ideas under consideration for future versions. None of these are committed, scheduled, or promised on any timeline — this is a list of directions, not a plan.
Remote MCP transport (currently stdio-only, by design, for v0.1)
SQLite cache for faster repeat queries on large boards
Webhook ingestion as an alternative to polling Trello's Actions API
Cross-board analytics (currently every tool is scoped to one board)
Historical snapshots for tracking board state over time, not just recent actions
Trend analysis (week-over-week movement/flow comparisons)
Agent-generated reporting — explicitly on the agent side of the boundary described in Design philosophy, not inside this server
Low-level historical inspection/debug tool: returns a compact, normalized view of a board's raw action history. For structural list-change auditing, prefer get_list_changes.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) | |
| actionTypes | No | Trello action type names to filter to, e.g. ["createList", "updateList"]. Unfiltered if omitted. |
| Name | Required | Description |
|---|---|---|
| actions | Yes | |
| truncated | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description conveys that this is a read-only inspection/debug tool and notes it returns a 'normalized' view, which adds behavioral context beyond the raw definition. However, it does not explicitly mention pagination behavior or potential performance implications, so it falls short of a 5.
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 only two sentences, front-loaded with the core purpose and then a clear alternative. Every word serves a purpose, with zero 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?
Given the existence of a full output schema and 100% schema coverage for parameters, the description provides sufficient context by clarifying the tool's niche and directing to an alternative. It lacks detailed edge-case guidance, but the schema fills most gaps, making this slightly above-average.
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 provides 100% coverage of all parameters with detailed descriptions, so the description does not need to add parameter-level semantics. The description's mention of 'raw action history' adds minor context but does not elevate beyond the schema's baseline.
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 tool returns a compact, normalized view of a board's raw action history, using specific verbs and resource. It explicitly distinguishes itself from sibling tool get_list_changes, making the purpose immediately obvious.
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 positions this as a low-level historical inspection/debug tool and directs users to get_list_changes for structural list-change auditing, providing clear when-to-use guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the cards on a Trello board, identified by ID, shortLink, or board URL. Returns raw card data (list, members, due date) — no overdue/analytics computation.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| includeClosed | No | Include archived/closed items in addition to open ones (default: false) |
| Name | Required | Description |
|---|---|---|
| cards | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns raw card data with specific fields (list, members, due date) and states it does not perform overdue/analytics computation. This adds behavioral clarity beyond the schema, though it omits details like pagination or default closed-card 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?
The description is a single, front-loaded sentence that conveys purpose, input, and return characteristics without redundancy or fluff. Every clause contributes meaningful information.
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 2-parameter tool with an output schema and no annotations, the description adequately covers purpose, input identification, return data, and scope exclusions. Minor omissions like pagination or ordering are not critical for this tool's complexity.
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 100% coverage with both parameters (board, includeClosed) described in detail. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline score of 3 applies.
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 tool 'Get the cards on a Trello board' with specific identification methods (ID, shortLink, URL) and return content (list, members, due date). The explicit 'no overdue/analytics computation' distinguishes it from sibling analytics tools like get_overdue_cards and get_upcoming_due_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 implies usage for raw card retrieval by stating it returns raw data and explicitly excludes analytics. This provides a clear context for when to use it, though it does not explicitly name alternative tools or provide exhaustive when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the lists on a Trello board, identified by ID, shortLink, or board URL.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| includeClosed | No | Include archived/closed items in addition to open ones (default: false) |
| Name | Required | Description |
|---|---|---|
| lists | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits beyond the basic operation. It does not mention that closed lists are excluded by default, do not indicate permissions, error behavior, or that it is a read-only operation. The identifier options are parameter semantics rather than behavioral transparency.
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 a single sentence that directly states the tool's purpose and key input flexibility. It is concise, front-loaded, and contains no filler or 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?
Given the simple purpose, complete input schema, and presence of an output schema, the description is adequately complete. It states the core function and identifier options, while parameter details are covered by the schema. It does not add usage context relative to siblings, but the overall context is sufficient for a basic getter.
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 100%, with both parameters already documented in the schema. The description repeats the board identifier options but adds no new meaning beyond what the schema already provides, meeting the baseline for high schema 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 ('lists on a Trello board'), and explicitly mentions that the board can be identified by ID, shortLink, or URL. This distinguishes it from sibling tools like get_board_cards or get_boards, which target different resources.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or alternative tools. Usage is implied by the purpose but not articulated, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the members on a Trello board, identified by ID, shortLink, or board URL.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) |
| Name | Required | Description |
|---|---|---|
| members | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. The description only restates the core function and board identifier options. It does not disclose what exactly is returned (e.g., full member objects vs. IDs), how errors are handled, or whether all members or only active members are included.
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 a single, front-loaded sentence that conveys the essential information with zero wasted words. It is concise and well-structured.
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 single-parameter read tool with an output schema, the description is adequate. It clearly identifies the input and what is retrieved. However, it could be slightly more complete by mentioning edge cases like missing boards or whether all members are returned, but overall it fulfills the basics.
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 100% and the description adds no new meaning beyond the schema—it simply repeats the board identifier options. The baseline for high coverage is 3, and the description does not go beyond that.
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?
Description uses a specific verb ('Get') and resource ('members on a Trello board'), making the tool's purpose unmistakable and clearly distinguishing it from sibling tools like get_board_lists, get_board_cards, and get_board_actions.
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 states that the board can be identified by ID, shortLink, or full URL, which is useful context. However, it does not explicitly explain when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Trello boards accessible to the configured account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| boards | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only restates the tool's purpose without detailing what 'accessible' includes (e.g., archived boards), the return format, authentication requirements, or potential rate limits. It adds no behavioral context beyond the 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?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity and directly communicates the core function.
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 tool with no parameters and an output schema, the description is sufficiently complete to inform an agent when to use it. It does not explain edge cases or the meaning of 'accessible,' but the output schema covers return values, so the overall package is minimal but adequate.
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 tool has zero parameters, which sets a baseline of 4. The description does not need to explain parameter syntax, and it adds no parameter-related detail, which is appropriate given the schema.
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 tool fetches Trello boards accessible to the configured account, with a specific verb ('Get') and resource ('Trello boards'). It distinguishes from sibling tools that target lists, cards, or members, and the 'accessible to the configured account' scope adds clarity.
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 this tool is used to retrieve all accessible boards, and the context is clear from the name and sibling tools, but it does not explicitly state when to use it vs alternatives or mention any exclusions or prerequisites. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List confirmed list-to-list card movements from a board's action history, optionally filtered by member, card, source list, or destination list. Workflow activity, not a productivity metric.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| cardId | No | Restrict results to this Trello card ID | |
| memberId | No | Restrict results to this Trello member ID | |
| toListId | No | Restrict results to movements into this Trello list ID | |
| fromListId | No | Restrict results to movements out of this Trello list ID | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) |
| Name | Required | Description |
|---|---|---|
| movements | Yes | |
| truncated | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes | |
| matchedMovements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only confirmed list-to-list movements are returned and frames results as workflow activity rather than a productivity metric. It does not mention auth, rate limits, or pagination details, but those are standard for a read-only Trello action query and the schema covers pagination via maxActions.
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 sentences, front-loaded with the action and resource, and a distinct second sentence for semantic nuance. No filler or repetition of schema details.
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 list tool with a full input schema and an output schema, the description covers the core purpose, filter options, and semantic caveat. It could add more explicit usage guidance, but it is complete enough given the schema and sibling context.
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 100% with descriptions for all 8 parameters, including examples for board and since. The description only restates the filter categories (member, card, source list, destination list) without adding additional semantics beyond the schema, so the baseline score of 3 applies.
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 ('List') and resource ('confirmed list-to-list card movements from a board's action history'), and immediately scopes the operation with optional filters. It distinguishes itself from productivity-oriented siblings by stating 'Workflow activity, not a productivity metric.'
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?
It provides clear context for when to use the tool (listing confirmed card movements with optional filters) and explicitly cautions that it is workflow activity, not a productivity metric. It does not name specific alternative tools, but the exclusion of productivity use cases gives some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Main structural audit tool: who created, renamed, archived, or unarchived lists on a board, optionally scoped to a date range and/or a single list.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| listId | No | Restrict results to structural changes on this specific Trello list ID | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) |
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| truncated | Yes | |
| matchedEvents | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the type of changes reported and optional filters, but doesn't mention pagination behavior, response format, rate limits, or authentication needs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that packs purpose, scope, and filtering options. No filler or 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?
With an output schema present, no need to describe return values. The description covers scope and intent well, but omits behavioral details like pagination limits that are only partially in the 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 coverage is 100%, so parameters are already well-documented. Description adds context on date range and list scoping, but doesn't add format or usage details beyond schema descriptions.
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?
Specific verb 'audit' plus concrete actions (created, renamed, archived, unarchived) and scope ('on a board', date range, single list). Clearly distinguishes from sibling tools like get_board_actions and get_list_flow.
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?
Labels itself the 'main structural audit tool', indicating primary use for list lifecycle events. Implies when to use, but doesn't explicitly contrast with siblings like get_board_actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns incoming and outgoing card movement counts by Trello list for a date range (explicit since/before, or the convenience days — default last 7 days if neither is given). Useful for seeing where card movement concentrates. This is a factual movement-flow signal only — it does not identify bottlenecks, throughput, or performance; that interpretation is left to the caller.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Convenience alternative to since/before: look back this many days from now. Cannot be combined with since/before. | |
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) |
| Name | Required | Description |
|---|---|---|
| flow | Yes | |
| truncated | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes | |
| totalMovements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the default behavior (last 7 days), the date range options (since/before or days), and the factual scope ('factual movement-flow signal only'). This goes beyond a basic summary, though it does not mention pagination or maxActions behavior that could affect results.
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 two sentences, front-loaded with the core action and result. The second sentence adds a precise caveat about what the tool does not do. No wasted words; every clause 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?
Given the tool's moderate complexity and the presence of an output schema, the description covers the essential context: what it returns, how to filter, default behavior, and interpretive boundaries. It is sufficient for an agent to decide when to use it and what to expect, without needing to enumerate return fields since the schema handles 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 100%, so baseline is 3. The description adds value by explaining the convenience relationship between days and since/before, and the default when neither is provided. This is not explicitly in the schema for each parameter, making the description more than just a repeat.
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 tool's function: 'Returns incoming and outgoing card movement counts by Trello list for a date range.' It specifies the resource (Trello lists), the action (counting movements), and the input (date range). This distinguishes it from sibling tools like get_card_movements (individual movements) or get_list_changes (list modifications) by focusing on aggregate movement flow.
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 use case: 'Useful for seeing where card movement concentrates.' It also gives an explicit when-not: 'does not identify bottlenecks, throughput, or performance; that interpretation is left to the caller.' However, it does not name alternative tools for those interpretations, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalized chronological activity feed for one board member: card movements, list structural changes, card creation, and card archival. Resolve by memberId when known; memberName is looked up against board members and rejected with a clear error if it's ambiguous or matches no one.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Convenience alternative to since/before: look back this many days from now. Cannot be combined with since/before. | |
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| memberId | No | Restrict results to this Trello member ID | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) | |
| memberName | No | Full name or username of a board member, used to resolve memberId when it isn't known. Rejected with a clear error if it matches zero or more than one board member. |
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| memberId | Yes | |
| truncated | Yes | |
| matchedEvents | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses significant behavioral traits: the feed is 'normalized', includes specific event types, and rejects ambiguous/non-matching memberName with a clear error. However, it does not mention pagination, rate limits, or the fact that it scans across pages (maxActions), leaving some behavioral gaps.
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, with the core purpose front-loaded in the first sentence and resolution logic in the second. No redundant or filler text.
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?
With a full input schema, an output schema, and a clear description of the tool's scope and behavior, the description is sufficiently complete for a getter tool. It could explicitly mention time-filtering parameters (since/before/days) but those are well-documented in the schema, so this is a minor gap.
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 already provides 100% parameter coverage with detailed descriptions for all 7 parameters. The description adds a marginal clarification about memberId vs. memberName resolution, but the schema already conveys this. Baseline 3 is appropriate since the schema does the heavy lifting.
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 what the tool does: provides a normalized chronological activity feed for one board member, listing specific event types (card movements, list structural changes, creation, archival). This specific verb-resource pairing distinguishes it from sibling tools like get_board_actions or get_card_movements, which are broader or focus on different aspects.
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 context: it is for member-specific activity, and the resolution note ('Resolve by memberId when known; memberName is looked up') gives parameter-selection guidance. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cards with a past-due date that aren't marked complete and aren't archived, based on the board's current card state (not action history). Sorted most-overdue first.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| listId | No | Restrict results to structural changes on this specific Trello list ID | |
| memberId | No | Restrict results to this Trello member ID |
| Name | Required | Description |
|---|---|---|
| board | Yes | |
| cards | Yes | |
| evaluatedAt | Yes | |
| totalOverdue | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses filtering criteria and sort order, which is helpful, but it does not mention whether the operation is read-only, requires permissions, or has pagination limits.
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 a single, front-loaded sentence that communicates scope, filtering criteria, and sort order without 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 description covers the core purpose and sorting, and an output schema exists for return values. It lacks explicit mention of optional filters listId/memberId and pagination behavior, but the schema covers the filters, so the description is adequately complete for this tool's complexity.
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?
All three parameters already have descriptions in the schema (100% coverage). The tool description adds no additional meaning to the parameters, meeting the baseline for high schema 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 defines overdue cards as past-due, incomplete, non-archived, based on current card state, and sorted most-overdue first. This distinguishes it from sibling tools like get_upcoming_due_cards and get_stale_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 implies usage for retrieving currently overdue cards but does not explicitly state when to prefer this over siblings. It does provide a key exclusion ('not action history') that hints at alternatives but stops short of naming them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns open cards with no recognized activity (creation, list move, archive/unarchive) for at least staleDays (default 14). Stale does not imply blocked — Trello data alone can't say why a card hasn't moved. When the underlying action history couldn't be fully scanned, affected cards are still returned but marked historyComplete: false rather than silently assumed stale.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| listId | No | Restrict results to structural changes on this specific Trello list ID | |
| memberId | No | Restrict results to this Trello member ID | |
| staleDays | No | A card with no recognized activity for at least this many days counts as stale (default: 14) | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) |
| Name | Required | Description |
|---|---|---|
| cards | Yes | |
| truncated | Yes | |
| totalStale | Yes | |
| evaluatedAt | Yes | |
| actionsScanned | Yes | |
| staleThresholdDays | Yes |
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. It reveals specific recognized activity types, the default staleDays threshold, and critically explains the historyComplete: false fallback when action history cannot be fully scanned. It also clarifies that staleness does not imply blockage, adding important context beyond the raw schema. This is exemplary transparency.
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 exactly two sentences, with the main action front-loaded. Every sentence adds value: the first defines the tool's purpose, the second clarifies caveats. There is no fluff or repetition of schema information.
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 list tool with a rich output schema and 100% parameter coverage, the description is remarkably complete. It covers purpose, default behavior, edge cases (incomplete history), and a key behavioral nuance (stale vs. blocked). No critical information is missing given the tool's complexity.
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 provides 100% coverage with clear descriptions for all five parameters (board, listId, memberId, staleDays, maxActions). The description adds a little extra context (e.g., default staleDays value and activity types) but does not explain parameters beyond what the schema already conveys. Baseline 3 is appropriate given the schema's completeness.
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 tool returns open cards with no recognized activity for at least staleDays. It uses a specific verb ('Returns') and resource ('open cards'), and defines what counts as 'recognized activity' (creation, list move, archive/unarchive). While it does not explicitly differentiate from sibling tools like get_overdue_cards, the concept of 'stale' is distinct and the description is unambiguous.
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 clear context about what the tool does and even cautions that 'stale does not imply blocked,' which helps set usage expectations. However, it does not explicitly mention when to use this tool versus alternatives like get_overdue_cards or get_card_movements, nor does it state any exclusions or prerequisites. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks board members by list-to-list card movements in a date range (explicit since/before, or the convenience days — default last 7 days if neither is given). This is a Trello workflow-activity metric (cardsMoved), not employee productivity or performance.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Convenience alternative to since/before: look back this many days from now. Cannot be combined with since/before. | |
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| limit | No | Cap on the number of ranked results returned (default: all) | |
| since | No | ISO 8601 timestamp — only include actions at or after this time (e.g. 2026-01-01T00:00:00.000Z) | |
| before | No | ISO 8601 timestamp — only include actions strictly before this time | |
| maxActions | No | Cap on the total number of actions scanned across pagination (default: 1000) |
| Name | Required | Description |
|---|---|---|
| movers | Yes | |
| truncated | Yes | |
| actionsScanned | Yes | |
| requestedRange | Yes | |
| totalMovements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the default date range and the type of metric (workflow activity), but does not explicitly state that this is a read-only operation or describe the output structure. The lack of mention of side effects or return format is a gap, but the description does add meaningful context beyond the 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 two sentences, front-loaded with the primary action, and every word earns its place. The second sentence provides a crucial nuance about the metric's intended use, with zero 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?
Given the tool's complexity (6 parameters, output schema present, no annotations), the description adequately explains the core functionality, date handling, and metric semantics. It leaves out details about pagination limits and exact ranking criteria, but those are partially captured by schema parameter descriptions and output schema. Overall, it provides sufficient context for an agent to select and invoke 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default behavior when no date range is provided ('default last 7 days') and clarifying that the 'days' parameter is a convenience alternative to since/before. This goes beyond the schema's param descriptions.
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 tool's purpose: it ranks board members by list-to-list card movements within a date range. The verb 'ranks' combined with the specific resource (board members) and metric (card movements) is precise. It also distinguishes itself from general activity tools by noting it measures workflow activity (cardsMoved) rather than productivity.
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 provides clear context on when to use this tool: when analyzing card movement activity on a Trello board. It explains the convenience of the 'days' parameter and the default behavior (last 7 days). While it does not name alternative sibling tools, it clarifies the metric's scope, giving adequate guidance for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cards due within the next N days (default 7) that aren't marked complete and aren't archived, based on the board's current card state (not action history). Sorted soonest-due first.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Trello board ID, shortLink, or full board URL (e.g. https://trello.com/b/abc123/my-board) | |
| listId | No | Restrict results to structural changes on this specific Trello list ID | |
| memberId | No | Restrict results to this Trello member ID | |
| withinDays | No | How many days ahead of now to look for upcoming due dates (default: 7) |
| Name | Required | Description |
|---|---|---|
| cards | Yes | |
| withinDays | Yes | |
| evaluatedAt | Yes | |
| totalUpcoming | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are based on current card state rather than action history, excludes complete/archived cards, and sorts by due date. It does not mention potential limitations (e.g., cards without due dates) or permission requirements, but the core behavioral traits are well disclosed.
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 sentences, immediately states the core function, then adds essential qualifiers and sorting. No redundant wording.
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 4-parameter tool with output schema, the description covers the key behavior: time window, exclusions, data source, and sort order. It lacks discussion of edge cases (e.g., cards without due dates) but is largely sufficient for an agent to invoke 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?
Schema coverage is 100%, so the baseline is 3. The description adds the default value context ('default 7') which is also present in the schema, and clarifies filters (not complete/archived), but doesn't add parameter-specific meanings beyond schema definitions.
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 identifies the tool's purpose: returning cards due within a configurable future window, with explicit exclusions (complete, archived) and sorting ('soonest-due first'). It distinguishes from sibling tools like get_overdue_cards and get_board_cards by noting it uses current board state rather than action history.
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 communicates the intended use case ('cards due within the next N days') and key filters, but does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to select it over get_overdue_cards, though explicit sibling differentiation is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks that the trello-ops-mcp server is running and reachable. Requires no Trello credentials — useful for verifying the MCP connection itself before troubleshooting anything else.
| Name | Required | Description | Default |
|---|---|---|---|
No 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 that 'Requires no Trello credentials,' which is a meaningful behavioral trait. It doesn't describe return formats or error behavior, but for a simple health check the description is adequate.
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 sentences with no waste. The purpose is front-loaded, and the usage note is secondary. 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?
Given zero parameters and simple scope, the description covers purpose and usage. It lacks explicit return-value info, but the tool is straightforward and the description is otherwise complete.
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 tool has zero parameters, so per rubric baseline is 4. No parameter explanation needed.
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 tool's function: 'Checks that the trello-ops-mcp server is running and reachable.' The verb 'checks' combined with the specific resource (server) distinguishes it from sibling tools that fetch Trello data.
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 phrase 'useful for verifying the MCP connection itself before troubleshooting anything else' provides a clear when-to-use context. It doesn't name specific alternative tools, but the context is strong enough for a health check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target a distinct resource and concern (boards, lists, members, cards, actions). The main overlap is between get_board_actions, get_list_changes, get_card_movements, and get_member_activity, but the descriptions explicitly differentiate raw history from normalized/audit views and direct users to the intended tool.
All tools follow a consistent get_* pattern with descriptive noun phrases (e.g., get_board_lists, get_list_changes, get_top_card_movers). There is no mixing of styles or vague verbs, making the set predictable.
With 14 tools, the set is well-scoped for a Trello operations/monitoring server. Each tool addresses a specific query need without redundancy, and the count sits comfortably within the ideal range.
The server covers the core read/monitoring surface for Trello boards: lists, members, cards, activity, and action history. The only notable gap is a single-card detail endpoint, but get_board_cards already provides raw card data, so agents can work around this minor omission.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bienherasme/trello-ops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
