feat: MCP server for npmx.dev #727
Description
The Problem
Many of our users build with agents on a daily basis. The value proposition of npmx.dev applies as much in that context as in the human-only workflows. It would be a great value add, if npmx.dev was useful for agents too. You can argue that it already is, because it's just a regular website that any agent can navigate, but with a specific agent-focused API that an MCP server is, it could potentially be even better.
An example of a workflow that would be improved here, is that we could specifically instruct the agent (via the MCP server's instructions and tool descriptions) to use npmx to look up package's known vulnerabilities, versions and getting started commands before installing new pacakges.
The Proposal
We could build an MCP server at pnpx.dev/mcp or similar, that would give agents direct access to some of the information and workflows that pnpmx supports. On the top of my head, we could expose search, package viewer and comparison tools similar to the ones already on the website. There might be more things we could do that I just don't have the imagination for yet. Especially when npmx adds support for admin features, they would probably be valuable in the MCP server too.
The Counter Proposals
- Agent Skills is all the rage at the moment, and right now it's not entirely clear which horse to bet on and where each falls short (see this great article on the subject). This might be both easier to implement and use with skills instead of a dedicated MCP server. The downside of Skills is that their distribution is a bit more complicated, as it's often something users put in their local environments once, where an MCP server would just be updated as soon as we deployed a new version to npmx.dev. I know there are various plugins and extension marketplaces for Skills and Friends™, but I still think that is inherently more complicated.
- The MCP server might not be necessary if we implement feat: Support
Accept: text/markdownheader for improved LLM usage #725, as that would already improve an LLMs usage of npmx a lot. What it would not do, however, is add instructions to the LLM to use npmx correctly in certain workflows.