Skills & MCP ecosystem: sources, watch, evaluation

Knowing where to look, not knowing everything

Here you are at the end: you can read, write and govern a skill (steps 2-4), understand the protocol, plug in, code and secure an MCP server (steps 5-8). One skill remains — the most durable, because it is the one that will spare you redoing the other eight for every new need: knowing how to find your way in an ecosystem that, for its part, will not stop moving.

The trap, at this stage, would be to look for the list of the best skills and servers. Any frozen list is stale in three weeks in this field. The real question is not "which are the best today?" but "where to look, and how to recognize the good one when it appears?". It is a method, not a directory — and a method does not go out of fashion.

The map of sources

Three families, three distinct uses. Confusing them means either drowning or missing out:

Official repositories — the trust bedrock. The vendors' repositories (the one publishing the model, those of the services you target), the protocol specification itself, reference servers maintained by identified organizations, and official registries where they exist. This is where you go first, and it is the most accountable provenance in the sense of step 6. Pace: measured but followed — what moves here sets the standard.

Community lists — the abundance. The "awesome" lists, server directories, individual projects, blog shares. It is the richest source and the most uneven: the gem and the abandoned fork sit side by side. You go there to discover, never to adopt unfiltered — the end-of-step checklist is made precisely for that.

Discussion venues — the weak signal. The discussions attached to repositories, specialized communities, changelogs you put on watch, field feedback. This is where you see things coming: a flaw discussed before it is documented, a server rising before it is in the lists, a maintainer change that heralds drift. Anticipatory intelligence, in short — and the most neglected.

Building a watch that lasts

An effective watch is not a consumption of feeds, it is a filter. Three principles, learned the hard way by anyone who has followed a fast-moving field:

Follow sources, not news. You do not "read the MCP news" — you put a small number of precise repositories and changelogs on watch, and let the rest come to you through their updates. Watching the official repositories and the two or three servers you use beats scrolling ten feeds a day.

Read the right signals, not the big numbers. A repository's star total tells its past; what matters is the present — recent stars (is the project rising now?), the date of the last commit, the pace of issue resolution, the maintainers' activity. A 20,000-star repository frozen for a year is less reliable than a living 800-star one. That is exactly why the dashboard at the end of this step shows fresh data, not an engraved ranking.

Distinguish roles by reader. A developer watches technical capabilities and spec changes; a CIO/CISO watches something else — announced flaws, governance changes in a critical project, servers appearing in their organization without going through the registry (the Shadow AI of step 8). The same source, read with two grids. The meta-advice nobody gives: decide what you are looking for before deciding where you look.

Where it moves, live

Theory is only worth its confrontation with reality. Here is the living state of the repositories that structure the ecosystem — data refreshed automatically, in the spirit of our 40 Claude & MCP tools sheet:

🏛️ The official bedrock — know it by heart

These are the authoritative sources. You go there first, always.

Skills — official Anthropic repository: github.com/anthropics/skills. The reference skills (docx, pdf, pptx, xlsx) in source form, plus teaching examples like skill-creator. The best school for writing your own.
Skills — open standard: agentskills.io. Since December 2025, Agent Skills are an open specification: a skill written for Claude can, in principle, run on any platform adopting the standard.
Official Claude Code plugins: github.com/anthropics/claude-plugins-official. Anthropic's directory of high-quality plugins, with security criteria at entry.
MCP — the protocol specification: modelcontextprotocol.io. The source of truth for the protocol itself: primitives, transports, security.
MCP — reference servers: github.com/modelcontextprotocol/servers. The official implementations and third-party integrations showing how a server is cleanly coded.
MCP — official registry: registry.modelcontextprotocol.io. Launched late 2025, backed by Anthropic, GitHub, Microsoft and PulseMCP. The source of truth for published servers, with namespace authentication (reverse-DNS format) guaranteeing a server comes from who it claims — exactly the provenance control of step 6.

🌱 Community lists — the abundance, to be filtered

Rich and uneven: the gem and the abandoned fork sit side by side. You discover here; you never adopt without the checklist below.

awesome-mcp-servers (several active maintainers): wong2/awesome-mcp-servers and appcypher/awesome-mcp-servers — two of the most complete directories, categorized.
Auto-updated list: abordage/awesome-mcp — refreshed daily via the GitHub API, handy for judging recent signals (stars, last commit) rather than totals.
Remote / hosted servers: awesome-remote-mcp-servers — the "remote server" counterpart of step 6's local/remote trade-off, useful for team hands.
Browsable web directory: mcpservers.org — to explore without cloning.

💬 Where it is discussed — the weak signal, upstream

The discussions and changelogs of the official repositories above (put them on watch).
The registry repository modelcontextprotocol/registry: issues and PRs announce the evolution of the distribution standard.

How to read this list (the real skill). These links are an entry door, not a blank check. Before adopting anything from a community source, run the seven-point checklist below — provenance, full reading, scope, pinned version, registry. The official bedrock is trusted; the rest is verified. Last verification of these links: August 2026 — and because the ecosystem moves every week, re-check freshness (last commit, recent stars) before any serious use.

Evaluating a third-party block: the checklist that closes everything

This is the moment the whole path converges. You have found a promising skill or server; before adopting it, one single checklist — and you will recognize every line, because each condenses a step:

Seven lines, ten minutes, and the entire path mobilized. This is where what you have acquired shows: each of these checks would have seemed abstract at the start; by the end, each is a reflex anchored to a precise reason. The rule that sums them all up: you do not adopt on reputation, you adopt on verification.

Establishing this discipline at an organization's scale — inventory, adoption checklist, living registry, tooled watch — rather than leaving it to each person's goodwill, is the passage from craft to governance. It is exactly the ground of our nAIvigate Studio engagements: turning these individual reflexes into a team process.

