Forem: Patrick Rary

7 bugs I caught in my MCP server before publishing (and why I almost shipped a data-corruption disaster)

Patrick Rary — Fri, 22 May 2026 04:59:39 +0000

I shipped elementor-mcp-agent v1.0 today — an open-source Model Context Protocol server that lets Claude (and any MCP client) drive WordPress Elementor across many client sites. It's MIT, on npm as elementor-mcp-agent, listed in the official MCP Registry.

Repo: github.com/Mogacode-ma/elementor-mcp-agent

What I want to write about isn't the architecture — it's the 7 bugs I caught only because I forced myself to test end-to-end against a live WordPress install before publishing. Three of them would have silently corrupted data on a client site in production. The others would have just looked broken. All of them would have been a customer-support nightmare.

This post is the bug list, with context. If you're building an MCP server (or any automation against an opinionated SaaS), these patterns apply.

The setup

I run a small agency. We manage ~50 WordPress + Elementor Pro sites for clients across Belgium, France, Luxembourg and Morocco. Day-to-day operations are predictable: text updates, image swaps, template synchronization, plugin updates, backups. Cumulatively painful.

MCP felt like the right shape for it: type-checked tools, explicit side effects, confirmation dance for destructive ops. I built 24 tools across 7 categories (sites, pages, widgets, templates, WP-CLI, screenshots, fleet versions).

My v0.1 passed npm run build, npm test, ESLint, tsc --noEmit. I almost published it without touching a real Elementor install.

I'm glad I didn't.

Bug #1 — WordPress REST API silently drops writes to unregistered postmeta keys

The symptom: I implemented automated backups by writing the current _elementor_data to a timestamped postmeta key (_elementor_data_backup_2026-05-22T04-35-37-847Z) via PUT /wp-json/wp/v2/pages/{id}. The API returned 200 OK. My code marked the backup as successful. The subsequent elementor_find_replace applied with confidence.

When I tried to verify via wp post meta list 8 | grep backup, the result was empty.

The root cause: WordPress REST API requires register_meta() with show_in_rest: true for a postmeta key to be writable through REST. Plugins like Elementor register their canonical keys (_elementor_data, _elementor_page_settings). Custom keys you invent at runtime are silently dropped by REST.

200 OK. No warning. No error.

The fix: switched backup to WP-CLI via SSH (always works). Local JSON file as fallback when SSH isn't configured. REST is no longer trusted for non-canonical writes.

The lesson: any REST API that requires schema registration for meta-like fields will silently swallow your writes when the schema isn't there. Test that the value actually persists. Don't trust the response code.

Bug #2 — `wp` binary not in non-interactive SSH PATH

After fixing #1, I tried again. New error:

/bin/bash: line 1: wp: command not found

I'd been testing in my local terminal where wp was aliased. On managed WordPress hosts (Infomaniak, in this case), wp-cli is usually installed at ~/bin/wp.phar and invoked as php ~/bin/wp.phar. The non-interactive shell that ssh user@host "command" uses has a stripped-down PATH that doesn't include ~/bin.

The fix: auto-detection at first SSH connection — probe command -v wp, fall back to ~/bin/wp.phar, then ~/wp-cli.phar. Cache per-site. Allow explicit override via ssh.wp_cli_path config field.

The lesson: non-interactive SSH sessions have a different PATH than interactive ones. If your tool spawns remote commands, never assume a binary is in PATH. Probe or accept an explicit path.

Bug #3 — SSH banner pollutes stderr and corrupts output parsing

OpenSSH recently started printing a warning on connections that don't use a post-quantum key exchange algorithm:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

It goes to stderr. My code captured stderr and concatenated it into the error message. So a successful wp post meta get call would still surface this warning as if it were an error.

The fix: filter known-benign stderr lines after capture. Whitelist by substring (post-quantum, openssh.com/pq, decrypt later, etc.) before deciding the operation failed.

The lesson: stderr is not synonymous with "error." Tools that pipe stderr into error-handling paths need to filter benign banners.

Bug #4 — "Default Kit" returned as a widget in template_type=widget filters

