Should I Build My Own MCP for Trello? Yes, But Keep It Thin
After wiring Trello directly into the game, I kept asking myself the same question:
Should I build my own MCP for this, or am I just making extra work?
My answer now is yes, build it, but keep it thin.
This topic came up in my workflow post and my infrastructure post, but I wanted one post that stays focused on the actual tradeoff.
Where the Old Integration Helped
The direct Trello integration did exactly what I needed at first. I could hit F9 in game, file a bug with context and screenshot, and keep moving. For early momentum that was a great call.
The weakness only showed up once the workflow got heavier and more shared: secrets in places they should not live, repeated request formatting logic, and no strong boundary for automation.
Code Compare: Old Direct Trello vs New MCP Bridge
This is the practical difference.
Old direct integration in game client
The reporter built Trello requests directly and carried auth details in runtime-facing code:
1
2
3
4
5
6
7
8
9
10
var url = "https://api.trello.com/1/cards?key=" + TRELLO_KEY + "&token=" + TRELLO_TOKEN;
fetch(url, {
method: "POST",
headers: {"Content-Type": "application/json"},
body: JSON.stringify({ idList: TRELLO_LIST_ID, name: title, desc: fullDesc, pos: "top" })
})
.then(function(r) { return r.json(); })
.then(function(card) {
// then upload screenshot directly to Trello attachment API
});
It worked, but the client had too much responsibility.
New game client path (thin boundary)
Now the game only posts to one local tool endpoint:
1
2
3
4
5
6
7
8
9
10
fetch("/tools-api/bug-report", {
method: "POST",
headers: {"Content-Type": "application/json"},
body: JSON.stringify({
title: desc.substring(0, 80),
description: desc,
context: context,
screenshotDataUrl: screenshotDataUrl
})
});
That endpoint is proxied by tools/html5_static_server.js to a local MCP bridge.
MCP side (where the Trello logic now lives)
The MCP server exposes explicit tools such as trello_bug_create, trello_bug_move, and trello_bug_resolve, and keeps auth and policy in one place:
1
2
3
4
5
6
7
8
9
10
11
const TOOL_DEFINITIONS = [
{ name: "trello_bug_create", ... },
{ name: "trello_bug_move", ... },
{ name: "trello_bug_resolve", ... }
];
async function runTool(name, args) {
if (name === "trello_bug_create") return await apiCreateCard(config, args);
if (name === "trello_bug_move") return await apiMoveCard(config, args);
if (name === "trello_bug_resolve") return await apiResolveBug(config, args);
}
That is the key shift: the app submits intent, the MCP layer owns Trello details.
What MCP Adds in Practice
MCP does not make bugs easier to understand, but it does make integration behavior more reliable. You get one contract for multiple clients, centralized env-based secrets, better input validation, and cleaner idempotency/audit hooks.
For my workflow, that matters because I am using both Codex and Claude heavily. A shared tool contract reduces drift between sessions and between model providers.
Is It Worth Building Your Own?
If you file occasional bugs manually, maybe not. If you are running this loop constantly and want safe automation, yes.
I am in the second camp, so a thin custom MCP is worth it. Thin is important. I am not trying to build a giant platform. I just want the boring parts handled correctly every time.
For me, done looks like this: no Trello secrets in client code or docs, full bug lifecycle covered by tool calls, and both Codex and Claude using the same interface without custom glue each time.
That is enough value for a small, focused service.