MCP tools/list available when MCP is disabled?
6 posts by 2 authors in: Forums > CMS Builder
Last Post: June 28 (RSS)
Hey
I've been playing the new MCP feature and admittedly I know very little about MCP, so this may be completely normal...
I noticed that even with MCP disabled, the endpoint still responds to a `tools/list` request and returns the full list of available tools. Same when using no/incorrect auth.
For example, with MCP disabled (or no auth) I can still see things like:
- serverShell
- serverPhp
- queryWriteserverRead
- upload tools
Attempting to actually run a tool correctly returns an error saying MCP is disabled, so it doesn't look like anything can be executed.
My question is simply whether exposing the tool list when MCP is disabled is intentional?
I'm guessing there's probably a good reason for it, and you guys know the MCP spec far better than I do, but it feels a little odd that a disabled feature still advertises everything it can do.
Just curious whether that's expected behaviour or something worth tightening up.
Cheers
Rob
Hi runriot,
Thanks for the report, and good eye. This one's intentional, not a leak.
The tool list is static. It's the same hardcoded list on every install, and it already ships in the source you can download, so tools/list isn't handing out anything you couldn't read straight from our freely downloadable code. The only things we hold back until you authenticate are install-specific hints, like the server's working directory, OS, and shell, since those would fingerprint the actual box. Nothing in the public list is install-specific or secret.
The real security boundary is on running tools, not listing them. That's exactly what you ran into: the list comes back, but the second you try to call a tool, you get "MCP is disabled." Disabled means disabled, nothing executes, and that holds whether MCP is switched off or the auth is missing or wrong.
The other reason we always return the list is so you don't have to restart Claude every time you toggle MCP. Claude grabs the tool list once when it connects and caches it. If we only sent the list while MCP was enabled, every on/off would mean restarting Claude to pick the tools back up. Keeping the static list always on means you can flip MCP on and off, and it just works, since the tools are already known and only execution changes.
So the short version: the listing is public by design; execution is locked down.
This is also a common pattern for APIs built to be called by an external client. Plenty of public APIs serve their full OpenAPI/Swagger spec, every endpoint and parameter, to anyone, and gate only the actual calls behind a key.
Hope that helps, let me know if you have any other questions or concerns!
interactivetools.com
Thanks Dave, that makes sense.
One lingering thought is less that the list is secret, and more that at an individual site level it fingerprints the install / CMS / MCP surface. I understand public Swagger on a vendor API, but this feels slightly different because it's exposing the capabilities of a specific install rather than the product documentation itself.
So while it's not leaking secrets, it is revealing what technology is sitting behind that particular endpoint and what capabilities exist if authenticated. It doesn't give someone access, but it does tell them what system to go and research.
The Claude restart explanation makes sense, and I can see why you'd want the tool list available for active development. For sites that never need Claude connected (or production environments), would there be any merit in an option to return a generic disabled/auth response to tools/list until a valid key is provided?
We can block it at the edge easily enough by having a CMS-level option would be handy for those of us who'll inevitably roll out an upgrade and forget!
Cheers
Hi Rob,
So, with fingerprinting, any static response or file (CSS, JS, images, etc.) can be used. You just need to checksum a known response from some files from a given version of any software. There are actually some neat sites that do that (search "What CMS is this site running").
So the best solution for that is just to rename your /cmsb/ folder to something less guessable so no one can find it.
And/or, if you don't need the /api/ folder or /api/mcp.php, you should be able to safely just delete them.
But we want the UX to feel good end-to-end, so if seeing a big list of powerful tools, disabled or not, gives anyone pause, we could look into adding a one-time setting to enable it. We have a few questions about it already.
Maybe the first time you open the MCP menu, we could have an option where you click to enable it, and until then, it returns nothing in the tools list.
Let me know if that would work for you. Thanks!
interactivetools.com
Hi Rob,
I found a quick fix for this.
In cmsb/api/mcp.php search for "// Dispatch" and replace it with the following:
// Block all methods (no tool list, no dispatch) while the MCP server is disabled
mcpProtocolErrorIf(!isStillEnabled(), MCP_ERR_SERVER_DISABLED, 'MCP server is disabled. Enable it at Admin → Advanced → MCP Server');
// DispatchThat will prevent the MCP server from showing anything if it's not enabled.
Can you give that a try and let me know if that works for you?
Thanks!
interactivetools.com