How to search, concretely

Having the right entry doors is not enough: you still have to know how to dig behind them. Three terrains, three methods.

On GitHub: read the signals, not the storefront

GitHub is the primary source, but a repository's landing page lies by omission — a nice README says nothing about the project's health. The good reflexes:

Sort the search by activity, not relevance. On github.com/search, after your query (e.g. MCP server notion), filter: Sort: Recently updated reveals what lives now, Sort: Most stars what marked the past. The two sorts tell two stories — cross them.
Refine with qualifiers. The search bar accepts precise filters: pushed:>2026-06-01 (recently committed), stars:>100, language:python, topic:mcp. A query like mcp server topic:mcp pushed:>2026-06-01 stars:>50 eliminates dead and anecdotal repositories in one shot.
Read the Insights tab. It is the hidden health report: commit frequency, active contributors, issue-handling pace. A 20,000-star repository whose activity graph has been flat for a year is a frozen repository — the step 6 signal, read in the right place.
Check the three pulses. Date of the last commit (is it alive?), open vs. closed issues (does the maintainer respond?), date of the last release (does the project ship?). Thirty seconds, and you know who you are dealing with.

In an "awesome" directory: Ctrl+F, then trace back to the source

A community list is a starting point, never a destination. The method:

Search within the page (Ctrl+F) by domain keyword — "notion", "postgres", "calendar" — to spot candidates. These lists are categorized: read your whole category, the gems are not always at the top.
Always trace back to the source repository. The directory says "this server exists"; it says neither whether it is maintained nor whether it is safe. The link takes you to the GitHub repository — and there, you apply the five glances above. Never judge a server on its line in a list.
Beware of duplicates and forks. The same server sometimes appears under several entries, including forks. Always prefer the original (the oldest, most-followed repository, the vendor's) over the "improved" fork — the provenance trap of step 6.

In the official registry: reliable search by namespace

The official MCP registry is the safest tool, because it authenticates the origin: each server carries a reverse-DNS name (io.github.user/server or com.example/server) verified against the real GitHub account or domain. Concretely, a server published under com.notion/… really comes from Notion — name-squatting is blocked at the root. You search by keyword as elsewhere, but the result carries a provenance guarantee that community lists lack. For sensitive uses, it is the first source to query.

💡

THE concept of this step — and of the path: in a moving ecosystem, the durable skill is the method, not the catalog. Knowing where to look (official to trust, community to discover, discussions to anticipate), sorting on the right signals (recent stars and living maintenance, not cumulative totals), and adopting no third-party block without the checklist that condenses the eight previous steps. A list goes stale; an evaluation reflex does not.

📚Going deeper

For the geeks: tooling your watch instead of enduring it. Three automations that turn a manual watch into a system. Repository tracking via API: the forge's API (the one hosting the repositories) exposes stars, commits, releases — a scheduled script that queries your reference repositories and alerts you to a star spike, a new tag or an abnormal silence (a too-old last commit) gives you the ecosystem's pulse without spending your days on it. It is the exact mechanism of this page's dashboard. Description diffing: for your critical servers, a job that periodically captures their tools' descriptions and flags any change — the countermeasure to the "rug pull" of step 8, automated. Cross-checking with the registry: matching the list of actually-plugged-in servers (host-side, if your tools expose it) against the declared registry — any gap is a Shadow AI candidate to investigate. You recognize the thread: it is step 8's supervision, extended upstream, from the workstation to the source repository.

📚Going deeper

For the geeks: the update hygiene of an adopted block. Adopting is not the end — it is the start of a relationship to maintain. Three rules. A version bump re-runs the checklist: a new version of a skill or server does not inherit the old one's trust (version drift, step 4); you reread the diff, at minimum the scripts and tool descriptions. The changelog is read before applying, not after an incident: a note "added an export tool" on a server that reads sensitive data is a chaining signal to re-evaluate (step 8). Revocation follows retirement: unplugging a block implies revoking its token target-side right away (step 6) — a retired dependency whose access survives is a forgotten door. A third-party block is a production dependency: it is managed as such, from adoption to exit.

The four pitfalls of watching and adopting: 1. ❌ Looking for THE list — any frozen list is stale in weeks; it is a method you acquire, not a directory 2. ❌ Reading the big numbers — the star total tells the past; recent stars and living maintenance tell the present 3. ❌ Confusing the sources — official, community and discussions have three distinct roles; mixing them means drowning or missing out 4. ❌ Adopting on reputation — "it is widely used" is not an audit; the seven-point checklist, systematically, before any adoption

🎓 The path is complete

Nine steps, one connecting thread held end to end — from "who does what?" to an agent that writes and distributes a meeting summary, secured and governed. You now know:

What a skill is and how to write, test, govern one (steps 1-4)
What MCP is, how to plug in, code and secure a server (steps 5-8)
How to find your way in the ecosystem and evaluate a block before adopting it (this step)

And above all, the thread running through it all: the model decides, the skill says how, the server supplies and acts — and at every link, you bound what can go wrong.

📍 Skills & MCP path — step 9/9

🗺️ The map before the territory
🔬 Anatomy of a skill
🛠️ Create your first skill
🏛️ Skills in the enterprise: governance
🔌 MCP: the protocol explained
⚡ Use an existing MCP server
⚙️ Build your minimal MCP server
🛡️ Secure your MCP servers
📡 The ecosystem: where to find, where it moves ← you are here

Did this path help? It condenses what our firm implements at its clients. To move from individual reflexes to team governance — inventory, security, AI Act compliance — discover nAIvigate Studio.

The Skills & MCP ecosystem: where to find, where it moves, how to evaluate