wonderwhy-er
Spyware Injection and Context Pollution
I noticed some strange new prompting coming from Claude after using its tools. Turns out the maintainers of this project have injected spyware for sleazy gains. The maintainers seemed to miss that this spyware injection actually pollutes the context pretty badly. All Claude wants to do after these injections is discuss my tool usage. While I did find the options to disable collecting my data -- they shouldn't have been turned on in the first place -- the feedback configuration was not disabled. I was unfortunate enough to find the condition where I get prompted for feedback, but can't ignore or nor submit it. Great tool and UX.
Why weren't the feedback options highlighted in the release notes like the other tools? Is that working on improving privacy? Why is this spyware opt-in by default? Was there any privacy work done in the implementation of this work? It seems like it was snuck in and released with little fanfare to hide it's data collection tactics.
Thanks for the detailed feedback. Let me share where we are and get your thoughts on how to handle this better. Our situation: As an MCP server, we have no direct access to users - we only know someone is using the tool when they interact with it. After 100+ of your commands, we genuinely want to know what's working well so we can build the right features. The challenge is: how do we reach active users for feedback when we can't email, notify, or contact them directly? And we are interested in users who do find value and use regularly. Not ones that are just installing and have not used yet.
What we implemented:
- Periodic prompts (every few hours) that include instructions to disable them
- The prompt was: set feedbackGiven=true to stop them permanently
- The release notes listed "usage stats and feedback" as the second feature. Did you read that part? Should we phrase it differently?
Your experience suggests we missed something: If you couldn't find the disable instructions or they didn't work, that's a UX problem on our end. The prompt should have been clearer about how to turn it off.
Data collection reality:
- Local usage stats (for your get_usage_stats tool) - stays on your machine
- Optional anonymous telemetry - can be disabled
- Feedback system - only sends data when you explicitly choose to use it
Given that we need feedback from active users but have no direct contact method, what would you suggest?
P.S we are updating readme/faq too
Public forums, requests for feedback, call-to-actions in documentation are good methods for requesting feedback without invasively injecting tracking code into users private chats. I frequent a lot of these Reddit channels and don't recall seeing one. Given the bugginess and the "creativity" it took to put this "feature" into this once valuable MCP, it should make you think if it was the correct way to go. Maybe the developer UX was telling you that this is not the direction to take.
I, once again, received your feedback notice after attempting to disable this thing.
Why are you trying to turn the MCP into a WordPress plugin? Maybe it's just not the protocol for that 🤷🏻♂️
+1 I also get the feedback notice although I tried to disable it. Please, turn it off! If I want to give feedback, I'll do, but don't force me to!
Ouch, that's definitely a bug. Sorry for that frustration.
We just pushed v0.2.6 where we disabled the feedback prompts completely until we can investigate why the disable isn't working properly. Thank you for reporting this!
Our challenge remains though: We genuinely need feedback from active users to build the right features, but we have no direct communication channel. The users who matter most typically aren't on Reddit/GitHub discussions. At least from what we see we get very small fraction.
Our options seem to be:
- Require users to login on our website (like commercial MCPs do) to get a communication channel
- Find another non-invasive way to reach active users
- Accept that we'll have limited feedback and build based on assumptions our own assumptions(not really an option)
Also we not want to spam Reddit with surveys - we need input specifically from people who've actually used the tool extensively.
Such surveys are normal thing for sass products. MCPs are different in that sense but that does not change the need for it. In practice we do plan to do MCP protocol feature requests in future as MCPs do need more GUI communication with user options. Like ability to create buttons person can click to quickly ask something from LLM. Requests for feedback that are not disruptive to work of MCP is another thing too that is not there yet.
I'm glad there's already an issue for this. ~Instant uninstall forever.~ Edit: productive discussion below.
Inserting this feedback message into the conversation is invasive and inappropriate. Considering the many open questions around ethics and privacy in AI tools in general, earning and building trust as a new project is already an uphill battle. Prioritizing user consent is the absolute bare minimum that should have been considered before adding a feature like this; not opt-in by default data collection (that also poisons its own well, re: context pollution).
I can see that the functionality was mentioned in the release notes for 0.2.4 (there's no visibility into release notes changes so I'm just taking it at face value). The feedback system is mentioned in the README, which is good, although added after the fact and not with 0.2.4. I notice that External Telemetry is Opt-Out rather than Opt-In as well. Overall it gives the impression that privacy is at the very least an afterthought.
We genuinely need feedback from active users to build the right features
Is the need for feedback really more important than building user trust? The whole approach undermines both trust and the quality of the feedback.
@delano Firstly I want to apologize for creating bad experience for you here.
And I also agree that its uphill battle to work in open source + AI space, but there are many challenges in it.
Couple of questions. What do you mean by "there's no visibility into release notes changes so I'm just taking it at face value"? What can we do better in about release note visibility?
About readme you are correct. I was working on updating it after functionality release to try to get it out swiftly. Still its a fail on our side not to update it at the same time but with something 8h lag.
As for privacy being an after thought, not really we are constantly discussing it with such features. You would be correct to say that its not on top of the list but second or 3rd though. Project direction is on first and that does require insights.
By the way feature in question here is opt-in. It asks for feedback and you are free to say no. So, can you explain how it affects your privacy? In that sense anonymous telemetry we collect is opt-out. How is asking for feedback that is voluntary here worse?
Thanks for responding.
What do you mean by "there's no visibility into release notes changes so I'm just taking it at face value"? What can we do better in about release note visibility?
It's just how releases on GitHub work. They can be edited, deleted, and recreated without a paper trail. @jeremy-green mentioned "Why weren't the feedback options highlighted in the release notes" and when I had a look I could see them mentioned. I meant that I'll give the benefit of the doubt and assume the notes were there and they just didn't see them (as opposed to assuming the release notes were edited).
By the way feature in question here is opt-in. It asks for feedback and you are free to say no. So, can you explain how it affects your privacy?
The privacy concern isn't about data collection per se, but about consent to the interaction itself. When a tool injects prompts into my private conversation with Claude, that crosses a boundary regardless of whether I can decline to answer. It's similar to how popup ads are intrusive even when you can close them.
From a privacy-by-design perspective, the question isn't "can users opt out" but "should this be happening at all." Many users (myself included) expect tools to operate without injecting themselves into our conversations, especially when handling potentially sensitive data.
How is asking for feedback that is voluntary here worse?
It's not necessarily worse, but it highlights a pattern: opt-out telemetry + intrusive feedback prompts + the general approach suggests privacy considerations come after functionality decisions. This erodes trust, especially in a tool that has broad system access.
To put it another way: a lot of people aren't even able to use the project as-is because it violates regulations and privacy standards. This is not just a matter of consent, but also a matter of respecting user autonomy, privacy, and actual laws.
On a practical note: I created a privacy-focused fork that removes the telemetry and feedback systems while keeping the core functionality. It's a work-in-progress community effort for users who prefer a different privacy approach. I'm not trying to compete with your project - I genuinely appreciate the tool and wanted to continue using it with a different privacy model.
https://github.com/delano/DesktopCommanderMCP-with-privacy
@delano really appreciated for detailed and nuanced thinking you shared here. And ye, this project is open source and you are free fork and change it however you like! There were few forks like that before too. I think @jeremy-green and one more did such before.
We are also speaking with some ecosystem players to see how to better balance privacy and needs of further development. In that sense today all information belongs to clients like Claude and MCP creators have no access to it and are not in a good position to track quality signals of their MCPs.
I hope we can find better way to do it in the future.
Once again, than you for your detailed feedback! We are bit in product helmets here and need to test it more with beta testers before releasing such things. Need to start looking for volunteers for beta tests soon.
Thanks for the thoughtful response and for being so open to feedback. The MCP ecosystem challenge you mentioned is really interesting. If you want any perspective from the privacy-focused side of things, feel free to @ ping me anytime.
Yes, we need to finalize on our side how we want to go with beta testers and let you know. Probably it will be a closed channel in Discord for beta testers