[FEATURE] support MCP resource subscriptions for automatic context updates

This is a fantastic feature request. The use-case you described for synchronizing contexts between multiple Claude instances via an MCP knowledge-base server is a total game-changer.

I was curious and dug into the docs a bit. It looks like you're right that the current implementation is a one-time fetch. The MCP documentation page states that when you @ mention a resource, it "fetches data from connected MCP servers" and includes it as an attachment. There's no mention of subscribing for updates, which aligns with what you observed.

You're spot on to compare it to how Claude Code handles local file Read() operations. The fact that it can watch local files for changes suggests the core logic for updating context based on external events is already there. Applying that same "watch and re-read" principle to MCP resources that support subscriptions seems like a very natural extension of the feature.

While we wait for something official, I wonder if a temporary workaround is possible using custom slash commands.

For example, you could create a project-level command in .claude/commands/refresh-context.md that explicitly tells Claude to re-read the resource:

File: .claude/commands/refresh-context.md

---
description: Manually re-reads the primary knowledge base from the MCP server.
---

Please discard your previous understanding from the knowledge base and get the latest version by reading the following resource: @my-server:kb://main-context

Summarize the key changes you've observed.

Then, you could just run /refresh-context periodically. It's not the automatic, push-based update we really want, but it's a bit better than manually re-typing the prompt every time.

Still, having true, push-based updates via notifications/resources/updated would be far superior. Fingers crossed the team sees this and considers it! It would unlock some really powerful, stateful agent workflows.

Hi! I also read this issue and fully support the idea of implementing resource subscriptions in MCP.

I just wanted to add that personally, I think using bidirectional gRPC/protobuf would be the ideal solution for this kind of interaction. It would be much more efficient and technically interesting:

• High performance thanks to binary format and HTTP/2
• Native streaming support for real-time updates
• Strong typing through protobuf schemas
• Cross-platform with support for multiple languages

It's a shame such a mechanism isn't currently part of the MCP standard. I think adding gRPC transport could enable completely new game-changing use cases - like true context synchronization between multiple Claude instances or agents.

Maybe we should create a feature request specifically for adding gRPC transport to MCP? I would definitely throw my support behind it.

What do you think?

A separate issue makes sense because:

1. It's a different scope: This issue is about the behavior of resource subscriptions. Your idea is about adding a new transport layer to the MCP standard itself. They're related, but one could be implemented without the other.
2. It has broader implications: As you said, adding gRPC could enable all sorts of new use cases beyond just this subscription feature. It deserves its own discussion.
3. It's clearer for triage: A title like "[FEATURE] Add gRPC transport support to MCP" is much more direct and easier for the team to categorize and assign.

Looking at the MCP docs, it's clear the current transports are stdio, HTTP, and SSE. Adding gRPC would be a significant and valuable foundational improvement.

You should definitely go ahead and create that new feature request. It's an excellent suggestion.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

The issue is stil present.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

The issue is stil present.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.