MCP tools/list available when MCP is disabled?

3 posts by 2 authors in: Forums > CMS Builder
Last Post: 9 hours ago (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

By Dave - 10 hours ago

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!

Dave Edis - Senior Developer
interactivetools.com

By runriot - 9 hours ago

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