CMSB v3.83 Beta (Show/Hide Fields & MCP Server)

I had my Claude Code do some testing on our end in VS Code. I had developed my own MCP a few months back and we were able to compare that one with with this native one.  Here's Claude's take after doing some extensive testing guided by my instructions. I had Claude write the summary for this forum post:

MCP Server Beta Feedback — v3.83

We've been testing the new MCP Server hard over the last few days. Big picture: this is a well-designed server. The tool surface is thoughtful, naming is consistent, the layered IP + bearer auth is above typical MCP quality, and the instructions block on initialize is the best I've seen anywhere — you explicitly tell the model when to use CMSB MCP over raw MySQL, warn about hook/timestamp gaps, and point to cmsApiPublic / cmsSignature as guardrails against hallucinated APIs. That's exactly the failure mode those tools should address, and most MCP servers don't bother.

That said, there are some real issues worth flagging before this comes out of beta. Posting them here in severity order so others testing can corroborate or tell me I'm wrong.

Security — Pre-auth info disclosure

Bearer auth is currently only enforced on tools/call. With no Authorization header at all, I was still able to get back:

• The full initialize response including serverInfo.description and the long instructions block
• All 19 tool definitions via tools/list
• Both prompt names and — via prompts/get cms-logs — the entire prompt body, which enumerates internal table names (_error_log, _log_audit, _cron_log, _outgoing_mail) and internal settings keys (serverChangeLog, bgtasks_lastRun, mail.outgoingMail)

Tool invocation itself is safe — I correctly got No Bearer token provided / Invalid API key when I tried to call anything. So this isn't a data breach. But it's pre-auth info disclosure against anyone who's already past the IP allowlist, and if a user ever clears the allowlist the whole discovery surface becomes public.

Fix: require the bearer on every method, not just tools/call.

Bugs

1. cmsApiSearch emits raw PHP warnings before the JSON-RPC payload.

Calling cmsApiSearch {"query":"DB::sel"} returns six PHP warnings, then the JSON:

Warning: include(.../vendor/composer/../../lib/ImageFactory.php): Failed to open stream: No such file or directory in .../cmsb/api/mcp.php:1081
Warning: include(.../vendor/composer/../../lib/Validator.php): Failed to open stream: No such file or directory in .../cmsb/api/mcp.php:1081
... (6 warnings total)
{"jsonrpc":"2.0",...}

Two problems with this:

• Strict JSON / SSE MCP clients will fail to parse. curl tolerates it; a real MCP client may not.
• It leaks absolute filesystem paths.

cmsErrorSummary confirmed these are real errors — it groups six matching entries on mcp.php:1081. Looks like an autoloader/composer issue where ImageFactory and Validator are referenced but not present. Fresh composer dump-autoload might do it.

2. Unknown methods return a fake tool result instead of a JSON-RPC error.

resources/list returns:

{"jsonrpc":"2.0","id":51,"result":{"content":[{"type":"text","text":"Unknown method: resources/list"}],"isError":true}}

Per the JSON-RPC spec this should be {"error":{"code":-32601,"message":"Method not found"}}. Clients that branch on protocol-level errors vs. tool-level errors (most proper MCP clients) will mis-handle this. Same pattern shows up for notifications/initialized returning "Invalid JSON-RPC version" wrapped in a fake result.

3. initialize returns protocolVersion: "2025-11-25" regardless of what the client sent.

I sent "2025-06-18"; the server echoed "2025-11-25". The MCP spec says the server must return the client's requested version if supported, or the highest it supports that's ≤ the client's. Hardcoding a single (and future-dated) version can break strict clients.

4. selectOne silently coerces string → int.

selectOne {"table":"recipes","num":"abc"} returns Record not found: recipes num=abc rather than a validation error. The inputSchema declares num: integer — the server should reject this at schema validation. As-is, "bad input" and "real miss" are indistinguishable to a model.

Tool-design suggestions

• listTables and cmsErrorSummary take no args. A filter/prefix on listTables (98 tables on a small install; could be much larger elsewhere) and limit / since / minCount on cmsErrorSummary would scale better.
• query / queryWrite take raw SQL, which means a model that bypasses the safer helpers can still do anything. Documenting that tradeoff in instructions is great. Consider a dryRun option on queryWrite that runs EXPLAIN plus (for DELETE/UPDATE) reports affected-row count without committing.
• queryWrite's destructiveHint: true annotation is good, but surfacing affected-rows count on success would make model behavior safer still.
• No _meta/version on tool responses. While the output shape is still changing in beta, a version field would help clients detect drift.
• cmsApiPublic's docstring explicitly says "cheap to call" — that's a nice explicit cost signal to the model. More MCP servers should do this.

What's working well

Not just being nice — these are design wins worth calling out so they survive the next round of changes:

