MCP server: should storing consumer offsets need only read permission?

[justinmclean]

A read-only MCP server can’t keep an agent’s place on a stream.

In the MCP server, storing a consumer offset needs update and deleting one needs delete. Polling with next or auto_commit=true also needs update, because it stores the offset.

The broker treats these as part of reading. A read-only Iggy user can store and delete its own offsets.

So to let an agent resume where it left off, you have to give it update. That also lets it change streams, topics, users and permissions.

@hubcio, you added these checks in #4151. Was the stricter rule intended? If not, I can raise a PR to move the offset operations to read.

[hubcio]

yes, that was on purpose. #4151 moved every tool that writes server (broker) state off read, offsets included, and should_reject_mutating_tools_with_read_only_permissions pins it.

but i think youre right, it looks wrong. the server only asks for poll permission on offsets, and the mcp server always uses its own consumer (iggy.consumer, default iggy-mcp). so the agent can only move its own cursor.

go ahead with the PR and put store, delete and auto-commit / next polling on read. the readme table, the poll_messages tool description and that test need updating too. also worth a readme line that iggy.consumer shouldn't share a name with a real app's consumer, since read alone will move its offsets.

until then, update with a read-only iggy account works. the server still blocks stream, topic and permission changes for that account.

[justinmclean]

Thanks @hubcio, raised as #4608: store, delete and auto-commit/next polling are on read, with the README table, the poll_messages description, the read-only test and a line on iggy.consumer naming updated.