The query /wp-json/wp/v2/elementor_library?meta_key=_elementor_template_type&meta_value=widget was supposed to return the global widgets on a site. It returned the Default Kit (Elementor's site-wide design tokens) which has _elementor_template_type=kit, not widget.

The root cause: WordPress REST meta_value filtering is unreliable for meta keys that aren't register_meta-declared. In practice, it falls back to a meta_key presence check, ignoring the value.

The fix: fetch all elementor_library entries (no meta_value filter), then filter client-side on meta._elementor_template_type === 'widget'.

The lesson: don't trust server-side filters on unregistered meta. Always validate the response structure matches your intent.

Bug #5 — `_elementor_page_settings` is an object via REST, a string via WP-CLI

When I added duplicate_elementor_page, the copy path did:

read source → copy data + page_settings → write to new page via REST PUT

It failed with:

"Le paramètre meta._elementor_page_settings n'est pas de type object."

The cause: GET /wp-json/wp/v2/pages/{id}?context=edit returns meta._elementor_page_settings as a parsed object (Elementor registers it that way). wp post meta get returns it as a serialised JSON string. My code typed it as string everywhere, so when REST returned an object and I passed it back via REST PUT (expecting JSON string serialization in my templating), the API rejected the type mismatch.

The fix: normalize on read. If you got a string, JSON.parse() it before REST writes. If you got an object, JSON.stringify() it before WP-CLI writes. Don't assume one transport's representation matches the other.

The lesson: when two transports read/write the same field with different serialization rules, normalize at the boundary, not in the middle.

Bug #6 — Headless Chrome cold-start exceeds 30s

I built a screenshot_page tool using chrome --headless --screenshot=... via child_process.spawn. Locally it was instant. On the first call after a long idle period, it timed out at 30s. Chrome was downloading codec libraries or whatever it does on first-launch in headless mode.

The fix: bump the default timeout from 30s to 60s. Document that this is a one-time cost per Chrome cold start.

The lesson: cold-start latency on local tools is real and often invisible during dev. Set timeouts based on worst-case, not happy-path.

Bug #7 — Templates listing had the same filter bug as globals (Bug #4)

I'd written the templates listing code right after the globals code, and copy-pasted the same broken meta filter pattern. Caught it when I tested list_elementor_templates with type='widget' and got back the Default Kit again.

The fix: same client-side filter pattern.

The lesson: a bug in one place is a bug in N places where the same pattern is reused. Search the codebase for the smell before declaring the bug fixed.

What I'd take from this for any MCP build

End-to-end test against a live target before publishing — always. Unit tests + lint + typecheck told me v0.1 was "ready." End-to-end told me 7 things were broken.
Don't trust REST silent acceptance. 200 OK means "I received your request," not "I persisted your change." Verify post-write that the value actually exists.
Filter at the boundary, not in the middle. Type mismatches between transports (REST vs CLI, JSON vs YAML, etc.) are easier to handle at the read/write edge than to track through your domain code.
stderr ≠ error. Don't conflate them.
PATH is not what you think it is in non-interactive shells. Probe or accept explicit paths.
Cold starts are real. Set timeouts based on worst case.
Update the skill / playbook that taught you the safe patterns. I patched the upstream WordPress-Elementor skill on GitHub with the three REST quirks I'd surfaced, so the next person doesn't have to learn them the hard way (PR #92 on jezweb/claude-skills).

Try it

npx -y elementor-mcp-agent

You'll need:

A WordPress site with Elementor installed
An Application Password for an admin user
Optionally SSH access for WP-CLI tools

Config snippet for Claude Desktop / Code in the README.

The MCP is on the official registry: search "elementor-mcp-agent" in your favourite MCP-aware client.

If you hit a bug, open an issue with the exact tool call + response (sanitize tokens). I'll usually patch within a day. Battle-tested against an agency fleet — but every WordPress install is its own snowflake, so PRs and bug reports welcome.

⭐ if it saved you time.

Built by MogaCode in Essaouira.

Building an MCP server for a Swiss hosting provider (and what reverse-engineering its manager taught me)

Patrick Rary — Thu, 21 May 2026 16:46:58 +0000

I spent the last six weeks building an unofficial MCP server for Infomaniak — the Swiss hosting provider — that lets Claude (and any MCP client) drive web hosting, mail, kDrive, DNS, SSL certificates and AI tools from natural language. It's MIT, on npm as infomaniak-mcp-agent, runs locally over stdio. This post walks through what I learned, what's surprisingly hard, and what I'd do differently.

Repo: https://github.com/Mogacode-ma/infomaniak-mcp-agent

Why an MCP for Infomaniak specifically

I run 200+ websites for clients across Belgium, Luxembourg, France and Morocco. Most live on Infomaniak (managed cloud, shared hosting, mail, DNS). Day-to-day operations are: provision a new site, swap a DNS record, add a mailbox, request an SSL cert, audit which domains expire in the next 60 days.

These tasks are all doable from the manager UI, all doable via the public API — but only one or two clicks/calls each, and they don't compose. Claude is good at composition: "audit all my DNS zones for missing DNSSEC, list every domain whose certificate expires in the next 30 days, and create a redirect from www.legacy-site.be to legacy-site.be on the production hosting." That's three API calls minimum, and the cognitive overhead of remembering the right endpoint each time is the friction I wanted to remove.

MCP is the right shape for this:

Tools are typed (Zod → JSON Schema → MCP)
Side effects are explicit (idempotent? destructive? confirmation required?)
The LLM doesn't need to know HTTP — it sees a catalogue of named operations

The architecture in one paragraph

A single Node 18+ binary, ESM, stdio transport. 54 tools registered with the MCP SDK, each backed by a thin function calling api.infomaniak.com (Bearer token) or manager.infomaniak.com/proxy/... (cookie-authenticated). A token-bucket throttles to 60 req/min (Infomaniak's hard cap). Confirmation tokens for destructive operations (TTL 60s by default). Per-tool tests, ESLint, Prettier, gitleaks, CodeQL, vitest with 35% coverage and climbing.

Install: npx -y infomaniak-mcp-agent. Config: one env var (INFOMANIAK_API_TOKEN), generated at https://manager.infomaniak.com/v3/api-token.

The first surprise: the public API is missing half of what the manager does

I started with the public Infomaniak API. Documented at https://developer.infomaniak.com, neat OpenAPI-ish spec, Bearer auth. Within a week I'd wrapped most read operations: list sites, list databases, list domains, list mailboxes.

Then I tried to create a site. The public POST endpoint returned 200 OK with a site ID. The site never appeared in the manager. No error. Just... nothing.

I diffed the network tab of the manager's "Create site" wizard against what I was sending. The manager wasn't calling the public API at all. It was calling manager.infomaniak.com/proxy/<int>/v3/api/proxypass_2/1/... with a different payload shape, and with two cookies (SASESSION + MANAGER-XSRF-TOKEN) instead of Bearer auth.

The "public API" silently ignores the operation. The "manager-private API" actually creates the site.

The same pattern holds for: database creation, FTP/SSH user creation, mailbox creation, redirection creation, password rotation. The public API is read-mostly. Real automation requires the manager-private surface.

This is documented honestly in the repo's REVERSE-ENGINEERING.md. The cookie extraction is done with chrome-cookies-secure in memory only — nothing is written to disk.

The second surprise: Infomaniak's rate limit is shared per token

60 req/min sounds generous until you write a workflow that iterates over 50 domains and makes 3 calls each. You hit the limit in 30 seconds and Infomaniak starts returning 429 with a 60-second cool-off.

I implemented a token-bucket in src/throttle/:

class TokenBucket {
  private tokens: number;
  private readonly capacity: number;
  private readonly refillPerMs: number;
  private lastRefill = Date.now();

  constructor(capacityPerMinute: number) {
    this.capacity = capacityPerMinute;
    this.tokens = capacityPerMinute;
    this.refillPerMs = capacityPerMinute / 60_000;
  }

  async acquire(): Promise<void> {
    while (this.tokens < 1) {
      this.refill();
      if (this.tokens < 1) await sleep(50);
    }
    this.tokens -= 1;
  }

  private refill(): void {
    const now = Date.now();
    this.tokens = Math.min(this.capacity, this.tokens + (now - this.lastRefill) * this.refillPerMs);
    this.lastRefill = now;
  }
}

Wrapped around every HTTP call. Workflows like audit_dns_zones now run reliably across 50+ domains, just slower (1 second per call instead of 100 ms — but they finish).

The third surprise: destructive operations need a confirmation dance

Claude is enthusiastic. Give it a tool called delete_site and a thread of context saying "let's clean up old test sites", and it will happily delete production.

The MCP spec has tool annotations (destructiveHint, idempotentHint) but they're hints — they don't enforce anything. I added a requireConfirmation wrapper:

// First call: returns a confirmation token, no destructive action yet.
delete_site({ host_id: 12345 })
// → { confirmation_token: "abc...", expires_in_seconds: 60, "what_will_happen": "Site 'legacy-corp.be' (123 files, 2 databases) will be deleted." }

// Second call (within 60s): actually deletes.
delete_site({ host_id: 12345, confirmation: "abc..." })
// → { deleted: true, host_id: 12345 }

The first call describes what's going to happen and returns. The LLM has to ask the human (or itself) "are you sure?" before the second call. The token expires after 60s. Multiple in-flight tokens per resource are allowed.

This pattern saved me from production accidents twice already during dogfooding.

The fourth surprise: MCP JSON Schema strictness varies across clients

zod-to-json-schema produces JSON Schema Draft 7. Anthropic API and Claude Desktop are happy with that. The MCP Inspector tool? Stricter. Some clients use Draft 2020-12 and reject exclusiveMinimum: true (Draft 4 syntax) — they want exclusiveMinimum: <number> (Draft 6+).

A community contributor (@ruffzy) sent a PR fixing this by targeting jsonSchema7 explicitly in zodToJsonSchema config. I merged it and shipped 0.8.2 within a day. Open source working as intended.

What's hard about a hosting-provider MCP that isn't obvious

Idempotency is the LLM's responsibility, but the tool author has to surface enough information. The list_hostings tool returns is_locked: bool — if I hid that, the LLM would happily try operations on locked hostings and fail. Verbose output is fine; surprise failures aren't.
Pagination has to be invisible. Some Infomaniak endpoints page at 25 items, others at 50. The MCP tool always pages through everything and returns the merged list. Letting the LLM do pagination = it forgets, gets the first page only, and reasons over incomplete data.
Error shapes must be normalized. Infomaniak's public API returns {error: {code, description}}. The manager-private API returns either that or {"errors": [{"code", "description"}]} or raw HTML on auth failure. I wrote InfomaniakError to flatten everything into a consistent {kind, code, message, raw} so tools can handle errors uniformly.
Logs go to stderr, not stdout. stdio transport mixes JSON-RPC and arbitrary writes on stdout, so any console.log corrupts the protocol. I use pino with stderr destination. If you build an MCP server, do this from day one.
npx -y requires bin field + shebang in your built JS. tsup config:

banner: { js: "#!/usr/bin/env node" }

And in package.json:

"bin": { "infomaniak-mcp-agent": "dist/server.js" }

Missing either and npx -y either fails silently or runs the wrong entry point.

What I'd do differently next time

Cookie-based manager auth is a maintenance debt. The session cookies expire every few hours. Users have to re-open the manager in Chrome to refresh them. A long-lived service account would be cleaner if Infomaniak ever ships one.
Reverse-engineering needs a version pinning strategy. The manager-private endpoints change without notice. I'd add a smoke-test workflow that hits a known set of endpoints daily and opens an issue when something 404s.
Start with tests, not tools. I built the tools first and added tests later. Inverted, I'd have caught the rate-limit issue 3 weeks earlier.
Make the README the install path. Anyone who lands on the npm page should be able to copy 3 lines and have it running in Claude Desktop. That's the win condition.

Try it

npx -y infomaniak-mcp-agent

You'll need an Infomaniak API token (https://manager.infomaniak.com/v3/api-token) and to wire it into your MCP client. Full Claude Desktop / Claude Code config snippets in the repo README.

If you're on Infomaniak and you hit a bug, open an issue with the exact tool call + response (sanitize tokens). I'll usually patch within a day.

If you're building an MCP server for your niche provider, the patterns above (token bucket, confirmation dance, error normalization, stderr-only logging) are reusable. The repo is MIT, fork it as a starting point.

⭐ if it saved you time. PRs welcome.

Forem: Patrick Rary

7 bugs I caught in my MCP server before publishing (and why I almost shipped a data-corruption disaster)

The setup

Bug #1 — WordPress REST API silently drops writes to unregistered postmeta keys

Bug #2 — wp binary not in non-interactive SSH PATH

Bug #3 — SSH banner pollutes stderr and corrupts output parsing

Bug #4 — "Default Kit" returned as a widget in template_type=widget filters

Bug #5 — _elementor_page_settings is an object via REST, a string via WP-CLI

Bug #6 — Headless Chrome cold-start exceeds 30s

Bug #7 — Templates listing had the same filter bug as globals (Bug #4)

What I'd take from this for any MCP build

Try it

Building an MCP server for a Swiss hosting provider (and what reverse-engineering its manager taught me)

Why an MCP for Infomaniak specifically

The architecture in one paragraph

The first surprise: the public API is missing half of what the manager does

The second surprise: Infomaniak's rate limit is shared per token

The third surprise: destructive operations need a confirmation dance

The fourth surprise: MCP JSON Schema strictness varies across clients

What's hard about a hosting-provider MCP that isn't obvious

What I'd do differently next time

Try it

Bug #2 — `wp` binary not in non-interactive SSH PATH

Bug #5 — `_elementor_page_settings` is an object via REST, a string via WP-CLI