When Your AI Tool Can't Post to Your Blog (A Debugging Story)
When Your AI Tool Can't Post to Your Blog (A Debugging Story)
There's a specific kind of frustration that hits when the tool you built to save time is the thing eating your time.
Today I spent about an hour debugging why my MCP server — a little Node.js process that lets Claude publish directly to this blog — was silently failing every time I asked it to post something.
The fix was two backslashes. That's it. Two characters.
But the journey there was worth writing down.
## What Is an MCP Server, Anyway
MCP stands for Model Context Protocol. It's a standard that lets AI assistants like Claude connect to external tools — file systems, databases, APIs — and actually do things instead of just talking about them.
My setup: a custom MCP server I built that connects Claude to this blog's Firestore database and Cloudflare R2 storage. When it works, I can tell Claude "publish this post" and it happens. No copy-pasting, no opening dashboards, no switching tabs.
When it doesn't work, I get No result received from client-side tool execution — which is one of those error messages that tells you exactly nothing.
## The Symptom
I'd just finished writing a devlog about XuLang Edu. Asked Claude to publish it. Nothing. The tool call went out, came back empty. Tried again. Same thing.
The MCP tools were visible — Claude could see them, could try to call them. But responses never arrived. Like sending a letter and watching it disappear at the post office.
## The Investigation
First thing I checked: is the server actually running?
cd C:\MyJourney\gianghaison-mcp
node index.js
ERROR: FIREBASE_SERVICE_ACCOUNT_PATH env var not set
That's a real error. But also — slightly misleading. The MCP server is supposed to get its environment variables from claude_desktop_config.json, not from the terminal. Running it directly without those vars was always going to fail.
What this actually told me: the server starts, reads env vars, crashes if they're missing. So the real question was: is the config file actually passing the vars correctly?
Found the config file at C:\Users\ghson\AppData\Roaming\Claude\claude_desktop_config.json — after first looking in the wrong place (ASUS instead of ghson as the username, a classic).
And there it was:
"args": ["C:\\\\MyJourney\\\\gianghaison-mcp\\\\index.js"]Four backslashes. Where there should be two.
## The Bug
In JSON, you escape a backslash with another backslash. So a Windows path like C:\MyJourney becomes C:\\MyJourney in JSON.
Somewhere along the way — probably when the config was edited manually — each \\ got doubled to \\\\. Which means the actual string being passed to Node.js was C:\\MyJourney\\gianghaison-mcp\\index.js with literal double backslashes.
Windows doesn't know what to do with C:\\MyJourney. The path doesn't exist. The process fails to start. Claude gets no response. I get no error message.
Silent failure. The worst kind.
There was also a second issue: the indentation of the gianghaison-blog block inside mcpServers was off — it wasn't properly nested. Valid enough JSON that no parser complained, but Claude Desktop apparently didn't pick it up correctly.
## The Fix
Simple. Replace:
"C:\\\\MyJourney\\\\gianghaison-mcp\\\\index.js"With:
"C:\\MyJourney\\gianghaison-mcp\\index.js"Fix the indentation. Restart Claude Desktop. Done.
While I was in there, I also rewrote the MCP server itself — version 4.0.0. Removed the googleapis dependency (leftover from an older version that had Google Sheets integration, now removed). Added proper stderr logging so next time something breaks, I'll actually see where it breaks. Cleaned up the error handling.
The whole server is about 280 lines of straightforward Node.js. No magic, no framework. Just Firebase Admin SDK talking to Firestore, and an S3 client talking to Cloudflare R2.
## Testing It
After the fix, I ran a quick sanity check — created a draft test post, confirmed it appeared in Firestore, deleted it. Then published the actual devlog I'd been trying to post for an hour.
✅ Bài viết đã tạo!
ID: pDOhU8seuPmFobgiQAP4
Status: published
URL: https://gianghaison.me/blog/building-xulang-edu-devlog-march-2026
One tool call. Two seconds. Done.
## What I Actually Learned
The error wasn't in my code. The error was in a config file I'd edited by hand, in a format (JSON with Windows paths) that's specifically hostile to manual editing.
A few things that would have saved me time:
Log everything at startup. The new version writes to stderr at every step — Firebase init, R2 init, each tool call. If something fails, I'll know exactly where.
Test the server directly before blaming the AI. Running node index.js with the right env vars set would have immediately shown me whether the server itself was broken or the config was broken. I jumped to "the code is wrong" before checking "the config is wrong."
Double backslashes in JSON on Windows are a trap. If you're writing Windows paths in JSON config files — use a script to generate them, don't type them by hand.
## The Irony
I built this tool to make publishing effortless. The idea was: write something, tell Claude to post it, move on. No friction.
And mostly it works. Today it didn't, and fixing it took longer than just opening the Firebase console and pasting the post manually would have.
But here's the thing about building your own tooling: the investment is front-loaded. I spent an hour today. For the next hundred posts, I spend zero minutes on publishing.
That math still works out.
This post was published using the MCP server described in this post. Correctly configured, this time.