• The instructions block. Already mentioned above; it's genuinely excellent.
• Error messages point the human to the fix UI. "Add it in Admin > Advanced > MCP Server > Allowed IPs" and "Check the Authorization header in your .mcp.json file" tell the human what to do, not just what went wrong. That's the gold standard.
• cmsApiSearch + cmsSignature is a clever pair. The signature response returns file / line / class / inheritance / signature / docblock — exactly the right shape for keeping models from inventing function signatures against stale training data.
• cmsInfo.customUploadDirs surfacing per-field upload overrides is a thoughtful touch. Anything touching uploads needs exactly this.
• Defense in depth is real here. Password redaction in settings worked. MySQL system-table denial worked. Read-only query correctly rejected DELETE with a clear message pointing to queryWrite.
• The two prompts (cms-logs, cms-fix) are substantive runbooks, not placeholder stubs.

Comparison notes — running CMSB MCP alongside our fleet MCP

Some context: we run our own MCP server (mcp.sagentic.dev) for fleet-level portfolio management across 100+ client sites — it's purpose-built endpoints for domain management, support logs, cross-site reports, that kind of thing. Built on the official PHP MCP SDK v0.4.0. It's a very different animal from CMSB MCP (fleet control plane vs. single-site database plane), and we're treating them as complementary, not competing.

Running them side-by-side did surface some patterns worth sharing in both directions.

Things CMSB MCP could borrow

1. Tiered API keys. Our server has creator / standard / full / write tiers with field-level visibility differences — e.g., creator-tier responses hide credentials while standard-tier hides sensitive notes. CMSB has one key and a single "Allow write access" checkbox. For site owners wanting to give a lower-trust AI client read-only access to a subset of tables, tiering would be a big deal.

2. Implement MCP Resources. resources/list currently returns "Unknown method." Natural candidates for CMSB: cmsb://schema/index, cmsb://schema/{table}, cmsb://settings (non-sensitive subset), cmsb://errorlog/recent. Resources are proactively loadable, which fits AI workflows better than on-demand tool calls for schema/reference data.

3. Proper JSON-RPC error codes. Using -32001 Invalid API key, -32600 Invalid request, -32603 Error while executing tool lets strict clients branch on error class. CMSB currently returns everything as a successful result with isError: true and the reason in a prose string. Already covered above but worth reinforcing — this is what the PHP MCP SDK gives you for free.

4. Sessions + Mcp-Session-Id. Streamable HTTP per the MCP spec expects session management. Stateless is tolerable today but forecloses future features (subscriptions, progress notifications, listChanged events — CMSB advertises both as false on the capability flags, which confirms these haven't been wired up).

5. Moving to the official PHP MCP SDK (mcp/sdk v0.4.0). The protocol-level quirks I listed above (hardcoded protocolVersion, fake results for unknown methods, PHP warnings in response bodies) all smell like hand-rolled JSON-RPC. The SDK gives you sessions, error codes, and resource/prompt handling for free. There's one known SDK bug — it silently fails to discover #[McpResource] attributes, so you have to register manually via addResource() — but everything else Just Works.

6. Prompts with arguments. Our prompts take parameters like use_skill(skill, domain, context) to customize the workflow. CMSB's cms-logs / cms-fix are static. Both are valid, but parameterized scales better.

Things our servers should borrow from CMSB

Being honest — CMSB MCP has some patterns our custom servers don't, that we should steal:

1. Live schema / API introspection (cmsSchema, cmsApiSearch, cmsSignature). Our own troubleshooting doc literally calls out two schema quirks — "uses skill_content, not content" and "no api_id column." That's the exact failure mode these tools solve. A schema-lookup endpoint would make those quirks discoverable rather than doc-resident.

2. The instructions block. We have equivalent guidance in our .guides/*.md but it's not wired into the server's initialize response. The PHP SDK supports this — just populate it.

3. UI-pointing error messages. Ours say "Invalid or missing API key. Provide via X-API-Key header or key query parameter." Yours say "Your IP is 170.000.000.000. Add it in Admin > Advanced > MCP Server > Allowed IPs." The difference in helpfulness is real.

Audit logging — question for the devs

CMSB has both _log_audit and api_audit_log tables. Can you confirm MCP writes (insert / update / delete / queryWrite / uploads) are landing in one of them? Didn't see explicit confirmation in the docs and it matters for compliance use cases. If cmsErrorSummary is intended to be the canonical surface for MCP-origin errors specifically (vs. generic PHP errors from the whole site), that'd be worth documenting too.

Suggested priority

• P0 — Require bearer auth on initialize / tools/list / prompts/*.
• P0 — Fix whatever's missing at mcp.php:1081 so cmsApiSearch stops emitting PHP warnings into the response stream.
• P1 — Switch unknown-method / protocol-error paths to real JSON-RPC error objects with proper codes.
• P1 — Echo the client's protocolVersion (or negotiate downward) instead of hardcoding 2025-11-25.
• P2 — Strict type validation on tool inputs (reject num: "abc" rather than coercing).
• P3 — Filter/limit args on listTables and cmsErrorSummary; dryRun on queryWrite.

I didn't run any write operations (insert / update / delete / upload) against production data.

Overall, really good work on this release. The MCP server is a genuinely useful addition to CMSB and most of what I flagged above is protocol-correctness polish rather than design problems. Looking forward to v3.83 final.

Thanks - Claude