I have been clear from the start if any of you read the post properly.
“I know many of us don’t like using it(AI) whether its open or closed source. This is for those who want to use it.”
It was only about my project that I found useful in my workflow and wanted to share with other who may find it useful by posting in community contributions.
There are too MCPs out in public and many find it useful. Docker MCP Catalog
Regarding arch forum, people there had a sane discussion about it than outright reject it.
Out of three, two understood the project and appreciated it.
The post is moved to an different section(not deleted) likely because of a potential fire-hose of hatred from people who don’t like AI
as one of the administrators mentioned there.
Here is the complete thread from Arch forum till now: <t:1761390360:F>(dynamic timestamp)
A simple search in the search bar here on the forum and a little time reading would have told you this is a touchy subject around here (not as bad a browser wars YET). Would have better prepared you for the responses you got.
First of all, Its a good call to only provide the MCP server to run locally.
But from my point of view : Even local MCPs should only be run within an virtual environment with restricted access to the underlying system. Not exposing the whole systems environment. Tool calls such as search (the AUR / Wiki / official packages) are totally fine from my perspective, also security auditing features (checking PKGBUILDs within the AUR for instance). But I strongly oppose the concept to implement or enable MCP tool calls which would install packages on its own.
For those who’ld like to consult the package databases and the solutions available in the Arch Wiki - through the mediation of an LLM and a MCP server to summarize given solutions and such - totally fine.
But please, don’t touch the underlying system. Let the AI provide recommendations & step by step instructions - which would be transparent to the end user. A MCP should really only live in an restrictive environment, without full system access. Especially system altering changes would be highly problematic if an tool call would allow for system altering changes that aren’t transparent to the actual user which would make it tough to troubleshoot if something went wrong.
And you, as the author of that MCP server toolcalls, should be ready to take on all those troubleshooting requests of an feature / functionality that is from my perspective… experimental.
But in reality, its more likely that the potential issues are taken to the Arch forums or, in cases specific to EndeavourOS, they’ll ask for help here.
Stepping in to just communicate - @nihalxkumar - Looking at the Arch Forum’s suggestionss, and very few of the comments here for that matter as well - there are of course some valid suggestions that you can take out for the project.
When ChatGPT came up, please note that almost everyone called it the worst project from OpenAI so far. I’m not comparing the products here, but I’m surely comparing the way critics responded to. Fine to ignore the f-word responses tbh - it’s there way of saying a polite no I think. Glad that EOS CoC is very liberal in that way
I think this definitely has use-case for many users, who don’t necessarily read through the PKGBUILD files and/or aren’t aware of the security vulnerability checks. Agreed that ideal solution is to always have users go through it line by line, but looking at your examples here: https://nxk.mintlify.app/arch-mcp/examples, I think there’s definitely a lot of use-case to at least give information to users on it before installing a package.
For more context, looking at examples again, your MCP would ideally target the following for a sample prompt [which I think is really helpful, as others also mentioned - help in auditing]:
Fetch package metadata
Analyze PKGBUILD for threats
Provide security recommendations
Nice project overall. Do consider safety issues in your next iterations!
Hey, thank you for a detailed feedback for the project.
To my best of the knowledge, uv it always run in a python virtual environment. It is just like pip, uvx is just pip install.
Here again, to my best of knowledge, Any package on arch or arch-based system can not be installed without sudo password.
Same is the case with my mcp here.
Please check this demo showcasing an installation of package using the MCP on Claude 4.5 Sonnet:
Nothing of this sort has been implemented. Just like most of us here I too care about my for privacy and security.
Still, Every step requires user to approve.
Is that so? I think general MCP is audience is smart and would likely reach out on github issues if anything is messed up with it.
Also, with or without this, the LLMs can access official Arch sources. The purpose of MCP is to seamless integrate this process, add useful features and reduce all the friction down to press of a button.
This mcp also has rate limits to the Arch servers. None of the code has been changed till now. Everything is as it is was on announcement; Open for any scrutiny.
Please correct me if any thing I said is wrong or I missed any of your points. Thanks
Thank you for understanding what the project is actually about.
(although it can do more than just verifying and installing packages)
Your comment is very much appreciated.
I think general MCP is audience is smart and would likely reach out on github issues if anything is messed up with it.