Shopping for Skills and MCP Servers (Without Getting Burned)

A year or two ago, giving an AI assistant new abilities meant waiting for the company behind it to ship a feature. Now it feels more like wandering through a market. There are directories full of MCP servers, there are piles of skills on GitHub, and every week someone posts a shiny new one that will supposedly change how you work. I like this a lot, but I've also learned that browsing it is a skill in itself. Like any market, there are real finds, there are things that look good on the shelf and are useless at home, and there are a few things you really shouldn't put in your basket.
First, a quick word on what you're actually shopping for, because the two things get mixed up constantly. An MCP server is a connection. It's what lets an assistant reach out to something beyond the chat: your calendar, a database, a code host, a project tracker, a folder of files. MCP stands for Model Context Protocol, and the whole point of it is that one standard way of plugging things in means a server written once can work with many different assistants. A skill is something different. It's know-how. At its simplest it's just a folder with a text file called SKILL.md that explains how to do a certain kind of task well, sometimes with templates or scripts alongside it. The assistant reads a short description of each skill, and when your request matches one, it pulls in the full instructions. So an MCP server gives the assistant hands, and a skill teaches it how to use them well. The best setups I've seen use both together: a connection to your tracker, plus a skill that explains how your team likes tickets written.
Where do you shop? For MCP servers, the closest thing to an official storefront is the MCP Registry, a community-run directory that launched in preview in September 2025. It's less a store than a catalogue of listings, and the actual code lives elsewhere, in places like npm, PyPI or Docker Hub. At last count, one guide put it at nearly two thousand servers, which is plenty to get lost in. On top of that sit lots of other directories that pull from it and add their own ratings or curation, and they're worth browsing, though their quality bar varies a lot. Skills are scattered more widely. Because the format is simple and has been picked up by other tools, not just Claude, you'll find them in vendor repositories, plugin marketplaces and community directories that claim tens of thousands of entries. Many companies also publish their own official skills and servers for their own products, and those are usually where I'd start.
Now for the part that matters most, which is how to tell a good find from a dud. My first question is always who made it and whether they're still around. A server from the company that runs the service in question is a very different thing from a weekend project by a stranger, and a repository that hasn't been touched in a year may quietly stop working the next time the underlying API changes. Stars and download counts help a little, but I'd rather see recent commits and people actually responding to issues.
My second question is what it can do, and here MCP servers deserve more suspicion than skills. A server runs code, often on your machine, and it's usually holding a key to one of your accounts. That means it's worth reading the list of tools it exposes before you connect it. Does a note-taking server really need to delete things? Does a read-only task need write access? If there's an option to limit it, I limit it, and I give it the narrowest token I can get away with. There's a second, sneakier issue too: the text a server returns, such as an email or a web page, gets read by the assistant, and a malicious bit of text can try to give it instructions. This is one reason I'm cautious about connecting an assistant to a lot of untrusted content and a lot of powerful actions at the same time.
Skills feel safer at first glance, since they're mostly just words, and the great thing is that you can read one in two minutes. Do that. Open the SKILL.md and check that it says what the listing claims. The description at the top matters most, because it decides when the assistant will reach for the skill. A vague one gets triggered at the wrong moments or never at all. Also look for any scripts bundled in the folder, because those do run, and they deserve the same scrutiny as any code you'd download.
There's one more thing I've learned the hard way: resist the urge to hoard. It's tempting to install everything that looks interesting, but every tool and every skill description takes up space in what the assistant has to keep in mind. Load up forty servers and the assistant has to pick between overlapping tools, and it often picks worse. Two tools that do nearly the same thing are a recipe for confusion. I'd rather have a small kit that I trust and understand than a huge one I can't keep track of.
So my routine is simple. Start from a problem I actually have, not from what's trending. Look first at official offerings from the service involved. Check who maintains it and how recently. Read what it can do, and give it the least access that works. Try it on something low-stakes. And if it earns its place after a week or two, keep it, and if it doesn't, remove it without guilt. The market is only going to get bigger and noisier, and I think the people who get the most out of it won't be the ones who install the most, but the ones who choose carefully and keep their kit small.

Comments

[Nikolas Dimitroulakis]

Can you restrict its access?" is the question most listings can't answer. On the ApyHub MCP (I co-founded it) we made that the default: teams curate which endpoints their agents can see, so a new tool only shows up when someone adds it. Do you re-check a server after it updates, or only at install?