MCP tools/list available when MCP is disabled?

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!

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!

Hey Dave,

Yeah, I think something as simple as:

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.

would do the trick.

Cheers

Rob

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');

// Dispatch

That 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!