Support granular ReadOnly permissions

[aljesusg]

What?

The current implementation of the MCP server creates a binary distinction between "Read-Only" and "Write" tools. When the server is started with the --read-only flag, any tool that is not explicitly marked with ReadOnlyHint: true is effectively disabled or hidden from the client.

Example

Currently, the manage_istio_config tool in the Kiali toolset has the ReadOnlyHint explicitly set to false. Ref: pkg/toolsets/kiali/tools/manage_istio_config.go#L56

This is technically correct because the tool supports destructive actions like create, patch, and delete.

The Problem

When the MCP server is running in Read-Only mode, the entire manage_istio_config tool becomes unavailable/unusable.

However, this tool also handles safe list and get operations. This means that in a restricted environment (read-only), users lose the ability to view Istio configurations entirely via this tool, which is a significant limitation.

Proposed Solution

We should find a way to allow this tool to function in Read-Only mode for specific actions, rather than splitting it into two separate tools (e.g., get_config vs modify_config).

Goal: Keep the tool interface unified but restrict operations dynamically.

Suggestions:

Dynamic Permission Check: Allow the tool to be invoked in Read-Only mode, but strictly validate the action argument.

If action is list or get -> Allow.

If action is create, patch, or delete -> Deny (return a clear error message citing read-only mode).

Metadata Enhancement: (Longer term) Investigate if the server implementation can support finer-grained hints, where a tool is partially available based on input parameters.

Current Workaround

The only current workaround would be splitting the tool into two, which degrades the user experience and adds maintenance overhead. We should avoid this if possible.

[manusa]

Same applies to DestructiveHint and --disable-destructive

[Cali0707]

@manusa @aljesusg love this idea - thinking about the proposal a bit more, maybe we can:

1. add a new hint to our api layer like PartialReadOnly so that when the --read-only flag is set those tools are still exposed (maybe even with the ReadOnly annotation set) while the actual ReadOnly annotation can still normally be set to false (as it isn't fully a read only tool)
2. Push the read only control down into the AccessControl round tripper (https://github.com/containers/kubernetes-mcp-server/blob/main/pkg/kubernetes/accesscontrol_round_tripper.go), so that it can enforce read only interactions at the round tripper level, regardless of what the tool is annotated with (IMO this is safer for end users too)

Regarding eventually having more fine grained hints/mutating the tool params dynamically, supporting use cases like that was the idea behind the ToolMutator interface in the mcp package. I do agree that this would make more sense as a future enhancement beyond a first pass at this use case