Read-only tools annotations & mode

[localconst]

Azure MCP server supports the --read-only flag allowing to expose only safe tools.

Are there any plans to add something similar to this server?

Also, it would be great if tools had read-only hint annotation.

Annotations will allow to provide more flexibility on tools choice on client side, and read-only flag would be just general simplification on top of it.

[danhellem]

We could certainly add read-only flag. But this is a local MCP Server and users would just be able to bypass it anyway. We don't have any tools that would cause destruction of data. Some updates and adds.

What specifically is concerning?

[Novaes]

Thanks for the contribution @localconst

For context, by default, our implementation is intentionally conservative, avoiding destructive operations by design—unlike Azure MCP mentioned, which does support actions such as deleting resources, e.g. an entire key vault. This was by design, in the line of @danhellem comment, given the associated flag can be toggled, intentionally or not, with potentially harmful consequences.

Historically, we began with read-only and additive operations, later moving to additive updates. Currently, we do have though non-additive updates, and we seem gradually expanding in that direction.

Given this trajectory, I support introducing a flag to restrict non-additive updates. I’m also open to reviewing the contribution or implementing it ourselves if no code is expected from the author.

[localconst]

@Novaes @danhellem Thank you so much for your responses!

I have few reasons why I would like to have such a read-only mode:

1. Programmatic: I'm using this MCP server as extension for AI agent built for some research operations.
   And I had a case that in one heavy run, LLM hallucinated and... decided to open a PR.
   Although this was not really damaging incident, the possibility of this does not allow to use this the server the 100% safe way without some additional logic to filter well-known read-only tools.
   It would be just great to have such option from the source of truth than hardcoding assumptions.

2. UX: Yes again, about no-human-in-the-loop. Sometimes there is a case when you want to give a task to your assistant(copilot) and forget about it for a while. A clear example of it is the Research Mode available in almost all nowadays chatbots.
   It would be great if I didn't have to check every tool call from assistant just because I'm afraid it might break/change something/etc due to LLM hallucinations.

I understand that most probably you are not considered/ing this server as some toolset for autonomous agents, but I believe such use cases will become more and more popular in the future.
E.g. the new agent framework was promoted as MCP-ready, so this server is a potential target :)

Please let me know if you have any thoughts about it, and yes I would be very glad to contribute.

P.S. (Actually ☝🏼🤓) some update tools might be considered as delete tools - e.g. afaik if you change PR description you can't revert it back (tool for it) so it's previous state was deleted.

[gavinhenderson]

Hey, i am also keen to see a read-only flag. My worry is around the destructive nature of updates to descriptions of product backlog items and pull requests. We spend a lot of time making sure every task has detailed acceptance criteria and users stories etc. The MCP has the ability to change descriptions, in theory it could clear the description of any of these things, erasing all that work.