.png)
Your agent needs to read and write Trello. Trello ships an official MCP server at mcp.trello.com/v1 and a full REST API at api.trello.com/1. They are not the same object: different capability coverage, different auth generations, different operational surface in production. The choice is not permanent either, since what your agent does determines which path fits. Here is how to pick.
Both let an agent act on a user's boards. One is a hosted tool interface Atlassian maintains; the other is the raw REST surface that has powered Trello integrations for years.
The Trello MCP server is Atlassian's official, first-party server, launched in 2026 and hosted at mcp.trello.com/v1. It is distinct from the Atlassian Remote MCP Server that covers Jira, Confluence, and Bitbucket; that server does not include Trello. An agent connects through a browser-based OAuth consent flow, selects a workspace, and grants Read, Write, and Search permissions. You can read the official overview on the Trello MCP page.
The Trello REST API is versioned under api.trello.com/1 and exposes the full workspace: boards, lists, cards, checklists, labels, members, comments, attachments, and webhooks. Every capability the MCP server has is reachable here, plus a large surface the MCP server does not touch. The official reference is the Trello REST API introduction.
An API key is tied to a Trello Power-Up, created at the Power-Ups admin page. That detail matters because it is where both paths ultimately anchor their credentials, and it is the first thing your auth layer has to model correctly.
Four dimensions decide this for an agent builder: what the agent can do, which auth path each puts you on, what you own in production, and when each one wins.
The MCP server covers the day-to-day loop well: search a workspace, read boards and cards, create and move cards, mark work done, manage checklists, and handle Trello's newer Inbox and Planner views. The gaps appear when an agent needs to comment, attach files, react to changes, or clean up.
The MCP server's 15 tools are consolidated, action-dispatch tools: one trellomcp_trello_write_card tool covers create, update, move, archive, mark done, and label attach or detach through an action parameter. So 15 understates the real operation coverage. Scalekit's REST connector, by contrast, exposes 36 granular tools like trello_create_card and trello_add_comment_to_card, one operation each.
Two absences are structural, not cosmetic. Card comments are where decisions live, and Atlassian has publicly confirmed the MCP server does not expose them yet. Webhooks are worse: MCP is a request and response interface with no event-subscription surface, so any agent that must react when a card moves to Done needs the REST API. The MCP server also performs no destructive deletes by design.
This is where Trello inverts the usual MCP vs API story. For most tools the MCP path carries the auth limitation. For Trello, the MCP path is the modern one.
The MCP server uses a browser-based OAuth consent flow, classified by Scalekit's connector as OAuth 2.1 with Dynamic Client Registration. The user picks a workspace and approves Read, Write, or Search scopes. It is built for interactive, user-present sessions. A headless agent with no browser cannot complete that consent on its own. For a deeper look at Dynamic Client Registration in OAuth2 and its role in agentic auth, that post covers the mechanics in detail.
The REST API does not support OAuth 2.0 at all; Atlassian has stated this directly. Per-user delegation runs on OAuth 1.0a, which means your service signs every request with HMAC-SHA1 using your application secret. Most modern auth libraries default to OAuth 2.0, so OAuth 1.0 support has to be selected or hand-rolled. That is real integration cost.
For single-account, headless automation, the REST API also accepts a static API key plus user token in the query string, with no signing. Tokens can be set to expire in 1 hour, 1 day, 30 days, or never, chosen at generation and fixed after. Convenient for one account; it does not express per-user permissions across many.
Both paths produce one credential per user. The MCP OAuth flow yields a per-user session; the REST path yields an OAuth 1.0a token or a key-and-token pair per user. In neither case does the path itself store, rotate, or revoke those credentials. That is infrastructure you own regardless. The divide between single-tenant and multi-tenant tool calling agent auth shapes every design decision here.
The question in production is simple: what breaks, what needs your attention, and who fixes it.
Atlassian hosts the server, ships tool updates, and normalizes the schemas. Your agent picks up new capabilities without a redeploy. What you still own: the credential per user, detecting revocation, and tenant isolation. Tool schemas are unversioned, so a server update can change a tool's shape under you.
You own endpoint selection, request construction, retries, pagination, rate limit handling, and the entire token lifecycle, including the OAuth 1.0a signing. The REST path also has documented rate limits: 300 requests per 10 seconds per API key, and 100 requests per 10 seconds per token. A 429 means back off. The tradeoff is control and stability: the /1 surface is long-lived and predictable.
The decision comes down to how your agent runs and what it needs to touch.
Use Trello MCP when:
Use the Trello REST API when:
The awkward part of Trello is the auth: OAuth 1.0a signing on one path, an OAuth consent flow on the other. Scalekit removes both. It offers two connectors, one per path, and handles the credential mechanics behind a single interface. The Trello REST connector signs OAuth 1.0a for you; the Trello MCP connector manages the OAuth 2.1 flow.
Install the SDK and set your Scalekit environment variables. The examples below use Python.
Each user authorizes Trello once. Scalekit stores the resulting credential and never exposes it to your agent runtime. The connection_name must match the connection you created in the Scalekit dashboard exactly; use "trello" for the REST path or "trellomcp" for the MCP path.
Before the agent runs, retrieve the tools scoped to the current user's connected account. This is not a flat catalog; it is the surface that user authorized. Scoping the tool surface is what keeps selection accurate and context lean, especially when the REST connector alone carries 36 tools. This pattern is exactly what token-efficient tool calling recommends for keeping agent context lean.
The LangChain adapter maps the scoped tools straight into StructuredTool objects, so you register them on an agent without hand-writing schema conversion. The same call works for either connection by swapping connection_names. For a deeper look at how LangChain tool calling fits together, see LangChain Tool Calling: How It Works, Where It Stops, and How Scalekit Completes It.
When you want a deterministic, single call instead of an agent loop, execute a tool by name. Use trello_create_card on the REST connector, or trellomcp_trello_write_card on the MCP connector.
Whichever path you pick, every user in a multi-tenant agent has their own Trello credential. Fifty customers is fifty credentials, each with its own lifecycle. The path changes the token type; it does not change the infrastructure you need.
The MCP OAuth flow gives you a per-user session. The REST path gives you an OAuth 1.0a token or a key-and-token pair. In both cases the credential must live somewhere encrypted, isolated per tenant, and revocable when a user disconnects. Trello tokens can be revoked by the user at any time, and your agent only learns about it from a failed call unless you are watching. Scalekit's connectors handle the OAuth flow, token storage, and rotation for both paths, so the MCP vs API decision does not change your auth layer. The credential ownership patterns across agent tool-calling piece covers this architecture in full.
A shared credential gives every user the same surface. Connected accounts invert that: scope is a function of identity, so what the user cannot do, the agent cannot do. Loading all 36 REST tools also burns context and degrades selection before the agent reads the request; scoping to the five or ten a task needs fixes both.
Most real agents call more than Trello. A Virtual MCP server gives every agent one scoped endpoint that declares exactly which tools it can see and whose credentials it acts with. One server definition serves all users; a short-lived session token is minted per run, scoped to that user's connected accounts. There is no MCP server to deploy, host, or maintain. The difference between MCP and APIs covers the underlying model in depth.
In production you need to answer who did what. Scalekit logs each downstream tool call: which user, which tool, which connected account, and the outcome. That record is the difference between an agent you can audit and one you cannot, as covered in the agent tool observability guide.
If your agent is interactive and its job is searching, reading, and creating Trello work, the official MCP server is the faster path, and it hands you the modern OAuth flow instead of OAuth 1.0a signing. If your agent runs headless, needs comments or attachments, must react to changes through webhooks, or has to delete, the REST API is the only complete path.
The single question that decides it: does your agent need to react to Trello events or touch comments, attachments, and deletes? If yes, build against the REST API. If no, the MCP server is on the table. Either way the credential problem is identical, and that is what needs production-grade infrastructure.
Start from the Scalekit Trello connector, browse the full connector catalog, or model the pattern on templates like the engineering standup agent and the DevOps assistant agent. Usage-based details are on the pricing page.
Building a Trello agent and want a second pair of eyes on the auth model? Join the Scalekit Slack community, or talk to us for help right away.
.webp)
